795441 - Links to firefox-stubinstaller in the admin UI of Bouncer should start with https://

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Melissa O'Connor [:melissa]]

This is an action item from the stub installer meeting.

Comment 1

[Chris AtLee [:catlee]]

Not sure how we can do this since the locations in bouncer have no schema, e.g.
firefox-latest currently has /firefox/releases/15.0.1/win32/:lang/Firefox%20Setup%2015.0.1.exe as the location.

Comment 2

[Jake Maul [:jakem]]

To clarify:

The stub installer itself (not firefox-latest, which is what the stub installer downloads and verifies on its own) needs to be over SSL.

The trick here will be to make sure the stub installer product (yet to be created) is available only on an SSL mirror. That means spinning up such a mirror, and then making sure the stub installer *cannot* be reached by the existing non-SSL mirror.

Comment 3

[Rail Aliiev [:rail]]

Sounds like in Bounceradmin we need to add new mirrors starting with https:// and use only these mirrors for stub installer products. This may require changes in bouncer afaik. CCing fwenzel, he may know more.

Comment 4

[Jake Maul [:jakem]]

We won't need to change bouncer to do that necessarily... we just need to make the relevant files available only on the right mirrors.

So an SSL mirror could have all the files, and a non-SSL mirror can have everything except stub installer. Then Sentry will take care of making sure bouncer sends people to the right mirrors.


Having said that, it would be seriously awesome if Bouncer had a simple flag on each product indicating if it has to be delivered over SSL or non-SSL (or if either is allowed), and that this flag would automatically dis-allow the wrong 'types' of mirrors from ever being used for that product.

We can get by without that, but that would be seriously awesome.

Comment 5

[Rail Aliiev [:rail]]

(In reply to Jake Maul [:jakem] from comment #4)
> We won't need to change bouncer to do that necessarily... we just need to
> make the relevant files available only on the right mirrors.
> 
> So an SSL mirror could have all the files, and a non-SSL mirror can have
> everything except stub installer. Then Sentry will take care of making sure
> bouncer sends people to the right mirrors.

Does this mean that we would need a separate rsyncd excludes file to allow rsync from SSL enabled mirrors only? Otherwise sentry may find stub installer files on non-SSL mirrors and put them into the pool.

Comment 6

[Jake Maul [:jakem]]

Maybe, but that's not particularly relevant anymore IMO... we're not sending any significant traffic to community mirrors that use rsync, and by the time we launch to prod I'm hoping for that number to be not just minimal but "zero". Instead all the traffic is going to Mozilla-controlled CDN accounts.

We'll set up a separate SSL CDN property which uses a different origin. The non-SSL origin will get some Apache logic to disallow access to the stub installers, whereas the SSL one will have complete access.

Comment 7

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

Easy enough to add an exclude for the stub to the rsync modules until we get to the point of disabling rsync access. That's blocked on AMO moving to CDN (sorta bug 626564), but we can drop the product delivery earlier if we teach sentry to not disable the CDN when it has transient issues. Jake has been working on improving sentry to debug that.

Comment 8

[Laura Thomson :laura]

(In reply to Jake Maul [:jakem] from comment #4)
> We won't need to change bouncer to do that necessarily... we just need to
> make the relevant files available only on the right mirrors.
> 
> So an SSL mirror could have all the files, and a non-SSL mirror can have
> everything except stub installer. Then Sentry will take care of making sure
> bouncer sends people to the right mirrors.
> 
> 
> Having said that, it would be seriously awesome if Bouncer had a simple flag
> on each product indicating if it has to be delivered over SSL or non-SSL (or
> if either is allowed), and that this flag would automatically dis-allow the
> wrong 'types' of mirrors from ever being used for that product.
> 
> We can get by without that, but that would be seriously awesome.

Let's get a separate bug on file for that; but we should aim to work around it for now.  (ccing Brandon)

Comment 9

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to Jake Maul [:jakem] from comment #6)
> Maybe, but that's not particularly relevant anymore IMO... we're not sending
> any significant traffic to community mirrors that use rsync, and by the time
> we launch to prod I'm hoping for that number to be not just minimal but
> "zero". Instead all the traffic is going to Mozilla-controlled CDN accounts.

Recall that we're explicitly staying with community mirrors for Thunderbird/SeaMonkey. Its unclear if those products expect to use same stubinstaller code in later releases. If we're planning to do anything here that *breaks* using community mirrors, we should check with the TB/SM teams.

Comment 10

[Jake Maul [:jakem]]

This bug is itself a tracker bug (of sorts) for 2 others... one to make an SSL CDN "mirror" in bouncer, and one to update bouncer to support an "SSL-only" flag on a product that will exclude non-SSL mirrors from delivery consideration.

Comment 11

[Jake Maul [:jakem]]

... not to mention actually having a "firefox-stubinstaller" product in bouncer in the first place! Adding that dependency as well.