Earlier quoted context omitted.
Would something like curl http://google.com/keylogger.sh > temp.sh && sh temp.sh work?
More like: curl http://google.com/keylogger.sh > temp.sh less temp.sh # actually read the fucking thing sh temp.sh rm temp.sh
curl | sh
61–70 of 115 posts
Re: curl | sh
#62Earlier quoted context omitted.
That goes for every software you install. The only solution is to not install any software. And then hope that the preinstalled software on your device is OK:
OR I could verify an asymmetric cryptographic signature based on a public key I already possess. As long as the private key is not stolen, an attacker who can breach the server cannot backdoor the software I'm downloading.
Re: curl | sh
#63Earlier quoted context omitted.
More like: curl http://google.com/keylogger.sh > temp.sh less temp.sh # actually read the fucking thing sh temp.sh rm temp.sh
Somewhat inexperienced with linux/unix. What's the purpose of "less temp.sh" here?
Re: curl | sh
#64Earlier quoted context omitted.
OR I could verify an asymmetric cryptographic signature based on a public key I already possess. As long as the private key is not stolen, an attacker who can breach the server cannot backdoor the software I'm downloading.
How do you get the public key? I've heard the ssl certificate system that ships with browsers is broken, too. Maybe it would be an improvement to create a small command line tool that ensures https connections and asks for a hash before running a script?
Re: curl | sh
#65My thing with piping curl to a shell was always that a severed connection will run a partial script, which can have weird consequences. I wrote about it awhile back: http://blog.seancassidy.me/dont-pipe-to-your-shell.html
Would something like curl http://google.com/keylogger.sh > temp.sh && sh temp.sh work?
Re: curl | sh
#66Earlier quoted context omitted.
OR I could verify an asymmetric cryptographic signature based on a public key I already possess. As long as the private key is not stolen, an attacker who can breach the server cannot backdoor the software I'm downloading.
Which is exactly the same as you verifying the public HTTPS key of the server you're downloading the software from; in reality, the only thing that differs is the server you're targeting (the compilation server, v.s. the downloading server).
Re: curl | sh
#67Earlier quoted context omitted.
Sure, but if the server response is not pipelined (as is probably often the case), then bash should never see anything.
HTTP pipelining is about reusing a TCP connection for multiple requests. It doesn't influence when curl outputs data and wouldn't apply here anyway. I don't think there's any mode which would cause curl to buffer the entire response before writing any of it.
Re: curl | sh
#68Note 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…
Trust is really the only solution, we as developers might be able to inspect some code before we run it but if it is sufficiently complex we could spend months auditing it. Even worse for the non-technical users that can't tell a hello world from a keylogger, there really is no solution other than some trust based system.
Re: curl | sh
#69Earlier quoted context omitted.
OR I could verify an asymmetric cryptographic signature based on a public key I already possess. As long as the private key is not stolen, an attacker who can breach the server cannot backdoor the software I'm downloading.
Which is exactly the same as you verifying the public HTTPS key of the server you're downloading the software from; in reality, the only thing that differs is the server you're targeting (the compilation server, v.s. the downloading server).
Re: curl | sh
#70Earlier quoted context omitted.
Why don't shells NOT execute a command if there's no trailing EOL character, to mitigate this very problem?
Why should shells encourage this behaviour (piping unknown stuff to them?) You should at least download, verify the size and checksum (if available), take a peek at it, and only then run it.