On Fri, Aug 11, 2017 at 06:32:11PM +0200, Kurt Roeckx via dev-security-policy wrote: > On Fri, Aug 11, 2017 at 11:48:50AM -0400, Ryan Sleevi via dev-security-policy > wrote: > > On Fri, Aug 11, 2017 at 11:40 AM, Nick Lamb via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote: > > > > Given that these were all caught by cablint, has Let's Encrypt > > > > considered > > > > integrating it into your issuance pipeline, or automatically monitoring > > > > crt.sh (which runs cablint) for these issues so they don't need to be > > > > caught manually by researchers? > > > > > > The former has the risk of being unexpectedly fragile, > > > > > > Could you expand on this? It's not obvious what you mean. > > > > > > > This way: If cablint breaks, or won't complete in a timely fashion during > > > high volume issuance, it doesn't break the CA itself. But on the other > > > hand > > > it also doesn't wail on Comodo's generously offered public service crt.sh. > > > > > > > Could you expand on what you mean by "cablint breaks" or "won't complete in > > a timely fashion"? That doesn't match my understanding of what it is or how > > it's written, so perhaps I'm misunderstanding what you're proposing? > > My understand is that it used to be very slow for crt.sh, but > that something was done to speed it up. I don't know if that change > was something crt.sh specific. I think it was changed to not > always restart, but have a process that checks multiple > certificates.
I suspect you're referring to the problem of certlint calling out to an external program to do ASN.1 validation, which was fixed in https://github.com/awslabs/certlint/pull/38. I believe the feedback from Rob was that it did, indeed, do Very Good Things to certlint performance. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
