victorb
commented
5 years ago Hi @d4hines! Thanks for question and no worries that it's not specific to this project.
The current way of dealing with this, is as far as I know, only scanning packages with some for-profit service which has collaborated with the npm registry. This obviously only works finding issues that already been found before (ala blacklist).
My thinking around this issue is that there are two ways we can improve the current situation:
1) Offering a build-solution for packages, where instead of the current way where packages are built locally on the developers machine and then pushed to the registry, the source code gets read directly from the source, and the build happens on servers, then pushed to the registry. Then we can also serialize the build steps and run tests to see if the packages are actually reproducible.
2) Package signing MUST be used for package releasing. A recent issue happened in npm as a user account with compromised and the attacker managed to push code that the actual developer did not write. By requiring package signing, we authenticate that the package actually come from the author we think it should come from.
Both these thoughts are very young (see: underdeveloped) and might miss the mark.
I'm very eager to hear about other possible solutions. I think solution 1 would work very well, but does kind of set stop-wheels in 2, but we don't need 2 if we have 1.
Hello, I have a question about regarding package security. This isn't specific to your project, or even to JavaScript, but sort of a noob question about package registries in general.
Say you register a library. You also link your GitHub repo. Let's say your source code is also minified/compiled in some way. How do I verify that the package I'm getting is the source code you linked, plus whatever build steps were necessary?
As it is, packages seem terrifying to me. If your registry had some solution to this (even if its a standard/well-known solution), that would be super exciting!