1331667 - https://www.mozilla.org/en-US/firefox/developer/all/ sends users to http downloads

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect)

Description

[[e-mail] (:bhearsum)]

I just noticed that the links on these page end up with real download URLs such as http://download.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-aurora-l10n/firefox-52.0a2.ach.win64.installer.exe

This is bad, because it means users are download Firefox over an insecure channel. These downloads should go through https://download-installer.cdn.mozilla.net instead.

Comment 1

[Chris More [:cmore]]

Good catch.

I believe this is a specific issue with Bouncer and not www.mozilla.org.

See here:

curl -I https://download.mozilla.org/?product=firefox-aurora-latest-l10n&os=osx&lang=ach
[2] 17752
[3] 17753
[1]   Done                    curl -I https://download.mozilla.org/?product=firefox-aurora-latest-l10n
[3]+  Done                    os=osx
Chriss-MacBook-Air:~ cmore$ HTTP/1.1 302 Found
Cache-Control: max-age=60
Content-Length: 142
Content-Type: text/html; charset=utf-8
Date: Tue, 17 Jan 2017 20:34:24 GMT
Location: http://download.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-aurora-l10n/firefox-52.0a2.en-US.win32.installer.exe

The https request to bouncer does a 302 redirect to http. All the links on www.mozilla.org point to https bouncer links and thus the problem is likely bouncer.

:nthomas/:coop: can you check this out and if it is bouncer, can you adjust the product and component?

Thanks!

Comment 2

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

I suggest swapping to the firefox-aurora-latest-l10n-ssl product, which already exists, to be consistent with the products we use for beta/release/esr (eg firefox-50.1.0-SSL, case doesn't matter).

Incidentally, there is an firefox-nightly-latest-l10n-ssl product which could be used on /en-US/firefox/nightly/all/.

Comment 3

[Chris More [:cmore]]

(In reply to Nick Thomas (UTC+13) [:nthomas] from comment #2)
> I suggest swapping to the firefox-aurora-latest-l10n-ssl product, which
> already exists, to be consistent with the products we use for
> beta/release/esr (eg firefox-50.1.0-SSL, case doesn't matter).
> 
> Incidentally, there is an firefox-nightly-latest-l10n-ssl product which
> could be used on /en-US/firefox/nightly/all/.

ok, then that changes the fix to a www.mozilla.org change.

Eric: this looks like a change for your team now.

Comment 4

[Craig Cook (:craigcook)]

Looks like this is specified in bedrock at https://github.com/mozilla/bedrock/blob/master/bedrock/firefox/firefox_details.py#L233

We can update that to the ssl product and test.

Comment 5

[Eric Renaud [:erenaud]]

pmac - can you please take a look and confirm the proposed updates here?  ^^

Comment 6

[Eric Renaud [:erenaud]]

Craig - let's proceed with updating to the ssl product and then test.

Comment 7

[Paul [:pmac] McLanahan]

Apologies for the delay! Somehow I missed this NI (thought it used to email daily about those).

In any case, this looks like a great change, and we do have it on our list to update nightly to use these new "latest" products as well (bug 1324579). I'll work on this now.

Comment 8

[Paul [:pmac] McLanahan]

Attachment: PR with the fix

Fixes this and a couple of other bugs. Aurora and Nightly should both now use standard "latest" product names for stub and l10n builds.

Comment 9

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

That looks good from a bouncer product point of view, except that we can possibly use the stub for win64 as well as win32. Bug 797208 made the stub smarter, so it downloads win32 or win64 based on what it's running on. See also bug 1320662, although I'm not sure that's still being used.

Comment 10

[Paul [:pmac] McLanahan]

I looked at that, but bouncer issues a 404 for product=firefox-*-stub and platform=win64. So I'll have to have the site print out no win64 product for only those buttons, or spit out 2 "win" buttons but only change the link, not the platform ID. Tl;dr is that the buttons aren't really setup to allow that logic and changing them to do so isn't trivial. So we can do it, but haven't yet. And win64 buttons aren't enabled mostly on the site anyway, so it's not much of an issue so far. The easiest fix from our perspective would be to add firefox-stub, and firefox-{beta,aurora,nightly}-stub with the win64 platform in bouncer so that those links would Just Work. Do you think that's feasible?

Comment 11

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

Yes, I filed bug 1342814 for that.

Comment 12

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

We can request a stub with os=win64 for nightly/aurora/beta/release now. Would you mind hooking bug 1342814 to a more appropriate bug, given the PR has already merged to prod ?

Comment 13

[Paul [:pmac] McLanahan]

Marking this fixed as I believe the original issue has been resolved for quite a while. And the stub installer for win64 in bouncer has been handled in bug 1342814.