I think the blog author is implying as much as he can, without directly accusing, that he believes that https://github.com/shinnn was responsible for the bad code, not a random hack.

To quote the article: "As far as we are aware, the only purpose of the malicious code was to sabotage the purescript npm installer to prevent it from running successfully... the purpose of this condition [in the code, hardcoded to include the word 'cli'] seems to be to ensure that the malicious code only runs when our installer is being used (and not @shinnn’s)."

:hmm:

>>[[ 9 July, around 0100 UTC: @doolse identifies thatload-from-cwd-or-npm@3.0.2 is the cause. See purescript/npm-installer#12 (comment) @doolse opens an issue on the load-from-cwd-or-npm repo pointing out that the package is breaking the purescript npm installer (although at this stage, none of us spot that the code is malicious). This issue is later deleted by @shinnn. ]]

Hmm indeed. A hack is possible but the timeline of events is dubious.

2FA would also make it much harder to use the "somebody hacked me" defense.

No at that point they'd be saying "zomg NPM has a terrible bug that allowed the hacker to bypass my 2FA!"

If someone is trying to redirect blame they'll always find some way to do so.

The problem is not liars, the problem is being unable to prove they were lying. With 2FA, the logs would prove it.

Unfortunately, based on preexisting cases it really doesn't make much of a difference, the liars will still deflect the blame and the logs will always be "wrong".

I mean, do you really think some hacker compromised @shinnn's account, solely for the purpose of sabotaging a new installer that had only been published for 8 hours?

I mean, I'm all for benefit of the doubt and such, but it's pretty obvious what happened here.

This was my gut reaction, but on further thought, this whole thing seems so needlessly petty that it could have easily been the author attempting to make the other person look bad.

I'm not really familiar with how NPM packages are published - is it just referencing a commit hash in a repo, or is it a separate upload direct?

If it's the former (or could be made to be the former), requiring GPG signed commits would go a long way to preventing malicious activity.

npm should absolutely enforce 2FA imho.

I don't think encryption keys actually are useful for the average case here.

Currently, developers store npm tokens which may be stolen because they're often stored on disk or as environment variables.

Requiring developers to store encryption keys makes almost no difference: the private key will still be stored on disk and will still be vulnerable to effectively the same attacks.

There are some differences of course. Security-conscious users could use hardware tokens to store their encryption keys, and they could password protect the private key in either case. This is not the large majority of users though, so in the average case, it won't matter.