Skip to main content
← Back to list
01Issue
FeatureOpenSwamp CLITeam
AssigneesNone

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."
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED

Open

8/11/2026, 3:25:29 AM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.