GNOME Bugzilla – Bug 791653
Download for windows installer redirects to HTTP
Last modified: 2017-12-22 10:04:39 UTC
When I go to the GIMP webpage and try to download GIMP for Windows (or for OS X, same issue) it provides me with an URL of the form
That looks like the download is provided over a secure channel. However that HTTPS url redirects to HTTP urls like:
Downloads over HTTP are a risk, as they provide no integrity guarantee and can be modified on the way. I think this is particularly problematic, as it's deceiving the user by first providing an HTTPS URL that later on forwards to HTTP.
(As a sidenote: The torrent downloads that are provided are also no secure alternative  as long as the Bittorrent v2 format is not finalized and used )
This is due to how we utilize mirrors. I'll check with the appropriate folks and see if there's something we can do (about the http(s) requests).
As for bittorrent, we do provide a hash of the files, and we could bump the hash to sha256 going forward if needed I suppose.
[Update]: We do, in fact, generate sha256 sums for the files as well (https://download.gimp.org/mirror/pub/gimp/v2.8/SHA256SUMS).
Also, moved this to gimp-web, as I think it's more appropriate there.
That has annoyed me several times before - but whenever I wanted to change this and checked, I couldn't access the mirrors via HTTPS, so I figured they just didn't support it.
Seems like there is support now, and changing this isn't hard, either.
And seems to work fine.
Regarding the SHA* sums, those are pretty useless if the files aren't signed. The challenge there is there multiple people should be able to sign them (and likely the actual downloads as well).
I'm not sure how this is done best - we do not want to introduce single-points-of failure where the absence of one person can be a roadblock. Hanno, any hints for best practices there?
But the signing discussion is probably something for the gimp-developer mailing list.
Switching to HTTPS is a good start, just one note, it seems right now 1/3rd of the time one is forwarded to an URL like:
I believe this is probably an empty line in a mirror list or something.
I think the hashes could be seen as an additional security mechanism if one considers the webpage to be more trustworthy than the mirrors. In any case they can serve as a way to verify if a download happened without errors. (HTTPS should guarantee that as well, but there can always be bugs.) I'd switch them to a secure hash function however (probably sha256, as it's both secure and widely supported).
Signatures don't need to go over the hash, they could directly sign the download files.
However in any case: I believe none of that is as important as having the downloads as HTTPS, because probably few users will bother to check hashes or signatures manually. HTTPS happens automatically.
Yeah, the empty host redirect was a | too much.
I'm somewhat surprised by the "nah, you do not need to sign the hashes files".
That's the one security feature (if it is one in its present for at all) people have actually noticed before, at least its temporary absence - we've gotten complaints when someone added a file but didn't update the *SUMS files. Some download utilities seem to actively look for those sum files and compare them with the downloaded file, that's why we even have them in the first place.