1335224 - System addon to disable HSTS priming on Release and Beta

Status: RESOLVED FIXED

(Core :: DOM: Security, defect)

Description

[Kate McKinley [:kmckinley, :Kate]]

This bug is for a system add-on to implement the pref flip described in bug 1335134 to disable HSTS priming requests in Release.

Comment 1

[Kate McKinley [:kmckinley, :Kate]]

Attachment: Patch (without .xpi file)

Comment 2

[Kate McKinley [:kmckinley, :Kate]]

Attachment: hsts-priming.xpi

hsts-priming.xpi (unsigned)

Comment 3

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

RaresB - can you help with QA?

Comment 4

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 8831860 [details] [diff] [review]
Patch (without .xpi file)

Review of attachment 8831860 [details] [diff] [review]:
-----------------------------------------------------------------

(I'll take a second look early tomorrow)

Comment 5

[Kate McKinley [:kmckinley, :Kate]]

Jason, could you please sign the hsts-priming.xpi pending Felipe's final r+?

Comment 6

[Jason Thomas [:jason]]

Attachment: hsts-priming.xpi signed

Please see attached.

Comment 7

[Kate McKinley [:kmckinley, :Kate]]

Steps to test from bug 1311807 

On https://www.franceinter.fr/ page, click headphone icon to start audio player
This opens audio player in the bottom, audio should begin playing quickly.

Before the addon is installed:
Audio will be delayed for some time (1 minute or more, depending on OS timeouts)

After the addon is installed:
audio playing starts within 1 or 2 seconds

Comment 8

[ovidiu boca[:Ovidiu]]

Hi, 

I verified this bug on FF release 51.0.1 and beta 52.0b2 on Mac OS, Windows and Ubuntu and I can confirm the fix. I used the .xpi from comment 6.

Comment 9

[Andrei Vaida [:avaida]]

We tested this on the release-sysaddon update channel using various platforms, versions, build architectures and locales, detailed test report available here:

        https://public.etherpad-mozilla.org/p/1335224&1307568

Comment 10

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

This has been deployed to release.

Comment 11

[heidi]

Is the system addon deployment actually working and being picked up by live browsers? From my understanding it's supposed to check for it once per day, and by using the Timer Fire plugin I can see it fire off some HTTPS requests, but it doesn't seem to be poking the Balrog/AUS system or install this system plugin on any of the 51.0.1 installations I'm running, even after a restart.

I can see the [e-mail] plugin listed here, so it is deployed to Balrog:

https://aus5.mozilla.org/update/3/SystemAddons/51.0.1/20170125094131/default/en-US/release/default/default/default/update.xml 

But the extension log in the browser console does not reference this URL at all, it seems to be poking https://services.addons.mozilla.org/en-US/firefox/api/1.5/search with a specific list of (previously installed) addon checks instead.

Is the wiki entry at https://wiki.mozilla.org/Firefox/Go_Faster/Releasing_an_add-on_mechanics outdated when it comes to using the Timer Fire plugin to force the system addon check, or is something else wrong here?

Comment 12

[Kate McKinley [:kmckinley, :Kate]]

You should be able to see if it is installed by going to about:config and searching on hsts. If the addon is installed, extensions.bootstrappedAddons, extensions.systemAddonSet, and extensions.xpiState should all appear with the hsts-priming extension listed. Additionally, the security.mixed_content.send_hsts_priming preference default will appear as "false".

Comment 13

[heidi]

None of my four 51.0.1 installations on the release update channel have picked up the system addon yet. The metioned extensions.bootstrappedAddons, extensions.systemAddonSet, and extensions.xpiState do not contain the [e-mail] addon, and security.mixed_content.send_hsts_priming is still set as "true". Some of these have been restarted in the last day.

While the communication is obviously encrypted, I've been monitoring outgoing TCP connections from Firefox, and the IPs listed on the DNS entry for aus5.mozilla.org have not been touched.

All this leads me to believe that the system addon update mechanism is not working, or at least not reliably. Do you know of any 51.0.1 release channel installations that *have* picked it up without manual intervention?

Comment 14

[heidi]

I figured it out: if the automatic update setting is set to "Check for updates, but let me choose whether to install them", it doesn't look like it will ever look for system addon updates at all, much less ask to install them. When changed to "Automatically install updates", it did successfully grab the HSTS addon from aus5.mozilla.org and toggle the prefs as intended.