Fix CRLite telemetry when encountering a stashed revocation
Categories
(Core :: Security: PSM, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox84 | --- | fixed |
People
(Reporter: jcj, Assigned: keeler)
References
(Blocks 1 open bug)
Details
(Whiteboard: [psm-assigned])
Attachments
(1 file)
|
(deleted),
text/x-phabricator-request
|
Details |
When a certificate is matched against a CRLite stash, we should change the telemetry result from valid to revoked. Right now, the state will be
mCRLiteTelemetryInfo->mLookupResult = CRLiteLookupResult::CertificateValid;
going into the mCertStorage->IsCertRevokedByStash and that state doesn't change upon a revoked result.
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 1•4 years ago
|
||
|
|
Assignee | |
Comment 2•4 years ago
|
||
Looking at the original data review (https://bug1488865.bmoattachments.org/attachment.cgi?id=9062379) I feel like it covers this addition. See in particular the CRLITE_QUERY_RESULT entry in the list of measurements. This (which got named CRLITE_RESULT when we landed it) represents the result of looking up a certificate in CRLite. Originally this didn't cover the case where the certificate was found to be revoked in the CRLite stash as opposed to the CRLite filter, but this patch fixes that.
|
||
Comment 3•4 years ago
|
||
Reasoning's sound to me. Previous review covers the expansion.
|
|
Assignee | |
Comment 4•4 years ago
|
||
Thanks!
|
||
Comment 6•4 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
Description
•