GeezerVison

The regression

A clean scan --mode vendored run on a real 2019-era yarn-classic monorepo (strapi 3.6.8) failed 14 of 62 patchable packages with vendor_fetch_failed: no usable hash in SRI 'sha1-…' — all npm-era packages whose lockfile entries carry only legacy integrity sha1-… ([email protected], [email protected], [email protected], [email protected], …).

verify_sri (registry_fetch, #115) ranks sha512/384/256 and refuses everything else. The path only triggers when the prebuilt-artifact service misses (e.g. freshly rotated patch UUIDs) and the local-build fallback fetches the pristine registry tarball — which is why earlier runs, served entirely from the service, never hit it.

The fix

sha1 joins the ranking at the bottom — never preferred over sha256+, used only when it's all the lockfile records. That's the exact guarantee the package manager itself enforces for those entries, and the same trust decision the LockIntegrity::Sha1Hex bare-hex arm already made in this file. md5/unknown algos stay refused.

Tests

New unit test pins all four properties: sha1-only verifies; sha1 mismatch refuses (not fail-open); sha1 never outranks a stronger hash in multi-hash SRIs (wrong-sha512 + right-sha1 fails, right-sha512 + wrong-sha1 passes); md5 still refused.

End-to-end validation (real monorepo)

Rebuilt and re-ran the clean vendored flow on the strapi repo: all 14 previously-failing packages now vendor (scan exits success, 62 wired lockfile entries), and [email protected] install delivers 62/62 packages byte-identical to their patched blobs.

🤖 Generated with Claude Code