| ▲ | jwr 4 hours ago |
| "curl -fsSL https://pi.dev/install.sh | sh" — seriously? That tells me a lot about the whole project, unfortunately. |
|
| ▲ | throwaway2027 4 hours ago | parent | next [-] |
| Claude Code does it the same way (which doesn't excuse it obviously) but still. curl -fsSL https://claude.ai/install.sh | bash https://code.claude.com/docs/en/quickstart |
| |
| ▲ | ardacinar 4 hours ago | parent [-] | | Yep, that's not an excuse. Claude goes down all the time, should pi also go down? Oh wait (from another comment under this article):
> https://pi.dev/models is throwing an internal server error for me. |
|
|
| ▲ | mik3y 4 hours ago | parent | prev | next [-] |
| I am genuinely curious what it tells you, as "curl https//.. | sh" has long been an enormously popular approach to distribution in the open source world. Homebrew, to name just one example, advertises a similar method. (pi.sh also documents other install methods, like `npm`, on their homepage) If trust and security is the issue, unfortunately "better" ideas like hashpipe [1] never achieved critical mass [1] https://news.ycombinator.com/item?id=9318286
|
| |
| ▲ | NekkoDroid 2 hours ago | parent | next [-] | | I really hate the `curl <url> | sh` specifically because if your connection drops at a specifically unlucky point in time you are left with a partially executed script which if you are unlucky enough may just have been executing `rm -r ~/.cache/<pkg>/download` but it stopped at `rm-r ~/`. Is it likely? No. Can it happen? Yea. Just make it `curl -o <file> <url> && sh <file>` and this entire problem is gone. | | |
| ▲ | cyberax an hour ago | parent [-] | | Most scripts now put all the code into a shell function and call it in the last line of the script, so this bug can't happen. |
| |
| ▲ | tovej 4 hours ago | parent | prev | next [-] | | What about better ideas like installing from source, or using a package manager? Or even flatpaks. | | |
| ▲ | arbll 4 hours ago | parent | next [-] | | From source: creates much more work for the user. Package managers: ecosystem is fragmented, requiring a long list of distro- and package-manager-specific instructions. Many scripts already install through package managers, they simply make the user’s life easier. Flatpaks: These are clearly designed for desktop applications, with CLIs treated as an afterthought. They may be the best long-term hope, but today they are definitely not as convenient or widely available as a simple script. If you care about adoption, `curl | sh` is the only real option today, which is why virtually all project show it as the first option. | | |
| ▲ | tovej 4 hours ago | parent [-] | | Bullshit. There's plenty of big projects that don't suggest you curl a script right into your shell. If you have curl, you're probably on Linux. Just use the package manager like an adult. | | |
| ▲ | arbll 2 hours ago | parent [-] | | The "like an adult" is what has and will continue to hold back linux on the desktop. Always gatekeeping less technical users instead of acknowledging adoption and ease of use are critical. | | |
| ▲ | pluralmonad an hour ago | parent [-] | | Is this stance gate keeping users? Isn't a pkg manager installation also a one liner? This seems more like gate keeping lazy distributors. | | |
| ▲ | arbll an hour ago | parent [-] | | A lot of those scripts are wrappers around package managers. Creating them is extra work for distributors, but they still do it because package-manager installs are not truly one-liners and offer far less control over the installation experience. Users need to figure out which of the 10+ package managers they should be using, then run several commands. If something fails, the error messages are often cryptic and not easily configurable by the distributor. And that’s before getting into the many rough edges of package managers. Most of them flat-out refuse to handle configuration and leave that part to the end user. Now you also need to document how to edit YAML and restart a systemd service. With an install script this is also solved. For power users, this always looks trivial. In practice it raises the barrier to entry and can meaningfully affect adoption if your product is often used by less technical people. |
|
|
|
| |
| ▲ | mik3y 4 hours ago | parent | prev [-] | | The ideas aren't mutually exclusive, and I've never seen an open source project support "curl | sh" without also supporting those methods. Indeed, plenty of these scripts often act as a "what OS and packager do we have" mux. Just look at the source of this one, for example. When you support an open source project at scale and/or with less savvy users, you come to see the benefit of "here, just f'ing slam this into your shell and we'll figure it out" installers. I know I have. |
| |
| ▲ | TacticalCoder 3 hours ago | parent | prev [-] | | > I am genuinely curious what it tells you, as "curl https//.. | sh" has long been an enormously popular approach to distribution in the open source world. It's plain horrible. You could have, for example, a compromised server serving malware but only one out of every 100 download. The only signature you rely on is TLS. Proper package distribution are using proper signatures schemes, are decentralized, even for some offer reproducible builds (meaning you can rebuild the whole package yourself and verify your build matches), etc. Hashpipe is an attempt at reproducing some of those guarantees. Not unlike container pining using hashes. It at least fixes the "Jack and John installed this already and I know I'm getting the same version as they did". Proper software distribution is signed, reproducible and ideally also uses some proof-of-existence for the hashes. My bet is this: in the face of the countless supply chain attacks, we'll see more and more people getting very serious about security, including the security of software distribution. And curl bash'ing won't be part of it. | | |
|
|
| ▲ | sippeangelo 4 hours ago | parent | prev | next [-] |
| Seriously, what is the threat model here? |
| |
| ▲ | InsideOutSanta 4 hours ago | parent | next [-] | | There is no threat model that doesn't also apply to pretty much every other distribution method. It's just people who have internalized "don't paste commands from the Internet into your terminal" and aren't thinking about exactly what makes pasting commands from the Internet into your terminal dangerous, and how that applies to this specific case. | |
| ▲ | arbll 4 hours ago | parent | prev [-] | | Nah bro package manager where you copy and paste their custom repo and key from the same website that hosts the `.sh` is definitely safer, trust me /s |
|
|
| ▲ | efficax 4 hours ago | parent | prev | next [-] |
| it tells you they're just like basically every other CLI targeting project for the last 15 years? I mean is it a big security hole we all accept, yes, it is. But it's not really indicative of much. That's also how I install rust. |
| |
| ▲ | croes 2 hours ago | parent [-] | | We also accepted the security risks of npm and such and we get one supply chain attack after another. Maybe security should be at a higher position on our priority list. The careless days are ultimately over but we still don’t act like that. |
|
|
| ▲ | Arubis 4 hours ago | parent | prev | next [-] |
| I get this, and would recently have had a similar reaction. But I have to ask: do you typically run your agent harness in yolo mode? |
|
| ▲ | horsawlarway 4 hours ago | parent | prev | next [-] |
| Yeah, totally reasonable comment given the utter security that must come from anthropic with their installer, amiright? oh wait... "curl -fsSL https://claude.ai/install.sh | bash" (right from https://claude.com/product/claude-code) Further - what the flicking fuck do you think an installer is going to do on your system? Not run any commands? Because I've written installers for every platform... they ALL can run commands. So what exactly is the complaint in this comment? If you want to go read the install script - knock yourself out (or hell, point your agent at it...). |
| |
|
| ▲ | tuvix 4 hours ago | parent | prev | next [-] |
| both the Julia and Rust programming languages use curl -> sh to install |
| |
| ▲ | tovej 4 hours ago | parent [-] | | Both of them provide that option. I've never installed rust without a package manager. Why would I? | | |
| ▲ | qarl2 4 hours ago | parent [-] | | > Why would I? Because then you can install it without depending on a package manager? | | |
| ▲ | tovej 4 hours ago | parent [-] | | Yeah, from source in that case. Or using a verified binary if I absolutely had to. | | |
| ▲ | qarl2 4 hours ago | parent [-] | | Yes, if you want to, you can do that. Understand that 99% are comfortable trusting downloads. They know that it's just as easy to sneak backdoors into source code as it is to sneak backdoors into executables. See also: XZ hack. |
|
|
|
|
|
| ▲ | qarl2 4 hours ago | parent | prev | next [-] |
| My dude - if you're going to trust them then you're going to trust them. You think it's hard to obfuscate shell calls from inside a built executable? What it tells us is that you're probably searching for reasons to grouse about AI. |
|
| ▲ | plagiarist 4 hours ago | parent | prev | next [-] |
| In general I agree with you, but on the other hand it is an agentic coding agent you should have isolated in a container or VM anyway |
|
| ▲ | lo0pback 4 hours ago | parent | prev [-] |
| [dead] |