5 ms·
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 secu
by new299 12y ago
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 bad a curl | sh to me.
- zimbatm 12y agoBoth 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.
- new299 12y agoIf you're running it in production then that's a problem. But I'd dare say that relying on an external "apt-get install xxx" is pretty bad practice in production (to deploy new machines).
- zimbatm 12y agoI agree but most companies I know don't have the infrastructure or best-practices in place to avoid it. Copy-pasting the curl|sh is very low effort and will predictably end up in deploy code (if you have any).
- pritambaral 12y agoIf a git clone from github fails, I can still git clone from the last production machine I successfully cloned to.
- pritambaral 12y agoIf 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.