3 ms·
Not really asking for perfect/decidable. Just wondering out loud on how to detect even one of the other active exploits that are surely in the wild. This one w
by zawerf 8y ago
Not really asking for perfect/decidable.
Just wondering out loud on how to detect even one of the other active exploits that are surely in the wild. This one was live for 3-4 months before it got found by luck?
For example I would really appreciate if they added something to detect/warn when a package needs eval or http requests permissions (yes, I know npm packages don't have a concept of permissions).
Anyway your commonly repeated advice on how to defend yourself isn't practical (short of not using npm). The dependency that got me was nodemon. That ought to be "trusted code" with 17k github stars, 1 million downloads per week but apparently not. As I said already, even if I did check the commits to all my dependencies, I don't think I would've caught this one. It's a one line change in the minified build file of a transitive dependency nested 4 deep. All the commits around it are very normal looking.
- gnulinux 8y agoI wasn't intending to say reading every single commit of your dependencies is practical. I was arguing that unless you do that, you get absolutely no guarantee of security. If you take code for granted because it has 17k internet points, you're putting yourself at risk. I can't see how this is not very simple.
- zawerf 8y agoIt's "very simple" that you will also "get absolutely no guarantee of security" unless you personally rewrite every line of code you use in a provable/verifiable language, design and manufacture your own hardware, hide in a cave to avoid all social engineering, and so on. Hopefully you see why your advice is similarly impractical.