upvote
> Are you really checking all the files in there, even the binaries?

One should never trust the binaries, always build them from source, all the way down to the bootloader.

https://bootstrappable.org/

Checking all the files is really the only way to deal with potential malware, or even security vulns.

https://github.com/crev-dev/

reply
Nice ideal, but Chrome/Firefox would take days to build on your average laptop (if it doesn't run out of memory first).
reply
The latest Firefox build that Debian did only took just over one hour on amd64/armhf and 1.5 hours on ppc64el, the slowest Debian architecture is riscv64 and the last successful build there took only 17.5h, so definitely not days. Your average modern developer-class laptop is going to take a lot less than riscv64 too.
reply
> If you don't what's the point of checking only the install script?

The .tar.gz can be checksummed and saved (to be sure later on that you install the same .tar.gz and to be sure it's still got the same checksum). Piping to Bash in one go not so much. Once you intercept the .tar.gz, you can both reproduce the exploit if there's any (it's too late for the exploit to hide: you've got the .tar.gz and you may have saved it already to an append-only system, for example) and you can verify the checksum of the .tar.gz with other people.

The point of doing all these verifications is not only to not get an exploit: it's also to be able to reproduce an exploit if there's one.

There's a reason, say, packages in Debian are nearly all both reproducible and signed.

And there's a reason they're not shipped with piping to bash.

Other projects shall offer an install script that downloads a file but verifies its checksum. That's the case of the Clojure installer for example: if verifies the .jar. Now I know what you're going to say: "but the .jar could be backdoored if the site got hacked, for both the checksum in the script and the .jar could have been modified". Yes. But it's also signed with GPG. And I do religiously verify that the "file inside the script" does have a valid signature when it has one. And if suddenly the signing key changed, this rings alarms bells.

Why settle for the lowest common denominator security-wise? Because Anthropic (I pay my subscription btw) gives a very bad example and relies entirety on the security of its website and pipes to Bash? This is high-level suckage. A company should know better and should sign the files it ships and not encourage lame practices.

Once again: all these projects that suck security-wise are systematically built on the shoulders of giants (like Debian) who know what they're doing and who are taking security seriously.

This "malware exists so piping to bash is cromulent" mindset really needs to die. That mentality is the reason we get major security exploits daily.

reply
> And I do religiously verify that the "file inside the script" does have a valid signature when it has one.

If you want to go down this route, there is no need to reinvent the wheel. You can add custom repositories to apt/..., you only need to do this once and verify the repo key, and then you get this automatic verification and installation infrastructure. Of course, not every project has one.

reply