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

161–170 of 201 posts

Re: Curl to shell isn't so bad

#161

Post by tuldia »

pm7 wrote: post #150
tuldia wrote: post #111

Earlier quoted context omitted.

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

> It can (and does) take days for critical security updates to migrate from unstable to testing after stable has access to patched version.

Now you are making way to many assumptions with this phrase.

Do you really think that make sense to have critical security updates for stable having to pass through the normal release cycle? :)

Re: Curl to shell isn't so bad

#163

Post by goatinaboat »

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's probably quite a similar risk. But who does that?

After downloading you can at least do some sanity checks - even if you don’t checksum it if you are familiar with it does it look right? Is make doing anything weird? Whereas curl|sh doesn’t give you this opportunity.

Re: Curl to shell isn't so bad

#164

Post by jonathanwall »

sigjuice wrote: post #147
dmitriid wrote: post #51

Earlier quoted context omitted.

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.

isn't brew itself a curl'd script?

Re: Curl to shell isn't so bad

#165

Post by tuldia »

axaxs wrote: post #115
tuldia wrote: post #104

Earlier quoted context omitted.

Ubuntu is nothing more than the Debian "unstable" branch with Canonical branding plus non-free packages. Compare https://distrowatch.com/table.php?distribution=debian and https://distrowatch.com/table.php?distribution=ubuntu and you will realize that all the freshness of Ubuntu is build on top of what is available in Debian unstable. I don't think this idea of "Debian packages are often very outdated" still applies n…

> Ubuntu is nothing more than the Debian "unstable" branch with Canonical branding plus non-free packages. This just isn't true. Ubuntu is typically quicker to update popular packages, such as desktop environments, kernel, etc. Debian unstable, even experimental, are often months behind on Gnome, for example.

https://en.wikipedia.org/wiki/Ubuntu#History

Re: Curl to shell isn't so bad

#166

Post by Barrin92 »

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…

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

are you asking who compiles and runs software? A lot of people, for example I every time a new emacs version comes out and it isn't in the package manager yet

Re: Curl to shell isn't so bad

#167

Post by tln »

vbezhenar wrote: post #148
y4mi wrote: post #33

Earlier quoted context omitted.

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.

True, you can detect it without a way to stop the damage! Or easier and more thorough,

    curl | bash -x

Re: Curl to shell isn't so bad

#168

Post by tln »

heinrich5991 wrote: post #92
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... .

FWIW docker doesn't publicize those instructions, they give:

    curl -fsSL https://get.docker.com -o get-docker.sh
    sh get-docker.sh
And, it's the only one of the examples listed in the article that doesn't pipe to shell.

Re: Curl to shell isn't so bad

#169

Post by eikenberry »

tuldia wrote: post #135
titanomachy wrote: post #124

Earlier quoted context omitted.

Making Debian packages is a colossal pain in the ass, or at least it's poorly documented. I've tried to learn it twice and abandoned it for more user-friendly solutions to the problem. Some people may say I'm stupid for not figuring it out, but the standard for usability of software has improved a lot since these systems were invented. The UX needs a serious overall.

I guess you are exagerating quite a bit. Creating a Debian package is actually pretty straight forward: 1. download upstream tarball. 2. execute dh_make -f 3. debuild -us -uc -b That is it! There is no secret. dh_make does the heavy lift of generating everything you need. Your only job is to declare the dependencies (build and runtime ones) inside the "control" file, maybe change the "rules" file (it is a Makefile).…

> That is it! There is no secret.

I've been using Debian for 20 years and have never seen this advice. I currently use custom scripts for building local packages of things.

I think this comes down to Debian's weak documentation. The recommended intro guide from the wiki page [1] doesn't say this and looking through the maintainers guide I do see this [2] in there but it is buried in pages and pages of other docs.

Really, someone needs to write a new basic intro that doesn't bury the lede. It should start with this then expand on what to do for various issues.

Or maybe start with one of those 99% automation options. If they are even easier. As is you cannot find this information without some person telling you as you cannot find it by searching for it or reading the docs.

[1] https://wiki.debian.org/Packaging/Intro

[2] https://www.debian.org/doc/manuals/maint-guide/first.en.html...

Re: Curl to shell isn't so bad

#170

Post by beatgammit »

samueloph wrote: post #97
jacobush wrote: post #95

Earlier quoted context omitted.

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)

Yup, and Debian recently started committing to 5-year support cycles, so it's basically the same as Ubuntu LTS releases (can skip one, but not two releases), with the difference that Debian is released when it's ready, whereas Ubuntu is released on a schedule.

Personally, I don't trust Ubuntu LTS releases until they get their first point release, and even then I'm skeptical since they're a bit more loose with package versions on stable. I do trust Debian when it first releases because they're far more rigorous in their testing, though I usually wait a week or two before doing a release upgrade just in case.

I used to really like Debian testing, but I've since moved to OpenSUSE because they have a real rolling release (for my desktop) and a solid release based version (for servers). I like Debian, but testing gets a bit sketchy around release time (frozen, and then a ton of updates), and I honestly don't trust Sid aside from pulling in the odd package. I don't trust Ubuntu at all, since it has caused me far too many problems in the past.

Post reply on HN