Curl to shell isn't so bad • Hacker News Board

Re: Curl to shell isn't so bad

#81

Post by mirimir » Sat, Nov 09, 2019, 1:20 PM UTC

hannob wrote: post #36

yoavm wrote: 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…

> Every decent Linux distro has a package manager that covers 99% of the software you want to install I wish this were true, but plenty of experience with Linux usage tells me that not having something packaged is a very common occurence. Though of course this can be improved: More people should actually help working on their favorite Linux distro, so more software gets packaged. And upstreams should try better to co…

Right. I love Debian, but its packages are often very stale. That's why many end up using Ubuntu. And yes, I get that package review takes time, and that Debian is arguably more secure. But that's little consolation when you're dead in the water because what's packaged is too old.

Re: Curl to shell isn't so bad

#82

Post by DrKabab » Sat, Nov 09, 2019, 1:22 PM UTC

tommos0 wrote: post #70

bonoboTP wrote: post #48

Earlier quoted context omitted.

The package manager is only an option if you have root rights. Otherwise you either download binaries or compile it yourself, from the source downloaded from their website.

There are user space package managers, e.g. conda, flatpack and homebrew come to mind.

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

Re: Curl to shell isn't so bad

#83

Post by e12e » Sat, Nov 09, 2019, 1:37 PM UTC

> Either way, it’s not a problem with just pipe-to-shell, it’s a problem with any code you retrieve without TLS.

Well, yes. But the typical alternative is a tar-ball and a gpg signature - both via insecure transport, but verifiable (like with tls and a CA).

Git will typically be via ssh or https - so to a certain degree over a secure channel.

Re: Curl to shell isn't so bad

#84

Post by ZoomZoomZoom » Sat, Nov 09, 2019, 1:38 PM UTC

I think normalization of this practice makes the scripts the primary attack interest of the wrongdoers, and these scripts are often an easier target.

Re: Curl to shell isn't so bad

#85

Post by coldtea » Sat, Nov 09, 2019, 1:41 PM UTC

yoavm wrote: 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…

>Not so bad comparing to what?

Compared to donwloading a binary and 10 other similar methods people use.

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

Millions of people?

And even more just download binaries off of websites...

Re: Curl to shell isn't so bad

#86

Post by diogotito » Sat, Nov 09, 2019, 1:47 PM UTC

daxterspeed wrote: post #44

Is there a simple command you can use to read the contents of the script (pipe) before it's sent to sh? Something like: curl ... | less-and-maybe-cancel | sh

You can pipe the output of cURL to Vim like this:

  curl ... | vim -

Then, you can review the script, maybe tweak it a little, and you can send it to sh's stdin by running

  :w !sh

Or you can just quit Vim (:q! or ZQ) and nothing happens.

Re: Curl to shell isn't so bad

#87

Post by Boulth » Sat, Nov 09, 2019, 1:48 PM UTC

kijin wrote: post #78

Boulth wrote: post #50

Earlier quoted context omitted.

The problem with deb, rpm, etc is that you need to add instructions to all supported systems one by one. Check out this site for reference: https://www.sublimemerge.com/docs/linux_repositories and compare with curl URL|sh that can detect target system and delegate to appropriate system. Much simpler. The root cause of this is no universal packaging format for Linux in my opinion.

I understand the difficulty. But if you're going to write a shell script that detects the target system and takes different actions, you might as well move that logic to the packaging system. It's much more robust, especially when it comes to dependency management and updating. I wish there were a simple, modern, easily configurable tool that can take a declarative description of a project and spit out a ready-to-ser…

> you might as well move that logic to the packaging system

Depends on who do you mean by "you". Software vendor can definitely write a script but they have no power over distributions to "move that logic to the packaging system".

This would have to be a collaborative work by different distros but from my casual look it's just not happening as everyone is happy with their own package manager that's "obviously the best".

I do agree on systemd. I didn't like it before I moved to Linux now I see a lot of value that it brings.

This may also be relevant: http://0pointer.net/blog/revisiting-how-we-put-together-linu...

Re: Curl to shell isn't so bad

#88

Post by minxomat » Sat, Nov 09, 2019, 1:52 PM UTC

coldtea wrote: post #85

yoavm wrote: 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…

> Not so bad comparing to what? Compared to donwloading a binary and 10 other similar methods people use. > 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? Millions of people? And even more just download binaries off of websites...

Isn't there even a comment from Linus (could have been someone else) saying that he does exactly that and if that doesn't work gives up on the software?

Re: Curl to shell isn't so bad

#89

Post by brianpgordon » Sat, Nov 09, 2019, 1:56 PM UTC

yoavm wrote: 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 exactly the same as downloading a tar file from the developer's website over HTTPS. Same with npm. Some package managers like Maven and NuGet will rehost artifacts but if the project owner is malicious or compromised then that won't help - so the risk profile is again basically the same as downloading a tar file from the website.

Re: Curl to shell isn't so bad

#90

Post by heinrich5991 » Sat, Nov 09, 2019, 1:59 PM UTC

Carpetsmoker wrote: post #11

LIV2 wrote: post #7

I disagree with some of this, I.e paste jacking. Plenty of software projects put more care and focus into their software and not in their website, if you're running a vulnerable version of Wordpress or whatever CMS it'd be easy for someone to insert something malicious without being noticed whereas something that modified your code would show up in git, code reviews etc

Pastejacking should be mitigated if you use zsh, as it will never run pasted commands automatically. From quick test it seems that recent(?) versions of bash also implemented this feature and have it enabled by default. I don't know about fish or other shells.

Fish also does this.