|
|
|
|
|
|
by ubernostrum
3080 days ago
|
|
|
This is your occasional reminder that package signing is not a panacea, and as typically proposed for community package repositories like npm, PyPI, etc. would likely do absolutely nothing. For example, people often insist in the Python world that PyPI should support package signing. But it already does -- you can generate a signature for a package and upload the signature with the package. Django does this, and has been doing it for years. You can also get package download/install tools that will check the signature. But then what? What people really mean when they say there should be "signed packages" is that there should be a whole bunch of invisible infrastructure (set up by... who, exactly? Maintained by... who, exactly?) to decide which PGP keys are authorized to sign releases of which packages. And that's close to an intractable problem for an anyone-can-contribute community repository like npm or PyPI. |
|
|
An analogy might be drawn with the app stores. We all know it is massively easier to get stuff in the play store than the iOS store. We all know there is a shit ton of spam, malware etc on the play store and not really in the other. But it's also much easier to contribute to. It's a trade off. Security is important, but sometimes I feel that people are unwilling to treat it as an input in a basic cost benefit analysis, instead turning it into a kind of absolute value. I accept that it is not treated seriously enough by many in the community, but overcorrection is not the answer.
Of course, other relatively 'open' package indexes exist that do not have npm's typo squatting issues, so there are other design issues at work in this particular case.