NPM debug and chalk packages compromised

After all these incidents, I still can't understand why package registries don't require cryptographic signatures on every package. It introduces a bit more friction (developers downloading CI artifacts and manually signing and uploading them), but it prevents most security incidents. Of course, this can fail if it's automated by some CI/CD system, as those are apparently easily compromised.

Real registries do[1], npm is just amateur-hour which is why its usage is typically forbidden in enterprise contexts.

[1] https://www.debian.org/doc/manuals/securing-debian-manual/de...

Mmm. But how does the package registry know which signing keys to trust from you? You can't just log in and upload a signing key because that means that anyone who stole your 2FA will log in and upload their own signing key, and then sign their payload with that.

I guess having some cool down period after some strange profile activity (e.g. you've suddenly logged from China instead of Germany) before you're allowed to add another signing key would help, but other than that?

In all fairness—npm belongs to GitHub, which belongs to Microsoft. Amateur-hour is both not a valid excuse anymore, and also a boring explanation. GitHub is going to great lengths to enable SLSA attestations for secure tool chains; there must be systemic issues in the JS ecosystem that make an implementation of proper attestations infeasible right now, everything else wouldn't really make sense.

So if we're discussing anything here, why not what this reason is, instead of everyone praising their favourite package registry?

Supporting Passkeys would improve things; not allowing releases for a grace period after adding new signing keys and sending notifications about this to all known means of contact would improve them some more. Ultimately, there will always be ways; this is as much a people problem as it is a technical one.

The NPM team has repeatedly commented that it's "too hard", effectively, and would discourage new developers from publishing packages. See:

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

https://news.ycombinator.com/item?id=38645969

https://github.com/npm/cli/commit/5a3b345d6d5d175ea9ec967364...

I don't think I'd trust a package from a new developer like that, so this helps filter out people that don't know how to properly maintain a package. If they really want to make onboarding easier, saying "after e.g. 1000 monthly downloads, you'll need to sign your artifacts" is also a viable solution in my opinion.

I suppose you'd register your keys when signing up and to change them, you'd have some recovery passphrase, kind of like how 2FA recovery codes work. If somebody can phish _that_, congratulations.

That still requires stealing your 2FA again. In this attack they compromised a one-time authenticator code, they'd have to do it a second time in a row, and the user would be looking at a legitimate "new signing key added" email alongside it.

Yeah Microsoft would have bought or taken over npm just to train on all the data against peoples wills, not to actually improve or put any effort into making it better

The npm team is, frankly, a bunch of idiots for saying that. It has been obvious for TEN YEARS that the bar for publishing npm packages is far too low. That’s what made npm what it is, but it’s no longer needed. They should put on their big boy pants.

> discourage new developers from publishing packages

Good.

I'm a fan of post-facto confirmation. Allow CI/CD to do the upload automatically, and then have a web flow that confirms the release. Release doesn't go out unless the button is pressed.

It removes _most_ of the release friction while still adding the "human has acknowledged the release" bit.

It sure hasn’t been forbidden in any enterprise I’ve been in! And they, in my experience, have it even worse because they never bother to update dependencies. Every install has lots of npm warnings.

Maybe even send a user an email notification with a link...

lol granted! But notice how in that universe since npm has to send the link, then access to the link is coupled to access to the email address, serving as an auth factor.

In the attack described above, the attacker did not have access to the victim's email address.

It's not like these packages are super sophisticated million LOCs masterpieces. ansi-regex is literally just this:

    export default function ansiRegex({onlyFirst = false} = {}) {
 // Valid string terminator sequences are BEL, ESC\, and 0x9c
 const ST = '(?:\\u0007|\\u001B\\u005C|\\u009C)';

 // OSC sequences only: ESC ] ... ST (non-greedy until the first ST)
 const osc = `(?:\\u001B\\][\\s\\S]*?${ST})`;

 // CSI and related: ESC/C1, optional intermediates, optional params (supports ; and :) then final byte
 const csi = '[\\u001B\\u009B][[\\]()#;?]*(?:\\d{1,4}(?:[;:]\\d{0,4})*)?[\\dA-PR-TZcf-nq-uy=><~]';

 const pattern = `${osc}|${csi}`;

 return new RegExp(pattern, onlyFirst ? undefined : 'g');
}

< developers downloading CI artifacts and manually signing and uploading them

Hell no. CI needs to be a clean environment, without any human hands in the loop.

Publishing to public registries should require a chain of signatures. CI should refuse to build artifacts from unsigned commits, and CI should attach an additional signature attesting that it built the final artifact based on the original signed commit. Public registries should confirm both the signature on the commit and the signature on the artifact before publishing. Developers without mature CI can optionally use the same signature for both the source commit and the artifact (i.e. to attest to artifacts they built on their laptop). Changes to signatures should require at least 24 hours to apply and longer (72 hours) for highly popular foundation packages.

No kidding. New developers need to learn the important skill of doing something correctly, not just “ship fast; break things”

   ... | wc -c
   592

592 bytes of code including comments and whitespace versus which amount of overhead in package description, tarball caches, etc...?