No, NPM does not have a GPG signing.

There was once a PR open, but it was rejected after sitting idle for over a year.

Yes, you read that right.

https://github.com/npm/npm/pull/4016#issuecomment-76316744

Somehow people in the ESlint thread were defending the fact that NPM seems totally uninterested in this.

Yes, it doesn't solve all the problems and yes you still have to determine who to trust, but at least it makes it POSSIBLE to trust anything. Currently it's impossible to trust anything that you install—and packages can run arbitrary, unsandboxed code with access to the full filesystem when they are installed. That just seems insane to me.

How would GPG signing help? If someone can execute arbitrary code on your computer as your user account, the game is over, you are totally owned. An attacker can simply start signing their package with your GPG key. Since you are probably in sudoers, unless you have superhuman carefulness, they can also get root.

What you'd want is for the owner/maintainer to sign the code, rather than the repository. This wouldn't protect you against a malicious maintainer, but it would help in a case like this as long as the signing key or the maintainer's device isn't compromised along with their credentials. That would definitely raise the bar for attacks of this nature.

    Alice installs malicious eslint.
    Attacker has control of Alice's machine and signs a malicious version of Alice's package using Alice's key.
    Attacker publishes a new version of Alice's package.
    Bob installs Alice's (malicious) package.
    Attacker has control of Bob's machine and signs a malicious version of Bob's package using Bob's key.
    Attacker publishes a new version of Bob's package.
    ...repeat

IMO signing could only work if it were combined with 2FA so that each time a package is signed, the signing operation is verified by the user on a second device. Otherwise it doesn't really impede a worm significantly because the nature of this attack is that the maintainer's primary device gets completely owned. We are all very lucky that the eslint attack only stole npm credentials instead of installing rootkits.

In this attack, the maintainer's primary device was not owned. The maintainer's npm account was breached due to a reused password. Code signing would mitigate this because the attacker would be unable to release/sign a malicious version of the package.

Building a system that is immune against the maintainer's device being compromised puts you into "Reflections on trusting trust" territory. Just sticking two-factor authentication into that process won't change much (though it would of course also mitigate the password reuse vector).

The objections raised there are all legitimate. Generally usable public key infrastructure is, sadly, vaporware.

Yegge's security vs accessibility rant/monograph should be required reading. The NPM team's choice to favor accessibility is a reasonable choice. The trade-offs are significant.

The postmortem is on the HN front page

https://eslint.org/blog/2018/07/postmortem-for-malicious-pac...

The account of one of the eslint maintainers was compromised.

And this is a critical point. Gpg comes up constantly. It's a waste of everyone's time alive for this use case. If a developer with publish access is compromised, it doesn't help. If the infrastructure is compromised only hash history is required. Hashes are faster to compute in such an emergency, and more available on various mirroring/hosting solutions meaning more likely to have verification sets laying around.

A ledger of hashes of published packages that is run on separate infrastructure and consumed by the client would do just as well as signing for detection of both threats without a lot of complicated issues around third party key material handling, crypto library bugs, and the need for revocation processes.

Note: this is based on experience validating all gems after the yaml scare years ago.

I think in this particular case, the user's npm credentials were compromised. In a system where you have separate and independent credentials for generating a valid package and for publishing, this specific attack might have failed.

Clicking your heels three times and saying 'GPG', of course, doesn't fix much.

Once you identify a privileged user like this reusing credentials the steps to rooting their box and stealing everything else aren't far away. In this case it wasn't needed, but in any case the threat model and recovery model for packages remains unchanged and my recommendation stands.

A ledger of hashes doesn't prevent someone from publishing a new version of a package with the stolen credentials.

What you advocate in this thread is setting aside defense in depth. Could the attacker have used the stolen credentials to pivot to other machines and ultimately gain access to the GPG keys? Maybe, but it's a hurdle, and not a small one. The more hurdles we can place in the way, the less likely it is that small mistakes cascade into total system failure.

There may be legitimate reasons to not to use package signing, but this is definitely not one of them.

>2018-07-12 9:49 UTC: The attacker used the generated authentication token to publish [email protected], which contained a malicious postinstall script that attempts to exfiltrate the local machine’s .npmrc authentication token.

>2018-07-12 18:42 UTC: npm revoked all access tokens generated before 2018-07-12 12:30 UTC.

Does this mean that potentially any version update (of ANY npm package) published between 9:49 and 18:42 could potentially be compromised? Someone's going to have to go through all of them with a fine tooth comb...

That's how I read it. Seemed odd they didn't unpublish all updates for the period but then decided it's best to just stop thinking about it.

For some reason, the situation reminds me of the plot from Dr. Strangelove :P

And that's how it was compromised:

The maintainer whose account was compromised had reused their npm password on several other sites and did not have two-factor authentication enabled on their npm account.

I wonder how many accounts the attacker checked before hitting this account. This will definitely get a nice place in the bucket of examples I throw to people, when I see they are still reusing passwords.

As with IOT, apparently the "S" in NPM stands for security.

Signing will add another factor indeed. :(