5 ms·
What you'd want is for the owner/maintainer to sign the code, rather than the repository. This wouldn't protect you against a malicious maintainer, but it would
by pfg 8y ago
What you'd want is for the owner/maintainer to sign the code, rather than the repository. This wouldn't protect you against a malicious maintainer, but it would help in a case like this as long as the signing key or the maintainer's device isn't compromised along with their credentials. That would definitely raise the bar for attacks of this nature.
- bodas 8y agoAlice installs malicious eslint. Attacker has control of Alice's machine and signs a malicious version of Alice's package using Alice's key. Attacker publishes a new version of Alice's package. Bob installs Alice's (malicious) package. Attacker has control of Bob's machine and signs a malicious version of Bob's package using Bob's key. Attacker publishes a new version of Bob's package. ...repeat IMO signing could only work if it were combined with 2FA so that each time a package is signed, the signing operation is verified by the user on a second device. Otherwise it doesn't really impede a worm significantly because the nature of this attack is that the maintainer's primary device gets completely owned. We are all very lucky that the eslint attack only stole npm credentials instead of installing rootkits.
- pfg 8y agoIn this attack, the maintainer's primary device was not owned. The maintainer's npm account was breached due to a reused password. Code signing would mitigate this because the attacker would be unable to release/sign a malicious version of the package. Building a system that is immune against the maintainer's device being compromised puts you into "Reflections on trusting trust" territory. Just sticking two-factor authentication into that process won't change much (though it would of course also mitigate the password reuse vector).