[REQUEST] Consider provenance-backed patch releases for legacy v5/v6 lines

[fa0311]

Hi, would the maintainers be open to publishing no-code-change patch releases for the legacy v5 and v6 lines, for example semver@5.7.3 and semver@6.3.2, using npm provenance?

Context:

• semver@7.5.1 through 7.5.4 were published with provenance.
• semver@5.7.2 and semver@6.3.1 were published afterward without provenance.
• pnpm's trustPolicy: no-downgrade checks publish chronology, not semver major lines, so semver@6.3.1 is reported as a trust downgrade.

A provenance-backed patch release on the legacy lines would let consumers resolve within the declared dependency ranges without using package-manager-specific exceptions such as trustPolicyExclude.

Related issues:

• [BUG] pnpm trust policy violation #838
• no-downgrade should check the same major version pnpm/pnpm#10202

Thanks for considering it.

[ljharb]

Provenance is a useless signal, so doing a release solely to add it would be sending the wrong message.

It is 100% legitimate for a maintainer to start, and then stop, using provenance; it's also perfectly possible for an attacker to publish malware with provenance; as such, provenance disappearing is simply not an indicator of anything whatsoever.

[ranisalt]

It is 100% legitimate for a maintainer to start, and then stop, using provenance; it's also perfectly possible for an attacker to publish malware with provenance; as such, provenance disappearing is simply not an indicator of anything whatsoever.

You seem to grossly misunderstand provenance. It has nothing to do with security (judging by mentioning an attacker as the threat factor), but reproducibility and traceability of the code. Provenance doesn't attest "this code is safe", it attests "this is the code and how it was built".

While a maintainer can, there's little reason to stop using it once set up. Fine if you don't like it, just don't use it in your packages, but this is causing issues for everyone.

[ljharb]

All it attests is that a given GHA workflow published the package. It gives you no guarantees about the contents, or the reliability of the artifact, and after 3 months it's gone forever.

It adds no value, and relying on it as a supply chain indicator is a category error.

[roziscoding]

It gives you no guarantees about the contents

it attests that the artifact came directly from the repository code with a specific commit SHA, thus allowing users to inspect exactly what code generated the artifact.

giving you guarantees about the artifact contents is precisely what it does...

and after 3 months it's gone forever

it's really not. the GHA logs are gone, but you can still open the repo and inspect the commit a version was published from. the code is still there

[ljharb]

It only allows that for 3 months because that's when GHA logs expire; the packument already contains a git sha and that's been possible for 16 years; and that information simply isn't useful and wouldn't have stopped any incidents that have ever actually happened.

You can open the repo only if the sha still exists - which was also true long before provenance existed. It adds nothing, it serves no purpose, it has no value, and most importantly, it is not a trust signal and should never be treated as one..

[roziscoding]

It only allows that for 3 months because that's when GHA logs expire;

You don't need GHA logs to verify provenance at all. The proof is the signed attestation stored in the registry plus its entry in Sigstore's public transparency log (Rekor), which are both permanent. npm audit signatures verifies it years after the Actions run logs are gone; what expires at 90 days is the run log, which is a convenience, not the attestation. The source commit and workflow definition also stay in the repo regardless. Provenance isn't meant to prove trust, it proves origin: this exact binary was built from this source at this commit.

the packument already contains a git sha

Which is not signed nor tracked. It is entirely self reported and anyone that can publish a package can forge it. What's stopping an attacker that already has your token from cloning your repository, adding malware, then running npm publish? That would set the packument to the latest (genuine) commit SHA, but the published code would be malicious. The same thing is true for an ill-intentioned maintainer who could embed code in the package without ever making that code publicly available on the repo.

and that information simply isn't useful and wouldn't have stopped any incidents that have ever actually happened

That is simply not true.

Let's see an example:

1. Package foo normally publishes from GitHub Actions with provenance.
2. An attacker phishes or steals the maintainer's npm automation token (which is what happened with ua-parser-js, coa, rc in 2021 and Shai-Hulud / the qix phishing).
3. Attacker runs npm publish from their own laptop with a tarball whose postinstall contains a payload that was never in the repo.

Since the attacker's payload was not published from GH Actions, it does not have provenance (the cryptographic signature proving it was built from that code specifically). Anyone who uses that package and has provenance policies set up will skip that update, and might be alerted by scanners.

Now, if your package never had provenance to begin with, the attacker's tarball will just be a regular, valid version which, if published as a patch, is likely to be blindly updated anyway. The malware code never reaches the repo, it's way harder to audit because you don't have the source code and is way more likely to go unnoticed because inspecting tarballs is not as common as inspecting source code.

So, addressing your original points again:

It is 100% legitimate for a maintainer to start, and then stop, using provenance

It can be done legitimately, but it's meant to be taken as a red flag for a new release, prompting users to at least check with the maintainer if that is the intended outcome

it's also perfectly possible for an attacker to publish malware with provenance

It is, but not without going through the public repository, leaving a trail, and making the attack way louder.

provenance disappearing is simply not an indicator of anything whatsoever

This is also wrong. It is an indicator that there is no longer cryptographic proof that that specific tarball was generated by that specific code.

And you're right: it is not a trust signal when it exists, and it's not meant to attest to how safe the code is, or how genuine the maintainers intentions are or any of those things; it's simply meant to prove that a given binary was generated from a given source code, in a way that's public, traceable and auditable by the public and, thus, it's an important distrust signal when it goes missing.

Lastly, if you don't want to add it, it's your call. But saying it "proves nothing" is flat out wrong, and adding it only costs a one-time setup.

[ljharb]

It's true empirically - your example is contrived. Provenance absolutely could theoretically stop an attack, but there hasn't been any attacks of note that it would have stopped.

[ranisalt]

there hasn't been any attacks of note that it would have stopped.

[ljharb]

that principle doesn't apply here, because an attack that's stopped is something we still hear about :-) if provenance had never existed, precisely nothing would be difference with the state of security incidents in npm.