3 ms·
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 b
by zimbatm 12y ago
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.
- 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.