Meh. Just this week, I've had two Sonnet 4.8 agents generate, in parallel, a 2000 line wall of brittle bullshit, and a well architected solution with 20% of the amount of code, to the same problem, from the exact same initial context, and very similar prompts. Come on, they can do poor quality work too.
You're right that it's as dangerous as it's executing random third-party code on your machine, but the method also has propagated far beyond PoCs and such at this point. All of these projects and many others push that install method: Bun, Deno, rustup, k3s, Docker (if using their helper script), Homebrew, Tailscale...
Frankly, it's not really more insecure than any other installation method. Apt packages and the like generally have the ability to specify pre/post-install scripts, so `sudo dpkg -i ./random.deb` is equivalent to `sudo bash ./random.sh`. Even if they didn't have pre/post-install scripts, they're still writing arbitrary files to arbitrary locations on your disk, so they can trigger execution the next time you boot or log in or whatever.
And at the end of the day, no matter the installation method (even just unpacking a tarball and executing the program directly from that directory), you're going to run their program on your computer, and then the program can do whatever it wants. Maybe you don't run it with sudo, but https://xkcd.com/1200/ seems relevant.
A package (like a .deb) is a static artifact. It can be hashed, mirrored, and GPG-signed. Package managers usually verify that signature before any pre/post-install scripts. A "curl <some_url> | bash" pipe is a dynamic stream; the server can perform targeted attacks: sending a clean script to 99% of users and a malicious payload only to a specific IP address or User-Agent. This allows for targeted attacks that are invisible to the rest of the community.
Yes, running third-party code is always a leap of faith, but why choose a delivery method that removes the possibility of verification and opens the door to targeted injections? Convenience shouldn't be an excuse to ignore basic security hygiene.
The problem is that npm, cargo, etc. set the standard in people's minds for how package managers work, when the Linux community has been working on securing the supply chain issues for decades.
Like requiring a WoT (usually with physical meetups) vetting people creating packages, FTP-masters, dedicated clean buildbots, etc. in addition to the packages themselves being signed and so on.
That works, until that inevitable one merge that's harder to fix and takes longer, which in my experience then tends to snowball until it's basically the very merge hell you were trying to avoid. Can't say I've ever had a great experience with long lived feature branches. I can't imagine what it would even look like trying to do this on such a massive project and such an overarching feature.
Funny, I've been emulating games for literal decades at this point, but remapping buttons is one of the first things I did in every one of them, so I never knew the defaults hehe
Money pays the bills, not ambition and competition. Every freaking thing out there uses money to keep score. There's no reason we should not use money to keep score of the people hoarding more and more of the money bags, and actively using their money towards leaving the rest fighting over am ever shrinking pot.
Except it's pretty well documented (and this is total conjecture, but if you ask me, there are probably are a bunch of undisclosed cases) to have had a good amount of close calls. With the fire-on-warning stance many powers have, it doesn't take an attack, but just enough of the appearance of it to trigger a response.
reply