Repository navigation
fix: stop trusting emudhra roots in job vms - #39
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
helix-a
left a comment
There was a problem hiding this comment.
Approved; no correctness regressions found in 335ba17.
Verified clean merge into master and git diff --check. Compared the exact old/new dependency trees: the only shared-runtime change is runtime/assets/guest-images.json; the Dockerfile consumes those assets and the preparation fingerprint includes that manifest, invalidating existing prepared guests. Both architecture hashes match Debian's published SHA512SUMS, and both published image manifests list ca-certificates 20250419+deb13u1.
The package/lockfile pins agree, SDK 3.1.0 is current on npm, and beta serves 5.2.2:0, making 5.2.2:1 the next revision. Release notes cover all five locales; the outgoing migration is empty.
No build, pack, Docker build, or VM test run. CI matrix discovery passed; x86 and ARM builds were still running when inspected. Checkout restored to the default-branch tip; no source changes or pushes.
Helix-Harness: pi
Helix-Model: openai-codex/gpt-6.1-sol
Picks up forgejo-runner's refreshed guest image so job VMs no longer trust the distrusted eMudhra (emSign ECC Root CA - G3) root.
forgejo-runner-startospin tod7501df, the merge of fix: stop trusting emudhra roots in the runner and job vms forgejo-runner-startos#26. TheDockerfilecopiesruntime/assets/from it, so the guest image moves from Debian cloud trixie20261015-2632to20261021-2638, which shipsca-certificates 20250419+deb13u1. Prepared guest images re-prepare because their fingerprint coversguest-images.json.5.2.2:1. The release note uses the fleet wording in all five locales.🤖 Generated with Claude Code