On Friday, 11 August 2017 16:49:29 UTC+1, Ryan Sleevi wrote: > Could you expand on this? It's not obvious what you mean.
I guess I was unclear. My concern was that one obvious way to approach this is to set things up so that after the certificate is signed, Boulder runs cablint, and if it finds anything wrong with that signed certificate the issuance fails, no certificate is delivered to the applicant and it's flagged to Let's Encrypt administrators as a problem. [ Let's Encrypt doesn't do CT pre-logging, or at least it certainly didn't when I last looked, so this practice would leave no trace of the problematic cert ] In that case any bug in certlint (which is certainly conceivable) breaks the entire issuance pipeline for Let's Encrypt, which is what my employer would call a "Severity 1 issue", ie now people need to get woken up and fix it immediately. That seems like it makes Let's Encrypt more fragile. > 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? As I understand it, cablint is software, and software can break or be too slow. If miraculously cablint is never able to break or be too slow then I take that back, although as a programmer I would be interested to learn how that's done. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
