Do you also audit the sources of the programs installed by that install.sh? Do you make sure the binaries and sources match? If not, why? What makes the shell script so special that it must be audited with care, but the binaries are fine?

I do not use any "install.sh" that installs freestanding binaries. All of the ones I use just sets up repositories, and I make sure that the repositories are the correct/legit ones. If I have to install a freestanding binary, I compile it from source and install.

Since all the repositories are signed there must be a big breach to compromise these packages since the infrastructure is generally distributed. Different servers, keys, etc.

> What makes the shell script so special that it must be audited with care...

Because I need to know what changes I'm incorporating into my system(s), and plan accordingly, or prevent any change which is not in line with my system administration principles.

> ...but the binaries are fine?

They are not fine, but they are signed at multiple levels and checksummed, so they are a lower risk.

Your risk model is kinda perverse. You're saying you trust package maintainers because they sign things. So if I send you a signed script that checksums itself before running will you run that without audit?

It’s trust all the way down and always has been. You just have a different idea of how you formally signal and convey trust than someone else.

I paste commands into the terminal because I can read exactly what they do and they are delivered over a connection where my user agent has verified the TLS certificate of the server. In fact I’m electing to trust directly rather than transitively the source of the software.

The only thing signed files prevents is modification in transit (and at rest on macOS/iOS and Windows, Linux doesn’t do that). Linux is ripe with time of check vs time of use race conditions.

I think I failed to make myself clear. I don't trust the package maintainers, I trust the supply chain and the process.

For example, a well maintained APT repository contains multiple levels of signatures, and these signatures are stored in a keyring. You import the keyring, and it contains public key of every package maintainer, plus the repository manager. So, package maintainers sign their packages, and repository maintainer signs the repository, plus the packages via their checksums. Packages' own signatures and own checksums provides consistency and authenticity checks, and repository maintainer's signature makes sure that nothing in the repository moves after the repository is signed and published.

So, you have to compromise at least two private keys (or two people) to compromise a repository. If you're working with a critical repository, you can use "m of n" scheme for the repository signing keys, so you need to compromise m+1 people to do something nefarious.

> So if I send you a signed script that checksums itself before running will you run that without audit?

Hard no. You don't have a verifiable chain behind that script. Even if you do, scripts are always read and examined. Period.

> I can read exactly what they do and they are delivered over a connection where my user agent has verified the TLS certificate of the server.

Yes, a TLS certificate guarantees that MITM is impossible for now. But it doesn't guarantee that server has not been compromised and the file changed at rest. We have seen that happened in the past.

> The only thing signed files prevents is modification in transit ...

No. Both RPM and APT repositories' signature chains ensure that files are not modified at rest or at transit, plus the files are put into the repositories with an approval of a real human being.

These signatures are tip of a "web of trust" iceberg, and not mere automated signatures.

Moreover, if a software doesn't inspire confidence and doesn't pass the smell test, it doesn't get installed on my system anyway, regardless of its form.

If I have to install it, I install it to an isolated VM, and destroy the VM as soon as my work is done with it.