EXTENSION TRUST AND THE SUPPLY CHAIN

Extensions run arbitrary TypeScript on the user's machine, and anyone can publish to the registry. A registry is a distribution mechanism, not a quality guarantee — it tells you an extension exists, not whether it is safe to run. The trust model exists to close that gap by making trust an explicit, scoped decision rather than something implied by availability.

Trusted collectives

When an operative runs swamp extension pull @someone/something, they explicitly choose to download and execute code from that collective. But during swamp extension install, Swamp resolves dependencies automatically, and automatic resolution needs a boundary. That boundary is the trusted collectives list maintained per repository with swamp extension trust add.

Trust is per-repository because different repositories have different risk profiles. A production infrastructure repository that manages cloud resources should trust fewer collectives than a playground repository used for experimentation. A single global trust list would force the most permissive policy onto every context. The repository-scoped model lets each repo declare its own tolerance, and extensions from untrusted collectives still work — they just require explicit swamp extension pull rather than silent auto-resolution.

The reserved collective @swamp is trusted by default and cannot be removed from the trust list.

Auto-trust for membership collectives

swamp extension trust auto-trust true automatically trusts every collective the authenticated operative belongs to. This is convenient for teams that publish and consume their own extensions — there is no manual trust ceremony each time a colleague pushes a new version under the team's namespace.

The tradeoff is visibility. When auto-trust is on, the trust list is no longer a static declaration; it expands with the authenticated identity's memberships. In repositories managed by CI, where the authenticated identity may belong to many collectives, auto-trust can silently widen the resolution surface beyond what the repository owner intended. The default is off, and the recommendation for CI-managed repositories is to leave it off and maintain an explicit trust list.

Dependency trust scoring

The extension quality scorecard includes a dependency trust factor that audits every npm: import against OSV.dev for known vulnerabilities and the npm registry for deprecation status, license, maintainer count, and publish recency. Most of these signals affect only the quality score — a package with few downloads costs points but does not block anything.

The exception is the publishing gate. A deprecated package, or one with a HIGH, CRITICAL, or unknown-severity vulnerability, is a hard error that blocks swamp extension push. The reasoning is asymmetric risk: a single compromised or deprecated dependency in a published extension affects every repository that installs it. Catching the problem at publish time is cheaper than catching it across every consumer. The full factor list and thresholds are on the scorecard rubric.

Dependencies imported from jsr: are not audited because the jsr registry already enforces SPDX licensing, provenance, and a prohibition on install scripts — the npm-style gates would be redundant.

The "Verified by Swamp" badge

The badge indicates that the Swamp team has reviewed an extension for safety and correctness. It is separate from the automated quality score because the two answer different questions. The score measures surface-level quality that a publisher controls — documentation, type coverage, dependency health. Verification requires human judgment — does the extension do what it claims, is the author who they say they are, is the code worth running.

Most extensions do not carry this badge, and that is expected. An extension can score 100% on the automated rubric without verification, and a verified extension with poor documentation will still score low. The two signals are independent by design. More detail on how the badge and the score relate is in the scorecard explanation.

Yanking and deprecation

A published extension version can be deprecated or yanked. The distinction reflects intent. Deprecation is a lifecycle signal — the extension is superseded by something better, or the author no longer maintains it. A deprecated version is still pullable but flagged with a warning and an optional successor pointer. Yanking is a safety signal — the version was compromised, accidentally published, or contains a defect serious enough to warrant removal from normal resolution. A yanked version is removed from automatic resolution but remains downloadable by exact pinned version, because existing lockfiles should not silently break.

Both actions are reversible. Neither deletes the version from the registry, because the registry's promise is that a version, once published, keeps meaning what it meant. See the publishing reference for the commands, and the trust management reference for managing the trusted collectives list.

Related

• How Swamp Works — foundational concepts and architecture.
• About the Extension Scorecard — what the quality score measures and why verification is separate.
• Scorecard Rubric — exact factors, weights, and grade thresholds.
• Publishing Reference — yank and deprecate commands.
• Extension Management — trust commands.