Repository navigation
Conversation
security/hashicorp.asc had lapsed on 2026-04-18, and nothing said so: gpg --verify returns exit 0 for a good signature made by an expired key, so every Terraform download kept verifying and the build kept passing while the expiry bound had quietly gone. The key still in use, re-fetched from the vendor, now carries a self-signature valid to 2030-03-01. Same key, later expiry: the primary fingerprint is unchanged (C874011F0AB405110D02105534365D9472D7468F), so the trust root does not move. Verified before committing — every SHA256SUMS signature in security/ still reports a good signature under the refreshed copy and no longer warns expired, including the 1.15.9 and 1.16.3 material added in #205. The one signing subkey that expired in 2022 is a rotated historical subkey and is carried by the vendor's own copy. security/awscliv2.asc is expired too, since 2023-09-17, and is not fixed here: AWS publishes its key only in the install guide, and that host is unreachable from a hosted session. It needs the maintainer.
The oracle could not see the condition that cost this repository its supply-chain guarantee. gpg --verify returns exit 0 for a good signature made by an expired key, so both vendor keys lapsed under a green build: hashicorp.asc for five months, awscliv2.asc for three years, neither reported by anything. An expired key is only visible from outside the verification it weakens, which is what this oracle is for. The assertion, per key under security/: the primary key is unexpired, and at least one signing-capable key remains unexpired. A rotated historical signing subkey is expected to be expired and is not a finding, which the vendors' own copies confirm. The pass line carries the earliest expiry across the keys, so the next lapse is readable before it lands. Fails closed, and amends ADR-0016 to record the cost: a vendor letting a key lapse turns --fast red on master until the copy is refreshed. That is the intended reading, not a false positive. Refs #152 (P2 candidate list, broadened here from the HashiCorp key to every key under security/)
This was referenced Sep 21, 2026
Owner
Author
|
Blocker: the AWS CLI key itself. It cannot be refreshed from an agent session — AWS publishes it only inline in the CLI install guide, and What unblocks it: the current key block from the install guide, committed to Staying a draft until then: ADR-0016's acceptance criterion is that Generated by Claude Code |
6 of 7 tasks
security/awscliv2.asc had lapsed on 2023-09-17, three years, and failed silently the same way the HashiCorp key did: gpg --verify returns exit 0 for a good signature made by an expired key, so every AWS CLI download kept verifying and nothing reported that the expiry bound had gone. Same key, later expiry: the primary fingerprint is unchanged (FB5DB77FD5C118B80511ADA8A6310ACC4672475C), so the trust root does not move; the self-signature now runs to 2027-07-01. Taken from the CLI install guide, the only place AWS publishes it. Verified before committing: the committed signatures for 2.36.49 on both published architectures report a good signature under the refreshed copy and no longer warn expired, checked against the real archives downloaded from awscli.amazonaws.com. The repo's copy was two generations behind. 2023-09-17, then the keyserver's 2026-07-07, now 2027-07-01.
bgauduch
marked this pull request as ready for review
September 24, 2026 14:32
bgauduch
added a commit
that referenced
this pull request
Sep 25, 2026
## Summary Both keys under `security/` had lapsed, and neither failure was visible: `gpg --verify` exits 0 for a good signature made by an expired key, so every download kept verifying while the expiry bound was gone. | key | was | now | fingerprint | |---|---|---|---| | `hashicorp.asc` | expired 2026-04-18 | 2030-03-01 | `C874011F0AB405110D02105534365D9472D7468F`, unchanged | | `awscliv2.asc` | expired 2023-09-17 | 2027-07-01 | `FB5DB77FD5C118B80511ADA8A6310ACC4672475C`, unchanged | Same keys, later expiries — neither trust root moves. Sources: HashiCorp's `/.well-known/pgp-key.txt`, and the CLI install guide for AWS, the only place it publishes one. The AWS copy was two generations behind: 2023-09-17, then the keyserver's 2026-07-07, now 2027-07-01. Verified before pushing: every `SHA256SUMS` signature under `security/` (1.14.9, 1.15.9, 1.16.3) and both published architectures' AWS CLI signatures for 2.36.49 report a good signature under the refreshed keys and no longer warn `expired` — the AWS archives downloaded from `awscli.amazonaws.com` for the check. `validate.sh --fast` green; `build-test` green on the full matrix. Unblocks #211, whose check now reports `PASS vendor keys in security/ are unexpired (earliest 2027-07-01)`. Roadmap phase / closes: Phase 3 — closes #106 P0 action 2 ## Breaking change None. ## Architecture Decision Record - [ ] This PR adds/updates an ADR under `docs/adr/` (link: ____) - [x] This PR is **not** a structural change — no ADR needed Key material only; no policy change. ## Checklist - [x] PR title follows Conventional Commits - [x] Commits are scoped and reviewable - [x] Docs / roadmap updated if behaviour or policy changed - [x] Docs point to their single home (no restated facts); intros/sections earn their space - [x] Touches only files within the declared phase scope
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
--fastfails when a key undersecurity/has an expired primary key or no unexpired signing key. Expired historical subkeys are allowed. The pass line prints the earliest expiry.The check exists because the tool it guards cannot report the condition:
gpg --verifyexits 0 for a good signature made by an expired key, so both vendor keys lapsed under a green build —hashicorp.ascfor five months,awscliv2.ascfor three years — and nothing reported it.PASS vendor keys in security/ are unexpired (earliest 2027-07-01), exit 0FAIL security/<key>.asc expired on <date>, run completes, exit 1.ascFAIL ... is not a readable OpenPGP keyBased on
fix/refresh-vendor-gpg-keys(#210), which refreshes both keys; GitHub retargets this tomasterwhen that merges. No longer a draft: with #210 in place the check passes, so ADR-0016's "always green onmaster" criterion holds.The function always returns 0 so one failure does not abort the run under
set -e; the other checks still abort, noted on #152 P2.Roadmap phase / closes: refs #152 (P2), #106 (P0 action 2)
Breaking change
None.
Architecture Decision Record
docs/adr/(link: ADR-0016, amended)The amendment records the accepted cost: the repository does not control vendor key material, so a vendor letting a key lapse turns
--fastred onmasteruntil the copy is refreshed. That is the intended reading, not a false positive.Checklist