8 ms·

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 compromise

by raggi 8y ago

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.

pvg 8y 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.
- raggi 8y ago
  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.
mirashii 8y ago
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.

by raggi 8y ago

pvg 8y 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.

raggi 8y ago
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.

mirashii 8y ago

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.