Please don't tell people to do this. This is an idiom called "curl pipe sh"; you're asking people to run whatever code someone on their network decides to send them.
As an absolute minimum, you should change that http to https, so that they're merely running whatever code YOU decide to send them; but even that doesn't quite fit with the "share your terminal (read-only)" philosophy...
I agree with the HTTPS part, but aside from that I can't really see how it's less safe than saying "here, install this .deb (which gets to run scripts as root) and then run the binary inside".
deb packages distributed to the public should be pgp signed and in a proper repository. It doesn't help people who will just force-install it anyway, but if they care it allows verification.
Out of band verification. When you're doing curl pipe sh, you're trusting the host and that's it. With packages, you can verify the trust against external services like keybase, check website archive for changed key ids, check signatures on the public key if the author is into things like web of trust.
It won't protect you against someone being directly malicious, but it will against MitM, website hacks, etc. It also establishes semi-permanent trust on first use.
>Out of band verification. When you're doing curl pipe sh, you're trusting the host and that's it. With packages, you can verify the trust against external services like keybase, check website archive for changed key ids, check signatures on the public key if the author is into things like web of trust.
You could use hashpipe (https://github.com/jbenet/hashpipe), from Juan Benet (the author of IPFS). It simply checks that the input to the command matches a given hash, so you can do `curl <url> | hashpipe <hash> | sh`, and if the output of the curl command is different than expected it won't be passed in to `sh`.
Ironically the prebuilt binaries of hashpipe itself are provided without means of verification :I
So if you are going to use hashpipe, I think you should download it in source form, read it -- it's under 100 SLOC -- and then build it from source yourself. This way, you do that once and then in the future provided that you trust those sending you various scripts and binaries and the channel they used to provide the hash, all is well and no further manual verification is needed on your side of things ever again for any of those.
If an attacker can modify the output of the curl command (on the host or on the wire), cannot they also modify the value of the hash seen and copy-pasted by the end-user? I must be missing something...
As viraptor said, putting code into a public repository (e.g., debian packages); that way there should be a paper trail if the code is modified.
Beyond that, there's a simple matter of advertising: "Share your terminal (read-only)" may mislead some people about what is happening. A more accurate description would be "Give us control of your terminal (we promise we'll only let other people read it, not write anything)".
Imagine if this principle were applied to other software products. "Click here to download the Office installer, which will gain full admin-level access to your machine. We promise to only use that to install Office."
The only thing sent to shellshare's servers is the text in your bash terminal. There's no return channel for the servers to send commands back to the computer.
You could argue that you're giving control of the terminal because you're running a third-party executable, but that's the same for any executable you run.
Please don't tell people to do this. This is an idiom called "curl pipe sh"; you're asking people to run whatever code someone on their network decides to send them.
As an absolute minimum, you should change that http to https, so that they're merely running whatever code YOU decide to send them; but even that doesn't quite fit with the "share your terminal (read-only)" philosophy...