PerishLab/plumb
1
0
Fork 0
Code Issues 11 Pull requests 22 Projects Releases Packages 1 Wiki Activity Actions

Make the npm evidence be the tarball, not the name #332

Open
PerishFire wants to merge 1 commit from task/npm-evidence-that-is-the-tarball into main
pull from: task/npm-evidence-that-is-the-tarball
merge into: PerishLab:main
Conversation 0 Commits 1 Files changed 6 +58 -28
PerishFire commented 2026-08-18 13:49:27 +00:00
Owner
Copy link

The module adaptor skipped publishing when pnpm view <spec> version answered — which proves only that something was published under that identity. After publishing it fetched dist.shasum and threw the output away, checking only that the command exited zero. The strongest claim the npm lane could make about a release was that the name exists: weaker than cargo, S3, oci and chart, and weaker than the changelog's claim about the same release.

The open question is now measured

decision rank 1 settled the shape: compare digests where the artifact is reproducible, fall back to a ledger check and say so where it is not. Which branch npm fell into was unknown, so nothing was done. It is known now:

fresh clone at v0.26.0 → pnpm install --frozen-lockfile → stamp → pnpm pack
  f9cdaed9b7eed312921bc86b7faa60302d78c44a
published
  f9cdaed9b7eed312921bc86b7faa60302d78c44a      identical

The first attempt did not match, and the delta was worth finding: key order in package.json. stamp parses into serde_json::Value, whose map is a BTreeMap, so it alphabetises the manifest in passing. Reproducibility rests on that, and rests on it by accident — enabling serde_json's preserve_order would remove it silently.

The change

carried reads dist.integrity (sha512, what an npm client verifies) instead of dist.shasum (sha1), and the digest is compared on both paths: before publishing, to decide whether the version standing there is this projection; and after, so the fetched digest is read instead of discarded. Either mismatch is published module drift — the same refusal oci and chart already raise.

Verified against the live registry without publishing anything: the same sha2/base64 call over the downloaded published tarball reproduces the dist.integrity the registry serves.

The module adaptor skipped publishing when `pnpm view <spec> version` answered — which proves only that *something* was published under that identity. After publishing it fetched `dist.shasum` and **threw the output away**, checking only that the command exited zero. The strongest claim the npm lane could make about a release was that the name exists: weaker than cargo, S3, oci and chart, and weaker than the changelog's claim about the same release. ## The open question is now measured decision rank 1 settled the shape: compare digests where the artifact is reproducible, fall back to a ledger check and say so where it is not. Which branch npm fell into was **unknown**, so nothing was done. It is known now: ``` fresh clone at v0.26.0 → pnpm install --frozen-lockfile → stamp → pnpm pack f9cdaed9b7eed312921bc86b7faa60302d78c44a published f9cdaed9b7eed312921bc86b7faa60302d78c44a identical ``` The first attempt did **not** match, and the delta was worth finding: key order in `package.json`. `stamp` parses into `serde_json::Value`, whose map is a `BTreeMap`, so it alphabetises the manifest in passing. **Reproducibility rests on that, and rests on it by accident** — enabling serde_json's `preserve_order` would remove it silently. ## The change `carried` reads `dist.integrity` (sha512, what an npm client verifies) instead of `dist.shasum` (sha1), and the digest is compared on **both** paths: before publishing, to decide whether the version standing there is this projection; and after, so the fetched digest is read instead of discarded. Either mismatch is `published module drift` — the same refusal oci and chart already raise. Verified against the live registry **without publishing anything**: the same `sha2`/`base64` call over the downloaded published tarball reproduces the `dist.integrity` the registry serves.
Make the npm evidence be the tarball, not the name
All checks were successful
guard / guard (pull_request) Successful in 2m53s
Details
d6d3c3be2b 
The module adaptor skipped publishing when `pnpm view <spec> version` answered,
which proves only that something was published under that identity. After
publishing it fetched `dist.shasum` and threw the output away, checking that
the command exited zero. So the strongest thing the npm lane could say about a
release was that the name exists — weaker than what cargo, S3, oci and chart
had already been saying, and weaker than the changelog's claim about the same
release.

Decision rank 1 settled the shape of this a while ago: compare digests where
the artifact is reproducible, fall back to a ledger check and say so where it
is not. Which branch npm fell into was unknown, so nothing was done. It is
known now, and it was measured rather than reasoned about:

    fresh clone at v0.26.0 → pnpm install --frozen-lockfile → stamp → pnpm pack
    f9cdaed9b7eed312921bc86b7faa60302d78c44a
    published                                f9cdaed9…   identical

The first attempt did not match, and the difference was worth finding: the only
delta was key order in `package.json`. `stamp` parses into `serde_json::Value`,
whose map is a `BTreeMap`, so it alphabetises the manifest on the way through.
Reproducibility here rests on that, and it rests on it by accident — turning on
serde_json's `preserve_order` would remove it silently.

So the strong check applies. `carried` now reads `dist.integrity` — sha512, and
what an npm client verifies for itself, rather than `dist.shasum`'s sha1 — and
the digest is compared on both paths: before publishing, to decide whether the
version standing there is this projection, and after, so the fetched digest is
read instead of discarded. Either mismatch is `published module drift`, the
same refusal oci and chart already raise.

Verified against the live registry without publishing anything: the same
`sha2`/`base64` call, run over the downloaded published tarball, reproduces the
`dist.integrity` the registry serves.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
All checks were successful
guard / guard (pull_request) Successful in 2m53s
Details
This pull request has changes conflicting with the target branch.
  • AGENTS.md
  • crates/cli/src/command/ship/adaptor/module.rs
  • plumb.toml
  • skills/plumb/SKILL.md
View command line instructions

Manual merge helper

Use this merge commit message when completing the merge manually.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin task/npm-evidence-that-is-the-tarball:task/npm-evidence-that-is-the-tarball
git switch task/npm-evidence-that-is-the-tarball
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
PerishLab/plumb!332
No description provided.