It's exactly as insecure as running an unsigned binary installer downloaded over HTTP (without checking checksums), which no one should ever do.

(Because the authors should offer it over HTTPS, sign it, provide some checksum or ship it through some package manager that knows better, if they can't secure the process themselves)

But really? It'll get pretty onerous to check every checksum and guard every entry point. I think we should fix the real problem.

Well yes, that's the problem. Proper security is onerous, there's no use crying about it. Either do it right or accept that you're insecure. :P

Fix all the problems you can, of course, defense in depth is always a good idea. But hackers managing to alter a mirrored file without getting access to the website itself happens more often than you'd like to admit, and even hackers getting access to both a website and a tarball can be mitigated by signing tarballs instead of just listing sha sums.

If you trust your website won't be hacked to serve malicious code then you might do away with signing and cryptographic checksums, but then that only makes using TLS that much more important to avoid having your tarball zoinked by a MitM during transit.

Is there a standard yet where the SHA hash of an object can be stored as part of its HREF? And therefore the HTTP client can verify the hash easily?