Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Audacity of Piping Curl to Bash

yotam.net

Post reply on HN
Print view View original

61–70 of 111 posts

Re: The Audacity of Piping Curl to Bash

#61

Post by Sakos »

spsesk117 wrote: post #26
Sakos wrote: post #20

Earlier quoted context omitted.

> packaging for rpm/deb (in my experience) can sometimes be an enormous pain with many hoops to jump through, _especially_ if you're trying to get your package accepted upstream I would say this is the primary pain point for maintainers, which is why we're suddenly seeing bash scripts instead. The technical complexity and the process of upstreaming and then doing this for a bunch of different distros. If they're alre…

> the solution isn't "well, why don't they just use existing package management systems" Fair enough, I think I was more trying to unwrap the idea of "shell script standardization", which to me feels like a package management system. To your point about the challenges of packaging for multiple distros, there are force multiplying tools I've used in the past that make this easier, but in my experience it is always a b…

> Fair enough, I think I was more trying to unwrap the idea of "shell script standardization", which to me feels like a package management system.

And you're right, of course. I just think it's important to recognize what is being compensated for when existing solutions are rejected. We have a habit of saying "they shouldn't be doing that, we have this already" instead of "this is a signal that something in the environment is making what they're doing a viable alternative, how can we improve things?"

I don't think it's an accident that we're seeing the rise of Snap and flatpak or even Nix at the same time.

Re: The Audacity of Piping Curl to Bash

#62

Post by AnIdiotOnTheNet »

derefr wrote: post #23
simiones wrote: post #14

Earlier quoted context omitted.

It's even worse than that. The way common distros work is not "devs package software", it's "devs convince distro to pick up the package and maintain a fork". Of course, you can run your own APT or RPM repo, but that actually asks your users for even more control of their systems (since you now have a way to get any new version more or less automatically installed on their system in perpetuity), and it makes it even…

> but that actually asks your users for even more control of their systems Or you can support one of the limited-capability package ecosystems, like Flatpak or Snap or AppImage. Then it's sort of like installing an app on your Android phone: the installed app (and its updates) only get to interact with the system through a customized sandbox that must first be described to, and accepted by, the user.

AppImage is not "limited-capability" and has no sandbox mechanism at all without additional tools. An AppImage is the rough equivalent of a statically compiled binary.

Re: The Audacity of Piping Curl to Bash

#64

Post by bravetraveler »

mjw1007 wrote: post #17
simiones wrote: post #9

This seems almost like a misunderstanding of what is the role of an installer, especially for something like oh my zsh. The author is complaining that it takes over their zsh configuration, when in fact that is obviously the whole point of the installer. An installer isn't simply there to copy a program to your system. It's there to copy files to your system and then modify your system so that it is ready to use the…

The other part of an installer's job is to provide a reliable way to uninstall the program, without leaving any mess behind. I think that's the main reason I'm reluctant to run curl|bash-ware. I might trust the authors not to be malicious, but I generally wouldn't trust them to be competent at cleaning up after themselves.

Precisely, if this is the suggested distribution method then I have to assume there's been even less investment in 'undistribution'

It's possible for installers to be this full-featured, but it's plagued with footguns.

They try and often fail to make an idempotent shellrc patcher with command line pipes, or something equally convoluted. If at all.

Instead of using something established, or even better... drop-in config directories.

Not everything needs to own (or even touch) the main config file!

edit: Don't trust the 'curl the script before piping it' thing, either.

I don't have it handy, but there's been demonstrated means to alter the content based on timing, causing the pipe to be a malicious payload

Re: The Audacity of Piping Curl to Bash

#65

Post by simiones »

denton-scratch wrote: post #55
rich_sasha wrote: post #33

Earlier quoted context omitted.

I used to think that. But is it really that much worse than `pip install` random stuff? Or Homebrew, or Linux package managers - it's not like these things get audited.

> it's not like these things get audited. APT is part of the core Debian distro. I don't know about "audited", but it's tested, and it's maintained. And the packages in "main" are also tested. I don't program in Python, and I don't know how Pip packages are audited. An awful lot of the packages in Debian main are Python and Ruby libraries, and I suspect that they are rarely used: I assume most Python and Ruby users r…

Most software which doesn't just curl|bash tells you to add their custom repo to APT/YUM/APK/whatever. Very few packages actually rely on the Debian maintainers to add them to the core package repos as a way of being distributed, and even fewer want to use Debian's glacial pace of releasing updates.

Re: The Audacity of Piping Curl to Bash

#66

Post by user3939382 »

AnIdiotOnTheNet wrote: post #60
user3939382 wrote: post #51

Earlier quoted context omitted.

If only that were true. Apps leave their config and support files all over the file system.

Also true of literally every OS, on the inherited wisdom that separating the config from the actual application allows it to persist through upgrades and reinstalls easily. There are certainly other ways to do that, but this is how it has been done since forever.

Windows uninstall isn't guaranteed* to be perfect but it's much better in this regard. It's common on Windows to have uninstaller apps that go around cleaning up the crumbs of the application. The equivalent on macOS isn't unheardof but it's rare.

Re: The Audacity of Piping Curl to Bash

#67

Post by sjmulder »

steveklabnik wrote: post #41
sjmulder wrote: post #13

Another downside of these scripts is that they tend to make changes to your user or machine configuration, something which is tolerated from Windows installers but a big no-no for me. E.g. I believe Cargo edits .profile to add its path and Teams makes itself start at login (!). For reasons such as these, but also things like telemetry configuration defaults and clean uninstalling, I prefer using a package manager. In…

Cargo does not. Rustup’s installer does, by default. It informs you of this before it does so, and you can ask it to not if you’d prefer.

Thanks for clarifying - it’s been a while!

Re: The Audacity of Piping Curl to Bash

#68

Post by nimbius »

piping curl to bash is a heresy, an abomination that cannot be tolerated. it is an affront to my intellect and sensibility. it is an ethical turpitude and degeneracy that cannot be understated in its depravity.

It reduces the user to nothing more than an endured, pseudotrutworthy ball of lard in the developers formal equation of installation. As it is an installation however it beseeches the administrator, the root, the owner and the light of this system that it may achieve its purpose and in doing so is a blasphemy. it supplants my GNUlike will and in its stead enforces the hopes and dreams of nothing more than a transient, a visitor.

For the last time: The ground your code touches is holy and hallowed. the rites of Posix and the decree of the Unix philosophy at the sides of the throne you approach alone implores you not to speak unless spoken to, unless absolutely in the favor of the god of this land. To sudo curl|/bin/bash is to commit an unspeakable treason in the divine presence, a sin unforgiveable before the light of the PTY and the TTY. To take the sudo sword of the emperor alone and wield it as you see fit is damnable contempt indeed.

Re: The Audacity of Piping Curl to Bash

#69

Post by nhooyr »

dllthomas wrote: post #40
hprotagonist wrote: post #12

curl ... | bash is the moral equivalent of {npm, pip, nuget, ...} install and i really don't understand the folderol around that. In both cases, you can alter the command slightly to instead download the payload without executing it and inspect it first, if you wish. In both cases, you're ultimately going to either audit and then execute or just execute code from Somewhere Else. This is true for distro package manage…

If curl dies early, bash might be executing a truncated script. Arbitrarily truncated bash scripts are often valid bash scripts that do things you don't want.

You can trivially sidestep this with a main shell function called at the end of your script. https://github.com/terrastruct/d2/blob/729b12685af79bbdaf4b3...

Re: The Audacity of Piping Curl to Bash

#70

Post by zwkrt »

nimbius wrote: post #68

piping curl to bash is a heresy, an abomination that cannot be tolerated. it is an affront to my intellect and sensibility. it is an ethical turpitude and degeneracy that cannot be understated in its depravity. It reduces the user to nothing more than an endured, pseudotrutworthy ball of lard in the developers formal equation of installation. As it is an installation however it beseeches the administrator, the root,…

I've never been much for religion but maybe I just haven't gotten into the right stuff. Can I confess to you the sins of my .vimrc?
Post reply on HN