This applies to unencrypted downloads, of course; assuming no flaws allowing a man-in-the-middle attack, this sort of screwing around would be immediately obvious on a TLS connection. On Google Code, we had encrypted downloads, but Google Code (meanie) no longer allows uploads (scum); SourceForge's mirror network only supports regular HTTP downloads, which are not encrypted (please upvote this ticket if you have an SF account).
Are we high risk? No. You probably have a higher risk of developing Ebola than getting a tainted TenFourFox. It's hard to patch a compressed binary in flight, so it would almost certainly be a complete substitution, it would have to be done on a machine that can build such binaries and it would need to do something interesting on a Power Mac, and given all those preconditions frankly I'm not aware of someone who hates me that much except possibly the cute shop girl at the AT&T store who won't give me her phone number.
Still, I'd like to guard against that possibility, or of any network-imported code over an insecure channel (network snippets, for example, can be loaded into the start page -- which has chrome privileges -- and this should make you suddenly feel very icky and vulnerable). This ties in nicely with a recurring thought I've had of redoing the new tab and start pages so that we're not getting snippets from Mozilla anymore about browser things that don't really apply to us or aren't otherwise compatible. To that end, I think publishing a verifiable hash for all downloads and redoing the new tab (possibly just using a blank one?) and start page for 38ESR will achieve that. We also need to ensure the following:
- It should not require any special software to verify the hash. You should be able to do it with the tools that come with 10.4.11.
- The hash list needs to be secure, or that could be tampered with too.
- The new tab and start pages should not do network loads.
- The most secure hash algorithm that comes with Tiger's built-in OpenSSL appears to be RIPEMD-160; it doesn't support SHA-2, or I'd use that. RIPEMD-160 is a less common hash function but to date cryptanalysis has not demonstrated collisions so far with known attack methods (here's some light bathroom reading on that topic). You can verify that the .zip file downloaded properly by simply going into Terminal and typing (this is the actual hash):
% openssl dgst -ripemd160 TenFourFox7450-31.2.0.app.zip
- While we can't upload to Google Code any more, we can certainly post things. The Google Code project page is secured by SSL -- https://tenfourfox.googlecode.com -- and the hashes will either be listed there or on one of the wiki pages. You can grab the hashes securely before you update, download the file from SourceForge, and check that the hash matches. If it does, you have excellent assurance it has not been tampered with in transit. Hashes will be posted for the changesets too.
- We'll be taking the network and dynamic code out, which as a side benefit will reduce their overhead, and possibly some other minimizing changes. I'll probably still allow the old pages by an about:config switch, though I haven't really plotted how the infrastructure will look either. Just expect this for the next ESR.