First, "thank you" then some ideas :-)

[lirantal]

Daniel, we meet again, one more time on security topics 😍
So yes, first, a big thank you for putting this one out!

Some general observations and thoughts:

1. Would you consider a version of this GitHub Action as an npm package that will take a package name + version (or tag) and return the outputs per the way this action works? The idea being that it can be run programmatically (and not requiring a lockfile). If so, I'd happily use this for npq instead of sigstore dependency (which adds quite a bit of nested deps tree). You can see the implementation at https://github.com/lirantal/npq/blob/main/lib/helpers/npmRegistry.js and https://github.com/lirantal/npq/blob/main/lib/marshalls/provenance.marshall.js
2. The verification only checks one version back?
3. Continuing from (2), if an attacker publishes 2 malicious versions then basically the "before" is without attestation and the new is also without attestation and potentially bypasses the provenance check if I understood correctly on how you compare here.

[danielroe]

For 1 - I'd love to! It should be very simple to do so.

For 2 & 3 - this action compares the previous versions in the user's lockfile. So it doesn't matter how many versions an attacker publishes.

[lirantal]

The lockfile-based comparison makes total sense but I was pointing out that concern in the context of if you'd built a generic package/API that doesn't rely on a lockfile and runs "standalone". For example, imagine you just install a new package "npm install xyz" and in which case a lockfile entry doesn't even exist yet.

I was thinking it was ok to look back a few versions and perhaps pick one that isn't very recent so that with a bunch of heuristics it would be ok to figure out and avoid attacker intents but I was concerned that while for a few packages this might work, to traverse your entire dependency tree it might be a bit costly in terms of HTTP requests/responses and you'd have to get around rate limits on the npm side too.

If you end up building the package out of the GitHub Actions workflow I'm really looking forward to put it into npq and we can perhaps iterate on it from that point more.

[Drarig29]

I would also be interested in moving the lib of this github action into an NPM package, which could either be used as part of @antfu/install-pkg as a new option to require the installed packages to have provenance and a trusted publisher, or as a separate step otherwise.

This project is neat!