mirror of
https://github.com/okieselbach/AutopilotMonitor.git
synced 2026-10-24 04:32:32 +00:00
Oliver Kieselbach
21ec5e4773
Every assembly we author -- AutopilotMonitor.Agent.exe, AutopilotMonitor.SummaryDialog.exe and the three AutopilotMonitor.*.dll beside them -- is signed with AzureSignTool (pinned 7.0.1) against a certificate in the corporate code-signing Key Vault, SHA-256 file digest plus an RFC-3161 timestamp. Third-party assemblies keep their own publisher's signature. The position of the step is load-bearing: signing rewrites the PE file, so it has to run before the staging copy, the ZIP and every SHA-256 in "Create release artifact". Those hashes are the bootstrap's integrity oracle (version.json, AdminConfiguration) -- signing after hashing would publish hashes that no downloaded file can ever match. The signing identity is a SECOND federated principal in the same tenant and logs in FIRST, only to fetch a Key Vault token; the storage login of D-222 follows and owns the az context from there, because azure/login sets the default account and the last login wins. Both federated credentials carry the subject repo:okieselbach/AutopilotMonitor:ref:refs/heads/main, so this job must never be given a GitHub 'environment:' -- that rewrites the OIDC subject claim and would break BOTH logins at once. No unsigned fallback and no dispatch input to skip signing: a missing repository variable, a Key Vault failure or a non-zero azuresigntool exit code fails the run before anything is published. azuresigntool is a native tool, so $LASTEXITCODE is checked explicitly -- PowerShell does not throw on a non-zero exit, and a silently unsigned release is exactly the outcome signing exists to prevent. Verification runs against the STAGED bytes, not the build output: every AutopilotMonitor.* PE in the ZIP must be Valid, must carry a timestamp (without one the signature dies with the certificate) and all of them must share one signing certificate. Setting the optional repository variable CODE_SIGN_EXPECTED_SUBJECT additionally pins the publisher, so the gate proves "signed by us" instead of "signed by someone trusted". The build provenance attestation now covers the ZIP and both EXEs, so an extracted binary can be verified without the ZIP. Authenticode and the attestation answer different questions and both stay: who published this binary (offline, what Windows, SmartScreen and WDAC evaluate) versus which build produced these exact bytes (gh attestation verify). Not covered here: the customer bootstrap script (its signature block changes the published bytes and must follow the dev render; see B-57c, the two-stage loader), the bootstrap MSI, and the local build.ps1 path, which from now on produces unsigned bits. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>