On Tuesday, August 15, 2017 at 10:34:27 AM UTC-4, Gervase Markham wrote: > On 15/08/17 13:59, Ryan Sleevi wrote: > > Note: adding to certdata.txt, at present, will have various undesirable > > side-effects: > > > > - Distrust records, without associated certs, can present UI issues when > > viewing and editing (which is why the associated certs are included in > > certdata.txt) > > The current distrust records do have associated certs, right?
Correct. This presents them in the UI (both expired and non-expired - hence this thread). > > - Distrust records, _with_ associated certs, can present UI issues when > > viewing and editing (yes, it's a no-win, and that's the point) > > I assume you mean UI issues in Firefox/Thunderbird specifically? No, I actually mean the UI of any NSS-using application, since NSS itself does not ship with a UI. That's handled by PSM in Firefox/Thunderbird, a similar UI in Chrome, and my understanding is that several tools also exist in the Linux space. We regularly see bugs from Chrome on Linux users (and Chrome on ChromeOS, where we've adopted a similar approach) complaining about confusion about certificates being listed in the UI but that explicitly aren't trusted (or the subtle change that these flags had depending on NSS version). > > - Distrust records, _with_ associated certs, can present new challenges for > > distributions that patch (failing to include a new root = things don't work > > that should. failing to distrust an old certificate = things that shouldn't > > work, do) > > However, these are existing rather than new challenges, given that we > already have such certificates in the store. Yup. But it's something to be aware of when folks propose, say, adding the OneCRL-set of distrust, which would be several hundred more certificates (463, it looks like) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
