Skip to content

Add signed Windows Agent updates and versioned installation - #1316

Merged
AnthonyRonning merged 6 commits into
masterfrom
codex-win-update-maple
Oct 27, 2026
Merged

AnthonyRonning merged 6 commits into
masterfrom
codex-win-update-maple

Conversation

@AnthonyRonning

@AnthonyRonning AnthonyRonning commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

Windows Agent currently has a manual installer but no published update feed or native installed updater. This adds a clean Windows installation contract and a separate signed v3 feed, using the existing Agent keys, Azure signing workflow and protected publisher.

  • Install a stable signed bootstrap with immutable version directories. Commit updates by atomically switching current.json, retain the previous generation until authenticated startup, and restart with native argv and exact process identity.
  • Recover interrupted install/uninstall transactions, exclude concurrent mutation and executable mapping, reject unsafe DACLs/reparse points/archives, and preserve unknown files and user data. Existing-code startup uses local Windows trust; new payload admission retains chain/revocation verification. Storage accepts only the user/SYSTEM/Administrators authority set already trusted for writing. Unsigned Dev previews additionally require absence from local SHA-256/SHA-1 catalogs.
  • Produce and attest the updater tar alongside the signed NSIS installer. Extend exact producer qualification, independent platform manifests, reservations/signing/publication proofs, immutable routes and download analytics. Mac v1/Linux v2 contracts stay intact. No Windows legacy installation migration is included.
  • Add focused native Windows component tests and a separate opt-in, read-only verifier interoperability probe against an explicitly selected signed historical artifact. The latter never executes the selected PE.

Validation:

  • Native Windows run 40460420525, attempt 1: 83 passed, zero failed or ignored across both actual binaries (78 library + 5 bootstrap/reparse/native-argv). The harness verifies all 53 mandatory cases and uses --no-fail-fast without suppressing failures. Tested PR merge source: 30c7f6ec37fc656ebde0fa47a01d44485ea66db1; PR head: 3ea360dc7646ae190ecc7dcda3de6349299a58ad.
  • The separate app job in the same run passed cargo check -p maple-agent-app --all-targets --locked on native Windows MSVC / Rust 1.98.0, against that same tested merge source. This includes desktop application test targets; it does not produce or execute a release app.
  • 79 pinned updater tests on macOS; strict app Clippy for all default-feature targets; 30 Windows packaging tests; 49 shared packaging tests; 41 producer workflow tests.
  • 133 publisher tests; Worker formatting/typecheck/build and 46 tests/668 assertions, including actual workerd D1 migration preservation/rollback; 10 tracking-query tests; 640 repository hook tests; all 12 root Nix checks.

Native testing exposed and corrected Windows default-owner handling and catalog-signed-file classification in unsigned Dev admission. The original first failure and second failure remain recorded with their full logs. The second run's sole remaining failure was an invalid Unix-layout lock fixture; Windows public admission remains strict, with dedicated refusal and real lock contention/reacquisition tests.

The full Windows all-target build found two omitted Windows-only fields in desktop test fixtures; both are corrected. The latest focused run passed both native runtime tests and app/all-test-target typechecking. The full installer consumer, official Maple signature interoperability, signed installed A-to-B, visible GUI and composed paired-remote qualification remain pending. Broad workspace feature-matrix CI is not a publication claim.

Windows publication defaults off and also requires AGENT_WINDOWS_UPDATES_ENABLED=true. Keep that gate off until the native release qualification is recorded. The download-tracking 0002 migration must precede live Windows metrics; its guide preserves the existing database's manual migration baseline. This PR does not bump versions, publish packages, alter signing credentials or activate Windows delivery.

@AnthonyRonning
AnthonyRonning marked this pull request as ready for review October 27, 2026 06:43
@AnthonyRonning
AnthonyRonning merged commit 109188c into master Oct 27, 2026
45 of 47 checks passed
@AnthonyRonning
AnthonyRonning deleted the codex-win-update-maple branch October 27, 2026 06:51
AnthonyRonning added a commit that referenced this pull request Oct 27, 2026
#1316 (signed Windows Agent updates) landed while this branch moved the
Windows jobs. Carry its contracts over:

- agent-package-windows replaces the deleted PR-only windows-unsigned job,
  so it now exports MAPLE_PACKAGE_BUILD_NUMBER, which windows-release.py
  requires: the Actions run number, or 1 outside Actions (as
  package-release.sh does), so `just lane agent-package-windows` still runs
  locally.
- test_contracts C2 asks the publisher to trust a run with Windows too, and
  pins MAPLE_PACKAGE_BUILD_NUMBER to github.run_number on every job that
  packages or verifies Windows (the assertion #1316 added to the deleted
  test_agent_workflows.py).
- The manual signature probe checks that each Windows Prod job ran on
  windows-2025. The unsigned build now runs on Blacksmith, so the build job
  may also report blacksmith-8vcpu-windows-2025 (signing and verification
  still must be GitHub's). A new C2 contract runs the probe's producer check
  against this workflow's jobs and runners.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AnthonyRonning added a commit that referenced this pull request Oct 27, 2026
agent-windows-updater-tests.yml (from #1316) becomes the
agent-windows-updater lane, reported by ci-ok:

- Selected by the workflow's own paths on pull requests, the merge queue
  and master pushes alike, by ci:windows and ci:full, by CI edits, and
  nightly. Only the deleted workflow's own path is dropped.
- It runs scripts/ci/windows-app-typecheck.ps1, then
  scripts/ci/windows-updater-tests.ps1, unchanged, with pwsh from the
  repository root and the workflow's environment (RUSTFLAGS -D warnings,
  CARGO_TERM_COLOR never, no incremental build, no debug info). Both
  always run, as the two parallel jobs did, and either failure fails the
  lane.
- A special ci.yml job keeps both receipts and Cargo logs as one artifact
  even on failure. It uses setup-agent-windows, the pinned Rust, MSVC,
  native Perl and linker the workflow set up by hand, and restores no
  cache. The fxc selection is not carried over: GPUI compiles shaders only
  in builds without debug assertions, so a dev-profile cargo check never
  runs fxc.
- It runs on the Windows lane runner (Blacksmith, CI_WINDOWS_RUNNER to
  fail over) instead of GitHub's windows-2025. The native reparse fixtures
  need the symlink privilege, so this PR's own run is the first proof on
  Blacksmith.

test_windows_updater_workflow.py now tests the lane, the job and the
scripts instead of the workflow's YAML: no authority, the pinned toolchain
and no cache, selection through the planner, both scripts running (with a
stub pwsh) and the retained evidence. The script assertions are unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AnthonyRonning added a commit that referenced this pull request Oct 27, 2026
- agent-package-windows also runs on its own Windows inputs: the Windows
  packaging scripts, build-release.sh (its Windows branch), release-info.py,
  the release profile files and the Windows toolchain. #1316 put Windows on
  the Agent feed, and on master every Agent PR built, installed and
  smoke-tested an unsigned Windows package; label-only selection assumed
  Windows was not published. ci:package and ci:full still add it.
- test_contracts C2 evaluates each agent-desktop-build.yml job's `if:` and
  `needs` for a master push and a dispatch, so a condition that skips a
  Prod job the publisher requires fails the contract. Bare true, false and
  null evaluate as GitHub's literals.
- A new C2 contract runs every lane that calls windows-release.py package
  or verify with stand-ins and checks they receive MAPLE_PACKAGE_BUILD_NUMBER:
  the Actions run number, or 1 outside Actions.
- C7 also checks quoted or bold workflow display names in docs; updates.md
  named the deleted Agent Windows Updater Tests workflow and now names the
  agent-windows-updater lane.
- magic-nix-cache-action counts as a cache writer unless use-gha-cache is
  disabled. opensecret-eif.yml's eif job (fork PRs that edit approvals,
  manual runs outside master) is the one exempt pull-request writer: no
  FlakeHub, no id-token, branch-scoped cache. The workflow is unchanged;
  the cache docs now name the exception.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AnthonyRonning added a commit that referenced this pull request Oct 27, 2026
The first Blacksmith run of agent-windows-updater failed one native test:
the updater's storage validation rejects the test image because Blacksmith's
workspace inherits a foreign write ACE, which GitHub's workspace does not.
The validation is right, and #1316 proved these tests on windows-2025, so
agent-windows-updater and agent-full-windows (which runs the same tests) use
GitHub's image again. The Windows Clippy lane and the unsigned builds stay on
Blacksmith.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AnthonyRonning added a commit that referenced this pull request Oct 27, 2026
The Windows Clippy lane is the first CI job to lint #1316's Windows-only
updater code. Five mechanical fixes, no behaviour change: three collapsible
ifs (two as let chains), a range check written with RangeInclusive::contains,
and PROCESSENTRY32W built with its size in the initializer.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant