Repository navigation
Complete historical release-key records and verify consumer instructions #110
Copy link
Copy link
Closed
Labels
area: releaseSigned artifacts, release tooling, publication and custody.Signed artifacts, release tooling, publication and custody.documentationenhancementpriority: P2Planned maintenance; follow the ordered batch and documented dependencies.Planned maintenance; follow the ordered batch and documented dependencies.triage: readyScope reviewed; actionable within its batch, subject to the normal PR process.Scope reviewed; actionable within its batch, subject to the normal PR process.
Description
Reviewed 2026-09-25 (America/Los_Angeles) against main at bd249f5. Execution order and cross-issue ownership: #169. Batch 04.
This scope replaces the dated implementation prescriptions in the original report and earlier comments; linked historical evidence remains useful but must be rechecked before implementation.
Already complete
#156 added KEYS and release verification; #164 documented independent custody. The current project release key is 1C5F632B86809F2F5DB25092BEA0075F94074A9B, replacing the personal key used for 1.3.0–1.4.0. Do not label that historical personal key "current" or generate another project key for this issue.
Remaining acceptance criteria
- Establish the historical signing-key mapping from actual detached signatures for 1.1 through 1.4.0; authenticate full fingerprints using trustworthy historical/project records before adding archival public keys. Keyserver availability alone is not project authorization.
- Include/document historical keys and their validity/rotation periods, including the known 1.2.2–1.2.3 and 1.3.0–1.4.0 keys; report gaps honestly. Preserve all original artifacts and signatures.
- Verify consumer instructions with a fresh public-only keyring and full expected fingerprint. Distinguish a raw Maven checksum sidecar from a filename-bearing checksum manifest; provide commands that work for each format.
- Add discoverable README links to KEYS and verification via Rewrite the README and context guide, incorporating #114 and current 1.5 contracts #128. Explain PGP artifact verification separately from JAR signing; do not misstate either mechanism's guarantees.
- Retain the rule that new project fingerprints are recorded before first use. Operational vault drills/access remain Complete release readiness: Central 1.4.1 publication and independent maintainer recovery #111; future workflow automation remains Modernize release tooling and validate future releases without replacing 1.4.1 #95.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
area: releaseSigned artifacts, release tooling, publication and custody.Signed artifacts, release tooling, publication and custody.documentationenhancementpriority: P2Planned maintenance; follow the ordered batch and documented dependencies.Planned maintenance; follow the ordered batch and documented dependencies.triage: readyScope reviewed; actionable within its batch, subject to the normal PR process.Scope reviewed; actionable within its batch, subject to the normal PR process.
Activity
[-]Add a KEYS file and release-verification instructions[/-][+]Complete historical release-key records and verify consumer instructions[/+]jmanico commentedon Sep 26, 2026
Historical review in PR #185 establishes the full observed signing-key mapping for every Central core release 1.1–1.4.0. Original detached signatures verified in a fresh public-only keyring. Authenticated archival public keys for 1.2.2–1.2.3 and 1.3.0–1.4.0 are included, using the contemporaneous maintainer-owned OWASP Dependency-Check guide and this project's existing rotation record. Current project key unchanged. Consumer GPG full-fingerprint and raw checksum-sidecar commands were independently exercised by Sol.
Remaining evidence gap: independent historical/project authorization records for these first four observed fingerprints have not been found. Their signatures verify mathematically, but keyserver retrieval and matching identity text alone do not authorize archiving them as project keys:
37D880CD406BAD34CA2A8DD61845EF37A3B6533AAD0C981AEE36D3880512E28F5AD6F7C8740E3CF2C82AF58D3985677F9D575CEC9BC190E3DA071BD433F28D32BAB335D03EC5DAD6F7EBA8ECD6F22BFEAll four candidate keys are expired and remain outside KEYS pending a trustworthy historical record or explicit maintainer authentication. Cross-key signature inspection found only self-signatures, not an authorization chain to the already authenticated keys. Keep this issue open for that narrow gap; custody and Central staging/access remain #111.