Please include a lock file for reproducible builds / supply-chain hardening

[potiuk]

Hi! Thanks for maintaining this action.

I'm a maintainer of apache/infrastructure-actions, where we maintain an allowlist of GitHub Actions that ASF projects are permitted to use. Part of our review process is auditing each action (and each version bump) for supply-chain risk.

While reviewing a Dependabot bump from 23.0.0 → 23.1.0 (apache/infrastructure-actions#784), I noticed the repo doesn't ship a lock file (package-lock.json / npm-shrinkwrap.json).

Would you consider committing one? The reasoning:

• The action is bundled (dist/index.mjs via ncc), so dist/ is what actually runs at the consumer side. To audit it, a reviewer needs to reproduce the build and compare — that requires a deterministic dependency graph.
• Without a lock file, npm install resolves transitive dependencies at build time, so two builds of the same source commit can produce different dist/ contents depending on when they were built. That makes reproducibility (and therefore review) harder for downstream consumers.
• A compromised transitive dep at the moment dist/ is generated could be silently bundled into a release, with no signal to reviewers that anything changed in the source tree.

Adding a package-lock.json (committed to the repo) would let downstream auditors:

1. Pin to a known dependency closure for each released SHA.
2. Reproduce the dist/ artifact deterministically.
3. Catch unexpected transitive-dep movement via lockfile diffs.

If you'd prefer a different mechanism (e.g. npm-shrinkwrap.json, or pinning all transitives in package.json), that would also work for our purposes — the goal is just a deterministic dependency closure per release.

Happy to send a PR with npm install --package-lock-only and the resulting lock file if that helps. Thanks for considering!

[DavidAnson]

My experience with Node’s auditability provisions so far has not been positive:

• https://dlaa.me/blog/post/npmprovenance
• https://dlaa.me/blog/post/shrinkwrap

And I already pin direct dependencies:

• https://dlaa.me/blog/post/versionpinning

But your scenario seems legitimate. I will look into this, thank you.

[DavidAnson]

@potiuk, if I chose "pinning all transitives in package.json", how would you validate that? If I understand you correctly, I would (manually?) enumerate all transitive dependencies and list them as package.json/dependencies - but how would you check that I hadn't omitted one? (Either deliberately or by accident...)

[potiuk]

We can reproduce the build (we already do) and what we do we combine manual + AI review of all the changes coming from all pinned dependencies vs. previous build - with every update.

Manual review of minified javascript is practically impossible, but with pinned dependencies and node version it's absolutely possible to do reproducible build check - where you can look at source diffs. We also use cooldowns https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns - so that we rely quite a bit on a fact that the deps were out there for days and security researchers and other people who already do that job (many) could have a time to react.

Lack of package.json - makes it impossible, because essentiallly any time you run your action, latest version of deps are used - which means that you could use a dependency that was released 2 minutes ago. The Trivy Security Incident is a good example showing what could happen. Package.lock and dependabot upgrades with cooldowns mitigate a lot of those security risk.

[potiuk]

Also for more practical part -> You can look at our https://github.com/apache/infrastructure-actions/tree/main/utils/verify_action_build - we handle all kinds of action types and whate we do - we just try to reproduce exactly what the author did when they built their action. And we handle many cases (and we keep on adding new ones -when we see failures). In your case - this is the error we see https://github.com/apache/infrastructure-actions/actions/runs/25111602194/job/73586871370?pr=784#step:4:39 Mostly because at the time when you built the minified .js , some of the dependnecies you had were different than what you have now (and package lock does not freeze them)

[ppkarwasz]

Hi @DavidAnson,

My experience with Node's auditability provisions so far has not been positive:

• https://dlaa.me/blog/post/npmprovenance
• https://dlaa.me/blog/post/shrinkwrap

Thanks for the writeups, and I share your skepticism about NPM Trusted Publishing. It removes the long-lived token but doesn't replace 2FA with anything equivalent: an attacker who can trigger the configured release workflow gets a valid OIDC-bound publish without ever touching a second factor. For GitHub Actions the situation is even harder, since there's no separate publish step at all, and the released artifact is just a commit on a tag.

That's why we're trying to detect malicious releases by looking for deviations from a project's normal publishing pattern, similar in spirit to spam filtering. Two signals would help a lot:

• Locally signed tags. If tags carry a signature from a key on your machine (GPG, SSH), we can verify something a CI-token-stealing attacker doesn't get.
• A lockfile. As covered by @potiuk, committing package-lock.json lets us reproduce dist/ deterministically per release SHA, which is the prerequisite for any diff-based audit. It also lets us flag known malicious or vulnerable transitive deps. If they are present and actually reach code paths the action exercises (most don't), we can report those problems back to you.

TL;DR: We're not asking you to change how you publish. We just want to learn what signals to expect from a genuine release, so an attacker impersonating you becomes easier to spot.

[DavidAnson]

@ppkarwasz Thanks! I do not use GPG and want to keep things simple. Is signing using my SSH key acceptable? And does that work okay with multiple machines/SSH keys at the same time? And is it a problem that I do not back up my SSH key? In other words, is it enough that GitHub can verify the signature at push time, or must GitHub be able to verify indefinitely (i.e., I can never delete a registered SSH key from GitHub), or must you be able to verify signatures indefinitely (i.e., I need to share the SSH public key with someone other than GitHub and preserve it)?

https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key#telling-git-about-your-ssh-key

[ppkarwasz]

Hi @DavidAnson,

Signing with your SSH key works great for our needs. To answer your questions in order:

• Multiple machines / keys: fine, just register each public key in your GitHub account as a signing key too.
• No backup needed: also fine. We can rely on GitHub's verification result at push time, which is recorded on the tag object and exposed via the REST API (GET /repos/{owner}/{repo}/git/tags/{tag_sha} returns a verification object).
• Deleting keys later: also fine, since past verification results persist on the tag objects regardless of whether the key is still registered.

So as long as the key is registered as a signing key in your account at the moment you push the tag, we get what we need.

Signing tags also works around something I find odd about GitHub's permission model: a “fine-grained“ token with contents: write is enough to create commits, tags, and releases, but fortunately it cannot modify your SSH signing key. So a stolen token still produces unsigned tags, which is exactly the deviation we want to detect.

[potiuk]

TL;DR: We're not asking you to change how you publish. We just want to learn what signals to expect from a genuine release, so an attacker impersonating you becomes easier to spot.

Precisely.

[DavidAnson]

Yes, this all seems reasonable. :) I expect to publish a new release of the action in a few days with package-lock and an SSH-signed tag.

[potiuk]

Yes, this all seems reasonable. :) I expect to publish a new release of the action in a few days with package-lock and an SSH-signed tag.

Just a question - .... are you also going to submit package.lock as part of it ? Because otherwise we won't be able to verify the minified script were done from the sources that we see. While it would be great to see your signature, we also only trust reviewable sources.

In ASF we don't really even trust our release managers - when we we release our packages, we have to have 3 PMC members stating +1 - and in many of our projects this involves either looking at the packages and verifying that the sources there are the same as in Git tag, and in many cases also full binary reproducibility check - i.e. each of the PMC members has to build binary package from their own local git copy and it has to be bit-to-bit the same (or at least the differences have to be explainable).

[DavidAnson]

@potiuk, yes, I plan to include package-lock. (See the text you quoted. :) )

[potiuk]

🤦 ..... heh... read with understending Jarek :D

[ppkarwasz]

Thanks a lot! On our part, we'll implement logic in our check script to verify new releases are signed by you.