4 ms·
For NPMs you can mitigate executing malware with `--ignore-scripts` https://blog.uirig.com/getting-rid-of-npm-scripts https://blog.uirig.com/getting-rid-of-npm
by efortis 3y ago
For NPMs you can mitigate executing malware with `--ignore-scripts`
https://blog.uirig.com/getting-rid-of-npm-scripts https://blog.uirig.com/getting-rid-of-npm-scripts
- pas 3y agoinstead the downloaded malicious code runs in prod. maybe, if you are lucky, it does something strange in CI and you can catch it. the only real solution is a reputation system (like https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev ), which of course is unfortunately barely used
- efortis 3y agoCorrect, the above mitigation is only for malware on the dev laptops and build servers. IOW, it doesn't prevent injecting the malware on your program when compiling it.
- eptcyka 3y agoProd is bad, but stealing signing keys or credentials is worse.
- zoover2020 3y agoShouldn't build servers have limited or zero network connectivity in the first place?
- deleted 3y ago[deleted]
- silverliver 3y agoModern languages make offline builds far more difficult then they have to be, unfortunately. Rust, for example, buries its off-line installer on another domain. Rust also doesn't advertise or encourage bundling dependencies. Lastly, unrestricted build scripts basically give every dependency full code execution.
- remram 3y agoAny equivalent for non-Rust projects? I see git-crev is abandoned...
- pas 3y agounfortunately the Rust version seems abandoned too :(
- silverliver 3y agoUnfortunate but expected. You get tired after swimming against the current for so long. The rust community has for better or worse settled on wild unauditable dependency graphs. A real shame given how delightful the base language is (ignoring async, of course). Most people who can't deal with this, including myself, simply switched to other languages.
- pas 3y agocan you please elaborate on which language(s) you switched to?
- silverliver 3y agoPerhaps an over-correction, but I've switched to Go. Any language with a proper standard library would do, but I found Go's modern and useful standard library to be well-worth the inefficiency and clunkyness of that language. The more expansive the standard library is, the better.
- reactordev 3y agoShould be the default from a security perspective. Note their note about the need for a Makefile.