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-yankedornot-auditedfinding.jsr-yankedcounts as a blocker. - 1/2: no 0/2 finding, but a
loose-specifieron 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-yankedorloose-specifierfinding, 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 --jsongives 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.
Shipped
No activity in this phase yet.
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):
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--yesaccepts and it does not cost the dependency-trust factor in either the CLI (dependencyTrustBlockerCountcounts onlydeprecated-versionbesides 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: makejsr-yankeda push error alongsidedeprecated-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.Reconsider
loose-specifieras 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 updatecontent/manual/reference/extensions/publishing.md(Shipped-version warnings) either way.
Sign in to post a ripple.