[RFC] fail installs on publish-trust downgrades#891
Conversation
Proposes a `trust-policy` setting (off, warn, error) that warns or fails an install when a package's publish-trust level drops, for example from trusted publishing (OIDC) to provenance-only or none. The check runs per package, ordered by publish date, before any lifecycle scripts, so a malicious postinstall is gated rather than caught afterward by `npm audit signatures`. It adds `trust-policy-exclude`, a date-valued `trust-policy-enforce-since` that grandfathers the pre-provenance back-catalogue, `trust-lockfile`, and a one-off `--allow-trust-downgrade` escape hatch. It records the established trust level in `package-lock.json` and raises `ETRUSTDOWNGRADE` on a downgrade. The design follows pnpm's `trustPolicy` family, and the RFC surveys prior art elsewhere (Go's checksum database, NuGet trusted signers, PyPI, TUF, and more). Assisted-By: GitHub Copilot (Claude Opus 4.8)
|
This is a very bad idea. First of all, OIDC ("trusted" publishing) is one factor, so this is a fundamentally untrustworthy mechanism. Second, provenance provides no actual guarantees, and it is a perfectly legitimate decision for a maintainer to decide to stop publishing from CI or using provenance. Simply put, provenance is a misfeature that imo should even be removed, and implying it's a "trust signal" is dramatically shredding the security of the npm ecosystem. The best approach is to forbid any non-2FA publishing - meaning, everything either goes through a staged publish, or uses actual 2FA (iow, local publishing + 2FA, which prior to staged, is the only secure method of publishing to npm that has ever existed). |
|
Red Hat Miasma shows the gap in provenance-only TOFU: 32 @redhat-cloud-services packages republished through the existing CI/CD pipeline. Valid SLSA provenance on every malicious version. Trust level never downgraded — a TOFU check sees green. What actually broke: 32 packages in a 3-hour batch (normal cadence: weekly). Orphan commits with no parent vs. PR-based flow. New If |
|
I continue to wait for anyone to point to an actual npm security incident/campaign where provenance would have been a material barrier - in almost a year, the GitHub security team hasn't been able to provide a single one, and nor has anyone else. Relying on provenance before it would have been useful once ever in the history of npm, let alone in a significant number of incidents, seems like a massive waste of resources on security theater. |
|
Miasma is a sharp counterexample. SLSA was correct, and 2FA wouldn't have helped: the credential was the CI/CD's own OIDC token. The attacker pushed orphan commits to a repo with Anomalous in registry metadata alone:
None rely on OIDC or any identity signal. Behavior baselines on the package itself, a different axis from a TOFU check. Wiz: https://www.wiz.io/blog/miasma-supply-chain-attack-targeting-redhat-npm-packages |
3 participants
Adds an RFC proposing a
trust-policysetting fornpm install.It warns or fails when a package's publish-trust level drops, for example when a version that used to ship via trusted publishing (OIDC) or provenance is later published with weaker evidence or none. The check is trust-on-first-use: it only fires when a package that earned trust loses it, and it runs during resolution, before lifecycle scripts, so it gates a malicious postinstall instead of catching it afterward. It relies only on metadata npm already fetches (
_npmUser.trustedPublisher,_npmUser.approver,dist.attestations).Configuration:
trust-policy(off, warn, error)trust-policy-excludetrust-policy-enforce-sinceto grandfather the pre-provenance back-cataloguetrust-lockfile--allow-trust-downgrade.References
#860