[cyphar]

The problem is that users downloading the package can't verify that the developer used TOTP to publish. Really, it takes minimal effort to make and use a GPG key.

You can write a fairly basic script to automate the signing of stuff as well. Here's an example (it even signs the source archive): https://github.com/openSUSE/umoci/blob/master/hack/release.s...

[pilif]

> can't verify that the developer used TOTP to publish

they can if npm enforces the usage of TOTP for publishing.

As a user who uses both a GPG key to sign commits and a 2FA token to authenticate to all sites where this is possible, I can assure you that dealing with TOTP token is more fun than dealing with GPG keys.

[cyphar]

> they can if npm enforces the usage of TOTP for publishing.

So what is going to happen to all of the packages published before TOTP is turned on? Not to mention that there have been many cases where second-factors have been bypassed (even Google's authentication[1]). Which means I'm forced to trust that there are no exploits in NPM's authentication system, as opposed to trusting that PGP signatures are not broken. I know which one I would bet on.

As for dealing with PGP keys, come on. We all know that GPG's interfaces are bad for normal users, but all it takes to be able to sign things is:

  % gpg --generate-key

And answering the interactive prompts. There are many tools that wrap this functionality as well. Once you have a key you can just write a single script and then re-use it (I would expect that NPM would also publish said script to make it even easier). I'm sorry, but if you are trying to develop software for other people to depend on, I expect you to have enough technical literacy to be able to run two commands and read some documentation. It's really not that hard.

[1]: https://shubs.io/how-i-bypassed-2-factor-authentication-on-g...

[pilif]

>So what is going to happen to all of the packages published before TOTP is turned on?

same as what happens with all the package that were uploaded before the hypothetical GPG support was added to npam an packages could be signed.

>Which means I'm forced to trust that there are no exploits in NPM's authentication system

with signatures you are forced to trust NPM's authentication system to make sure that nobody has stripped a signature of a published package or changed the signature of an existing package.

Alternatively, it's up to you to keep track of all previously used signing identities of all your dependencies and to manually check the whole dependency tree if any of the keys in the tree have expired and been replaced.

> but all it takes to be able to sign things is[…]

unless you have more than one machine. If you do, you have to sync your keys between machines and just putting ~/.gpg on Dropbox (which would be ok as the keys are encrypted) won't do because there are still two maintained forks of GPG out there that work differently and require different config settings.

> And answering the interactive prompts

of which depending on GPG version some give bad advice with regards to key compatibility and strength and none of these prompts will help you deal with an expired key in the future (and yet, these prompts recommend you create one that expires after only a year).

Just stating `gpg --gnerate-key` as the complete solution will put people in position where in case of an emergency release they won't be able to publish that release because of previous administrative failure. That's a risky proposition.

And finally, the same malware that steals your 2FA token can also steal your ~/.gnupg and the passphrase once you enter it.

What I'm getting at is that gpg is actually significantly harder to use and maintain for users, requires significant updates to npm on both the server and client end, will cause false positives due to key changes and doesn't provide much more security than enforced 2FA authentication for publishing packages which would just require a small server-side change.

I get that you personally are totally willing to deal with a the maintainer's key of a dependency of a dependency of a dependency of yours having expired and thus being replaced with a new key and I also totally get that you yourself are willing to manually check the signatures of the whole dependency tree for changes (you're not willing to trust NPM itself as a public key repository, I get that, so you'll have to manually keep all previously used public keys around), but don't expect this same due-diligence from everybody else.

Once you trust NPM.com to manage identities (which is the only way to halfway conveniently deal with key rotation), everything hinges on NPM's authentication system again and at that point we're back to square one.