Relationships
#3352 extension push: audit the dependency versions the bundle actually ships (pinned facts, deno info resolution, JSR existence)
Opened by skunk-ape · 10/13/2026· Shipped 10/19/2026
Part C (#3352, release 2, swamp) of the extension dependency trust plan (#3350–#3354). Plan: Extension dependency trust plan (https://claude.ai/code/artifact/c333312a-ca26-4056-a7f2-cabd7f30457c).
Problem
The push gate audits something other than what ships.
- Facts come from latest.
fetchNpmFactsreadsdist-tags.latestfor deprecation, license, maintainers and publish date. Only OSV uses the pinned version. So a pin to a deprecated old version passes, and a good pin fails when latest is deprecated. - Unpinned and range specifiers are guessed. With no version, latest is audited. A range (
^1.2) is sent to OSV as if it were a version, and can match nothing. - JSR is never audited. Every
jsr:dependency is marked passed without a lookup.
Change
- The pinned version's facts. Read
versions[<resolved>]for deprecation, license, maintainers and publish date. - What the bundle resolves. Run
deno info --jsonon each entry point, with the same config and lockfile settingsdeno bundleuses (src/domain/models/bundle.ts:--configwhen the extension has a deno.json, otherwise no lock). Audit those resolved npm and JSR versions. Each unpinned or range specifier gets a finding that names the version this push bundled. - JSR. The package and version must exist: missing is an error (the push would fail to resolve anyway). A yanked version is a warning. OSV has no JSR data, so there's no vulnerability check.
- Severity. A deprecated pin and an unpinned or range specifier are warnings in this release. #3354 makes them errors after a two-week window. A missing JSR version is an error now.
Depends on
#3350.
Acceptance
- Unit tests: a pinned deprecated version; latest deprecated with a good pin; unpinned;
^/~ranges; an exact version; a subpath import; with and without a deno.json and lockfile; JSR present, yanked and missing. - A UAT item covers the deprecated-pin warning, the range warning naming the resolved version, and a missing JSR version. Its tests skip themselves until the binary has the capability.
- Release notes, plus a notice to publishers whose latest version would block once #3354 ships.
Shipped
Click a lifecycle step above to view its details.
skunk-ape commented 10/19/2026, 2:51:14 PM
Re-scope (Seth, 2026-10-19): push will not run deno info to find the version that ships, because swamp is moving off Deno and this work must not deepen the dependency on Deno tooling. The shipped version is found instead, in order: (1) an exact pinned specifier is that version; (2) when the extension carries a lockfile, the locked version, read as data with no shell-out; (3) otherwise a range or dist-tag resolves from npm's package data to the highest published version that satisfies it, and an unpinned specifier means latest. Step 3 reuses the #3439 resolver and the packument push already fetches, so there is no second request. The resolution sits behind one small interface so the next platform's lockfile can plug in. Pinned facts, the loose-specifier warning and the JSR existence check are unchanged from the issue body.
Sign in to post a ripple.