WIP: Guarded Windows administrator onboarding candidate #12
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "issue/5-protected-admin"
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?
Related to #5. Work in progress: both protected-onboarding gates remain disabled. Do not merge or use with real credentials. This prepares a native PowerShell/WSL process protocol, protected password prompts, in-memory local SR claim issuance, verified HTTPS submission, and conservative recovery including a project-scoped inert reservation. Existing nonsecret managed startup remains available and legacy bind-mounted startup remains blocked.
PR acceptance scope
The supported target is Windows 11, Docker Desktop, one ordinary WSL2 Ubuntu distribution, the existing managed TLS volume, and SR's first-administrator contract. Cross-distribution testing is not a mandatory acceptance criterion; no additional distribution is required.
Acceptance requires: (1) explicit consent and password entry followed by successful administrator login without displaying the claim; (2) no intentional disclosure of password or claim through output, logs, arguments, environment, URLs or diagnostics, checked with synthetic sentinels and a positive control; (3) repeat launch detects the administrator without reissuing a claim or changing credentials, certificates or volumes; and (4) interruption or lost results are not treated as rollback, potentially committed transactions are not blindly repeated, and ambiguous completion retains a reservation for explicit recovery.
Previous exact-head Sol High reviews approved scoped synthetic experimental testing only, not gate activation, real credentials or merge. The PR discussion records prior synthetic native success, repeat and parent-death evidence, including an unclassified claim-shaped output observation. The uncommitted ACK correction has not yet been accepted as part of the PR HEAD. An exact-candidate independent review and bounded native synthetic validation remain necessary. Browser trust, real-credential activation, owner-operated acceptance and the remaining M0 gates are separate; #5 stays open.
Additional native synthetic entrypoint evidence
After the initial PR description, the actual Windows PowerShell 5.1 entrypoint completed two isolated synthetic runs from a temporary Windows-local copy of commit
455e9f0acf59f47e0d3534da652e3e151983941c, with only the two bootstrap gates toggled in that copy. A dedicated console helper verified its process list before injecting synthetic key events at the certificate, consent and two password prompts. The entrypoint reportedsubmittedand exited 0. Incremental console-screen samples showed password masking and did not contain the synthetic password; no 43-character claim-shaped token was detected outside the public certificate. The latter is a heuristic, not exact-claim comparison or proof against transient leakage.A separate verified, fingerprint-pinned HTTPS client observed unauthenticated
/control/state401, synthetic/control/sessionlogin 200 with a cookie, and authenticated/control/state200. No real secret or global trust/policy change was involved. The temporary copy and owned Docker project resources were removed after quiescence/identity checks. This does not establish native interruption, recording behavior, browser trust, private operator acceptance, or approval to enable the checked-in gates. Sol High follow-up was requested on this additional evidence; existing verdict remains synthetic-only until updated.Independent review follow-up
GPT-6.1 Sol High independently rechecked exact clean HEAD
455e9f0acf59f47e0d3534da652e3e151983941cand the reported native synthetic evidence. Verdict: APPROVE_SCOPED_SYNTHETIC_EXPERIMENTAL_TESTING, including disposable copies with only the two gates toggled. No new actionable P1/P2 was found under the stated trusted-host/Docker/image/operator assumptions; the original orphan-worker P2 is contained by reservation and recovery, not guaranteed cancellation. This is not approval to enable the checked-in gates for real credentials, general use, production or merge. The reviewer independently reran 106 tests (99 pass, 7 skip) but did not personally reproduce the native harness.Real-use validation still requires actual parent-death/orphan issuer and retained-lock retry tests, protected POST negative identity/TLS cases, native refusal/cancellation/Unicode/boundary cases, more complete synthetic claim-disclosure assertions, and separately accepted browser trust and operator privacy. Any gate-changing commit requires exact-change independent review. M0 remains unaccepted.
Native synthetic repeat and recovery
Further tests of temporary gated copies on the native Windows PowerShell entrypoint passed initial synthetic onboarding, repeated startup with an existing administrator, same-container stopped recovery, and consent refusal. Repeat and recovery prompted only for certificate confirmation, returned
already-configured(exit 0), and project-scoped Docker exec events showed no claim-issuer invocation. Container ID, data/TLS volumes, labels and leaf fingerprint remained unchanged; pinned HTTPS synthetic login and authenticated state both returned 200. Consent refusal returneddeclined(exit 1) and no claim issuer was observed. These were disposable projects; owned resources and copies were removed.Disclosure-test limitation: in the first run of this additional test, a screen heuristic flagged an unclassified claim-shaped token whose value was not retained. Its origin is unknown. A corrected repeat found no candidate, but neither that result nor prior screen sampling proves that the claim was never displayed. Exact synthetic sentinel comparison and transient-output coverage remain required. Consent refusal is not a Ctrl+C, parent-death, or in-flight interruption test. No real secrets or trust/policy changes were involved.
Synthetic Windows parent-death experiment
An actual native-console disposable test used a temporary gated copy with test-only pause/collision markers. After credential EOF and reservation retention, the Windows wrapper was forcibly terminated while its WSL worker was paused immediately before the real issuer. The worker remained alive. A second native attempt was refused with
recovery-requiredbecause Docker rejected the existing reservation name; it did not reach a password prompt. After the worker was released and exited and no router execs remained, verified/adminredirected to login and the reservation was gone. This is consistent with the original worker continuing and committing after its Windows parent died; it does not establish cancellation or reservation retention after the worker finishes. The result underscores the need for quiescence and administrator-state inspection before recovery.A separate test-only fake issuer used a deterministic synthetic sentinel: the exact sentinel was absent from sampled console output, the request failed as expected, administrator state remained unconfigured, and the reservation remained. This does not identify the earlier unclassified token or rule out transient leakage. No real secrets or persistent trust/policy changes were used; all owned fixtures and copies were removed after quiescence checks.
Security reassessment of parent-death evidence
Sol High reviewed the reported parent-death and sentinel experiments against unchanged HEAD. Verdict remains scoped synthetic experimental testing only, not general gate activation or real credentials; no newly demonstrated P1/P2. The result strengthens evidence that a concurrent native retry is blocked while the first worker holds the reservation. Later reservation removal after a successful completed transaction is consistent with the source, but the observation does not prove delivery of the result to Windows or cancellation. The earlier unclassified claim-shaped token remains an unresolved disclosure-test anomaly, not a confirmed leak or a proven false positive. Further issuer-output-loss, POST-response-loss, in-container orphan, cross-distribution, TLS-negative and complete synthetic-output/positive-control tests remain outstanding.
Scope reset and exact local-candidate review
The supported acceptance target is one ordinary Ubuntu WSL2 distribution on Windows 11 with Docker Desktop; cross-distribution testing is not a mandatory PR gate. The revised PR description records the four requested acceptance properties.
Independent GPT-6.1 Sol High reviewed PR HEAD
455e9f0acf59f47e0d3534da652e3e151983941cplus the existing five-file uncommitted binary diff SHA-256fa9f322e511d0e0701623e640c392365b573da5201e90730a8f9cb9898a87c72. It found no actionable P1/P2 under the stated trusted-host/image assumptions and assessed the ACK correction as addressing premature reservation release after a lost result. It approved only experimental merge with the gates disabled; not gate activation or real credentials. The owner explicitly does not want a disabled-only progress merge. The reviewer ran 118 tests (111 passed, 7 skipped); native exact-candidate validation and owner/browser acceptance remain outstanding. The prior unclassified claim-shaped output remains an unresolved observation, not a confirmed leak or proven false positive.The owner approved a bounded five-launch synthetic native test batch. It was not executed: the available tooling did not establish a controllable visible native console with bounded interruption, and the entrypoint rejects redirected console input. No test resources were created and no trust or policy changes were made. Both gates remain disabled, the local correction is not part of PR HEAD, and #5 and M0 remain open.
Superseded by the simpler owner-approved manual first-admin workflow in #13, merged as
8d4179b3197d0a3026c68951671980b97a1c7eb0. Closing this PR unmerged preserves its history; the existing local uncommitted work and separate rejected candidate are not being removed. Foundry #5 remains open for browser trust, certificate lifecycle, and complete installation acceptance.Pull request closed