is just evil. That's a great way to own a machine. You can even read the code today, but run the command tomorrow when someone had replaced the code with a giant exploit. Not saying there is a better way to distribute something like this that is as easy to use, but damn, this is just asking for trouble.
Well, technically, I trust the Debian developers to do that for me. And I verified that they have approved of the software automatically, by checking their signatures on the Release file, which contains the hashes of the packages.
If I have the option to, yes. Or rather I take much less care to actually read the code when I am installing a package out of the Debian repo's. Otherwise, I at least try to review what the heck that I am installing, especially on my own machine.
Nope, "curl |bash" is worse, because (a) if there's any network problems when downloading it might split a command in half. like "rm -rf /tmp/$PID". What happens if the bytes after the first / are dropped? and (b) at lease you have the option of reviewing it when you download the script.
So does any package installation where you don't read the source. Piping curl into the shell is bad because the server can choose to serve malicious content to your curl that it didn't show in the browser.
Piping curl into the shell is bad because the server can choose to serve malicious content to your curl that it didn't show in the browser.
And to head off objections, Piping curl into the shell does not leave any record on disk, unlike the "download .... ./execute" workflow in which it is trivial and natural to insert "and take a quick peek at it too".
Edit: And in the best case scenario, where the script delivered by curl is perfectly innocent, it is still a bad idea since you are left with no authoritative record of what was done. You could run curl again in the future, but that assumes that the same version is delivered, or that the file is still there at all.
Not quite true. Not all packages are created equal. For example anything from PyPI, npm, Ruby Gems, and Homebrew is suspect. On the other hand Debian/Ubuntu or Red Hat repo's are likely much more trustworthy since they have actual paid trusted maintainers who review the source code.
Not sure where you got that impression. In lots of cases, package maintainers are people who use the software and are volunteering their time to bundle it up with the necessary bits to put in a distro repo. The same is true of language-specific repos or homebrew.
Run the command, then look through the local copy to make sure it's safe. Once you have downloaded the code, there's no way that the project owner could change your copy.
Not sure if you replied to the wrong comment by accident, but the person you replied to is agreeing with you, while making a general statement about how they wish more people checked the code they're running between the download and run steps.
A benefit of this is you can also use it in your node programs (and clientside JS if you use something like browserify.)
And like any software you install that doesn't run in a sandbox, you should look at the source before running it or have some other reason for trusting it. (I briefly thought about how ironic it would be to have this program do something evil, but decided against it.)
I know that, I did not want to be evil writing that in the instructions but that's the best way to copy that file, also this is a file to be executable, so even if you use wget you are asking for trouble, downloading a file to your $PATH and making it executable, do you have any idea on how to improve the instructions?
When are these comments going to stop? Everyone lazy enough is going to keep suggesting "curl install" and everyone lazy enough is going to keep using it, and everyone that has something worth protecting and cares enough is either not going to use it or is going to audit it anyway, and comments like this aren't going to move anyone between those camps.
If you all think "curl install" is so evil then build something secure to replace it. It's got to be as easy from a "package maintainer" as well as a user's perspective, and you have to figure out some way to validate security. But until then, warning people that they should read code they execute is a waste of bandwidth.
Comments
Great idea, one random nitpick:
is just evil. That's a great way to own a machine. You can even read the code today, but run the command tomorrow when someone had replaced the code with a giant exploit. Not saying there is a better way to distribute something like this that is as easy to use, but damn, this is just asking for trouble.How is it worse than: $ ./configure && make
I guarantee you that it'd be easier to hide something nefarious in 3000 lines of autoconf boilerplate.
It's not. And at least the download here is over HTTPS, not HTTP. But you are right, both are vulnerable unless the user is ready to be cautious.
Well if it's not, then how exactly is it "evil"? Do you audit install scripts and source code before using software?
Well, technically, I trust the Debian developers to do that for me. And I verified that they have approved of the software automatically, by checking their signatures on the Release file, which contains the hashes of the packages.
So you only install signed Debian packages then?
If I have the option to, yes. Or rather I take much less care to actually read the code when I am installing a package out of the Debian repo's. Otherwise, I at least try to review what the heck that I am installing, especially on my own machine.
I think you may have mistaken that for the "curl ...|sh" idiom?
Not really: unless you inspect ~/bin/hr before using or updating it, both boil down to the same thing.
Nope, "curl |bash" is worse, because (a) if there's any network problems when downloading it might split a command in half. like "rm -rf /tmp/$PID". What happens if the bytes after the first / are dropped? and (b) at lease you have the option of reviewing it when you download the script.
This doesn't contradict at all what I said. (See http://idioms.thefreedictionary.com/boil+down+to)
So does any package installation where you don't read the source. Piping curl into the shell is bad because the server can choose to serve malicious content to your curl that it didn't show in the browser.
And to head off objections, Piping curl into the shell does not leave any record on disk, unlike the "download .... ./execute" workflow in which it is trivial and natural to insert "and take a quick peek at it too".
Edit: And in the best case scenario, where the script delivered by curl is perfectly innocent, it is still a bad idea since you are left with no authoritative record of what was done. You could run curl again in the future, but that assumes that the same version is delivered, or that the file is still there at all.
Not quite true. Not all packages are created equal. For example anything from PyPI, npm, Ruby Gems, and Homebrew is suspect. On the other hand Debian/Ubuntu or Red Hat repo's are likely much more trustworthy since they have actual paid trusted maintainers who review the source code.
Not sure where you got that impression. In lots of cases, package maintainers are people who use the software and are volunteering their time to bundle it up with the necessary bits to put in a distro repo. The same is true of language-specific repos or homebrew.
Run the command, then look through the local copy to make sure it's safe. Once you have downloaded the code, there's no way that the project owner could change your copy.
Yup, that's the only way to see if what you are downloading is safe. Unfortunately, not many people will do that.
And how is this different from downloading any other source code or compiled executable from the web?
Not sure if you replied to the wrong comment by accident, but the person you replied to is agreeing with you, while making a general statement about how they wish more people checked the code they're running between the download and run steps.
I just built a nodejs version of this, available on npm.
http://www.github.com/jaredsohn/hr
Install it via 'npm -g install hr'.
A benefit of this is you can also use it in your node programs (and clientside JS if you use something like browserify.)
And like any software you install that doesn't run in a sandbox, you should look at the source before running it or have some other reason for trusting it. (I briefly thought about how ironic it would be to have this program do something evil, but decided against it.)
I know that, I did not want to be evil writing that in the instructions but that's the best way to copy that file, also this is a file to be executable, so even if you use wget you are asking for trouble, downloading a file to your $PATH and making it executable, do you have any idea on how to improve the instructions?
I honestly don't know of another way, other than encouraging the user to read the code.
Make a Homebrew version :)
Practical example: http://russianroulette.sh
When are these comments going to stop? Everyone lazy enough is going to keep suggesting "curl install" and everyone lazy enough is going to keep using it, and everyone that has something worth protecting and cares enough is either not going to use it or is going to audit it anyway, and comments like this aren't going to move anyone between those camps.
If you all think "curl install" is so evil then build something secure to replace it. It's got to be as easy from a "package maintainer" as well as a user's perspective, and you have to figure out some way to validate security. But until then, warning people that they should read code they execute is a waste of bandwidth.
It's never a waste of bandwidth if it prompts one person to do the critical checks and prevents them from being owned.