[naasking]

Signing won't help unless the end user specifies the signature or certificate that they expect (signing would only help ensure package upgrades are from the same author).

If you're going to have clients specify a signature anyway, then you don't need to sign packages, you just need strong one way hash function, like SHA-1024 or something. User executes "pkg-mgr install [package name] ae36f862..."

Either way, every tutorial using npm will become invalid.

[0x0]

"npm install packagename" could record the public key in package.json (or package-lock.json) on first save, and only accept installs (or upgrades) matching the same public key. Just like how android app code signing works, or similar to ssh known_hosts trust-on-first-use.

Granted it wouldn't save those adding a new package to a project the first time, but it would save the bacon of anyone re-running "npm install" in an existing project, for example during a deploy, or when trying to upgrade to a newer version of a given package.

[styfle]

Would that mean a package with multiple authors would have to shared the private key with each other in order to publish a new version?

[naasking]

> Granted it wouldn't save those adding a new package to a project the first time

Right, that's the real problem.

[no29]

independent site that maps packages to author certs that npm uses for verification at install time?

also, this is a problem that every package mgmt system faces. they alert on changes on upgrade but there's a requirement at the end user level to verify that at install time, the cert being trusted is the right one.