Live data from Hacker News

curl | sh

curlpipesh.tumblr.com

101–110 of 115 posts

Re: curl | sh

#101
post #11

`curl ... | sh` installations don't really bother me. The scripts tend to be short and commented, or at least readable. Sure beats running an opaque .pkg installer, which invariably asks for your password (presumably for no reason) and installs god-knows-what all over your hard drive.

Generally, yes, but some package managers have code-signing support, which means if you trust the authors, you can avoid potential hijacks. At the end of the day, though, you're always going to trust someone with something.

[deleted]

Re: curl | sh

#102
post #5

Note that dowloading an app (.exe for windows, or an apple app) and running it, is just as bad. Downloading an installer, and running it, is also insecure. So the question is... What is the proper alternative? I think the best alternatives are appstores such as found on ios and android, right? However that doesnt really fit for open source. Is the way to install open source software, to download the source and compil…

No it's not because MSI packages and EXEs are signed so there is at least a chain of trust. SmartScreen kicks you in the face if it's not "known" by various metrics and it's hard to get around that these days (as someone who just had to get EV certs for their MSI). If you click through that, and you don't know what the source was then you're a muppet. curl + bash is suck and blam the machine. Hope you didn't do a sud…

SSL certificate signing provides basically the same level of trust as a signed installer. As long as you curl over https from the domain you trust, you're good.

Re: curl | sh

#105
post #13
post #8

It's obviously somewhat prone to failure, as the script can't possibly work in every environment. But other than that as long as it's over https is there a security issue? Obviously, a better alternative is a package manager, pulling from a repository for which you have gpg keys installed (such as Debian provides). But that's not always an option. Even checking out a git repository and building from source seems as b…

Both curl|sh and git checkouts tend to end up in production deploys so it's interesting to compare them. Both introduce a point of failure if the remote host becomes unavailable and you need to deploy new machines. The curl|sh method is vulnerable to change from the maintainer or any attacker who gets access to the storage layer. git is also vulnerable but requires a collision attack on SHA-1.

If a git clone from github fails, I can still git clone from the last production machine I successfully cloned to.

Re: curl | sh

#106
post #13
post #8

It's obviously somewhat prone to failure, as the script can't possibly work in every environment. But other than that as long as it's over https is there a security issue? Obviously, a better alternative is a package manager, pulling from a repository for which you have gpg keys installed (such as Debian provides). But that's not always an option. Even checking out a git repository and building from source seems as b…

Both curl|sh and git checkouts tend to end up in production deploys so it's interesting to compare them. Both introduce a point of failure if the remote host becomes unavailable and you need to deploy new machines. The curl|sh method is vulnerable to change from the maintainer or any attacker who gets access to the storage layer. git is also vulnerable but requires a collision attack on SHA-1.

If a git clone from github fails, I can still git clone from the last production machine I successfully cloned to. But this would be no different than curl -o installer.sh; rsync installer.sh; ssh remote@server 'sh installer.sh';

Mismatched SHA-1s are only noticeable when you have one to compare against. A git clone is always fresh, so if the attacker rewrote history, you'd not be warned.

Re: curl | sh

#107
post #96

Earlier quoted context omitted.

No it's not because MSI packages and EXEs are signed so there is at least a chain of trust. SmartScreen kicks you in the face if it's not "known" by various metrics and it's hard to get around that these days (as someone who just had to get EV certs for their MSI). If you click through that, and you don't know what the source was then you're a muppet. curl + bash is suck and blam the machine. Hope you didn't do a sud…

> No it's not because MSI packages and EXEs are signed Is it more difficult to provide your own fake exe installer than to middle-man https that curl examples use?

The question is, is it easier to place your code on that curl site. If there is some web-layer vulnerability, you can put your own code there.

With signed MSIs and EXEs, you'd need to get your code signed, which is probably more difficult than the web layer.

Re: curl | sh

#108
I think not saving the script somewhere first makes it worse, You can't go back and inspect what it has actually done in the worst case scenario. To install rust the other day and had to read the whole script to be sure.

Re: curl | sh

#109
post #7

I don't see how this is less secure than downloading a program and running it. Or downloading some package that asks you to run an install script. People will see no problem with curl | sh as long as they feel they can trust the source/site asking them to do so. They will be running the same risk as with downloading binaries or install packages.

Exactly. This is little more than cargo culting.

I'd at least save the script somewhere so i can audit it if something goes wrong after i run it.

Re: curl | sh

#110

Earlier quoted context omitted.

No it's not because MSI packages and EXEs are signed so there is at least a chain of trust. SmartScreen kicks you in the face if it's not "known" by various metrics and it's hard to get around that these days (as someone who just had to get EV certs for their MSI). If you click through that, and you don't know what the source was then you're a muppet. curl + bash is suck and blam the machine. Hope you didn't do a sud…

SSL certificate signing provides basically the same level of trust as a signed installer. As long as you curl over https from the domain you trust, you're good.

Actually no as that signs the communications and not the software. If the target server is compromised then you are screwed. Also for example there is no guarantee that github.com isn't serving malicious traffic from one user under a legitimate request I.e. the poisoned sharecrop problem.

EV signed software is usually done off the internet. In our case we use a physical key to sign it offline and then upload.

Post reply on HN