1226221 - download.mozilla.org latest redirects to http for firefox-latest

Status: RESOLVED FIXED

(Release Engineering :: Release Automation: Other, defect, P5)

Description

[dennis.hoer]

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

Comment 1

[dennis.hoer]

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

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 5

[Robert Strong (they/them - no direct email)]

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.

Comment 6

[Robert Strong (they/them - no direct email)]

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

Comment 7

[dennis.hoer]

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?

Comment 8

[Nick Thomas [:nthomas] (UTC+12)]

(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.

Comment 9

[Chris AtLee [:catlee]]

This was fixed in bug 1410458.