Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

They need to pull their socks up and start signing these packages


Been discussed. Repeatedly. For years.

Can't understand why it hasn't happened still.


Can't understand why it hasn't happened still.

https://github.com/npm/npm/pull/4016 - I read this as "it´s hard, and we don´t care." took them forever to look at and reject a patch that would have gotten the ball rolling


What would signed packages have achieved in this incident?

Who needs to sign the packages? The developers of the packages, right? Otherwise developer credential compromise subverts the entire point.

Which keys are authorized to sign for which packages? How to prevent credential compromise from affecting those authorizations?

What's the difference between a signed legitimate package and a signed malicious package?

If they introduced package signing, would packages would adopt it fast enough for users of packages to only use signed packages?

What happens when signing keys are lost or compromised? Do we need to use countersignatures from timestamping services as with other forms of code signing, so that CI systems do not break if a key is pulled?

I think this is very much not straightforward. npm+pgp may be well intentioned but seems grossly inadequate.


Android and the Google Play store works pretty well. The systems "locks on to" a public key signature so further updates for a given app must be signed with the same key. That would fix the problem with reproducible builds here. Only adding new top level packages to a project for the first time is at risk then.


No one is asking for perfect, just an ssh style warning of "the key of the system you are connecting to changed from last time" would be a good start. Implementing that is trivial, straightforward, requires zero setup and would have easily prevented the copycats here.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: