Live data from Hacker News

Curl to shell isn't so bad

arp242.net

141–150 of 201 posts

Re: Curl to shell isn't so bad

#141

Earlier quoted context omitted.

Well, in this case people should have been using Debian Testing instead of Stable. But yeah it's often that people don't understand what's Debian stable and its trade offs compared to Testing and end up unhappy with it or switching to Ubuntu (which is ~very~ similar to Debian Testing).

Agreed, but that's actually an (UX) problem that Debian should fix. "Testing" is an awful name for "stable enough for normal use". When I first installed Debian I made the same error of installing stable on desktop and then fighting with it to install packages from testing... Just renaming testing to "regular" would prevent lots of wasted time all around.

It's been this way forever, though - when I started woody was "stable" but obsolete the day it was released. Since "stable" and "testing" are aliases of branch names, changing them would break scripts all over the place. You move to Debian, you have to learn to speak the language.

Though the truly baffling bit of Debianese is "contrib" which means "this is free software but depends on non-free software." I can kinda see how it came to mean that, but it's very non-intuitive.

Re: Curl to shell isn't so bad

#142
post #131

Earlier quoted context omitted.

If Ubuntu is the not stale alternative to Debian (stable), then I can't imagine how bad the situation is there. I often build software myself because Ubuntu is very often stale.

Ubuntu LTS (freezes every two years) or "regular" Ubuntu (freezes every six months)? I'm wondering if the periodic freeze-the-universe model that many distros use reflects a world that doesn't really exist anymore where distros came on DVDs (or CDs, or floppies). Whatever version you had on the disc, that's the version you're going to use. I just started playing with FreeBSD in a VM, which has a frozen base system an…

This isn’t how Ubuntu even works. Ubuntu doesn’t just “freeze” their operating system every two years. They are constantly delivering package, security, and hardware enablement fixes. Often the stuff that lands in Ubuntu non-lts versions end up in the lts point releases. They keep a stable base of x.x versions but they definitely backport bug fixes to x.x.x versions of their software packages. For example there was a bug in sudo like 3 weeks ago, and Ubuntu immediately issued a fix within hours of the upstream project’s fix.

Re: Curl to shell isn't so bad

#143
post #35

Not so bad comparing to what? Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a similar risk. But who does that? Every decent Linux distro has a package manager that covers 99% of the software you want to install, and comparing to an apt-get install, pacman -S, yum install and so on - running is a script off some website is way more risky. My p…

> Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a similar risk. But who does that?

Many linux users? I get most of the software I need through package managers, but somewhat frequently I need to build it by source. Particularly if I want the most up-to-date version on debian.

Git cloning a repo is marginally better in the sense that, well, it's open. Theoretically if it were doing something nefarious, someone would've noticed. Is it perfect? No, of course not. I still think it's better than running random curl'd scripts.

Re: Curl to shell isn't so bad

#144
post #35

Not so bad comparing to what? Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a similar risk. But who does that? Every decent Linux distro has a package manager that covers 99% of the software you want to install, and comparing to an apt-get install, pacman -S, yum install and so on - running is a script off some website is way more risky. My p…

It seems like you're assuming that there's someone vetting these packages. For enterprise distros like Red Hat that's certainly true. Community package maintainers in, for example, the Debian project provide some safety as well. But there are plenty of package managers where that's just not the case. In the case of Homebrew, the package manager pulls down the program directly from upstream and installs it. It's exact…

> In the case of Homebrew, the package manager pulls down the program directly from upstream and installs it.

Sure, in the most basic case it does this, but even in the most basic case it does more than that. At minimum it also verified the download matches a known good hash.

The important part (to me) is that Homebrew also ensures the package installed conforms to Homebrew’s standard. There’s a lot of standards (install in /usr, /usr/local, /opt, etc) on something as simple as where the files are put, let alone how it’s built and it’s dependencies are pulled in.

So to say there’s no value in installing from Homebrew over curl|sh is clearly misguided IMHO.

Re: Curl to shell isn't so bad

#146
post #82

Earlier quoted context omitted.

Ironically conda and Homebrew themselves need to be installed from a script off the internet

Conda has an .exe installer on Windows and a .pkg installer on macOS. Both signed by Anaconda, Inc. for the OS. There are RPM and deb bootstrap repos for Linux. Then there’s also the .sh shar file installer.

It would be nice to have something like a fusion of conda and apt to work right out of the box on distros like Ubuntu. Like an "apt install --user". I don't understand why we need root rights to install programs that will not need root rights to run anyway. Seems like a huge and obvious oversight to me. I guess it's not a big pain point because in most cases people use their own machines and have root access. Not always the case though in companies or university labs for example.

Re: Curl to shell isn't so bad

#147
post #40

I hate install scripts, period. They feel so Windows-ish. Just distribute a .deb, .rpm, .snap, homebrew package, npm package, or whatever is the most appropriate for your software. All the scripting you need to do should be done inside of the regular package installation process, and even that should be kept to a minimum. The only software that has any right to rely on an ad-hoc install script on a Unix-like system i…

What’s the difference between a curl you blindly pipe into sh and a blind brew install/npm install command?

Based on experience, brew will place files in a place that I expect.

I can’t predict where a shell script will scribble or what other changes it will make to my system.

Re: Curl to shell isn't so bad

#148
post #33

Earlier quoted context omitted.

An unmodified curl invocation does not require weird timing based attacks, it sends an appropriate user-agent header the server can use (and which the article already adresses).

different attack vector. by detecting the usage of `curl | bash` you can serve a different script only when someone does it, so someone doing `curl -O /tmp/some_script.sh` to audit the script wont see the harmful code. It opens you up to a literally undetectable attack. nonetheless, the point of the article author does have some truth. there is always a degree of trust involved when you're installing binaries from a…

Is it undetectable? `curl | tee file | bash` should detect IMO.

Re: Curl to shell isn't so bad

#149
post #106

Earlier quoted context omitted.

Unfortunately, Debian testing doesn't get security updates.

To the best of my knowledge, this is not true. Have a link?

See this comment: https://news.ycombinator.com/item?id=21492080

Also, this: https://www.debian.org/security/faq.en.html#testing

> there is a minimum two-day migration delay

Re: Curl to shell isn't so bad

#150
post #111
post #106

Earlier quoted context omitted.

Unfortunately, Debian testing doesn't get security updates.

One can think of Debian testing as the "next-stable". How does it works? 1. Upstream release a new version, it goes to unstable. 2. Package is tested for some days in unstable and get promoted to testing. So telling that testing doesn't get security updates is somewhat incorrect, since you are grabing recent software. But by the other hand having too recent software also has its downside ;)

I simplified a bit. Yes, Debian testing gets new updates, which means it gets security updates. Eventually. It can (and does) take days for critical security updates to migrate from unstable to testing after stable has access to patched version.

https://www.debian.org/security/faq.en.html#testing

> there is a minimum two-day migration delay

Post reply on HN