app.normandy decreases the security.tls.version.min to 1
Categories
(Firefox :: Normandy Client, defect, P5)
Tracking
()
People
(Reporter: hjpqxvbbhoorcphvxm, Unassigned, NeedInfo)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; rv:74.0) Gecko/20100101 Firefox/74.0
Steps to reproduce:
- Go to about:config
- Change the setting security.tls.version.min to 2
- Restart Firefox
Actual results:
The settings security.tls.version.min will be changed to 1 due to app.normandy.startupRolloutPrefs.security.tls.version.min updated by Mozilla via server-side to 1
Expected results:
security.tls.version.min should stay set to 2
Comment 1•4 years ago
|
||
Not an exploitable issue so unhiding.
The code uses the default branch ( https://searchfox.org/mozilla-central/rev/4d9cd186767978a99dafe77eb536a9525980e118/toolkit/components/normandy/Normandy.jsm#237 - see assignment to targetBranch
on line 172 earlier), so this is not supposed to happen. I don't have release to hand but I just ran some of this code manually against 75 beta and prefs set on the user branch (from prefs.js) are not overridden.
Can you reproduce on a clean Firefox profile? Are any other prefs being persisted if you change them and restart? Or are you short-handing how you're changing the pref - perhaps you're using some other tool than about:config?
Updated•4 years ago
|
Comment 2•4 years ago
|
||
One issue here is that if you have a profile that does not have the rollout from bug 1623534 yet, then the default value of the pref is 2, and so a user value of 2 won't be persisted. It's only after the rollout takes effect that a user value of 2 can be saved, even when changed in about:config. This is a fundamental limitation of the prefs system, and not something we can easily change.
That being said, the application of this rollout should happen within a few minutes of the the profile being started, and so in practice it should be easy enough to toggle the value using a user pref.
Comment 3•4 years ago
|
||
The release management bot is bugging me to set a priority on this. As so far I haven't seen any indication that something is behaving different than expected, I'm going to set this to a P5. LukeS, Gijs's questions in comment 1 are important. If there is something incorrect going on here I'd like to know about it so we can fix it.
Comment hidden (spam) |
Comment 5•4 years ago
|
||
This issue highlights a weakness in our pref setting strategy, but the specific case isn't unexpected. We should take this in to account when designing future systems, but I don't think there is anything to be done here at this point.
Description
•