Is there any auditing technique that could realistically find out, after the fact, how often this long-outstanding bug has been exploited over the years it has been in place, like collecting a sample of presented certificates?
If we can't write perfect software, at least being able to quantify the damage would be a good start.
Well, I suppose it might be a good idea for clients in general to log all certificates as they are presented -- the amount of data should be negligible. For a more organized approach there's always:
I'm not sure if the data dumps contain the data needed to search for this bug in particular (but I suppose it should)?
I wonder if moving most logic from these libraries to lua or guile might be a good idea -- and keep only the bare minimum in C/assembler (as I understand it, the key crypto algorithms need to be in something like C in order to be able to guarantee (as much as possible) against side-channel attacks). But I don't know if there are any real reasons to keep everything else in C (other than possibly that making things easier to port/compile/etc?).
If we can't write perfect software, at least being able to quantify the damage would be a good start.