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

Relationships

#1592 Explore: publish-time artifact signing for extensions (cosign keyless)

Opened by webframp · 8/11/2026

Problem statement

A supply-chain review of the extension publish/pull pipeline found that `swamp extension push` builds a tarball, runs local safety/quality/dependency checks, computes a SHA-256 checksum, and uploads to the registry — but nothing in the pipeline signs the artifact. `swamp extension pull` later verifies against a checksum served by the same registry that served the artifact, which is TLS/single-party trust, not independent provenance. If the registry or a publisher's account were compromised, a malicious artifact could be served with a matching checksum and nothing downstream would catch it.

The project's own quality rubric already names this gap — it references a "Sigstore-signed bundle verified by the server" provenance factor, currently gated off via a flag because "CLI-side signing support has not shipped."

This is one candidate idea, not a proposed requirement

This issue exists to open discussion, not to commit to an implementation. Adding cosign keyless signing at publish time is one possible path — there may be simpler or different approaches (e.g. maintainer-held GPG keys, leaning further on the existing OSV/npm audit gate instead of adding provenance at all) that would need less machinery. Filing this to get it on record and see whether the core team thinks it's worth pursuing at all before any design work happens.

Proposed solution (if pursued)

Sign the tarball with cosign (keyless, OIDC-bound to the publishing CI identity) immediately after archive creation and before the initiate/upload/confirm sequence to the registry. Log the signing event to Rekor (see companion issue on transparency-log integration) so verification doesn't depend solely on the registry that serves the artifact.

Alternatives considered

  • Maintainer-held long-lived GPG keys instead of keyless OIDC signing — simpler infra, but reintroduces private-key custody/rotation risk.
  • No signing at all, treat OSV/npm dependency audit as sufficient — doesn't address artifact tampering or account compromise, only known-CVE deps.
  • Third-party attestation service other than Sigstore — not explored yet.
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED

Open

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

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.