Skip to main content
← Back to list
01Issue
FeatureShippedSwamp CLIPublic
Assigneesskunk-ape

Relationships

#3354 Dependency trust scoring (CLI): yanked and loose specifiers cost one of the two dependency-trust points (no new push errors)

Opened by skunk-ape · 10/13/2026· Shipped 10/20/2026

Rule as shipped in https://github.com/swamp-club/swamp/pull/3236 (Seth, 2026-10-20), replacing the rule below:

  • 0/2: any error, deprecated-version, jsr-yanked or not-audited finding. jsr-yanked counts as a blocker.
  • 1/2: no 0/2 finding, but a loose-specifier on at least one dependency (one point however many).
  • 2/2: none of the above.

The shared vectors are in swamp src/domain/extensions/testdata/dependency_audit_vectors.json.


Part E (#3354, swamp; the registry half is swamp-club#3682, split 2026-10-20) of the extension dependency trust plan. Plan: Extension dependency trust plan (https://claude.ai/code/artifact/c333312a-ca26-4056-a7f2-cabd7f30457c).

Rescoped 2026-10-20 (Seth): no new errors, score points instead

Nothing becomes a push error. deprecated-version, jsr-yanked and loose-specifier all stay warnings that --yes accepts. The two-week window and the publisher notice aren't needed, so this can ship now.

Change

Scoring. The dependency-trust factor is 2 points, all or nothing today. It becomes:

  • A blocker loses both points, as today. Blockers are errors (HIGH/CRITICAL vulnerabilities, deprecated packages, missing JSR versions) and a pinned deprecated-version. Unaudited dependencies also lose both, as today.
  • A jsr-yanked or loose-specifier finding, with no blockers, loses one point (1/2).
  • The remediation text names which findings cost which points.

This issue changes the CLI scorer (push and quality): dependencyTrustBlockerCount and dependencyTrustRow in swamp src/domain/extensions/extension_rubric_scorer.ts, plus a count of yanked and loose findings from extension_dependency_trust_checker.ts. swamp-club#3682 makes the registry scorecard match. This issue settles the exact rule and remediation wording first and records them here, so #3682 can copy them.

Release notes say what changed. Versions already published aren't rescored (Seth, 2026-10-20, see #3629).

Acceptance

  • quality --json gives 1/2 on dependency-trust for a yanked dependency and for a loose one.
  • It gives 0/2 for a deprecated pin and for a blocker, and 2/2 when clean.
  • The test vectors are shareable with #3682, for example via testdata/dependency_audit_vectors.json.
  • A UAT item covers this. Its tests skip themselves until the binary has the capability.
  • The rubric docs are updated: in this change, or in #3631 if that lands later.
02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 2 MORETRIAGE+ 2 MOREREVIEW+ 7 MOREPR_MERGED

Shipped

10/20/2026, 9:40:02 PM

No activity in this phase yet.

03Sludge Pulse
skunk-ape assigned skunk-ape10/20/2026, 6:54:56 PM
Editable. Press Enter to edit.

skunk-ape commented 10/19/2026, 9:38:29 PM

Two scope notes from the manual work in swamp-club#3610 (PR https://github.com/swamp-club/swamp-club/pull/1382):

  1. Add jsr-yanked. A yanked JSR version only ships when it is pinned exactly or a lockfile holds it (resolution skips yanked versions otherwise), so the author chose a version its own author withdrew. Today it is a warning that --yes accepts and it does not cost the dependency-trust factor in either the CLI (dependencyTrustBlockerCount counts only deprecated-version besides errors) or the registry scorecard (lib/domain/scorecard/dependency-trust.ts). A deprecated npm version already costs the factor, and a yank is the stronger signal. Proposal: make jsr-yanked a push error alongside deprecated-version, and count it against the factor in both places. The manual (after #1382) already says deprecated-version and jsr-yanked become errors in a future release.

  2. Reconsider loose-specifier as an error. Refusing a pinned deprecated version, yes. Refusing every range or dist-tag specifier seems strict for an unclear benefit. The audit already names the version it resolved, and the lockfile pins what ships when one is honoured. The manual recommends exact pins but deliberately does not say loose specifiers will be refused. Whoever builds this should update content/manual/reference/extensions/publishing.md (Shipped-version warnings) either way.

Sign in to post a ripple.