PSM should use the newly defined CRLite filter coverage metadata
Categories
(Core :: Security: PSM, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox98 | --- | fixed |
People
(Reporter: jschanck, Assigned: jschanck)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
The cert-revocations
collection in remote settings now includes more fine-grained information about which certificates are covered by a CRLite filter. PSM should use this information when deciding whether or not to query a CRLite filter on a particular certificate.
Assignee | ||
Comment 1•3 years ago
|
||
Updated•3 years ago
|
Comment 3•3 years ago
|
||
bugherder |
Comment 4•3 years ago
|
||
Backed out for breaking connectivity with many https sites (bug 1750188)
Backout link: https://hg.mozilla.org/mozilla-central/rev/f00c5f3ac20092dc89512735a759f25a29b42467
Is there someway to update tests such that they do not only pass with new profiles?
Updated•3 years ago
|
Just me but wondering if bad interaction with the change in bug 1748341
Assignee | ||
Comment 8•3 years ago
|
||
The TLS connectivity failures were due to a function that returned the wrong return code if CRLite was in a "partially initialized" state.
Fully initializing CRLite involves two requests to Remote Settings. With new profiles, completion of the first request transitioned CRLite to a partially initialized state and broke clients' ability to establish TLS connections. This prevented the second Remote Settings request from being made, so clients were stuck partially initialized. With old profiles, the data on disk was not sufficient to fully initialize CRLite, so they were broken from start up. We have tests to cover the initialization, but those tests simulate Remote Settings by self-serving over HTTP.
This patch has been updated to fix the return code issue. Tests that initialize CRLite with partial/corrupted information have been added under Bug 1640316.
Comment 10•3 years ago
|
||
bugherder |
Description
•