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

Curl to shell isn't so bad

arp242.net

Post reply on HN
Print view View original

91–100 of 201 posts

Re: Curl to shell isn't so bad

#91

Post by OskarS »

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

Yeah, "vipe" from moreutils (which is a package on most platforms) does this. It inserts $EDITOR (usually vim) into the command pipe, and allows you to review and/or edit the text before passing it on to the next thing in the pipeline. Great little command line utility, for all sorts of things.

If you want to cancel, just erase the file. Or `:cq` in vim probably works as well.

Re: Curl to shell isn't so bad

#92

Post by heinrich5991 »

tandav wrote: post #25

I always install docker using simple command curl -fsSL get.docker.com | sh Instead of copy pasting dozen of commands from docs / SO

That looks vulnerable to MITM since it doesn't use HTTPS. Indeed, I just looked it up, it's not in the HSTS preload lists of any browser: https://www.ssllabs.com/ssltest/analyze.html?d=get.docker.co....

Re: Curl to shell isn't so bad

#93

Post by HankB99 »

ivanstame wrote: post #80
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…

Well if this was true "Every decent Linux distro has a package manager that covers 99% of the software you want to install" we wouldn't have to install it thru sh.

For one of the examples provided, rustup.sh, there were not complete packages the last time I looked for them. There were some packages on Debian and Fedora but I ran into problems configuring the Rust plugin for VS-Code because it assumed that the rustup executable was present and it was not (at that time.) Going down this path, one then becomes dependent on using rustup to update the Rust installation. Now I need to run two commands to keep my system up to date. (pip? Make that 4 commands pip, pip3. CPAN? Yet another.)

I have some confidence that at the least the Debian packages won't be changing rapidly, making it more likely that any problems will be discovered before they get to me. A script (or tarball) fetched and installed from the Internet can change literally from one second to the next. If a trusted site is compromised the next download could be tainted.

Not all "package managers" instill confidence. I've heard too many bad things about npm and the associated environment and won't have it on my systems, but I am not a web developer so the impact is the occasional utility I have to forgo.

Re: Curl to shell isn't so bad

#94

Post by amalcon »

glic3rinu wrote: post #27
mkup wrote: post #16

If curl loses connection to the source website while downloading the script, then partially downloaded script will be executed, no matter what. This is a main drawback of curl-to-shell piping approach, and the original article is missing it entirely.

A common solution is to wrap all code within a function. This way nothing gets executed until the last line, the one that calls the function, is executed. function main () { # all code goes here } main

Common, but not universal. If I pipe a response body into a shell, I don't get to check whether they were careful or not.

Re: Curl to shell isn't so bad

#95

Post by jacobush »

mirimir wrote: post #81
hannob wrote: post #36

Earlier quoted context omitted.

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

I'd go back to Debian and their stale packages if only they had scheduled releases like Ubuntu has. Imagine Debian 19.10, 20.04 and so on, with Long Time Support on the .04 releases every other year. What a bliss.

Re: Curl to shell isn't so bad

#96

Post by samueloph »

mirimir wrote: post #81
hannob wrote: post #36

Earlier quoted context omitted.

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

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

Re: Curl to shell isn't so bad

#97

Post by samueloph »

jacobush wrote: post #95
mirimir wrote: post #81

Earlier quoted context omitted.

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.

I'd go back to Debian and their stale packages if only they had scheduled releases like Ubuntu has. Imagine Debian 19.10, 20.04 and so on, with Long Time Support on the .04 releases every other year. What a bliss.

Debian has been doing a stable release every two years since 14 years now. If you want the equivalent of a non-LTS Ubuntu release, you should use Debian Testing (besides the naming, it's pretty stable)

Re: Curl to shell isn't so bad

#98

Post by kijin »

Boulth wrote: post #87
kijin wrote: post #78

Earlier quoted context omitted.

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 bes…

> This would have to be a collaborative work by different distros

I think there was a misunderstanding between us. I didn't mean anything so complicated.

By "moving that logic to the packaging system", all I meant is that instead of using a script to detect whether your app is being installed on Ubuntu or Fedora or whatever, you should just build and publish separate packages for each distro you wish to support. The logic for selecting the right package for itself is already built into every packaging system, ready for anyone to use.

Hopefully the process of building a dozen packages with each release can be easily automated once it is set up.

Re: Curl to shell isn't so bad

#99

Post by Un1corn »

ivanstame wrote: post #80
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…

Well if this was true "Every decent Linux distro has a package manager that covers 99% of the software you want to install" we wouldn't have to install it thru sh.

4/5 of the examples the author gave have a package in Fedora. The one that doesn't (oh-my-zsh) is simply a git clone so it doesn't make much sense to package it.

Re: Curl to shell isn't so bad

#100

Post by jchw »

pacifika wrote: post #75
jchw wrote: post #2

Agreed. If I don’t trust the server, or don’t have a secure connection to it, it is not likely wise to run any non trivial code downloaded from it. Verifying a hash that comes from the same server also doesn’t make that much sense. Verifying a PGP signature would be a compelling reason to not pipe to shell, and that’s really about it.

Just because the connection is secure doesn’t mean it’s controlled by a trusted entity

Then perhaps running any non-trivial code from it is blisteringly unwise.
Post reply on HN