[sgarland]

OK, fair-ish point. You won’t find major examples, because it’s not a CVE if you willingly download and execute malicious code. I hope you can understand the theoretical (but very real) risks of doing this, though.

For me personally, I try to use a distro/platform specific package if it exists, since hopefully that means at least one human has read through some of the code, and probably installed it. If that’s not available, I do download the script to review before executing it (and not re-downloading it to pipe to a shell). I’m sure I wouldn’t catch everything, but I would probably catch odd embedded curl calls and the like.

[treve]

It wasn't meant as a gotcha. I'm actually curious if this went wrong, and if it was more of a spear-fishing style attack or a vulnerability hitting multiple people.

Tons of devs download thousands of NPM packages as well, and each can execute code upon install, so a single curl-to-shell pipe from a HTTPS endpoint from a domain you checked always felt way safer than any `npm install`, and so a pretty minor in comparison and yet it gets a lot more attention than package manager, which _feels_ like security cargo culting. Plenty of supply chain attacks in package managers of course. But yeah, would like to be corrected if that intuition is wrong.

[arp242]

As far as I know there are zero examples, CVE or not. I have asked several times over the years and thus no one has been able to provide an example. It just doesn't happen because it just doesn't make much sense.

As I already said years ago[1], if you want to hide some nefarious stuff then you'd do it in something like autoconf soup, or something like that. The install.sh is just too obvious of a place. And this is exactly what happened in the real-world xz attack. I can guarantee you very few, if any, packagers are auditing all of that. And even if they did: it's just so easy to miss.

[1]: https://www.arp242.net/curl-to-sh.html