3 ms·

No, NPM does not have a GPG signing. There was once a PR open, but it was rejected after sitting idle for over a year. Yes, you read that right. https://gith

No, NPM does not have a GPG signing. There was once a PR open, but it was rejected after sitting idle for over a year. Yes, you read that right. https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://github.com/npm/npm/pull/4016#issuecomment-76316744

PeCaN 8y ago
Somehow people in the ESlint thread were defending the fact that NPM seems totally uninterested in this. Yes, it doesn't solve all the problems and yes you still have to determine who to trust, but at least it makes it POSSIBLE to trust anything. Currently it's impossible to trust anything that you install—and packages can run arbitrary, unsandboxed code with access to the full filesystem when they are installed. That just seems insane to me.
User23 8y ago
The objections raised there are all legitimate. Generally usable public key infrastructure is, sadly, vaporware. Yegge's security vs accessibility rant/monograph should be required reading. The NPM team's choice to favor accessibility is a reasonable choice. The trade-offs are significant.
bodas 8y ago
How would GPG signing help? If someone can execute arbitrary code on your computer as your user account, the game is over, you are totally owned. An attacker can simply start signing their package with your GPG key. Since you are probably in sudoers, unless you have superhuman carefulness, they can also get root.
- 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 ago
    Alice 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 ago
      In 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).

PeCaN 8y ago

Somehow people in the ESlint thread were defending the fact that NPM seems totally uninterested in this. Yes, it doesn't solve all the problems and yes you still have to determine who to trust, but at least it makes it POSSIBLE to trust anything. Currently it's impossible to trust anything that you install—and packages can run arbitrary, unsandboxed code with access to the full filesystem when they are installed. That just seems insane to me.

User23 8y ago

The objections raised there are all legitimate. Generally usable public key infrastructure is, sadly, vaporware. Yegge's security vs accessibility rant/monograph should be required reading. The NPM team's choice to favor accessibility is a reasonable choice. The trade-offs are significant.

bodas 8y ago

How would GPG signing help? If someone can execute arbitrary code on your computer as your user account, the game is over, you are totally owned. An attacker can simply start signing their package with your GPG key. Since you are probably in sudoers, unless you have superhuman carefulness, they can also get root.

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 ago
  Alice 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 ago
    In 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).