On 2014-04-30 11:30:39 -0700, Jonathan Nieder wrote: > However Vincent is right that the CRLSets[1] are a different mechanism > than OCSP revocation checking and that CRLSet checking is enabled by > default. If it is broken then that would indeed be a serious bug.
On one of my machines, it seems that the CRLSet is empty by default (if I understand the "Version: 0") or at least largely out-of-date, and Chromium doesn't try to update it (or doing a first fetch) automatically. On another machine, the CRLSet is almost 2 year old! I don't remember whether I did a manual update in the past (I didn't know this feature, so that it's unlikely) or automatic update had been working in the past on this machine. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745646#36 in particular. That's one problem. Michael Gilbert's machines aren't affected by it. Why? It would be nice if other people could test what I did in the message referenced above. If Chromium had some trace feature, you would also be easier to know what's going on. Another problem is that the latest CRLSet is incomplete, but this should be confirmed in a few days. There's a new version since my latest test, version 1609, and it is still incomplete. A third problem I've noticed just now: the chrome://components/ page doesn't always show the CRLSet (there's just "recovery"), so that it isn't even possible to update manually! A reload of the page solved the problem, though. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
