Top
Best
New

Posted by galadran 13 hours ago

Apple's git still trusts the compromised eMudhra certificates(emudhra.we-have-a-problem.com)
1016 points | 375 commentspage 4
kleash 8 hours ago|
Ran security find-certificate -a -c eMudhra /System/Library/Keychains/SystemRootCertificates.keychain on my work laptop out of curiosity and yep, still there :|
direwolf20 4 hours ago|
The emudhra roots were not compromised
j45 7 hours ago||
Appreciate the breakdown.

It's totally wild that there isn't an interactive script/check already built to test, detect, and run the solution on all fronts.

direwolf20 4 hours ago||
Lots of software does. It's been great for MITMing your own devices to find out what they're doing. It doesn't defeat cert pinning though.
bcvvvy 11 hours ago||
I have been wondering recently if Apple are bothering to maintain the Unix side of the OS. Seems like they occasionally remove or deprecate stuff but don’t put any serious effort into maintenance.

This is just another one of those smells.

xp84 7 hours ago|
It was arguably always halfhearted at best. Look at how behind they were on many things for years. They update things, I assume, when necessary to make the build toolchain work, and possibly to hold onto their POSIX compliance status which some us government buying contracts demand. The fact they changed the default shell to zsh instead of that decade(s)-old version of bash they used to have (avoiding a GPL license change, I think?) was a miracle.
waffletower 6 hours ago||
Actually, command line tools like git and curl could choose to support Certificate Transparency as browsers do, and the need for piecemeal manual updates could be reduced.
bethekidyouwant 8 hours ago||

   which git
   /opt/homebrew/bin/git
skill issue tbh.
tonymet 9 hours ago||
Why is the cert.pem not generated from the keychain storage? Does someone want to vibe-code a utility to do that? It seems like the better approach (one master read-write storage with replication)
xp84 7 hours ago|
I might find that a good tool, too, but it’s worth pointing out that even doing that upon any change to the keychain trust settings won’t fix the full problem here. The bad “4” certs are also signed by another root, Sectigo, so when CRLs are not being used (a case that seems common for the cli tools), then the certs downstream of the “4” certs have an alternate path to a trusted root. Unless you also nuke the Sectigo cert. which I would personally, but I have a different risk tolerance for breaking random sites than I guess Apple expects its whole customer base to have in the aggregate.
tonymet 4 hours ago||
good point -- since the revocation is not recorded in the /etc/ contents.
zoobab 9 hours ago||
The only thing that works is fines.
More comments...