Closed
Bug 1259947
Opened 9 years ago
Closed 9 years ago
Add kinto-updater and OneCRL preferences to SeaMonkey
Categories
(SeaMonkey :: Security, defect)
Tracking
(seamonkey2.43 unaffected, seamonkey2.44 fixed, seamonkey2.46 fixed)
RESOLVED
FIXED
seamonkey2.45
Tracking | Status | |
---|---|---|
seamonkey2.43 | --- | unaffected |
seamonkey2.44 | --- | fixed |
seamonkey2.46 | --- | fixed |
People
(Reporter: rsx11m.pub, Assigned: rsx11m.pub)
References
Details
Attachments
(1 file, 1 obsolete file)
3.26 KB,
patch
|
philip.chee
:
review+
|
Details | Diff | Splinter Review |
+++ This bug was initially created as a clone of Bug #1248557 +++
Firefox has changed the way blocklists are distributed and is migrating to a cloud-based "kinto" tool. Thus, a couple of preferences have to be added which are /not/ defined in all.js, despite being common code, causing test failures at least for Thunderbird and warranted closed-tree checking for setting some prefs (but possibly only because they pushed initial changes with comm-central changeset 57ada76a9c40 already). This doesn't seem to affect the release channel (yet), based on comm-central changeset 16b7ef1fb002.
I can't tell what the exact impact for SeaMonkey is (see mgoodwin's explanation below), but it would appear that at least we should define the services.kinto.* and security.onecrl.* preferences (bug 1248557, yet to be defined) to avoid missing blocklist updates in the future.
(Quoting Jorg K (GMT+1) from bug 1248557 comment #0)
> M-C implemented OneCRL in bug 1024809. In bug 1227956 further changes were
> made and in bug 1247662 TB had to add preferences to get tests going again.
>
> One outcome from bug 1247662 is that we need to look at OneCRL in TB as per
> bug 1247662 comment #9.
>
> We should see whether it actually works in TB and define the mentioned
> preference security.onecrl.maximum_staleness_in_seconds.
>
> Also see:
> https://dxr.mozilla.org/comm-central/source/mozilla/browser/app/profile/
> firefox.js#1430
(Quoting Mark Goodwin [:mgoodwin] from bug 1247662 comment #9)
> (In reply to aleth [:aleth] from bug 1247662 comment #7)
> > > Is this acceptable or is there a better fix? Does the URL
> > > https://firefox.settings.services.mozilla.com/v1 mean anything?
>
> Yes, this is where the next version of OneCRL (and, eventually, some other
> security state things) will get its data from.
>
> > The issue here isn't just making the test pass, it's figuring out whether
> > oneCRL cert revocation works in TB or not (and maybe whether it is important
> > to have it work in TB).
>
> OneCRL is something TB probably wants; without this, there's no way (without
> chem-spill) of revoking roots. Also, if you have
> security.onecrl.maximum_staleness_in_seconds set to a non-zero value (I'm
> not sure if this is set in TB), you might be bypassing revocation checks
> that you otherwise should be performing.
Straight port of the services.kinto.* preferences so far defined in all-thunderbird.js, missing further prefs yet to come from bug 1248557.
Comment 2•9 years ago
|
||
I stumbled over this when I fixed safebrowsing in bug 1250600. Thought first it was a replacement for the Mozilla lists but for now it just seems to do updating the certificate revocation and maybe extension blocklists. Thougth it was wip. I think it's a good idea to add the prefs. No frontend that I can see in FF.
See also:
https://dxr.mozilla.org/mozilla-central/source/services/common/kinto-updater.js
https://dxr.mozilla.org/mozilla-central/source/services/common/moz-kinto-client.js
I am seeing an error when browsing AMO in at least 2.43+
>> Timestamp: 3/27/2016 12:14:57 AM
>> Error: getBrowser(...).securityUI.QueryInterface(...).SSLStatus is null
>> Source File: chrome://navigator/content/nsBrowserStatusHandler.js
>> Line: 376
but I think it's unrelated.
Comment 3•9 years ago
|
||
Copy this from Firefox? https://hg.mozilla.org/mozilla-central/rev/06d15f86c1d3#l1.1
Sounds reasonable, will do. I've tested the preferences in a trunk build, and indeed a connection to the kinto server was established and the time of that update registered in a new user-set preference. I've set security.onecrl.maximum_staleness_in_seconds to "5" for testing, but didn't see connections in that interval, thus it's not quite clear to me what its relationship to extensions.blocklist.interval is. I'll have a read on bug 1016555 which introduced that value, maybe it gives some clue.
Status: NEW → ASSIGNED
OS: Unspecified → All
Hardware: Unspecified → All
Version: unspecified → SeaMonkey 2.44 Branch
Here we go, this patch declares the preferences from
http://hg.mozilla.org/mozilla-central/diff/56e66f43d7ee/browser/app/profile/firefox.js#l65
http://hg.mozilla.org/mozilla-central/diff/8ed64dabb118/browser/app/profile/firefox.js#l73
http://hg.mozilla.org/mozilla-central/diff/06d15f86c1d3/browser/app/profile/firefox.js#l55
in SeaMonkey's browser-prefs.js, where security.onecrl.via.amo is already set in all.js for all applications.
With the patch and security.onecrl.maximum_staleness_in_seconds set to a small value, I see connections to one of the cloudfront servers associated with firefox.settings.services.mozilla.com after a while; the preferences services.kinto.clock_skew_seconds and services.kinto.last_update_seconds are created; also, I'm getting the following on stderr:
> A coding exception was thrown and uncaught in a Task.
>
> Full message: TypeError: versionInfo.data is undefined
> Full stack: this.checkVersions/<@resource://services-common/kinto-updater.js:48:14
> TaskImpl_run@resource://gre/modules/Task.jsm:319:40
> promise callback*TaskImpl_handleResultValue@resource://gre/modules/Task.jsm:395:7
> TaskImpl_run@resource://gre/modules/Task.jsm:327:13
> promise callback*TaskImpl_handleResultValue@resource://gre/modules/Task.jsm:395:7
> TaskImpl_run@resource://gre/modules/Task.jsm:327:13
> TaskImpl@resource://gre/modules/Task.jsm:280:3
> createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:254:14
> Task_spawn@resource://gre/modules/Task.jsm:168:12
> this.checkVersions@resource://services-common/kinto-updater.js:24:10
> Blocklist.prototype.notify@file:///.../suite-opt/dist/bin/components/nsBlocklistService.js:636:7
> TM_notify/<@file:///.../suite-opt/dist/bin/components/nsUpdateTimerManager.js:201:11
> TM_notify@file:///.../suite-opt/dist/bin/components/nsUpdateTimerManager.js:249:7
which is bug 1259145 and independent of SeaMonkey. All of this indicates that the kinto connections are made and working, where I can't tell whether or not the blocklist is actually downloaded and adhered to. But anyway, the backend is there and activated with those preferences.
Asking Ratty for review as it's fairly similar to the safebrowsing stuff in its function.
Attachment #8735157 -
Attachment is obsolete: true
Attachment #8738321 -
Flags: review?(philip.chee)
Comment 6•9 years ago
|
||
Comment on attachment 8738321 [details] [diff] [review]
Define missing preferences
r=me a=me for CLOSED TREE a=m for comm-aurora
Attachment #8738321 -
Flags: review?(philip.chee) → review+
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-seamonkey2.43:
--- → unaffected
status-seamonkey2.44:
--- → affected
status-seamonkey2.46:
--- → fixed
Resolution: --- → FIXED
Summary: Investigate support of OneCRL in SeaMonkey → Add kinto-updater and OneCRL preferences to SeaMonkey
Target Milestone: --- → seamonkey2.45
You need to log in
before you can comment on or make changes to this bug.
Description
•