[lrvick]

And once again calls to allow optional signing support natively to NPM will be rejected citing that it might intimidate drive-by devs who do not want to learn to setup a yubikey or nitrokey for artifact signing.

I have talked to the NPM team about this multiple times over the last several years and they literally believe no signing at all is better than some devs feeling pressured to sign.

You need no stronger evidence of the NPM teams negligence than these two times they refused to even accept community contributed optional signing support saying they would come up with something better than PGP. Still waiting 10 years later.

https://github.com/npm/npm/pull/4016

https://github.com/node-forward/discussions/issues/29#issuec...

Meanwhile PGP secures the supply chain of the Linux distros that power the whole internet, and Debian signs hundreds of npm packages used in their dependency graph, but it is still not good enough for NPM.

You can use the well tested and rust-written Sequoia/sq now and never touch GnuPG. You can also self certify your keys with keyoxide. The past complaints are largely moot and still people stick to their guns on this.

https://openpgp.dev/book/

[rkeene2]

This is the same NPM that made a change causing the `integrity` field to go silently missing from `package-lock.json` [0][1] when installing packages, and then also not complaining at any other time in the future.

[0] https://github.com/npm/cli/issues/4460

[1] https://github.com/npm/cli/issues/4263

[matheusmoreira]

The Debian PGP system is very impressive. Looks like the maintainers actually met each other, verified each other's identities and created the fabled web of trust.

https://wiki.debian.org/OpenPGP

> When joining the Debian project, developers need to identify themselves by providing an OpenPGP key that is signed by at least two existing members of the project.

[pcdoodle]

This PGP thing sounds pretty cool. What is recommended for getting started these days?

[feross]

This isn't quite accurate. In fact, npm did ship a form of code signing called 'npm provenance' in April 2023. We wrote a semi-official deep dive on the feature in cooperation with the npm team that explains how to sign your npm packages [1].

You can see npm provenance in action on this npm package page [2] if you scroll to the very bottom and look under the "Provenance" heading.

[1]: https://socket.dev/blog/npm-provenance

[2]: https://www.npmjs.com/package/@socketsecurity/cli

[lrvick]

I am sure virtually everyone understands "code signing" to mean what it has meant historically. The author of code signs git commits, or a tarball, or signing a package as in the debian, arch, guix sense. All of which typically share cryptography standards like PGP rather than rolling their own solutions.

Each maintainer has a signing key to identify themselves to the public without need for any central infra, and signs the packages they publish. Someone that accesses some centralized server or account will not be able to impersonate the key held by that developer or the signatures they issue.

This new provenance system and the fulcio system which it is based on, is a centralized setup where you use traditional, usually phishable, authentication with a SaaS, and then the SaaS takes your submission and signs it for you with a centrally managed keychain. Having done security auditing for many fintech signing systems, I can tell you I have almost never once seen anyone get this right, particularly when there is no accountability.

Is this done in a secure enclave with a public remote attestation of the software image running on it that I can locally compile and verify the matching hash of? Does that code enforce the participation of multiple distributed people to make updates, key exports, or key imports using shamirs secret sharing or similar?

Or maybe it is just sitting on an amazon box somewhere a few people ssh to from their daily driver macbooks ?

I don't -hate- centralized signing existing as an -option- if it is done very well and highly accountable (which fulcio is not, imo). That said, -mandating- centralized signing on behalf of developers as the only path is really insulting, as though people who write software can't type a couple commands to provision a PGP key on a smartcard and publish their key to keyoxide which is strictly better in every way from a threat modeling perspective.

Speaking of Fuclio, this was meant to "invent" a solution for container signing, even though PGP multisig has existed from the start. No one used it because none of the major players in container software documented it other than the podman team.

https://github.com/containers/image/blob/main/docs/container... https://docs.podman.io/en/latest/markdown/podman-image-trust...

Back to NodeJS, Debian and Arch already sign npm packages with PGP keys. It works fine. We need to let people actually do that with NPM. Tell me how many supply chain attacks have happened in Debian or Arch recently compared to NPM?

PGP may be a small barrier to entry, but it is a standard with solid smartcard support and works in practice. It should be the default recommendation to all developers, and end users should be able to set policies to only install packages signed by a trusted set of maintainer or reviewer keys.