▲ | homebrewer 3 days ago | |||||||
It's already solved by pnpm, which refuses to execute any postinstall scripts except those you whitelist manually. In most projects I don't enable any and everything works fine, in the worst case I had to enable two scripts (out of two dozen or so) that download prebuilt native components, although even those aren't really necessary and it could have been solved through other means (proven by typescript-go, swc, and other projects led by competent maintainers). None of it will help you when you're executing the binaries you built, regardless of which language they were written in. | ||||||||
▲ | jvanderbot 3 days ago | parent | next [-] | |||||||
I could be wrong but I believe Pnpm would not have helped with the supply chain attach that brings us here. It's simply a problem with deploying new code rapidly and automatically without verification to a billion machines at a time. | ||||||||
| ||||||||
▲ | danielheath 3 days ago | parent | prev | next [-] | |||||||
That doesn't help you if anyone on your team installs a vscode plugin which uses npm in the background & executes postinstall scripts. | ||||||||
▲ | ryukafalz 3 days ago | parent | prev | next [-] | |||||||
> None of it will help you when you're executing the binaries you built Lavamoat would, if you get to the point of running your program with lavamoat-node or built with the lavamoat webpack plugin: https://lavamoat.github.io/guides/getting-started/ | ||||||||
▲ | hdjrudni 3 days ago | parent | prev [-] | |||||||
> None of it will help you when you're executing the binaries you built, regardless of which language they were written in. Sure it would... isn't that the whole point of Deno? The binary can't exfiltrate anything if you don't let it connect to the net. |