← Back to context

Comment by a022311

3 months ago

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.

21 comments

a022311

Reply
parliament32  3 months ago

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...

  • 9dev  3 months ago

    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?

  • herpdyderp  3 months ago

    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.

Joker_vD  3 months ago

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?

  • 9dev  3 months ago

    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.

  • a022311  3 months ago

    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.

  • pants2  3 months ago

    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.

solatic  3 months ago

< 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.

rtpg  3 months ago

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.

  • eviks  3 months ago

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

    • rtpg  3 months ago

      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.