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