4 ms·

Each version of an npm package needs a certified git commit hash. Otherwise when vetting an npm package, you have no idea if the code you're reading on Github

Each version of an npm package needs a certified git commit hash. Otherwise when vetting an npm package, you have no idea if the code you're reading on Github is actually what you're going to download or not. In scenarios like this one, package publishers could easily configure getting an alert that someone tried to push to npm a hash for which no commit exists in Github. For packages with a build step this would likely mean npm would have to run the build step on their servers. Hopefully there's a way they won't have to eat that cost, but I believe publishing linking package versions to specific git hashes is the only way to prevent an attack like this.

nevir 8y ago
The challenge here is that you cannot just go with signed commits—it would also need to authenticate a specific user/org, repository, etc. (Anyone can sign a commit) Similarly, however that whitelist of identities is specified becomes another vector, without a lot of PKI
- jpochtar 8y ago
  I shouldn't have used the word 'certified'— I just meant the package version should have an associated commit hash. There has to be a relationship between the hash and the published code in some way, unlike eg. the "homepage" field people use to link to Github which can just be an outright lie. My goal is for readers to match the hash to one on Github so they know the code they're reading there to vet the package is what's on npm. For OSS maintainers, it's an immediate red flag to see a package version published with a hash that was never in the public repo. This won't certify that the version is blessed by a legitimate author. It just delegates the problem to Github (or their competitors). It doesn't solve the problem of preventing all OSS library-based attacks, but plugs one of the leaks in trust that caused today's failure: that Github->NPM is not checked in any way.
  - thephyber 8y ago
    If a malicious actor has access to change the npm module (therefore can change the public key used to verify the module code signature), how does signing code help? Now the malicious actor is signing their malicious code. Code signing still allows the fire to spread. What we need to be talking about is how to prevent the spark that starts a fire.

nevir 8y ago

The challenge here is that you cannot just go with signed commits—it would also need to authenticate a specific user/org, repository, etc. (Anyone can sign a commit) Similarly, however that whitelist of identities is specified becomes another vector, without a lot of PKI

jpochtar 8y ago
I shouldn't have used the word 'certified'— I just meant the package version should have an associated commit hash. There has to be a relationship between the hash and the published code in some way, unlike eg. the "homepage" field people use to link to Github which can just be an outright lie. My goal is for readers to match the hash to one on Github so they know the code they're reading there to vet the package is what's on npm. For OSS maintainers, it's an immediate red flag to see a package version published with a hash that was never in the public repo. This won't certify that the version is blessed by a legitimate author. It just delegates the problem to Github (or their competitors). It doesn't solve the problem of preventing all OSS library-based attacks, but plugs one of the leaks in trust that caused today's failure: that Github->NPM is not checked in any way.
- thephyber 8y ago
  If a malicious actor has access to change the npm module (therefore can change the public key used to verify the module code signature), how does signing code help? Now the malicious actor is signing their malicious code. Code signing still allows the fire to spread. What we need to be talking about is how to prevent the spark that starts a fire.