1109342 - Add optional version param check for full installer download url

Status: NEW

(Firefox :: Installer, enhancement, P5)

Description

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

It turns out that a couple of percentage points of people performing installs are using old stub installers and when changes are made to it this can lead to installation failures. To handle this case I'd like to propose the following:

Add an optional version number to the url requesting the full installer download on bouncer Currently, the url to download the full installer is:
http://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US

What I propose is the following where the stub installer will send the ver param http://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US&ver=#
where "#" is the version of the stub installer. It would be optional so our web pages that use that url can just continue serving the stub installer without the version check.

When the stub installer changes in a manner that requires the user to use the latest stub installer the value of the ver param would be increased to the new stub version in the stub and bouncer. Bouncer would then send an http error or similar for clients with a lesser value and the stub installer would direct them to download the latest stub installer.

Reference bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=1108898
https://bugzilla.mozilla.org/show_bug.cgi?id=995684

Comment 1

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

What if we changed the bouncer product each time (eg firefox-latest-r1, firefox-latest-r2, repeat for beta), and then we don't need any code change in bouncer or the release automation. I think we'd just need to modify configs http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla/release-firefox-mozilla-release.py.template#l150 each time. 

Old stubs would keep pointing at old installers, and we rely on the update system to bring people up to date.

Comment 2

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

One of the security review requirements is to always point to the latest version so that is a non-starter.

Comment 3

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

Another option would be to delete the stub installer from the users local file system after it finishes but that would surely piss some people off as shown by the number of people that run the old stub installers.

Comment 4

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

Nick, how about your proposal with the removal of the old url in bouncer when a new Firefox version is released and the new url is added to bouncer so old stub installers were unable to download? I think I might be able to get security to go along with this since I can make old stub installers download the new stub installer.

Comment 5

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

I had an idea for how we might do the original idea, so here's a couple of fleshed out scenarios on how we might implement this.

0, current situation

The stub requests the product firefox-latest, which in bouncer is an 'alias' to the product firefox-34.0.5 (as of now, changes each release). The beta stub requests firefox-beta-stub instead. Similar for aurora & nightly except these are actual products in bouncer, and I'm not clear how much they're actually used.


1, unique products

The stub starts requesting the firefox-latest-rN product, for some integer N which increments each time the stub changes in an incompatible way. As an incompatible stub reaches the release channel, RelEng is informed and
* updates their release config to create a new bouncer alias (http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla/release-firefox-mozilla-release.py.template#l150)
* deletes firefox-latest-r(N-1) channel 

Same for beta/aurora/nightly on their own products. ie for something riding the trains we need to make changes every 6 weeks.

The old stub would get a 404 response from download.m.o. Is that too ambiguous ? Could also happen if there was a misconfiguration/files missing/CDN problem.

To fix old stubs already out there we may have to deprecate firefox-latest, which would mean changing mozilla.org to use something else.


2, modify bouncer (from comment #0)

Add the new property 'ver' to alias objects. If ver is set in both object and request, and older in request then respond with some error (maybe a 410 Gone); otherwise follow the alias and serve the file.

Would need to modify nightly & aurora products to use aliases, probably not a big deal.


I'm coming round to the idea of changing bouncer now. Either way it would be good to know how frequently has the stub changed incompatibly in the past, and if might in the future.

Comment 6

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

We've had two changes since the stub installer was released where we would have definitely wanted to prevent people from using the old stub installer and we've had one change where it would have been nice to have but not necessary. Of the two where we would have wanted to prevent people from using the old stub installer one was for the certificate change and the other was for increasing the size checked for the download (which I believe will be removed).

Also, I'm much less concerned about nightly and aurora having this functionality.

Comment 7

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

OK, we both think option 2 is preferable, just need some webdev time to work on it. Laura, is that going to be possible in Q1 ?

Comment 8

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

We will need this unless we are willing to take hits again and again in the successful install rate in the future. Can I get an update on this bug? Thanks!

Comment 9

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

Laura, re-needinfoing you for comment #7 from December. Can I get an update on this bug?

Comment 10

[Laura Thomson :laura]

Thanks for the ping, totally lost track of this. I'm trying to track down a dev for it now. Leaving needinfo set until I do.

Comment 11

[Laura Thomson :laura]

Ok. We have a brand new version of Bouncer, and the person who can fix this for you is Jeremy Orem. Assigning.

Comment 12

[Jeremy Orem [:oremj]]

We discussed this today. We have two decent options:

First option:
* Make a file with the minimum working stub installer version available at https://SOMEDOMAIN/stub.min.version (name arguable)
* Stub installer requests https://SOMEDOMAIN/stub.min.version and asks user to download a new stub installer if it is older than the version in the response. In all other cases, including an error making a request to this url, it will attempt to install firefox

Second option:
* Stub installer sends a ver=$CURVERSION in the request to bouncer. If bouncer thinks the stub installer is too older, it sends some error code back causing the installer to prompt the user to download a new installer

The first version is nice, because we can just host a simple file on s3 with a version. Option two eliminates the need for a second request, but requires a one-off hack in bouncer. Both options require modifications to the stub installer.

Comment 13

[Jeremy Orem [:oremj]]

What's the current minimum version? I can upload the file somewhere, drop the URL in the bug and we can close this out.

Comment 14

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

I'll move this over to Firefox -> Installer and ping you when we get to that stage.

Comment 15

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

This is less than ideal but I think this would be good enough. We could add a minimum stub version number to the 7Zip self extracting archive. When the stub version is less than this version it would ask the user to download a new stub installer and open the web page for it. It would be nice to do this check before the download of the complete installer but this only affects a small percentage of users that choose to reuse the stub installer.