Closed Bug 1335134 Opened 7 years ago Closed 7 years ago

Put the security.mixed_content.send_hsts_priming pref behind the RELEASE_OR_BETA ifdef

Categories

(Core :: DOM: Security, defect)

51 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla54
Tracking Status
firefox51 blocking fixed
firefox52 blocking verified
firefox53 + verified
firefox54 + verified

People

(Reporter: kmckinley, Assigned: kmckinley)

References

Details

Attachments

(2 files, 1 obsolete file)

      No description provided.
Attached patch move pref into block (obsolete) — Splinter Review
[Tracking Requested - why for this release]: Raised on r-d. nomming for tracing although I'm not yet clear on whether this warrants a point release or should be fixed in a followup release.
Kate, who is going to review this patch, and what is the relationship between this change in all.js and the similar rules in security-prefs.js ?
Flags: needinfo?(kmckinley)
Attachment #8831773 - Attachment is obsolete: true
Setting this as blocking 51/52. This looks like a dot release driver to me.
Bug 1311807 has a site that can be used to verify the patch.
Flags: needinfo?(kmckinley)
We should explore pushing a hotfix or system add-on update for this before we start planning a dot release. This is a pref flip and afaik hotfix/SAO update are both good mechanisms of doing this.
We should do both a hotfix extension and ship and update. The hotfix would allow us to address a significant part of the userbase quickly. I recall our findings from websense hotfixes that we ended up with several million people who never got the hotfix, is there anything that has changed since that finding? Shipping an update has better penetration.
I agree, we should go ahead and ship the system add-on quickly as possible.  We can plan a dot release for later to improve uptake (And that dot release would likely include more fixes)
Felipe, ckprice, can you help Kate with this as needed? Or is there someone else you can suggest to help out with this over the next couple of days? Thanks!
Flags: needinfo?(felipc)
Flags: needinfo?(cprice)
From the process side, we need a sign off from QA, and a signed XPI posted to this bug (I think Liz linked to our docs).

Here are a couple of relevant resources

- Example pref flip tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1307108
- Repository with some boilerplate code: https://github.com/mozilla/one-off-system-add-ons/tree/master/addons/asyncrendering

You could open a PR on that repository, or create a patch on this bug for review.
Flags: needinfo?(cprice)
See Also: → 1335224
Flags: needinfo?(felipc)
Yeah, and https://github.com/mozilla/one-off-system-add-ons is the de facto repo for these add-ons now. So the easiest will be to make a copy of one of the existing system addons there and change what you need.
See Also: → 1328460
See Also: → 1311807
Comment on attachment 8831782 [details]
Bug 1335134 - pref security.mixed_content.send_hsts_priming to false

https://reviewboard.mozilla.org/r/108318/#review109604

thanks
Attachment #8831782 - Flags: review?(honzab.moz) → review+
Comment on attachment 8831782 [details]
Bug 1335134 - pref security.mixed_content.send_hsts_priming to false

Approval Request Comment
[Feature/Bug causing the regression]:
Bug 1246540.


[User impact if declined]:
Some discussion references here Bug 1335134 Comment 9. We're shipping as a system add-on in Bug 1335224, uplifting here in the case of a dot release.

[Is this code covered by automated tests?]:
I don't know.


[Has the fix been verified in Nightly?]:
No


[Needs manual test from QE? If yes, steps to reproduce]: 
Yes, Bug 1335224 Comment 7

[List of other uplifts needed for the feature/fix]:
None

[Is the change risky?]:
No

[Why is the change risky/not risky?]:
It's a pref flip

[String changes made/needed]:
No
Attachment #8831782 - Flags: approval-mozilla-release?
Attachment #8831782 - Flags: approval-mozilla-beta?
Comment on attachment 8831782 [details]
Bug 1335134 - pref security.mixed_content.send_hsts_priming to false

Let's uplift these changes in case we end up doing a dot release for 51. 
The patch should make it into beta 3 later this week.
Attachment #8831782 - Flags: approval-mozilla-release?
Attachment #8831782 - Flags: approval-mozilla-release+
Attachment #8831782 - Flags: approval-mozilla-beta?
Attachment #8831782 - Flags: approval-mozilla-beta+
seems this need rebasing for beta like :

patching file modules/libpref/init/all.js
Hunk #1 FAILED at 5537
1 out of 1 hunks FAILED -- saving rejects to file modules/libpref/init/all.js.rej
abort: patch failed to apply
Flags: needinfo?(kmckinley)
Flags: needinfo?(kmckinley)
Attachment #8832663 - Flags: checkin?(cbook)
Attachment #8832663 - Flags: checkin?(cbook)
But we're not intending to land this on 53+?
(In reply to Ryan VanderMeulen [:RyanVM] from comment #21)
> But we're not intending to land this on 53+?

We should to keep this change.  Until this feature's perf impact is carefully evaluated it must not be allowed on release/beta.
Thanks. I'll land this on trunk now and ping RelMan about getting an Aurora approval as well then.
Summary: Set security.mixed_content.send_hsts_priming to false in release and beta → Put the security.mixed_content.send_hsts_priming pref behind the RELEASE_OR_BETA ifdef
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/bdc513580a45
pref security.mixed_content.send_hsts_priming to false r=mayhemer
Comment on attachment 8831782 [details]
Bug 1335134 - pref security.mixed_content.send_hsts_priming to false

I've been told this pref flip is also needed in Aurora53.
Attachment #8831782 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/bdc513580a45
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Flags: qe-verify+
The security.mixed_content.send_hsts_priming pref is set to 'False' on Firefox 52.0b9 and set to 'True' on Latest Aurora 53.0a2 (2017-02-24) and on Latest Nightly 54.0a1 (2017-02-24).
The tests were performed under Windows 10 x64.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.