Hacker News new | comments | show | ask | jobs | submit login

Do they seriously not use any sort of public key cryptography to sign packages? Frankly, for a project that's been around as long as NPM, that's downright irresponsible if that's the case. That's like package management 101.



Most of the programming language Package managers that I've seen either don't have the facility or it's not widely used.


Maven central requires GPG signatures for every package, so all major libraries on the JVM have GPG signatures.

(Whether anyone's checking them is another question, but at least you can if you want to)


I really doubt anyone checks them. It's not integrated or enabled by default, there's no way to pin keys in the build files, etc. GPG isn't the solution to such problems, unfortunately.

In one of my old projects (bitcoinj) we did write a Maven plugin that let you put the hashes of the dependencies into your build file.

However it's rare to see Maven/Gradle builds that accept version ranges. And once downloaded it's cached.


There's a plugin for checking it in maven ( http://www.simplify4u.org/pgpverify-maven-plugin/plugin-info... ) that allows pinning the keys.

Ranges are rare but I'm not sure why - maven actually has very good support for them. I guess it's just that they're not the default?


Version ranges can create inconsistent builds. That's why they're not default and that's why they're not really recommended.


A spectacular failure just waiting to happen.

For example, RubyGems it's possible to sign them, but it's not used as much as it should be because option security never gets used. Waxseal is a gem to sign other gems.

Generally though, it's a worse vulnerability than bitsquatting because it gives quarter to silent, advanced, persistent threats by definition. (Dynamic, untrusted code modification either in-flight or at-rest in difficult to prevent/audit ways.)

The primary way for change to happen is for some company to get hacked, but then it will only change for that one platform because most people are reactive not proactive. Changing this proactively seems painful, but it's less onerous than the risks of the alternatives. The key point is to make end-to-end verification and public key management mandatory and simple.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: