After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 791653 - Download for windows installer redirects to HTTP
Download for windows installer redirects to HTTP
Product: gimp-web
Classification: Infrastructure
Other All
: Normal normal
: 2.8
Assigned To: The GIMP web bugs mail alias
The GIMP web bugs mail alias
Depends on:
Reported: 2017-12-15 13:53 UTC by Hanno Böck
Modified: 2017-12-22 10:04 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Hanno Böck 2017-12-15 13:53:30 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 [1] as long as the Bittorrent v2 format is not finalized and used [2])

Comment 1 Pat David 2017-12-15 15:36:01 UTC
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.
Comment 2 Pat David 2017-12-15 15:37:48 UTC
[Update]: We do, in fact, generate sha256 sums for the files as well (

Also, moved this to gimp-web, as I think it's more appropriate there.
Comment 3 Michael Schumacher 2017-12-19 18:44:32 UTC
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.
Comment 4 Michael Schumacher 2017-12-19 19:04:24 UTC
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?
Comment 5 Michael Schumacher 2017-12-19 20:21:27 UTC
But the signing discussion is probably something for the gimp-developer mailing list.
Comment 6 Hanno Böck 2017-12-19 20:42:06 UTC
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:
Location: https://v2.8/windows/gimp-2.8.22-setup.exe

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.
Comment 7 Michael Schumacher 2017-12-22 10:04:39 UTC
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.