Checksums/keys should be hosted officially and on HTTPS

[Eduard - Gabriel Munteanu]

https://help.ubuntu.com/community/UbuntuHashes is the only reasonable source for hashes for a sizable fraction of users (which likely don't have a solid web-of-trust already in place). That page is immutable and only the wiki admin can edit it, it seems. However a community page isn't really the proper place for hashes since Canonical should sign releases and take responsibility for them. In my opinion the community wiki admin isn't the proper role for that, and I don't mean the current wiki admin(s) aren't to be trusted.

Therefore, I propose the following changes:
* enable HTTPS support on www.ubuntu.com, either entirely (should be quite reasonable actually) or for specific pages, or specific portions of releases.ubuntu.com
* create a HTTPS-only section serving PGP keys used to sign downloads (or at the very least their fingerprints); optionally, but strongly recommended considering many users aren't familiar with PGP, host hashes for all downloads on said page
* write a small official guide on how to verify downloads, and warn users to do so from download pages, as also suggested in bug #873462
* remove that information from the community wiki, so users are forced to get the checksums from the official website

While we're at it, I'd also suggest making SHA256 the recommended hash, so verification instructions should refer to it exclusively.

I'm not suggesting the CA system should be trusted, but it's still better than nothing and it's very cheap for this purpose.

[Colin Watson (cjwatson)]

It doesn't seem unreasonable to move this onto www.ubuntu.com or something similar, although it would take some care. Some practical problems here, not necessarily blockers:

 * The reason we offer MD5 is that in practice many of the people consuming this kind of thing (often on other operating systems) only have an md5sum utility available and not sha256sum. While MD5 certainly shouldn't be assumed resistant against determined attack these days, it's OK as a transport checksum, so I don't think the situation is dreadful. I'd be fine with SHA256 being shown as well / by preference, but it would involve some design work to make sure it didn't just overwhelm people with detail; having something where they perform any check is better than nothing at all.
 * releases.ubuntu.com is very unlikely to have HTTPS applied to it; it is *ridiculously* high-traffic around release times. The same might go for www.ubuntu.com. It might be better to have a dedicated host name.
 * We need to make sure that ~ubuntu-release can edit the page to update hashes; most of us aren't web site editors.

[Peter Mahnke (peterm-ubuntu)]

This cannot go onto www.ubuntu.com right now because of the reasons Colin stated, nor on releases.u.c. Since Colin's team needs to be able to update the page, I think the best place is likely right where it is. Other, new hosts, will have the same issues as help.u.c.

My two cents.

Peter

[James Troup (elmo)]

So, www.ubuntu.com on https is not going to happen. Doing partial
https (i.e. for specific URLs) is terrible from a security
perspective, and forcing https for all of www.ubuntu.com would be
stupidly expensive from a scaling point of view.

Doing it on a separate, specific hostname
(e.g. cdimage-checksums.ubuntu.com) is possible, but if the
requirement from the release team is that ~ubuntu-releases retain edit
rights (which is perfectly reasonable), what will we have gained
except a different hostname in the URL?

[Also, for the avoidance of doubt, the wiki admins are the Canonical
 IS team.]

[Eduard - Gabriel Munteanu (edgmnt)]

Thanks for your answers.

Personally I'd be comfortable with getting the GPG key's fingerprint (or the entire key) over https, to check the checksum file's signature. Since that key could be longer-lived, the release team doesn't have to change anything, they don't even have to publish hashes on the wiki anymore, but I suppose it would make many users uncomfortable given the additional indirection. And the risk is they could skip checking the download altogether because of that.

Is there some way to make signature checking and download checksumming more seamless for users? The best I can think of is publishing a short script, maybe a oneliner, on the wiki to wget the key and automate the checking (it should probably use a temporary keyring for this purpose). But I don't know if that's a viable option for Windows users.

In the meanwhile, could you post the checksum signing key or its fingerprint on the wiki, on a similar, locked page? That would allow one to choose better digests like SHA256 and check them, which are available on release.ubuntu.com. (Well, unless the signature digest algo isn't too weak itself, I haven't checked.)