I am very surprised that a package manager of this calibre and impact abstains from best practices when it comes to authentication through code-signing. Other package managers are miles ahead of NPM. For example, Nix, which uses immutability and hashing to always produce the same artifact, regardless of changes of the sources.

So I know rpms and debs are signed, as I've setup repos for both. Docker repositories require a valid SSL key (or you have to manually allow untrusted repos). But do Python packages and Ruby gems have signature verification? How does pypy/pip and gem deal with validating a package is what it claims to be?

Ruby gems can be signed but the percentage of gems authors taking advantage of that is low.

At least we’ve got most people using https to transfer gems now!

PyPI (which is what Pip uses) at the very least does not require authors to sign their packages. I can't say whether it supports signing though.

Traditional python packages support GPG signing: https://pypi.python.org/security

There's new experimental signing in wheels: https://wheel.readthedocs.io/en/stable/#automatically-sign-w...

and the signing defined in PEP: https://www.python.org/dev/peps/pep-0427/#signed-wheel-files

comparing distro package managers is a ton different than free for all spaces like packagist, ruby gems, pypi, npm, etc.

You have a point, but we need to take into account that the technology has been around for a long time, the risks are well known and documented, and safety concerns of most of these package managers have been addressed to maintainers.

The example in the article has come to light accidentally, but we must seriously ask ourselves how many incidents are currently unidentified.

Besides, you can use Nix for 'normal' development. It is suitable for more things than just a distro package manager.

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.

"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.

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?

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

Right, that's the real problem.

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.