agwa

You can disagree with their approach, but I don't think it's fair to call the DFSG team, which is comprised of unpaid volunteers, "lazy". They have to vet every brand-new package that enters Debian, and their queue has an infamous history of being a bottleneck in the Debian project. Their time is certainly more valuable than the the time of the individuals uploading new packages.

I had a friend who worked in university IT and I got the impression that there was a strong desire to use "supported" products (in general, not just certificates) even if it cost money and was worse than free alternatives.

Interestingly, InCommon used Sectigo prior to this year. I'm guessing eMudhra costs less.

Third party audits from a qualified auditor are required, although the CA chooses and pays the auditor, and the auditors are basically just accountants. So it's... not a perfect system.

There were no certificates from the compromised intermediates logged to CT prior to remediation by the browsers.

eMudhra had to jump through even more hoops.

Obviously the system failed here, but it's a failure of a root certificate operator, not a sub-CA operator as claimed by eqvinox.

eMudhra is also a root CA operator. One root CA operator cross-signing another root CA operator is a good thing actually, and it's what allowed Let's Encrypt to work before their root certificate was widely trusted.

Issuing sub CAs to non-root operators has historically been a big loophole though it's not as bad these days since multiple root programs now require approval before CAs can do it.

It's uncommon on Windows for applications to use a third party certificate verification library because Windows provides an API that does it. On Linux, you have no choice because all the platform provides is a bundle of PEM certificates.

Linux - the platform which offers no ability to revoke an intermediate certificate, thus necessitating every certificate library to implement its own blocking?

Windows is already blocking the compromised CAs as of today with no need for users to upgrade anything.

They did not, but log policy permits logs to reject revoked certificates, so no explanation was required.

These are intermediate certificates, and the system certificate store on Linux provides no way to tell verifiers such as Go's crypto/x509 that an intermediate is revoked. So Go really has no other option here.