User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36 Steps to reproduce: Download of firefox-latest redirects to a non-secure URL. The firefox-esr-latest and firefox-beta-latest do not. This causes issues with Ruby open-uri which forbids https to http redirection. Actual results: https://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US redirects to non-secure site: http://download.cdn.mozilla.net/pub/firefox/releases/42.0/win32/en-US/Firefox%20Setup%2042.0.exe Expected results: It should behave like the esr redirect: https://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US redirects to secure site: https://download-installer.cdn.mozilla.net/pub/firefox/releases/38.4.0esr/win32/en-US/Firefox%20Setup%2038.4.0esr.exe

Amendment: Expected results: It should behave like the esr redirect: https://download.mozilla.org/?product=firefox-esr-latest&os=win&lang=en-US redirects to secure site: https://download-installer.cdn.mozilla.net/pub/firefox/releases/38.4.0esr/win32/en-US/Firefox%20Setup%2038.4.0esr.exe

tl;dr - To be honest, it looks like esr is the odd one out here. We might be able to change firefox-latest, but we need to be careful not to break the stub installer. I don't have a work around for you. Longer: In the configuration for download.m.o, firefox-latest is an alias to the product for current firefox release, which is Firefox-42.0. That does not have the SSL bit set, so it returns redirects to http://<CDN>. Meanwhile, firefox-esr-latest is also an alias, pointing to Firefox-38.4.0esr. That does have the SSL bit enabled, so it returns 302's to https://<CDN2>. ESR releases are added to download.m.o using the config at http://hg.mozilla.org/releases/mozilla-release/file/3d3759e71a7d/testing/mozharness/configs/releases/bouncer_firefox_release.py, notably the |"ssl-only": True,| at line 7. It's actually the only one of these config files which sets True for that particular product; Firefox beta & release and Thunderbird don't. Originally the latest- products were set up for the stub installer. The flow is that a user downloads the stub from www.mozilla.org over https, and when run it makes a request like https://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US to get the full installer via http. There are checks on the certificate used to sign the full installer, so we don't need https distribution. I'm wondering if we can swap the stub to SSL, then we can use Firefox-42.0 on www.mozilla.org instead of Firefox-42.0-SSL, and stop creating -SSL products.

Oops, I meant http://hg.mozilla.org/releases/mozilla-esr38/file/3d3759e71a7d/testing/mozharness/configs/releases/bouncer_firefox_esr.py in the last comment.

rstrong, we're serving full and stub installers via https when the download is user-initiated on www.mozilla.org. Could the stub also download by https ? We'd change the redirect rather than the url it queries. Would that open us up to problems with missing certs in the windows cert store ? I feel sure I've asked this before but can't find your earlier answer.

I really don't know. When the stub was developed it was developed explicitly to handle http since at that time the cost of downloading over https was more expensive without any time spent on https.

Note: the stub installer requests http://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US and not https://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US It gets away with this since we verify the downloaded binary's certificate. Perhaps bouncer could just keep the original http or https

That python script is missing the win64. How is that published? Note: I have refactored the Chef mozilla_firefox installer cookbook: https://supermarket.chef.io/cookbooks/mozilla_firefox To download from the redirect location based on this URL convention: https://download.mozilla.org/?product=#{product}&os=#{os}&lang=#{lang} Is there a way to keep abreast of changes to this URL convention?

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #6) > Perhaps bouncer could just keep the original http or https It doesn't have any smarts to do this right now, and I'm not sure how that would fit with the SSL config which can be set on each product, could be pretty confusing. (In reply to dennis.hoer from comment #7) > That python script is missing the win64. How is that published? With product=win64 in download.m.o urls. > I have refactored the Chef mozilla_firefox installer cookbook: > https://supermarket.chef.io/cookbooks/mozilla_firefox > > To download from the redirect location based on this URL convention: > https://download.mozilla.org/?product=#{product}&os=#{os}&lang=#{lang} > > Is there a way to keep abreast of changes to this URL convention? These are very infrequent, so we don't have any mechanism to notify.

This was fixed in bug 1410458.