Define secure automatic local TLS onboarding for Docker Desktop #5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
The supported Foundry M0 Compose requires an operator-provisioned, publicly trusted, hostname-matching server certificate and key. An ordinary Windows/WSL2 user cannot complete a simple installation without manual certificate management. This is an unresolved product capability, not a claim that the existing TLS preflight is defective.
Evidence
On Docker Desktop 4.97.0 / Engine 29.9.2 / Compose v5.6.1 and WSL2, an isolated short-lived test CA, explicit per-client CA trust, and a temporary Compose override for SR
--tls-reload-ca-certandSR_HEALTHCHECK_CAenabled verified WSL and Windows Python HTTPS, health, admin onboarding, client authorization and persistence. This was not unmodified Foundry Compose acceptance. Windows Schannel could not establish revocation status for the test CA. No system trust store, DNS or global Docker settings were changed. SR source was209f7d39f3ecebbd1b98b11d7c44c63192fe50a4; test imagesha256:ddd839d4cf4712115dd44cac8c2c121fd2faf24a69b20fdc94f3119db8f9837dwas built with mutable dependencies and removed after testing.Scope and acceptance
Define the smallest supportable onboarding mechanism and its trust model before implementation: authenticated initial trust establishment for actual Windows/WSL browser and other clients, secure local name/SAN resolution, key custody and renewal/recovery, SR's distinct reload/health trust settings, and the first-admin exposure boundary. Compare a publicly trusted hostname/certificate path with an explicitly consented and verifiable local trust path; neither disabled verification, TOFU, silent system trust modifications, nor an unverifiable private-CA bootstrap is acceptable. Verify the chosen approach on standard Docker Desktop/WSL2, including negative hostname/CA cases and rollback. Preserve standalone SR ownership and use one canonical Compose; do not assume a new daemon, CA service, proxy, global host networking or installer framework is required.
Real authenticated inference, lifecycle and independent network reachability remain separate acceptance requirements.
Local TLS investigation (2026-10-31)
Foundry main
c8fd679e02e870e0545a082edd10c864d6a1d4ba; canonical SR develop209f7d39f3ecebbd1b98b11d7c44c63192fe50a4. An isolated Linux Chrome 153 profile under WSL2, with a one-day test CA installed only in temporary NSS databases and a test leaf withIP:127.0.0.1SAN, loaded an OpenSSL HTTPS page. Separate untrusted and wrong-host tests showed Chrome certificate errors. No global trust changes or certificate-warning bypasses. This tests Chrome/NSS and IP identity, not native Windows browser trust or the Foundry application. On Docker Desktop 4.97.0 / Compose 5.6.1, a disposable Alpine container accepted the canonical Compose numericextra_hostsentry; this did not test SR startup or health with numeric IP. Existing prior scoped Windows Python test used DNS localhost; Windows Schannel revocation status remained unresolved.A public CA cannot issue a publicly trusted certificate for reserved loopback IP; a public-DNS option therefore needs a controlled DNS name and issuance/renewal path. A per-installation local trust option avoids DNS but needs independently authenticated distribution and explicit consent, narrow and protected key custody, real Windows browser/Schannel testing, renewal, compromise recovery and exact removal. A fingerprint provided solely by the endpoint to be authenticated is not independent verification. No product private-CA bootstrap has been selected or implemented.
SR source inspection found first-admin setup has no separate claimant authority; TLS and Docker loopback publication do not prove first claimant ownership. Its form onboarding route warrants actual browser-origin testing. A potential concurrent bootstrap race exists because the identity absence check and the upsert are separate; this is source analysis, not a reproduced exploit. First-claim authority and atomic initial identity creation require source-owner assessment; no upstream contract was changed.
No code, system trust, DNS or production state was modified. Issue remains open pending a reviewed trust/authority design and target-host acceptance.
Follow-up numeric-IP test: an isolated copy of canonical Compose with temporary test-CA trust overrides started SR with
FOUNDRY_ROUTER_HOST=127.0.0.1, an IP-SAN leaf, andmake up. After granting UID 10001 read access to the temporary TLS material, the container reachedhealthy; verified scoped-CA HTTPS to127.0.0.1returned 200 and wrong-host verification failed. This updates the earlier statement that SR numeric startup had not been tested. The reused local image ID wassha256:4d8e92d9142d3800843f8e658b5caf80277b0e778cb73f3a2279b27fed06fad4; its source provenance is unverified. The test used a private-CA override and is not production trust onboarding or unmodified Compose acceptance. Test project, volume, network and temporary keys were removed; existing image preserved.Progress (not closure): PR #6 adds optional offline host-side verification of operator-provided TLS files, not trust establishment or automatic local TLS onboarding. Final PR head
d264df43f1467bccb720c44e9194edc5e02ca276passed 16 tests. A fresh independent GPT-6.1 Sol High security review and follow-up verified resolution of its two findings; both are COMMENT reviews, not approvals. PR remains open, unmerged. Source-owned protected and atomic first-admin bootstrap is tracked at Creatidy/scarcity-router#242.Native Windows browser/Schannel direct-leaf trust, explicit consent and exact removal, renewal/recovery and authenticated bootstrap remain unverified. No disposable Windows account/VM was established and no trust stores were changed. A per-user local CA or direct-leaf trust must not be selected as proven merely from scoped WSL/Python results. Existing public DNS certificate support remains an alternative, not zero-touch local acceptance.
Functional local-TLS candidate is now open as PR #7, not merged or accepted. It generates a local self-signed
127.0.0.1leaf and starts an explicitly selected isolated Compose project using scoped leaf trust for SR reload and health; it does not install OS trust, authorize first administrator, or implement renewal. Isolated target-host tests passed against an image built from SR commit0493ed2b1892be6df0f96fb227fc96c68186e229for the initial head, and 19 tests including collision/FIFO regressions passed for follow-upf7750a4using a local compatible image. GPT-6.1 Sol High review identified project collision and FIFO issues; fixes are submitted and independent follow-up review pending. Native Windows browser/Schannel trust, renewal/recovery, secure first-admin (#242), and production acceptance remain unverified.PR #7 merged as
bed7e1760115a755ed5853a8207484b413c21ec7; PR #6 merged as93a9664db15eb6ee4736d74bd44c46b615ac8cc0. The integration resolved only the Makefile.PHONYconflict and added a README clarification; reviewed TLS implementations were unchanged. Combined isolated suite: 26 passed, including actual Docker runtime tests. Forgejo automatically closed this issue when PR #6 merged; it has been reopened because these experimental capabilities do not satisfy secure automatic TLS onboarding. Windows/browser trust, protected first-admin authority, renewal/recovery and related M0 gates remain open.Isolated failed recreation and manual recovery (2026-11-01)
Foundry
93a9664db15eb6ee4736d74bd44c46b615ac8cc0, SRa1c9e78c335e1b6286e17c1455a3665fc83889ee(merged protected first-admin). A source-built SR image wassha256:af80c6529971484f3e8dc7235c478af499ab0a0bc5193fe9cc935130d2a454a2; its Python base resolved tosha256:aa943ce411423c7582288f18707ff66eddcbaeb510502d747a72aeb34f30d159. Cached build layers and mutable base tag/PyPI dependencies mean this is not reproducible release provenance.In a disposable project, actual
make local-tls-initandmake local-tls-upestablished verified HTTPS, protected first-admin and a working client credential. After removing only its router container, startup with an unavailable image and explicit adoption failed with make exit 2. Project counts (containers, volumes, networks) remained(0,1,1). Restoring the image and explicitly adopting recovered healthy verified HTTPS, the same named volume and TLS certificate, the administrator login, original client credential and identical client metadata. Unauthorized access was rejected and bootstrap replay returned 409. Counts recovered to(1,1,1); cleanup returned them to(0,0,0). Certificate SHA-256 wasA3A9B77A5D0C96C0B16E3C144EDC4D30D11B2F1C6DF4AA247C99F35592A95E96before and after.The claim and credentials were held in process memory/pipes and not printed or passed as command arguments. No product defect was observed. This demonstrates manual recovery for an unavailable-image failure, not automatic rollback, other failure modes, inference, persistent Windows browser trust, or M0 acceptance. Existing-resource inventory was taken after the image build: all recorded resources remained after project cleanup, before removing the test image; absence of a pre-build inventory means preexisting sharing of the built image ID cannot be ruled out. No trust store or host networking changes were made.
Controlled local-leaf replacement (2026-11-01)
Foundry main
5b3be4c1054e2966ca2916831de64b2097dd5ce4; canonical SR develop had advanced toebeee2abe7d2b44a3383053754a07d8d220d017e. The isolated experiment built a clean canonical SR checkout at the earlierf96d58e6d7d0fffdbe70476850d824efa5de2fb5as imagesha256:cc1241d9a728d34c730da16d6f25eaab072c2c717f4382551fd65cdfeb1bc8bc. Base image and Python dependencies were not fully pinned; this is not a reproducible release.Using separate protected leaf directories and the real
make local-tls-init/make local-tls-uppath, the test created an admin and client credential and switched from A to B through explicit project adoption. A SHA-256c6e20e3ba7bb7c311be0fbbed8cd8a215c6fd12351e2e9c4395f62e875f552f7; B SHA-256f255b013fcca252bf569e0d4277592085adf4cfe0c908abf30515717193ba1af. B-trusting HTTPS succeeded and A-only trust rejected B. The named data volume, admin session, client credential and captured admin/client state fingerprints were preserved.A separate invalid C directory combined A's certificate with B's private key.
make local-tls-upreturned exit 2 and the running B container's inspected identity, start time, image, mounts, port, network, volume and restart count were unchanged; authenticated checks still passed. Explicit adoption restored A, with A-trusting HTTPS succeeding, B-only trust failing, and the same volume and credentials retained. A separate fresh A-to-B run verified Docker health statushealthywith healthcheck exit 0 after B recreation; the original sequence had checked HTTPS /healthz but did not inspect Docker health status.Both disposable projects cleaned up their own container/network/volume (1/1/1 before to 0/0/0 after), certificates and harnesses. No system trust store, browser trust or DNS was changed. Unrelated resources were not globally inventoried, and shared Docker build-cache effects were not measured. No defect was observed. This demonstrates a manual, explicitly trusted replacement and recovery, not seamless renewal, automatic rollback, browser trust or M0 acceptance.
2026-11-01: Added a partial, read-only Windows prerequisite diagnostic in open PR #10, HEAD
836d804e8e12d6431307dcebe4144d1cdd135b48. It is not an installer, start command, trust mechanism or M0 acceptance. It creates no Foundry resources and does not alter system/browser trust. Native PowerShell tests using process-only encoded test input passed 5/5, but the documented-Fileinvocation from this WSL UNC path was refused by WindowsAuthorizationManager; no execution policy was changed. Existing TLS Docker runtime suite passed 4/4 against the previously source-verified experimental SR/MI image.A read-only Windows inventory found native Edge and Chrome and enabled accounts, but none explicitly designated and authorized disposable; Hyper-V VM enumeration was access denied, so VM availability is unknown. Persistent browser trust experiments require an owner-designated, authorized disposable account or VM. No browser or system trust changes were made.
Recommendation pending complete implementation: use an independently provisioned public certificate and controlled resolvable hostname where available, avoiding new local root authority. This is conditional and does not provide a simple default installation today. A per-installation Windows CurrentUser root CA would extend trust beyond localhost for applications consuming that store, requiring explicit consent, independent bootstrap, secure key custody, lifecycle/removal testing and an exact-HEAD Sol High security review before use. Direct leaf replacement would require re-establishing client trust. First-run installation, protected onboarding UX, measured fresh-Windows timing, browser trust lifecycle, and real execution remain unaccepted.
Windows first-run candidate is WIP PR #11, HEAD
b69983244d27475a182fa5aae4fbe907c043c141, not mergeable as a working workflow. On an earlier candidate, isolated native Windows-Filefresh startup and repeated existing-admin inspection passed against source-inspected SR14580f629f123bd079e1aa80651a454e9b3e9ce7; a separate explicit-trust client completed onboarding. Native interactive claim handoff and browser onboarding were not tested. Those positive observations do not apply to the current fail-closed HEAD.Independent Sol High review reproduced in private synthetic mount namespaces that Docker Desktop-style WSL aliases may bypass the original TLS directory's 0700 ancestry for a group member, and that current shared-path inode equality does not attest what key an already-bound container holds. This is not a demonstrated actual Docker Desktop exploit, but custody is unproven. HEAD now stops before project discovery/start/adoption/claim. Sol's narrow exact-HEAD review found no bypass of that blocker; it mitigates risk by disabling the workflow, not by solving key custody. The blocker does not protect the pre-existing
local_tls_uppath or previously exposed keys.Full candidate suite 59 passed, 5 skipped; positive-path unit tests mock away the blocker and are not end-to-end evidence. A secure usable approach to actual container-mounted key identity and host alias access, interactive claim handoff, browser trust, completion verification, normal start/restart and real execution remain open. No Windows trust settings, execution policy or global Docker settings were changed.
A Docker Desktop named-volume candidate is available behind the existing unconditional Windows custody gate in WIP PR #11, HEAD
0216477d4c0483fc3be63e2d99fc030e98a890f4. A transient isolated initializer creates the key inside a named local volume; an SR identity mounts it read-only. Docker Desktop tests found no WSL bind alias for this volume and an unprivileged WSLnobodyprocess could neither access the Docker socket nor resolve the volume backing path on this host. Docker and host administrators remain trusted; results are not a platform-wide isolation guarantee.Independent Sol High review covered
d31c6c502cfdaa7f261a53805e2c0d19bc419860and the narrow0216477leaf-policy fix. No in-scope P1/P2 bypass was reproduced; the CA:TRUE verifier finding was fixed and independently rechecked. The reviewer explicitly did not approve lifting the shared custody gate: the legacy bind path remains unresolved, and test-only managed startup did not establish independently authenticated trust, private interactive claim handoff, browser onboarding, or end-to-end acceptance. Partial initialization remains ambiguous and Docker helper timeout may leave a process to finish. PR is WIP and not merged; it does not block unrelated Foundry work. Exact-head full suite: 68 passed, 7 skipped; managed helper opt-in suite 6/6. No Windows trust stores or policies were modified.Managed-only proposal
33c1600544b12467c4301b7169910e9fe4f5c51cis pushed to WIP PR #11. Both managed activation and legacy WSL-bind startup remain disabled. The proposal uses a deterministic project-specific TLS volume, one-process local certificate confirmation, and refuses unattached/ambiguous volumes without deletion. Exact-head combined tests ran 82 (81 pass, 1 skip), including isolated Docker runtime; those managed-flow tests mock terminal consent and are not native first-run acceptance. A real native Windows-Filenegative invocation refused before resources or credentials, consistent with the disabled gate.A fresh Sol High review of the exact proposal is underway. Its preliminary finding is do not enable: foreground TTY checks alone cannot establish claim confidentiality against PowerShell transcription or terminal recording. No private interactive Windows terminal was established through the test tool, and browser trust remains unverified. PR #11 remains unmerged; no M0/M1 acceptance or production-ready first run is claimed.
Managed-only Windows proposal updated in WIP PR #11 at
229f04dafe3739c5f271b8b07bdf82be4473efe0. Both managed and legacy activation gates remain closed. The proposal discovers a project-specific Docker-managed TLS volume, refuses unattached/ambiguous state, confirms the public certificate through trusted local Docker control rather than HTTPS, and no longer asks the user to copy volume/nonce identifiers. A verified image ID is still required.Independent fresh Sol High review of
33c1600found the managed claim handoff unsafe to activate solely based on TTY checks. The follow-up at exact HEAD229f04dfound the separate just-in-time operator privacy attestation conditionally mitigates that design gap under an explicitly trusted, informed operator; it is not technical recording detection, gate activation approval, or native private-terminal acceptance. Unknown or mandatory recording requires declining; organizational monitoring must not be bypassed.Exact-head suite: 84 run, 77 passed, 7 skipped. At predecessor
33c1600, source-inspected Docker integration and native Windows negative guard checks passed, but the positive test called dormant internal flow with mocked terminal/consent. No genuine private-terminal claim delivery, enabled-entrypoint login, browser trust or M0 acceptance has been established. The API session has no demonstrably private Windows TTY. Test-owned prepared image and source checkout were cleaned up; global settings and trust stores were untouched.Managed-volume Windows startup candidate is now on WIP PR #11, HEAD
aa8aaffcdb500ede02af3f73b7d44478df340101. Fresh independent Sol High approved parent9e23e0fand exact-head test-only follow-up only for isolated non-secret target testing, not production or real-claim issuance; the legacy WSL-bind path remains blocked.On Docker Desktop/WSL2, the actual native PowerShell
-Fileentrypoint using production code9e23e0fand source-inspected SR14580f629f123bd079e1aa80651a454e9b3e9ce7imagesha256:2cad0f7228d0ae175b9d1eaecb2dc2a316c7a071bfa03fdc3f11a3182b5a76c2completed fresh startup, repeated invocation and same-container stopped recovery. Each returned status 2SERVER_RUNNING — ADMIN_ONBOARDING_INCOMPLETE, after verified pinned-leaf HTTPS and onboarding redirect, with no claim. The same certificate, TLS named volume and data volume persisted; recovery was healthy. Public certificate YES was a synthetic observable test input, not user trust consent. Invalid image was refused before resources. An initial test sent its input before WSL preflight and failed with EOF; synchronizing with the public prompt fixed the test driver without changing product code. Test-owned resources were cleaned.Native already-admin behavior, genuine private-terminal claim, browser trust, wrong engine and mismatched volume/mount cases remain unverified; negative identity tests are ongoing. Full current suite 86 run, 79 passed and 7 skipped. The image uses cached base/mutable dependencies, not reproducible release provenance. PR remains WIP and unmerged; this does not establish authenticated readiness, real inference, M0 or M1 acceptance.
Follow-up target-host negative checks on the reviewed
9e23e0fproduction code passed: a deliberately conflicting test-owned TLS volume was refused before confirmation without changing that volume or creating router/data/network resources; an unexpected stopped TLS-volume consumer caused refusal while leaving the router, consumer and volume unchanged. The initial overly broad Docker state comparison was inconclusive because volatile state changed; a subsequent stable-field comparison passed. Wrong engine and wrong mounted TLS volume were not tested natively. Test-owned fixtures were cleaned; no claim or trust/policy changes occurred. Current PR #11 HEAD is1155ebbabe7dc0ce4b51c432628771d8196f1a11; subsequent changes from the tested9e23e0fare test-only and README-only and were narrowly reviewed by Sol. The PR remains WIP and is not approved for production, real claims or merge.PR #11 merged experimental non-secret managed Windows startup only at Foundry main
23d94fb3af183faaacd6ca6f8a014be95cd47caa, reviewed headdbbdcf6975d556111a7e7a7f81ec2d4039669731. Fresh independent Sol High verdict for exact HEAD wasAPPROVE_EXPERIMENTAL_NONSECRET_MERGE; see review evidence. Managed first-run never issues administrator claims; legacy WSL-bind startup remains blocked. No M0/M1 or production acceptance is claimed.Prior native Windows
-Fileisolated fresh/repeat/same-container recovery passed verified pinned-leaf HTTPS withSERVER_RUNNING — ADMIN_ONBOARDING_INCOMPLETE, no claim, against9e23e0f; the only later production change removes managed claim issuance. At final head: 87 tests run, 80 passed, 7 skipped; corrected explicit-image managed Docker suite 15/15 passed. Wrong-engine refusal is covered by a mocked production-function test, while wrong TLS volume and unexpected consumer were rejected against real stopped Docker fixtures with inspected resources unchanged. No native wrong-engine test is claimed.Remain open: secure private-terminal claim issuance and administrator login; authorized native Windows browser trust lifecycle; identity renewal and trust removal; verified image distribution without manual IDs; actual authorized inference and the other M0 gates.
Protected first-admin onboarding investigation (2026-11-02)
Canonical Foundry main
23d94fb3af183faaacd6ca6f8a014be95cd47caa(current checkoutdbbdcf6975d556111a7e7a7f81ec2d4039669731, identical tracked tree); canonical SR develop10c3ea639280777847605c8f7132fff5a49ef09a. SR's supported local issuer prints a 15-minute claim on stdout; its HTTPS bootstrap endpoint consumes it atomically with administrator creation. This API contract does not itself establish the confidentiality of a Windows password-input and WSL subprocess path.This API session runs under WSL2 with Windows interop but has no demonstrably private, authorized operator-controlled native Windows terminal. The requested actual password-input behavior and protected native end-to-end interaction have therefore not been established. No credential-handling implementation was enabled, no claims or credentials were issued, and no code was changed. Existing regression suite: 87 run, 80 passed, 7 skipped; tests do not establish native protected onboarding. No new review or PR was requested because there is no proposed commit. Existing PR #11 approval is only for non-secret startup. M0 remains open.
Next: establish an authorized private Windows operator-controlled terminal and verify an appropriate no-echo input mechanism across the actual PowerShell/WSL boundary using synthetic credentials, including redirected/unsupported terminal refusal and recording limitations; then implement, test, and request independent exact-head Sol High review without relaying secrets through agent tools.