Relationships
#1593 Explore: transparency-log integration (Rekor) for extension signatures
Opened by webframp · 8/11/2026
Problem statement
Companion to #1592 (publish-time artifact signing). If extensions were signed at publish time, that signature is only as trustworthy as wherever the signing event is recorded. Logging to Rekor (Sigstore's transparency log) would make the signing event independently auditable — not dependent on the registry that also serves the artifact — which matters if the goal is to survive a compromised registry or maintainer account, not just a compromised transport.
This is one candidate idea, not a proposed requirement
Filing this to open discussion on whether transparency-log integration is worth pursuing, not to commit to Rekor specifically or to any particular hosting model. Depends on #1592 landing first, or at minimum being decided in principle — there is nothing to log without a signature.
Open questions (if pursued)
- Public Rekor instance vs. self-hosted: a public instance is zero-infra but means signing events are visible outside swamp's control; self-hosting adds operational burden but keeps the log private if desired.
- Failure semantics: if Rekor is unreachable at publish time, should publish block, retry, or degrade to unsigned-with-a-flag?
- Retention/GC: does a transparency log conflict with any existing yank semantics, i.e. can a yanked version's log entry be marked or does it stay logged forever by design (this is somewhat inherent to how transparency logs work and may not be swamp's decision to make).
Alternatives considered
- Skip the transparency log, keep signatures verifiable only via the registry serving the public key — simpler, but doesn't close the "compromised registry" gap, only "artifact tampered in transit."
Open
No activity in this phase yet.
Sign in to post a ripple.