The problem is, doing this for a specific project you really trust is not a problem. But what you’re actually teaching inexperienced programmers, that this is true in the general case. Would you run a one liner like this if I sent it to you and it was hosted on GitHub?
The very intelligent people at Docker used to have this pattern at get.docker.io. They changed it.
And to obfuscate the attack, I think typo squatting in package managers like npm and pip, might be a blue print.
I really don't think anyone is being taught anything misleading here. curl|bash makes very clear that it's running arbitrary code as you, and I think almost everyone who invokes it does in fact understand that.
If anything, I think package managers create a false sense of security, especially ones that allow anyone to publish packages and declare dependencies on anything else. Installing an npm package -- even one from someone you trust -- could very easily transitively install something malicious. Debian packages are arguably better in that not just anyone can push packages to Debian's main package repo, but there's still a very real danger of a hidden backdoor. But I think a lot of people just assume installing from a package manager is not dangerous.
> The very intelligent people at Docker used to have this pattern at get.docker.io. They changed it.
Probably not for security reasons, though. There's a separate, very legitimate argument for distro packages, which is that they implicitly promise to play nicely with your distro's conventions and install themselves in a clean, manageable way. How to update or uninstall a distro package is well-defined. None of this is actually guaranteed, of course -- a package can do whatever it wants in an install hook. But assuming you trust the developer isn't malicious, then you can get some comfort knowing the package is unlikely to screw up your system.
curl|bash provides no such promise, even implicitly. Who the hell knows what it might decide to do. Maybe it has one of those `rm -rf $SOME_VAR_THAT_MIGHT_NOT_BE_DEFINED/*` bugs like Steam did at one point.
Sandstorm is careful to avoid messing up anything, installing itself to a self-contained directory, and providing an uninstall script. But the user doesn't really know that in advance.
The reason to use curl|bash in spite of this is because distro packaging is a lot of work (there are a lot of distros!) and may not be the best use of time for a small project. Docker is definitely big enough to do it, though.
So yeah, there's definitely a cleanliness argument. But the security argument is bogus.
It's still downloading and executing a script, just two steps instead of piping the output straight into bash.
You can't even inspect the code you run when you do curl|bash and the server is able to detect this distinction and hide code when you do a curl and then run bash.
You got me. The last time I installed Docker, I remember doing it using packages, so I assumed that was the replacement. Looking at their comment, it looks like they got tired of people arguing about it, so they changed the instructions to sidestep the argument. I don't think they seriously believe this made a security difference.
> You can't even inspect the code you run when you do curl|bash and the server is able to detect this distinction and hide code when you do a curl and then run bash.
I addressed exactly this argument two comments ago.
> Your argument is: "we do it and we use GitHub, you can trust us and can trust GitHub, you don't need to verify the code you run."
When did I ever say anything about GitHub? This isn't my argument at all.
> And devs learn: "Trust me, you don't need to verify the code you run."
Come on, nobody actually verifies all the code they run.
The very intelligent people at Docker used to have this pattern at get.docker.io. They changed it.
And to obfuscate the attack, I think typo squatting in package managers like npm and pip, might be a blue print.