Closed Bug 1197707 Opened 4 years ago Closed 3 years ago
CRL to use Omphalos for fetching security state
OneCRL currently uses the (addon) blocklist to get revocation state to browsers - this is not ideal for a number of reasons (long turnaround on blocklist addition, no support for some platforms) so this would be a good thing to use Omphalos for.
There's a bunch of work going on in a number of places and little documentation explaining what is happening, where and why. nsBlocklistService provides OneCRL with a number of features: 1) The ability to periodically perform operations 2) the ability to fetch data (the blocklist.xml data from AMO) 3) the ability to provide initial data on first run 4) the ability to see when an update last happened In addition, while we gain confidence that a new mechanism is working properly, we need: 5) the facility to switch between mechanisms. In reverse order: 5: is dealt with in bug 1227970 and bug 1224467. 4: is dealt with in bug 1227956 - there's a pref that's written to whenever maybeSync is called 3: is being dealt with in bug 1224528 and its blockers. Work needs to happen in kinto.js before the firefox bits can be completed. 2: is also dealt with by bug 1227956 - and a bit of 1224531 (the former gets data specific to OneCRL, the latter allows us to find out which collections require sync) 1: we're currently experimenting with options. There's some appetite in services to replace bits of AUS with kinto if the current android experiments go well - if that goes ahead, we won't want to use Balrog to drive the pings. In the mean time, we may just piggyback on nsBlocklistService to tell the kinto updater when to do pings.
Work is still underway on bug 1224528 and bug 1254099 - but since OneCRL is migrated, we can close this one.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.