Support for PGP / Signatures

[ThisIsMissEm]

Currently the only means of trusting a package on npm is through the fact that the registry is immutable* and the usage of SRIs / tarball integrity checksums. Are there developments towards supporting package signatures via PGP or signify, or https://gossamer.tools/ for being able to verify that the tarball uploaded is the tarball the author published?

Sure, to attack this way would likely require an inside-actor at npm / github to modify the tarball & integrity checksum, so the attack surface is low, but for high security applications, this could make sense.

(npm ci already fails if the integrity sum is not valid, so as long as you commit a lockfile, you should be safe in majority of cases)

[ljharb]

Given that the author has to have to ability to change their public key(s) (in the case of revocation, and/or to have multiples), what would stop an attacker who otherwise has publish access from adding a new public key, and publishing with the new private key?

[ThisIsMissEm]

I think it'd be a matter of giving the npm cli a list of public keys you trust, and then checking that the signature / key is on that list, if a signature was present on the package; and then the author would separately publish their public key(s)

Much like a pgp signed git tag or git commit.

[ThisIsMissEm]

That is, the key infrastructure is outside of npm's control, therefore you can do sneakernet transfer of keys if you choose.

[ljharb]

I can’t conceive of how anything relying on sneakernet would be viable; the vast majority of npm operations are automated. As for “giving the npm cli a list of public keys you trust” - what happens when a maintainer does the perfectly legitimate thing of updating their public keys? If the answer is “the user checks to see if the author published it in hopefully a central place and not an arbitrary place”, then what stops the attacked from publishing the key?

It’s extra steps, but if an attacker has my npm credentials and can generate 2FA tokens, it seems unlikely that they lack any access i have.

Perhaps it’d be much simpler to find ways to warn/prohibit packages published without 2FA?

[paragonie-security]

Given that the author has to have to ability to change their public key(s) (in the case of revocation, and/or to have multiples), what would stop an attacker who otherwise has publish access from adding a new public key, and publishing with the new private key?

Doing so requires an existing secret key (which means game over for the developer/publisher of a module) AND creates an immutable record of the attack, which helps with impact assessments in postmortems.

[paragonie-security]

That is, the key infrastructure is outside of npm's control, therefore you can do sneakernet transfer of keys if you choose.

If you deploy something like Gossamer, you don't need sneakernet. Gossamer's public API looks like this:

const currentValidPublicKeys = gossamer.fetch_keys('vendor_name');

There's some configuration under-the-hood (local or federated trust, for data storage savings), but the entire point of Gossamer is Key Transparency and Distribution without a Certificate Authority.

[dominykas]

The signing of packages has been discussed so many times, that I don't believe there's any arguments that remain that would change anyone's opinions enough for this to get implemented natively in npm in whatever form.

That said, I've been pondering some ideas to get this implemented in userland. Someone who has the infrastructure to set up and verify signing keys, would maybe have the infrastructure to maintain whatever is necessary to publish things with signatures? I assume the general public ecosystem will not adopt this, not at the scale required anyways - so it's up to whoever needs this extra security to keep it maintained.

As for implementation - at its simplest, I figured that an author could just attach the signatures on the Github Release? I doubt there'd be a place for any of the new metadata anywhere on npm (packument or else).

If there was a convention, then maybe there'd be an option to at least discuss some hooks in npm cli, which would allow intercepting packages to verify signatures before extraction?

[ThisIsMissEm]

The way I would see npm support this is to just add an additional in the packument / package.json, so signatures would exist in a common standard place, and then have a way for userland signature implementation to easily plug in to verify that. That is, discussing public key / private key infrastructure is out of scope.

An additional change could be to the registry website to highlight when packages do have signatures published.