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.