So no one can do a MITM attack and change the SHA1 checksum, OpenPGP Key ID, file lengths and code signing certificate fingerprints as you download package-integrity.html?
If you don't have any way to trust the signing key "out-of-band", then you shouldn't trust the binaries. I don't really see why they supply separate sha1sums in addition to the pgp signatures.
Now, the fact that people are more inclined to trust the bundled ca keys, rather than a web-of-trust backed pgp key is generally just because people don't understand trust.
Say, if you're in Thailand[1] and require a secure way to communicate, where do you get your os/browser-bundled ca keys? Do you trust a CA that is under influence of the Thai government? Under influence of a sympathetic government?
Do you really trust all the CA keys bundled with your os/browser/phone? Do you know which they are? If not, please don't spread FUD wrt web-of-trust based trust models.
To be clear, both have a bootstrap problem -- but only web-of-trust offers a reasonable way for the individual to ensure proper trust chains. No trust chain is (by definition) without trust, so no model (ca or wot) is immune to being betrayed. But at least wot is designed for the user to be able to influence (and be aware of) trust -- and for easy auditing (most keys are personal, or anchored to personal ids, while it can often be hard to tell who are able to access ca keys and sign possibly rogue certs).
You can do a MITM attack with certificates also. In fact NSA can do it by compromising any CA in the chain.
A distributed system that verifies identity would be much better. For example, namecoin based identities and checksums committed to the blockchain.
In fact, any self-signed public key system with a MAC distributed to many sources would be good enough. It doesn't have to have proof of work. The only requirement is that there are enough root CAs that you can't compromise them all.
This should be taken care of by browsers themselves!
Agreed, CAs are an easily-exploitable smokescreen. Distribution is the way to go here. Seems like you could post your public key in the data section of a namecoin domain entry, no?
I think there is movement on this type of system, but it's slow because people don't realize just how insecure HTTPS is when CAs and the US government are involved.
I heard of a project a while back, but haven't seen it since and I forget the name. My understanding is that it's slow going. I think the best bet is, as mentioned, piggyback onto the blockchain somehow. Namecoin is probably the closest to getting this right.
You're accessing both of those links over unsecured HTTP, which means that those could easily be MITMed as well.
If you were distributing packages over HTTP and distributing the verification signatures over a secure channel, I'd agree (this is similar to what Debian does[0]). But using one insecure channel to verify another doesn't provide you with any more security.
Furthermore, using SSL provides an additional layer of privacy - the path of the URL (everything after the domain) is hidden to eavesdroppers. They can tell which server you're accessing, but they can't tell which resources you're trying to access[1].
[0] Debian signs the packages (GPG, I believe), and the public keys for these signatures are distributed in the ISO that is used to install the base system. So the validity of the signatures is as trustworthy as the ISO used to install the entire OS (which is hopefully very trustworthy, or else there's a much bigger problem!).
[1] It's for this reason alone that I still wish Debian would distribute packages over SSL even though the GPG signatures provide more security in the authenticity of the packages than SSL would provide.
Just remember that the CA certs (that anchor ssl trust) is usually also distributed in a similar way (on the install media). The difference is that you can more easily independently review the trust of any given pgp key (you've personally verified the key, or have personally verified the key(s) of someone that have personally verified the key).
I suppose in theory one could take a snapshot of CA keys, sign them with pgp and use that a s "know set" (note: not known good, as there is no way to be able to fully trust all the certs typically supplied as CA roots -- a subset could probably be verified). But that's not how the CA system is designed.
There are no user registrations taking place or sensitive informations. It's just binaries.