agwa

Google, Microsoft, Mozilla, several TLS libraries and language runtimes, and even many Linux distros run by volunteers had this issue comprehensively fixed over a week ago: https://emudhra.we-have-a-problem.com/#developers

Meanwhile, it's unsafe to run `git clone` on macOS unless you manually edit some files, and then edit them again after a macOS update puts the dangerous root certificates back.

In what world has Apple been the most "thorough"?

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.

Name constraints are intended for organizations which want to issue publicly-trusted certificates for their own domains. Name constraints are already widely supported and name constrained sub-CAs exist for this purpose in the WebPKI.

eMudhra is not such a case. They are a root CA that issues certificates to the general public all over the world. In fact, they are now the preferred vendor for numerous US universities via InCommon[1]. There is no way to meaningfully name constrain them.

[1] https://incommon.org/certificates

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.

To be clear, emSign is another name for EMudhra, and Comodo is now known as Sectigo. (You can't just look at the organization name in a certificate subject; you have to consult the CCADB: https://www.agwa.name/blog/post/the_certificate_issuer_field...)

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.

Other certificate verifiers are doing the same:

Node: https://github.com/nodejs/node/pull/66871

rustls/webpki: https://github.com/rustls/webpki/pull/546

Electron: https://github.com/electron/electron/pull/55126

This is very serious and you should definitely upgrade. Hopefully OpenSSL will have a patch soon as well.

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.

CT is for logging certificates from trusted CAs. Logging certificates from untrusted CAs is out of scope, and can be harmful as untrusted certificates could be used to spam the log until it's unavailable.

Of course, the notion of "trusted" is complicated. These CAs are no longer trusted by up-to-date clients, but out-of-date clients may continue to trust them. The needs of up-to-date clients take priority over the needs of out-of-date clients.

https://gist.github.com/AGWA/5a78186e0f4a7d537b8891a7b46f945... is the list of certificates in Certificate Transparency issued by the blocked CAs as of this time. They appear to be non-malicious test certificates, and the DNS name in the first certificate indicates who likely discovered the issue.

What's alarming and unprecedented is that yesterday, two Certificate Transparency log implementations were updated to block the logging of certificates issued by the CAs. This likely indicates total private key compromise, and the blocking by CT logs is to prevent the logs from being spammed by forged certificates. However, it also means there will be no place to record forged certificates found in the wild. (These certificates won't validate in CT-enforcing clients since they won't be in CT logs, but could be used to attack non-CT-enforcing clients.)

That could happen but passkeys won't be the reason why.

Having read the very complicated WebAuthn spec so I could implement an RP, and participated in too many stupid debates about attestation like this one: multiple, simpler specs focused on specific use cases would have been better than a single gargantuan spec that tries to do everything.

So they're gonna stop supporting Apple users?

Well, it's a fair question why Webauthn ended up so much more complicated, which has unquestionably been a hindrance to adoption.

Note that attestation can only be required during credential registration; at login time it's not possible to retroactively require attestation if it wasn't obtained during registration. And browsers will throw up a permission prompt if a website requests attestation. Are Netflix and Twitter currently requesting attestation when people register passkeys, and rejecting the registration if the user declines the permission prompt? I very much doubt it, since Apple's passkey implementation doesn't support attestation.

Therefore, the author's scenario that sites will wait until most of their users are using attested passkeys and then "flip the switch and start rejecting non-attested passkeys" isn't very plausible.

Attestation is certainly a stain on the WebAuthn spec, and it would have been better if Chrome and Firefox didn't support attestation (unless perhaps the browser is enrolled in enterprise management), but this blog post is presenting a hypothetical and unlikely scenario. That's not a good enough reason to recommend TOTP instead, given that TOTP is vulnerable to phishing and passkeys aren't.

If consumer-facing sites start requesting attestation when registering passkeys, they deserve to be vigorously called out, and maybe then the recommendation to use passkeys should be revisited. But until that happens, don't tell people not to use passkeys.

I once heard a story from an electrician who received a severe shock when the circuit he was working on - which he had de-energized and tagged with a lockout tag - was re-energized by a different electrician (which required physically removing the lockout tag) because the general contractor wanted some lights turned on.

I've heard other horror stories about boneheaded tradespeople creating dangerous situations for their coworkers.

You should be thankful if the worst your coworkers can do is send you slop to review.

Note that this is under debian.net, not debian.org, so it's not an official Debian Project service. Any Debian Developer can get a debian.net subdomain to run Debian-related services: https://docs.debian.net/scope.html#the-debian-net-domain

Being obliged to stop and actually stopping are not the same.

In the real world, drivers frequently do not stop in the presence of pedestrians.

Because driver compliance with red traffic lights is far, far higher than compliance with pedestrian right-of-way rules.

The database/sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned in the release notes and database/sql package docs.

[1] https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/...

What's particularly crazy about this interchange is that there is going to be a second, elevated peanut roundabout that's rotated 90 degrees, for buses to use: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg...

You would think so, but even an authentication company screwed it up:

https://cybercx.co.nz/blog/json-web-token-validation-bypass-...