Even if I reviewed the code, that would not be enough to be safe with that install procedure. The difference is that it is known that the server can detect the client being used and serve different content to different consumers. Nevermind trusting the author, or some previously reviewed code, you also have to trust the delivery system. There are also degrees of trust. I might trust someone's code that was laid in plain sight but I might not trust a binary or obfuscated thing allegedly containing the same code.

What operating system do you use? How do you set it up without trusting many third parties? What delivery system would you recommend?

Everyone can easily clone the Omakub repository to their own server, review it, and use it from there. Should that be the recommended installation method? How do you deal with updates?

The recommended installation method should be to download the script, check the hash of the thing you downloaded against the hash of what you thought you were getting, and then run it. Obviously if you don't trust the author, you should do more research until you reach a conclusion.

If you ask me, you should do vetting proportional to the amount of time you have and the risk involved in a compromise of your system. That may practically mean that you won't install much of anything except via the most well popular software channels. Even then, you may opt to compile the stuff. If you don't have enough skills or time to do this vetting, you should err on the side of caution.

How do you distribute the hashes?

Do you read all the source code you compile?

The hash can be on the web server. Ideally you would do something with cryptographic signatures, or at least get the hash a different way than the file itself. Obviously I don't have time to read all the code I compile but I don't run code that I can't even inspect reliably. It's like leaving your door unlocked, or something like that.

You might not realize but there are several ways you can be compromised. What if the web server was set up to serve some exploit when you download from a terminal (which is doable), or else you were intercepted by a man in the middle? Both of those exploits have been demonstrated and aren't even difficult to do. They also require no involvement from the author of the software. If it's downloading other stuff, each of those items also has the same concern.

> The hash can be on the web server.

Wait, wasn't the hash supposed to help when the web server is compromised?

Man in the middle is also a problem for the hash. I really don't see what this theatre is about...

It's not theater. You're right that the hash could be compromised if the server is compromised, but it is one thing besides the code that you can use to check the integrity of your download. It is right in your face and obvious, so it is less likely to be faked. As I said, the download can be compromised, and it makes the most sense for it to be compromised in a way that is not obvious. When there's a hash you can check that the thing you downloaded is in fact what it was advertised to be. The hash can also be obtained outside the target environment and checked separately for an extra measure of security. People publishing exploits don't know if you are auditing or not. When you make them commit to a specific version of the code, then they can't randomly inject garbage as easily.

I already explained how the code could end up not being what you thought it was. If a we server randomly serves exploits to 1% of requests, or intelligently detects non-interactive downloaders, you can get hacked that way. And if you don't even save the script, you can't even look at it if you have doubts.