[BUG] pnpm trust policy violation

Is there an existing issue for this?

I have searched the existing issues

Current Behavior

 ERR_PNPM_TRUST_DOWNGRADE  High-risk trust downgrade for "semver@6.3.1" (possible package takeover)

This error happened while installing the dependencies of eslint-plugin-react@7.37.5

Trust checks are based solely on publish date, not semver. A package cannot be installed if any earlier-published version had stronger trust evidence. Earlier versions had provenance attestation, but this version has no trust evidence. A trust downgrade may indicate a supply chain incident.
Progress: resolved 299, reused 261, downloaded 0, added 0

Expected Behavior

no trust policy violation error

Steps To Reproduce

pnpm-workspace.yaml
trustPolicy: no-downgrade

Environment

npm:
Node:
OS:
platform:

I've also encountered the same problem just now, after I set trustPolicy: no-downgrade in my pnpm-workspace.yaml.

According to the similar issue for chokidar, we can use trustPolicyExclude to exclude semver@6.3.1.

paulmillr/chokidar#1440 (comment)

But I am not sure if semver@6.3.1 can be safely exclude.

That isn't a good setting to enforce in pnpm (it shouldn't even exist). Provenance provides no security value, and a change or removal of provenance simply does not indicate a security concern.

I'm not sure what you're asking here. Provenance is very new and 6.3.1 was published 2 years ago. This is something that pnpm is likely going to have to work out. It's likely going to have to take into account older versions at different locations in the tree, but I don't know for sure.

This is not a bug or security issue w/ this package. 6.3.1 was published before provenance was being used for this package.

chore: fix dependabot pipeline by adding exception to trust-policy is…

6.3.1 was published before provenance was being used for this package.

According to npm, 6.3.1 was published on 7/10/2023. Version 7.5.1 through 7.5.4 were all published prior to 6.3.1 and included provenance. This is why 6.3.1 violates the pnpm trust policy.

That policy is not valuable - it's perfectly legitimate for a maintainer to decide to stop using provenance. Just turn it off.

@ljharb

@ljharb I'd be curious to hear your reasoning, as this policy would actually have protected from the axios supply chain compromise a week ago. I agree that by itself, it means nothing, but it seems like a reasonable part of a good defense strategy against supply chain attacks.

@techied

@techied nope, it wouldn't have - because the axios attacker had full control of the maintainer's machine, including their npm and github accounts - so if this requirement existed, they could have published the same thing through an ephemeral workflow.

If it means nothing by itself it is never a reasonable part of a defense strategy :-)

@ljharb

@ljharb would it not have prevented the s1ngularity attack on nx? From their own postmortem

Our publishing process itself wasn’t breached, but the token let attackers bypass release pipelines. We detected this because the malicious packages lacked NPM provenance signing. Unfortunately, provenance doesn’t block unsigned packages from being installed, which is what happened.

@robert-westenberger-mpulse

@robert-westenberger-mpulse it would have blocked the specific mechanism they chose, yes - but since the attackers also had github access, they would have just published the malicious one with provenance from an ephemeral workflow. In other words, all it would have done is forced them to publish an attack that was even harder to detect.

@ljharb

@ljharb I see, I actually didn't know they had the whole machine.

In theory it would prevent against a scenario where only a maintainer's npm account was compromised, right? I guess it's relatively unlikely that only that would be compromised though.

(And thanks for taking the time to explain, I find that I need to know the "why"!)

@ljharb

@ljharb I'll admit I don't know a lot about npm provenance signing, or publishing from an ephemeral workflow - but wouldn't publishing from an ephemeral workflow require pushing a malicious commit to trigger CI/CD? Potentially requiring approval from other maintainers ( I have no idea about the particularities of nx's publishing workflow setup ), so that would require the malicious commit to survive merge approval into the protected publishing branch? Or is that all sidestepped completely with access to a single maintainers github account? I'm assuming forced them to publish an attack that was even harder to detect. would require a more sophisticated attacker, no?

Yes to pushing a commit, no to requiring approval, because it could go to any branch.

If the attacker has github and npm account access you are screwed and no technological barrier can stop them.

Navigation Menu

Repository navigation

[BUG] pnpm trust policy violation #838

Is there an existing issue for this?

Current Behavior

Expected Behavior

Steps To Reproduce

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG] pnpm trust policy violation #838

Description

Is there an existing issue for this?

Current Behavior

Expected Behavior

Steps To Reproduce

Environment

Activity

LuckyWindsck commented on Dec 29, 2025

ljharb commented on Dec 29, 2025

wraithgar commented on Dec 30, 2025

techied commented on Apr 3, 2026

ljharb commented on Apr 4, 2026

techied commented on Apr 6, 2026

ljharb commented on Apr 8, 2026

robert-westenberger-mpulse commented on Apr 8, 2026

ljharb commented on Apr 8, 2026

techied commented on Apr 8, 2026

robert-westenberger-mpulse commented on Apr 8, 2026

ljharb commented on Apr 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions