On: Hashpipe – Pipe iff the hash matches

[dcposch]

I don't see how this gives additional security. When you run

   curl https://project.com/script.sh | sh

...you're relying on three things:

1. That the people running the project are trustworthy

2. That the server hasn't been compromised

3. That the CA system will ensure you're talking to the correct server

(I can think of recent news stories where each of those were violated.)

If, instead, you go to `https://project.com`, read the instructions, and paste in the following command...

   curl https://project.com/script.sh | hashpipe <somehash> | sh

..then you're relying on those same three things! Someone who wants to serve a modified version of `script.sh` just has to serve modified instructions as well. You also have a new requirement: you have to get a trusted install of hashpipe first.

[xnyhps → dcposch]

There is another assumption:

4. You download the script successfully.

It is trivially easy for a MitM to interrupt the download of the script between two TLS packets, without any CA or server compromises. When you do:

    curl https://project.com/script.sh | sh

Then sh happily executes instructions as they come in. It may be that the script starts by moving important directories aside or by creating large temporary files, so if the script is incomplete the user may end up with a broken system. Or maybe if you're really unlucky an attacker might manage to truncate "rm -Rf /..." to "rm -Rf /".

With hashpipe, you are at least guaranteed to have the complete script before you run it. I still don't like the practice, but it is better.

[vincentclair → dcposch]

You add an extra layer of security, if you receive the hash over a different channel, such as encrypted messaging.

That means, that even if the CA system is broken, you only execute the intended contents.

[ZoFreX → vincentclair]

> That means, that even if the CA system is broken, you only execute the intended contents.

No it doesn't - how are you installing hashpipe? ;)