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

RESOLVED FIXED

Status

Release Engineering
Release Automation: Other
P5
normal
RESOLVED FIXED
3 years ago
3 months ago

People

(Reporter: dennis.hoer, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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

Updated

3 years ago
Component: Untriaged → Releases
Product: Firefox → Release Engineering
QA Contact: rail
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.
Status: UNCONFIRMED → NEW
Component: Releases → Release Automation
Ever confirmed: true
QA Contact: rail → bhearsum
Summary: download.mozilla.org latest redirects to http → download.mozilla.org latest redirects to http for firefox-latest
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.
Flags: needinfo?(robert.strong.bugs)
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.
Flags: needinfo?(robert.strong.bugs)
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
(Reporter)

Comment 7

3 years ago
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.
Priority: -- → P5

Comment 9

3 months ago
This was fixed in bug 1410458.
Depends on: 1410458

Updated

3 months ago
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.