Hacker News Reader

Comment by cperciva | Hacker News Reader

wget -qO shellshare http://get.shellshare.net && python shellshare

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...

View on HN

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.

Both require trusting others, how is this any different?

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.

Your grandma is pretty advanced.

> Your grandma is pretty advanced.

Grandma level: Grace Hopper.

Who said anything about grandmas. The topic was "what's better than curl pipe sh". The target crowd knows how to use the terminal.

But if the software is already installed, trusted package author also allows secure updates.

Totally agree on the HTTPS. Wanted to change it for a while but life kept on the way. Changed it now, it's live on https://get.shellshare.net.

I also agree on the bad sides of the "curl pipe sh" pattern. Ideally, that command would be "apt-get install shellshare && shellshare", but haven't been able to write packages for it yet. There're 2 open issues about this: https://github.com/vitorbaptista/shellshare/issues/28 and https://github.com/vitorbaptista/shellshare/issues/31, if you or anyone else have some time to contribute.

What's a better alternative?

Download it, audit the code, and then do python shellshare

Boring, you need to live on the wild side a bit more :D

> Download it, audit the code

Applies to your operating system as well, plus any firmware.

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."

That would be awesome. Users might start to understand security.

Users don't read.

As usual, you can never be sure unless you read the code, luckily, it's very small: https://github.com/vitorbaptista/shellshare/blob/master/publ...

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.

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...

Reply on news.ycombinator.com