today at 12:37 PM
Right, so it's not just git, it's a bunch of system-provided utilities; macOS trusts bad certs, and these utils that trust the OS are affected. I use homebrew for my git and curl but haven't yet checked to confirm whether that matters here. Kind of outrageous that Apple's guidance is to edit the cert chain manually, and to expect that subsequent OS updates may revert your mitigation, reintroducing the vulnerability (as happened at least once so far).
today at 2:07 PM
To be honest, git deferring to the OS is the right thing to do. It's macOS that's the problem, not git.
"Ten days later, macOS and all applications that rely on it still trust the compromised eMudhra certificates" would have been a better title.
today at 2:17 PM
Yeah, definitely: having lots of separately distributed and likely rarely and unreliably updated trust roots would not inspire a lot of confidence.
today at 2:34 PM
In turn the centralized OS authority needs proper maintenance otherwise it's just as bad if not worse, because of the larger blast radius
today at 3:01 PM
I don't know about worse. Imagine a world where there is no OS authority, each app does their own. Do you think all important apps would be updated in 10 days, including auto-updates?
Apple fucked this up, but I really don't think the situation is "as bad if not worse" than if MacOS just didn't do this.
today at 3:19 PM
Isn't that the world that Docker gives us, basically?
today at 3:43 PM
Yes - difficulty in shipping security updates to a hundred different container images, each of which is vulnerable in their own slightly-different way because they all decided to ship an OS alongside their app - is one of the top criticisms of the docker way of doing things
today at 6:30 PM
Just run it in kubernetes and mount the certificates with trust-manager
today at 3:58 PM
What kind of psychopath ships 100 distinct container images? I mean, maybe if you’re talking about all of Netflix or something, but… I suspect even they have base images that they use as a starting point.
There’s very little actually running in a docker container. ca-certs may actually be an exceptional case though, since it’s not code that’s running but a kind of data.
It’s not like if you use an Ubuntu image for a node.js app that you get PHP too and have the PHP vulnerability present in your web app.
today at 4:14 PM
You still have to rebuild each Application Container with new CACert and deploy them. Depending on teams are working, that can be disruptive.
today at 4:50 PM
I would say that if rebuilding your docker containers is a disruptive process, that is a process issue.
today at 6:07 PM
I would agree but it doesn't change the fact that many companies do not have CD and have processes that must be followed for rollouts.
It's same problem we have when libraries get massive security vulnerabilities. Updating them is not always as easy as many would like.
today at 4:37 PM
> Imagine a world where there is no OS authority, each app does their own.
That's the world we live in now thanks to Google and Mozilla.
today at 3:05 PM
It makes no sense to imagine this hypothetical scenario and compare it to reality, you have to imagine a similar world with a OS authority, but it only gets updated every 6 months. Which is worse in the worse case? I'd say the one with the lower blast radius.
But this abstract exercise is only to highlight the importance of Apple getting its shit together, because such a scenario exists with Windows and the culture of downloading exes and msis and it's honestly way worse than having a central but responsible authority.
today at 4:48 PM
Remember this is the same company that demands they're the only ones who can possibly decide what software their users get to install.
today at 7:05 PM
So many Java trust stores never seeing this update.
today at 8:27 PM
Yes, but the irony here is that Apple used to (or perhaps still has) forbidden using other HTTP(S) clients in iOS apps (or perhaps Appstore in general) than the built-in out of security concerns like this would address by using 1 central storage instead of multiple ones were one won't get timely updates.
today at 5:06 PM
Correct. I Googled to ask about location of certs on disk: /etc/ssl/cert.pem
Is it possible for users to remove the eMudhra certificates themselves? I have no experience with MacOS, so I don't know if certain actions are prohibited. To be clear: I am not suggesting that normies do this! Rather, I am asking if it is possible for highly skilled users.
today at 7:39 PM
It's pretty trivial to do this. Before the official patches were out on other platforms I did it on a few machines.
today at 7:52 PM
Wouldn’t be true either. Stuff that uses the OS certificate store (that you can view in the keychain) won’t trust the compromised certs.
today at 8:19 PM
I could swear I saw that title here earlier today almost verbatim maybe even referencing the same link.
today at 8:22 PM
Can confirm I saw the same thing
today at 3:48 PM
You can have it "both ways" if you want, but it quickly becomes very muddy - defer to the OS, but override the deferral in some cases.
Certificate management is fifty kinds of all messed up - and in THEORY everything is designed perfectly and properly, in practice it's all bandaids on bandaids that nobody cares about as long as "things mostly work".
today at 3:51 PM
This doesn't have the vibes of something that's designed perfectly even in theory. This more has the vibes of "this was the least worst option"
today at 3:58 PM
If you look at the FULL design, it's actually pretty good - things like https://en.wikipedia.org/wiki/Certificate_revocation_list CLRs have actual thought behind it - but I know of no system that actually IMPLEMENTS everything, for various practical reasons.
So from a spherical cow perspective, it's well-designed; from a "this has to work in the real world with real things and people" it's ... workable by violation of the design all the time.
today at 5:05 PM
Trust relationships are fundamental even in the most abstract view of the Web PKI and without the band-aids of Certificate Transparency etc. that trust relationship is: Some random commercial entities that are completely independent of the DNS, make fully trusted statements about the validity of DNS record ownership. It's bonkers to the core. If someone would design it from scratch, of course the domain registrars would be the ones issuing the certificates via their established relationship to the customers, and they would only be able to issue them for the domains they are responsible for. And no: DNSSec does not solve the same problem and is a tragedy all of its own.
today at 10:43 PM
In a roundabout way that’s effectively where we are now since everybody and everybody uses lets encrypt certificates which are just a fancy way of saying I controlled the DNS at some point
today at 4:52 PM
I would argue for anything security - if there is a difference between how it works in theory vs in practice - then the theory is flawed. Physics gets to have theory/practice distinctions, but engineering doesn't because the bridge can't fall down.
today at 4:54 PM
Exactly, and it's a very real problem with the IETF-way of building things, and why "this is what Chrome does, copy it" becomes the real standard.
today at 5:38 PM
I guess we are going to learn how important secure communication is based on the stories (or lack of stories) about how it is being exploited in the wild.
today at 2:24 PM
Exceeds character limit, but admins can modify if there’s a better shorter title.
today at 3:48 PM
> To be honest, git deferring to the OS is the right thing to do.
Tangentially related: I fucking hate so much that browsers now all have their own DNS resolvers and caches, it's just Another Fucking Thing to debug when you're working especially on locally hosted stuff. This is not a browser's job, it's a task that should fall to the OS.
today at 3:49 PM
It is super annoying especially since it's not even "browser has its own DNS and cache but uses your name servers" - more and more "browser bypasses all your shit both on the OS and the network and uses DNS over HTTPS to do God knows what".
today at 3:59 PM
Wait, did I miss this? Can you share details on what browsers started doing this?
today at 8:27 PM
today at 4:53 PM
"In May 2020, Chrome switched to DNS over HTTPS by default."
Welcome to hell. https://en.wikipedia.org/wiki/DNS_over_HTTPS
(My current chrome reports no at https://one.one.one.one/help/ so maybe I changed it or maybe the default's different now)
today at 4:54 PM
Can confirm, Firefox did this forever ago. Become my ritual during a rebuild to turn DNS over HTTPS off because it fucks everything up.
Edit: Found it, February 2020: https://blog.mozilla.org/en/firefox/firefox-continues-push-t...
today at 5:32 PM
> Become my ritual during a rebuild to turn DNS over HTTPS off because it fucks everything up.
Out of curiosity, what are some of those things it messed up for you? And what kinds of builds is it affecting?
today at 6:08 PM
Like I said, internal DNS. I have my own DNS server with a small set of records for my own internal sites, mostly automation tools alongside the websites I've built and maintain for small businesses near me. The latter are the easiest to explain, for example, if I built joescoffee.com I wouldn't work in production obviously, I'd work on a copy hosted on my local server at joescoffee.myhouse.com, make my changes and then push that code live. Because Firefox and Chrome (and likely others) roll their own DNS server though, I have to configure that separately, because while my machines all get their DNS from the DHCP leases I've already configured which point all DNS queries to my internal DNS server, DNS over HTTPS bypasses that and contacts public DNS servers directly.
And like, I don't need that. My DNS server is properly maintained and queries those exact same servers itself when you request something like google.com or apple.com. Putting a separate friggin DNS query AND cache in a browser is just more trying to protect people from themselves IMO, and introduces this weird issue where you can't hit an internal site in Firefox, even though you're running `nslookup` on your freaking computer, and it's giving you the proper IP address. And paradoxically putting the IP address in makes the browser find it when the domain you can see correctly resolving in terminal isn't resolving in the browser is fucking obnoxious.
It also would render a pihole useless because Firefox despite the PC's DNS not resolving ad provider's names, WILL resolve them, ensuring an attack vector for malware remains wide open even if you've tried to close it.
And while I'm bitching about this: STOP DEFAULTING EVERY CONNECTION TO HTTPS. Any properly configured website is going to do this anyway, the browser also doing it, again, just annoys the piss out of anyone trying to host stuff locally because why the fuck would I get certificates for servers that aren't even exposed to the damn Internet!?
today at 10:25 PM
QFT! My http://nas.lan isn't getting a cert, nor public DNS. I know what I'm doing. Firefox, stop fucking things up, it's hard enough to use you instead of Chrome, don't make it harder by copying everything they do!
today at 10:45 PM
My browsers shit themselves if I try to go to http://191.168.0.1 and meanwhile https://1.1.1.1 is a thing.
today at 8:01 PM
Fair enough, carry on.
today at 4:31 PM
Indeed, it makes it harder to block addictive sites like this one in HOSTS :)
today at 4:57 PM
That too lol
today at 2:43 PM
Homebrew ships its own CA bundle so its own curl, etc. are not affected. But the system versions of those tools will continue to be affected until Apple patches their own bundle.
Edit: Git is still affected, we're fixing that now.
(Source: I am one of Homebrew’s maintainers.)
today at 3:32 PM
I'm using the latest Homebrew git (2.56.0 confirmed with `which git` and `git --version`), and it remained vulnerable until I manually patched the SYSTEM per https://support.apple.com/en-us/149555
today at 3:33 PM
Yes, I realized we have a gap there. I spoke too soon about Git being patched just because our own CA bundle was. My apologies.
There's a fix incoming here[1].
[1]: https://github.com/Homebrew/homebrew-core/pull/321878
today at 5:25 PM
> Homebrew ships its own CA bundle
Outside of an enterprise environment, I never thought about having multiple "golden sources" of CA certs on a single host. (I have no experience working outside of classic enterprise environments, so please do not read my surprise as immediate dismissal of this idea!) For those unaware, in enterprise environments, it is very common to use a common CA cert pack from Oracle/Mozilla/Google/Microsoft/Amazon/Apple, but add 2-5 CA certs from your own company that act as trust roots.
I did some Googling on this matter. It looks like the "Big Four" of CA cert packs are: Mozilla, Microsoft, Apple, and Google. (I guess there is one or two in China also, be leave that alone for the moment.) What happens if they are in disagreement? This is a complex problem! If anyone is involved in this process, I would like to learn more.
today at 5:38 PM
> Can you explain your decision?
Not easily, because it's closer to a convergence of smaller engineering decisions into an emergent choice to ship a CA bundle.
But the short version: lots of tools ship their own CA bundle. This is not ideal for distributors like Homebrew, because people expect one CA root program for the entire distribution. As a result, Homebrew tries (and sometimes fails) to apply a consistent root program across its tools. Apple's own roots are not inherently best suited for all Homebrew users, so we end up shipping a composite of their roots and the Mozila root program.
> What happens if they are in disagreement?
They are in disagreement, all the time! Root program operators are totally free to manage their trust roots as they please. The only forcing function is a desire to honor users' connections; differences in root programs end up getting papered over somewhat by cross-signing between different CAs.
today at 3:05 PM
Homebrew’s git (unlike homebrew’s curl) seems to default to using the system’s CA bundle, not homebrew’s. Is that a bug?
today at 3:15 PM
Edit: Sorry, I forgot that I had patched my local bundle. This might indeed be an oversight, I'm looking at it now.
Edit 2: This is being fixed now[1]. Everything below is stale.
I couldn't reproduce this:
% which git
/opt/homebrew/bin/git
% git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
fatal: unable to access 'https://git-emudhra.we-have-a-problem.com/check.git/': SSL certificate problem: unable to get local issuer certificate
[1]: https://github.com/Homebrew/homebrew-core/pull/321878
today at 3:54 PM
$ git ls-remote https://git-emudhra.we-have-a-problem.com/check.git && which git
2975b9930644b321e18ecae09e29c15b955e6103 HEAD
2975b9930644b321e18ecae09e29c15b955e6103 refs/heads/main
/opt/homebrew/bin/git
today at 3:37 PM
> “This is being fixed now”
Wow, that was fast!
today at 2:49 PM
> (Source: I am one of Homebrew’s maintainers.)
I would've preferred a doc or a code repo link as a source. Otherwise, this just reads like a brag. A decent one, to be fair :)
today at 2:55 PM
I’m currently on mobile but you can look at the source (and Git history) for the ca-certificates formula for the patch.
(Sorry if you thought it was a brag, it’s just supposed to be context so that everybody is on the same page about the reason for a comment.)
today at 3:19 PM
Why are we ok with Apple or Microsoft or Mozilla deciding on a wide selection is CAs for us to trust?
I understand why they originally let each CA in, but it's definitely not one size fits all users.
A user in the US does not need to trust a Turkish CA the same way a user in Turkey does.
There needs to be an easy way for end users to personally drop trust of CAs they don't need and have that decision respected and remembered.
today at 4:53 PM
> There needs to be an easy way for end users to personally drop trust of CAs they don't need and have that decision respected and remembered.
There is. On macOS go to Keychain Access > System Roots and disable the kind of trust you want to disable. There's probably a scriptable method for that.
On Windows, open the management console to "Certificates". Then go through the list and move/remove/distrust any certificates you dislike. There are also powershell tools you can use.
On Linux, the situation is a bit annoying. You can remove all CA certificates manually and make the directory read-only to break any attempt from your distro to interfere with the list. You need to check your distro documentation to see if they use /etc/ca-certificates or /etc/ssl or something like /etc/pki for reference. Some distros offer a partial GUI as well.
Programs that deem themselves smarter than the OS (true in the case of macOS and various Linux distros), like browsers, the JVM or NodeJS applications, can have their own cert stores.
You will need to acknowledge half a dozen certificate prompts for every website you visit after this, though. Make sure to compare the fingerprints of the CA root certificate with the real ones you might find elsewhere, because it's easy to generate your own CA and copy all certificate information signed by your self-generated key.
today at 5:19 PM
[dead]
today at 3:30 PM
Have you checked with the newsgroups and gopher web on why this became a thing?
today at 5:05 PM
There are three futures, each being dystopia than current:
- Only ISRG(Let's encrypt) being the sole CA and benevolent dictator of the internet. (then forced to be dissolved due to antitrust?)
- Each country controls their own CA and you need to purchase 200+ certs in order to make your website generally accessible. (then country XXX will charge you $200/year)
- Big techs owning OS/Browsers control their own CA and cross license each other (then Apple still being lazy handling incidents) (then they form a cartel and block others, like current Tier 1 ISP, email senders, credit card networks)
edit: put enter between numbered items.
today at 7:50 PM
If you want access to the whole internet and not just part of it, it has to be "one size fits all users". (At least with how the internet works currently.)
today at 4:11 PM
Someone has to decide on a set of default CAs to trust... It's natural that it's your OS vendor, since the trust store is an OS thing.
today at 3:56 PM
Because nobody is going to be arsed to figure this shit out, even the PGP fanatics don't bother.
So someone has to do it, and a pop-up on first boot asking you which "certificate providers" you want to trust would be as pointless as the "which browser do you want to use" ones were.
today at 4:12 PM
Honestly that last paragraph I totally agree. I did edit to “never trust” these clowns’ root CAs in Keychain Access on my Mac, and this is the first I’m hearing that there was any possibility of that being flipped back. Will have to look into that.
If I can speculate though on why these bundles come from the browser or OS and aren’t fully in the user’s responsibility. You’d have to start from scratch for it to not have a bunch of stuff the user had ‘no need for’ to be present, and the user would need to see a cert window semi-frequently that gives the possibility to start trusting a CA, and the bottom 99.99% of users in sophistication has no idea whether they should say yes or no. I mean, without being signed by a root CA you already trust, even the name on the new CA could be completely made up. “Do you want to trust the ‘Apple Root Certificate Authority’?”
today at 4:49 PM
Yet they ask you what keyboard type to use, what Wifi network and password to use. Is it too much to ask, do you want to trust "key authorities" from outside your country? Users used to see computers as inherently technical devices and expect to get asked technical questions.
But even if not, you get asked whether to turn on Siri, whether to send telemetry, whether to sign away your rights, etc., all of which are consequential but prompts are massaged in a way where it's nice and easy for the user to answer a certain way without having a clue. Makes me think user comprehension isn't even a problem.
Where I suspect the problem lies is that it will not fly to make it seem like US-based CA's are more trustworthy just because the majority of sites roll up to them. Then you'll need to do some non-country-specific human tiering, and who's the judge of that?
today at 4:56 PM
>do you want to trust "key authorities" from outside your country?
So what happens to americans visiting french sites?
today at 5:09 PM
"It seems like you're visiting a site registered in XYZ country. Do you want to start trusting XYZ country key authorities?
[Do Not Trust], [Trust Once], [Trust Forever]"
today at 5:15 PM
Then users just proceeds to hit trust for everything, just like people blindly accept ssh keys.
The country comparison doesn't do much either, because there isn't a good guarantee that they'll correspond. Some guy posted a repo to distrust every CA except the top 30, and that has a bunch of weird examples, like a bunch of russian sites being signed by a Greek CA. Not to mention some of the biggest sites use CAs that don't correspond with their country of origin. GlobalSign is Belgian for instance. Guess how many of their customers aren't Belgian?
today at 5:36 PM
Isn't the whole point of this to decide what "shady" CA's to trust? If a Russian site bothered to get signed in Greece, some people will trust the site, and some people will distrust the Greek CA's. That's how trust works.
You can add other options too, "Trust for 30 days" or something. I wish SSH known hosts has an auto-expunge.
today at 10:03 PM
today at 3:41 PM
today at 7:13 PM
I noticed a machine of my was using a Chinese mirror for Debian apt. Switching to the US apt source brought in updates to cacerts and libbrotli. Not trying to insinuate anything, my mirror was just outdated, and yours (plural) could be too.
today at 4:16 PM
I asked codex “find out if this Mac is still trusting that bad cert and remediate if so”. I got a few commands out of it to run myself with sudo, and now I’m good.
Thanks for being on the ball, Apple.
today at 4:56 PM
Rather than prompting the mechanical parrot, you can also refer to Apple's own website: https://support.apple.com/en-us/149555
I don't know why they haven't rolled out an update if they've already wrote a whole article about patching the problem yourself.
today at 5:40 PM
today at 6:59 PM
today at 4:16 PM
Second probe: confirming the fixed comment path resolves a parent comment correctly.
today at 4:15 PM
[flagged]
today at 2:42 PM
Apple gets a free pass on this website. If Google or Microsoft did the same thing, the torches and pitchforks would be out.
But instead the Apple fanboys will be out in force to tell us why actually its a good thing for Apple to leave parts of the OS insecure.
today at 3:35 PM
Apple makes incredible hardware and could easily be the best development machine on the market. But I ultimately prefer Linux because I own the maintenance story and it's simple + fast. System packages and xcode are horrible experiences, and there's no reason for this to be the case in 2026.
today at 6:06 PM
As a non mac user who's had to setup xcode and an apple dev account for the first time ever to compile and publish an app store app update for my company - the entire thing soured me on ever even attempting mobile app development.
It really surprised me what mobile devs put up with, just an utterly horrible hostile experience.
today at 4:07 PM
Shallow or misguided criticisms of Apple—of which there are countless—get shredded on this website. This is not a shallow or misguided criticism of Apple. It is clearly and obviously unacceptable.
Better luck next time.
today at 4:09 PM
> Apple gets a free pass on this website. … But instead the Apple fanboys will be out in force to tell us why actually its a good thing for Apple to leave parts of the OS insecure.
I have no idea how you've come to this conclusion, and clearly nothing of the sort is actually going on here.
today at 3:18 PM
It has the davantage that you can finally find out what those apps are sending back home, including your private data.
today at 3:27 PM
I’m somewhat of an Apple fanboy, and I find this absolutely unacceptable.
today at 3:15 PM
We clearly just don't know what complex level security Apple has put into their OS. Clearly their OS isn't vulnerable or else they would patch it! (/s)
today at 1:23 PM
That MacOS hasn't removed from OS-level /etc/ssl seems like a big deal, affecting more than just OS-supplied git. Is /etc/certs not used by most graphical Mac software, I guess? The chaotic state of OS-level cert management, on Linux as well, is pretty dismaying.
If Apple is still trying to brand themselves as security-forward, you'd think removing the revoked CA certs from /etc in a system update would be a pretty easy thing to do?
today at 3:59 PM
Following the eMudhra incident I made a tool to distrust all except the 30 most essential CAs on my Linux and Windows systems (https://github.com/hyperreality/distrust). I was shocked at how messy the situation is on Linux, with browsers, CLI tools, programming languages all having their own stores and distros building the bundles differently (update-ca-certificates in Debian vs update-ca-trust in Arch or Fedora). Or like Firefox not using the certs in /usr/share/ca-certificates/mozilla/ but its own per-profile NSS store instead. There has to be a better way.
today at 5:23 PM
Browsers were the original TLS trust store vendors. Operating systems started shipping trust stores because their OS came with a browser, not because they were the natural root of trust. Browsers also have tools to update revocation near-live, while operating systems lag behind by hours, or days in this case.
For your tool, remember to nuke Windows' automated certificate authority updates (separate from normal Windows updates) and possibly the automated intermediary cache. Microsoft publishes a list of trusted CAs/intermediaries periodically and they get automatically applied to Windows so websites don't need to send the full cert chain during TLS negotiation, and it has a tendency to cache trusted intermediaries as well.
Mozilla's trust store is one of the first to get updated when a revocation happens, as well as Google's CRLsets. Downloading full CRLs repeatedly would be a waste of time and bandwidth, that's why there's a specific distribution method for CA updates. I would extend your tool with a daemon that checks for revocation automatically, so you don't accidentally eMudhra yourself while browsers and the OS get updates next time something like this happens.
today at 10:06 PM
today at 5:29 PM
I was also surprised to find Java’s key tool returning successfully for the delete request without actually doing anything: list, delete, and list again would still show the CA. Debian had this right during the 90s, all they had to do was follow the system convention.
This feels like all of the C code getting attacked now where everyone spent the last three decades building up cruft because fixing it would be a chore, and now the separate bills are coming due all at the same time.
today at 4:58 PM
The better way then comes with the drawback where one vendor has all the power.
Then someone would ask "there has to be a better way" again, when the reason for the new inconvenience gets forgotten, and it oscillates.
today at 7:28 PM
I used to manage OS level trust root management for all internal machines at a hyperscaler. Hundreds of thousands of machines. Even when you have an edict from a common VP or CEO, and most people are even using the same linux distributions, it's hard to get people to adhere to or even understand that there is a standard. Throw containers, embedded devices, windows and mac in and it's just a total nightmare unless you exert strict control on how every single machine is set up. Which, of course, is impossible because cowboys gonna cowboy.
Fundamentally, people don't want to think about the intricacies of how we decide whether or not to trust a particular cert. They want it to just work without thinking about it. This includes that if they have a custom private root they need to trust, they just drop it various places until it starts working and call it done. And sometimes they do weird things like adding intermediates to their trust store because they were trying to call a service that has their cert chain configured incorrectly, and that "fixes it". Again, it's a nightmare.
The fact that linux, a system notoriously cobbled together by 873 different factions on the internet, is even more of a mess is not surprising in the least.
today at 4:58 PM
Apple's official API had revoked the certificate within hours. Only the Unix compatibility layer they sort-of maintain has this problem. This is hardly the first or only outdated Unix compat tool they ship with their OS.
Not great for unaware developers, but most macOS users are fine. Those who are aware can follow the steps in https://support.apple.com/en-us/149555 until Apple bothers to roll out an update.
today at 3:40 PM
The thing that makes this especially odd is that Apple apparently has a fast-track way of shipping security patches for the OSs that don't require the user to go through the lengthier OS upgrade process. But for some reason, they haven't used it here.
today at 4:37 PM
That fast-track method was used, but it only applies to "graphical" software which really means, software that uses Apple's macOS specific APIs and frameworks, not the lower level UNIX stuff like /etc/ssl
I suspect the fast-track background security updates can only update the databases and revocation lists that live in the proprietary APIs, not any arbitrary file on the system
today at 4:59 PM
I see other people making this statement, but it sounds like a really really weird excuse.
today at 5:33 PM
It’s not an excuse but an explanation: there are separate stacks owned by different teams and they haven’t been forced to collaborate. If you use an internal CA you’ve already had to deal with the easier additive version of this problem because that fails in an obvious, less harmful manner than quietly accepting something which needed to fail.
today at 5:52 PM
It doesn't explain why Apple who 1) sells itself on security and 2) ease of use doesn't 3) update what it installed and protect its users. Why are they not doing those things?
today at 6:52 PM
I wasn't trying to excuse anything, just explain that they haven't done nothing, but also why it's still an issue. I agree with you they've dropped the ball here. If I were a betting person I'd guess this is just something that slipped through the cracks and there will be changes whether that's to the release process for pushing OS updates, to the fast-track security update process, or to the OS so that everything is working off the same trust store
today at 5:46 PM
Agreed. Why does macOS ship with two copies of the trust store? Shouldn't the process to update the primary store automatically derive the other?
today at 4:53 PM
Or they just missed a spot?
today at 5:55 PM
Yes because that thing is completely useless and provides basically no value
today at 4:42 PM
Apple has one job here and it isn't to make UIs that look like melted plexiglass. I am fucking pissed.
today at 1:33 PM
Yeah, why may that be hard? That’s the question
I don’t think it’s gross incompetence, since they documented the steps to remove. They may have some unexpected dependency on the file? Looks mysterious from the outside.
today at 3:33 PM
I think the main problem is that the weak eMudhra intermediates were cross-signed by Sectigo. Certificate revokations are needed to handle this correctly.
Dropping the Sectigo root along with the eMudhra root is the easy and safe solution, and maybe this is what Apple should have done (it’s the workaround they recommend!). But it means that some small percentage of certificates that are fine won’t be accepted.
today at 2:02 PM
People would have to use it in some drastic catastrophic way for them to force it out in an update, which they might push it out in the next macOS update, which don't come nearly as frequently as Windows bloatware updates do.
today at 2:09 PM
This seems important enough to just send out a patch update that removes the cert and does nothing else. But apparently at least a couple people at Apple disagree; or, something I'm not familiar with makes that type of update impossible.
today at 4:15 PM
You have to admit that “just a quick patch” isn’t automatically low-risk. You could cause a large blast radius if you rush any patch out without proper testing.
today at 4:46 PM
I agree 100%, but I keep going back to the blast radius of a compromised CA and my gut instinct is still "get rid of it and push a hotfix" but I completely acknowledge it's a lot more complicated to ship a MacOS update than just branch off of master and push a new commit, and my experience is almost entirely the latter.
today at 2:59 PM
I mean, I agree with you, I'm just basing my thoughts of what I've seen managers at different companies prioritize as "important" even when engineers cry that a security issue should be of higher priority...
today at 2:41 PM
I would put Apple updates in that bloatware category given I was forced to upgrade my phone after iOS and updates eventually took up 50% of storage.
today at 2:11 PM
amusing you criticize windows updates here where the macos update schedule is woefully inadequate.
today at 2:29 PM
One is too delayed. The other is frequent but full of crap.
today at 2:38 PM
The issue with Windows is they eventually force it on you, no matter what.
today at 4:11 PM
What, MacOS doesnt?
today at 1:34 PM
> Is /etc/certs not used by most graphical Mac software, I guess?
Correct, those usually use Apple's networking APIs which all go through their security stack, which already picked up the OCSP revocation within about 2 hours in most cases.
today at 2:17 PM
this only affects terminal apps, which the vast majority of MacOS users don't run; the fix for graphical Mac software is already patched
my guess is their thinking is that if you're running those apps on Mac, you're a developer or know what you're doing, and can edit /etc/ssl/cert.pem until they push an update
they also have to consider that such users may have custom changes to their cert.pem file, and they probably don't want to rush an update that would potentially fu-bar those changes
today at 10:25 PM
If you're editing /etc/ssl/cert.pem yourself, you're setting yourself up for failure. Use the proper mechanism to add your own trust roots (on macos it's "security add-trusted-cert").
Whatever reason Apple had for not updating /etc/ssl/cert.pem yet, I am certain it's not out of consideration for users that might have put custom certs in there.
today at 2:26 PM
Certainly you're aware that every certificate sits in a separate file and an update can just remove the interested files?
today at 4:21 PM
It doesn’t look like that, it looks like it’s a cert.pem file.
today at 5:04 PM
I would be aware of that if it were true, but (surprise!) it's not
not convinced? take a look at your /etc/ssl/cert.pem
today at 2:06 PM
Here's what apple (themselves) recommends to patch: https://support.apple.com/en-us/149555
Pretty much every developer on mac should probably run their patch.
today at 3:14 PM
You have to re-run that every time you do a software update btw
Per https://emudhra.we-have-a-problem.com/apple.html
> macOS 27.2, released on 26th October, did not fix the issue and undid the workaround that users had applied by hand, leaving them vulnerable again.
today at 6:40 PM
Apple’s handling of this has been a disgrace. It took 4 days before my iPhone and MacBook Pro got the CRL, and now I hear they have done this. Dreadful.
Apple, for the company that prizes itself on believing privacy is a human right, why are you failing your customers so badly on PKI management?
today at 4:29 PM
That’s not a ‘patch’, it’s several command lines you need to copy and execute, some optionally.
It’s completely insane to me that Apple didn’t script this with interactive prompts as needed, and non-interactive options for automatic installs.
today at 6:22 PM
This is such a Linux way to resolve the issue lol
today at 6:43 PM
* Unix way
today at 9:35 PM
A script to automate this. https://gist.github.com/DavidCWGA/a5d09105371f734ccc7b0693a7...
today at 2:08 PM
I reposted this as it wasn't clear from previous comments with this URL that there's a patch that's worth running in there from Apple themselves
today at 4:12 PM
Why arent they just pushing this patch out on their security update channel?
today at 2:35 PM
First time I've seen AI-authored instructions from Apple. I guess it is hard for them to just post a new .pem because it could be MITM'd.
today at 4:22 PM
Why would it be more secure to post 4 manual commandline instructions than a single file?
today at 3:13 PM
Safari (and other browsers) is safe. The issue is terminal tools such as curl and git
today at 11:55 AM
Apple’s statement: https://support.apple.com/en-us/149555
today at 11:57 AM
Indeed!
On Mac, some command-line tools included with macOS or the Xcode Command Line Tools (including curl, git, python3, ruby, perl, and openssl) check certificates against /etc/ssl/cert.pem. For certificates that chain to a root CA certificate in this file, these tools don't check Apple's block or whether the certificate has been revoked. This file will be updated in a future macOS update. If you use these tools and don't want to wait for the update, you can remove root CA certificates from the file.today at 12:00 PM
Why are they not just pushing out the update asap? Unless they're relying on the compromised certs, then it feels it should be incredibly trivial to push
today at 2:09 PM
Because to Apple once you open a terminal you leave the supported world behind. This is a standard thing for them. Apple is not really a UNIX vendor and certainly not a Linux vendor: they sell macOS which is primarily a consumer OS and has its own APIs for everything.
Tools common on Linux like curl and git come with the OS basically for developer convenience. Apple doesn't write those programs, they don't use Apple's APIs or platform features, and thus in some sense you aren't really meant to use them in Apple's eyes. Ports of UNIX CLI tools exist in a kind of semi-supported netherworld on macOS. They run but they aren't fully integrated or supported parts of the OS.
today at 3:25 PM
This case not withstanding, Apple regularly includes patches to the built in CLI tools in security updates, so it's a little disingenuous to suggest those tools are not really supported.
today at 4:25 PM
I read GP as a descriptive comment not a justification. They are showing with this issue that they don’t truly support the cli tools in a way we ought to rely on. Whether they occasionally provide some support doesn’t mean they’re supported. Only full and competent support counts, everything else counts as “it’s best-effort at best”
today at 12:16 PM
The issue might be Root CA vs intermediates. The root CA that eMudhra rolls upto may be used for other intermediates which were not compromised or revoked. Removing the root CA will mean that these valid certificates no longer work.
This is technically a problem in the CLI - it needs to support revocations properly, not rely on root CA verification only. I’m not sure though whether there’s a standardised mechanism (that Apple supports) for CLIs.
> These steps affect every tool that uses /etc/ssl/cert.pem. Afterward, tools that use only this file might not be able to verify some websites whose certificates chain to these root CA certificates through intermediate CAs that weren't affected.
today at 12:18 PM
In pracitce, those root CAs have already been removed in major browsers. If your server uses them, you would likely have needed to migrate to another root already.
today at 3:49 PM
today at 2:30 PM
PKI works on trust. When a CA does things that violate that trust, their root gets removed. That's how it's supposed to work.
today at 12:37 PM
Apple’s own security framework is supported by curl with OpenSSL or GnuTLS (build with ./configure --with-apple-sectrust). That blocks the intermediate certificates via the same mechanism Safari uses for example.
Not sure why macOS doesn’t ship such a build of curl.
today at 2:07 PM
It's relatively new I think.
today at 12:31 PM
I'm no expert in the matter, but weren't only the intermediate CAs compromised, not the root?
today at 12:34 PM
Yep, but the certs.pem file only contains the root and does not know anything about intermediates.
So the only way to fix apps that don’t handle revocation of intermediates (eg the ones that only look at certs.pem) is to revoke the root.
today at 4:11 PM
I think it’s possible to add intermediate certificates with distrust marker attributes to bundles with OpenSSL. But other libraries consuming the bundle would not understand it, so the problem remains.
today at 4:28 PM
> Removing the root CA will mean that these valid certificates no longer work.
Great, that’s fine. They can reissue.
today at 12:29 PM
I think since 10.15 the built-in command line tools in MacOS are there mostly for backwards compatibility. This was clearly communicated about scripting languages, but there was a feeling back then that this was about the whole lot (all cli tools).
today at 1:16 PM
Git comes with Xcode, it doesn't come with macOS by default.
today at 12:05 PM
Theory: Apple are moving away from user-controllable development tools, towards an AI-hosted application development framework which removes the divide between user and developer, and thus the need for specialized developer tools.
The writing is on the wall for the command line tools.
(We can already see this tooling devaluation happening all over the place. Apple have their variant of this response to the AI tooling-paradigm tsunami…)
today at 12:09 PM
Apple seems like an odd company to lump into this group. Any evidence for this? I removed the cert using a CLI command on my Mac.
today at 12:24 PM
They have been treating the command line tools like the bastard child of their software portfolio, and then there’s that whole drive to remove the Unix’ness of MacOS .. Swift/SwiftUI is a drive away from lower tooling layers, and .. there is no doubt they already have a developer agent of their own, internally, pushing their abilities to make projections of hardware requirements and specifications for the next 2 - 5 years …
I’m not saying they’re going to deprecate XCode today, but I do believe they will “agent’ize” Developer Tooling drastically in the next year or so. Agents are becoming the most important user of command line tools.
Because they have to, in order to catch up with NVidia, their only real competition. If you want to understand why I think that, its because I have been developing and deploying cross-platform Linux-centric (but MacOS and Windows targeting) applications, mostly for the ARM platform but also with Intel (SIMD on both) .. for the past few months, and I haven’t touched an IDE in a month. On DGX Spark. Which turns out is a truly, utterly, mind-blowingly great platform to do cross platform high performance application development…
today at 12:36 PM
Apple has pretty well always got users to do things via the GUI – look at the Lisa and Classic MacOS.
CLI is just a thing that NeXT had and even that made it easy to use GUI tools.
Xcode is a GUI tool – it happens to expose some cli tools but they could be covered up – however some developers would complain a lot so I don't see that happeneing.
today at 12:13 PM
Command line tools seem to mesh well with AI. Why would they move away?
today at 12:21 PM
Precisely because the agent is becoming the user of the command line tools now, these are all being abstracted behind an interface which blurs the developer/user requirement…
The original question is, why aren’t Apple fixing the CA problems for the command line tools (whereas they have done it for .app’s such as Safari), and the reasoning is, because the user will just have to fix it themselves, because Apple don’t care about the command line users - they see that these command line tools are, indeed, becoming the front-line for agentic development, so .. presumably, they have an .app bundle which does away with this problem, to be shipped on the horizon ...
today at 12:38 PM
The command line tooling lets you/AI manage a lot of your app store interactions though. It's much easier to use that way then trying to deal with the Steamworks UI and doing things manually.
today at 12:17 PM
That would be a killer move!
today at 3:49 PM
Interestingly on a much older OS (Yosemite) cURL, etc. links to Security.framework which uses the system's trust store instead a separate .pem file in /etc/ssl (I can't find any .pem inside /etc/ssl)
I wonder why they stopped doing that and now just seem to do "standard" builds and end up with this (at least) 2 separate trust store situation.
today at 12:13 PM
Some depending on the executable, sometimes it goes through /etc/ssl/cert.pem and sometimes through the Apple framework. This OS is a mess.
today at 4:51 PM
I think this is basically related to apple's SIP system protection: they haven't figured out a way to update this quickly and would need to roll this out in like an OS update, which can take a while.
They might need to make a way to do this outside of os updates
today at 12:01 PM
Are they just saying "do it yourself"? Can't they just send out an update?
today at 4:19 PM
They did send out an update this week…that undid this mitigation for users that already removed the certs.
today at 2:37 PM
I imagine their response would be: "we need to parse a new file format, that may have been edited by users, reliably. That takes time."
today at 4:42 PM
Why would they need to? Can’t they ship an update that runs an executable that uses the already-existing tooling to update the pem? They’ve posted the cli instructions, so, ship that as a shell script and run it. It should be idempotent, whether the user has already “untrusted” it or not.
today at 10:15 PM
Isn't the file overwritten every update?
today at 2:54 PM
I'm not being sarcastic when I say that Apple should copy Windows Update, I have no idea how they have got this far without a method to add small patches outside monolithic OS updates.
today at 4:03 PM
They have it. It’s called Xprotect. I’m surprised it hasn’t been used to remove the bad certs.
https://fullmetalmac.com/cybersecurity/macos-security/xprote...
today at 5:57 PM
XProtect removes malware, not certificates
today at 8:31 PM
what are the capabilities? presumably it could a apply a diff, patch or overwrite a file. in this case it's not even in the protected partition.
today at 3:29 PM
Microsoft even has multiple express channels. For example Windows Defender definitions are practically real-time
today at 5:37 PM
Just like Apple has. The problem here is whoever made the decision not to use that capability:
https://support.apple.com/en-us/102657
today at 8:20 PM
not quite. this is more similar to Windows Quality Updates. Defender updates are real time (up to multiple times a day, and delivered p2p)
today at 3:25 PM
I have no idea how they have got this far without a method to add small patches outside monolithic OS updates.
You're either not an Apple user, or never noticed Settings → General → Software Update → Automatic Updates
today at 4:45 PM
I think they meant that Apple’s updates seem to be the opposite of incremental, and they’re not wrong. If anything, Apple has moved in the exact opposite direction in the past decade, moving towards using enormous cryptographically-signed volumes (“sealed” is the term). This makes Apple really happy because they can make sure the users aren’t allowed to modify any of the “system“ files themselves for any reason, but also means that they can’t incrementally update things as easily as they did before. They ship multi-gigabyte “patches” every time.
today at 5:39 PM
Being able to trust the OS is a huge advantage, though, and they built the rapid response mechanism to handle those updates:
https://support.apple.com/en-us/102657
The big question is why they’re not using it for things like this, where a tiny layered file system update would benefit almost all of their users immediately.
today at 8:32 PM
but the volume with these certs isn't protected. you can edit the files with vim. i'm curious what the holdup is.
today at 2:14 PM
While there is no proof that anyone knew about these weak keys for the year and a half that they were trusted by virtually everybody, and there's no evidence of MITM attacks happening in the wild because of it, you can imagine the payoff that a three letter agency would have if, for even 10 days, there was an opportunity to harvest credentials from important people in high places.
I have no evidence or proof, but I am convinced this wrap/unwrap key generation debacle was intentional and the weak keys were discovered and kept secret by the agencies or governments and used to exploit their adversaries.
You don't need to perform a traditional MITM attack _if you own the airport_ or you _own the free public wifi_. The traffic can be harvested in clear text and we have to come to terms with the _remote possibility_ that this was going on for over a year and a half. If not that long, then certainly for the past 10 days.
today at 8:12 PM
This would've been true a while back prior to major browsers checking for certificate transparency log entries as part of the handshake.
So, I do agree this could be problematic, on specific cases where people not using a major browser were accessing resources some is interested on, on a network they have control of. Makes the surface quite small.
The threat here is more so for 'backend' services than regular browser users.
today at 3:23 PM
This is misleading. In order to read traffic you would need to swap out the end-entity TLS certs being used. Phones and browsers (at a minimum) enforce certificate transparency, so connections would fail.
today at 4:51 PM
Buddy, 3 letter agencies don't need these weak keys, they straight up own root CAs.
today at 1:55 PM
It seems like we've all just... given up on certificate revocation? CRLs and OCSP were designed for exactly this sort of thing, but they both seen to have been abandoned as unworkable with no replacement.
today at 5:41 PM
It’s a hard problem: if you query on use, you not only introduce delay but also leak information about what servers people are connecting to. Dealing with that starts looking a lot more complicated (bloom filters per CA of recently-revoked cert IDs?) needing to be implemented into multiple libraries and the failure mode is an outage unless you fail open.
today at 3:07 PM
Same here - I genuinely thought this would have been easily, and almost immediately, remediated vis-a-vis CRLs. I'm not in the vuln management space anymore, but is there some sort of caching system used which would affect software differently than a typical browser?
Editing to add a link to this Apple support article which is unsurprisingly detailed - https://support.apple.com/en-us/149555
today at 4:58 PM
As far as I'm aware the typical command-line stuff and most things just using SSL libs or language standard libraries don't do revocation at all by default.
Similar reason (though with the opposite effect) as how a cert can be fine for browsers but fail for curl when they don't send an intermediate: the "vanilla"/library/command-line stuff is just checking for a path to a trusted cert and not doing the CRL or AIA stuff a browser does.
today at 5:52 PM
Yes, exactly what the Apple article highlights! Appreciate the extra context.
CLI-based activity references etc/ssl/cert.pem. While they say this will be updated in the future (likely the next dot release), admins can also proactively remove the eMudhra entries.
today at 4:54 PM
[dead]
today at 1:31 PM
A flat cert.pem file (or similar) can't say "distrust this intermediate".
macOS already has the verifier needed (Security.framework/trustd path that protected Safari). It would be good if MacOS routed CLIs through it.
today at 1:52 PM
> A flat cert.pem file (or similar) can't say "distrust this intermediate".
Why does that matter in this case? Can't this be fully mitigated with next to no collateral damage just by removing the trusted roots that signed them?
today at 2:03 PM
The root certs may have signed other intermediaries that are still trusted.
today at 2:32 PM
They aren’t trusted, though. Didn’t Chrome ultimately choose to drop the roots, not just the intermediates, from their root program?
today at 3:23 PM
Chrome dropped one of the eMudhra roots. The problem is that the weak eMudhra intermediates were cross-signed by Sectigo. ~~Browsers (at least Chrome) didn’t drop the Sectigo root, instead they store a revokation for the cross-signature.~~ (edit: this is wrong, see josephcsible’s answer below)
Dropping the Sectigo root along with the eMudhra root is the easy and safe solution, but it means that some small percentage of certificates that are fine won’t be accepted.
today at 3:44 PM
Wasn't the cross signing root AAA Certificate Services, which modern browsers had already dropped trust of before this incident?
today at 4:22 PM
Ah, you’re right. Though unless I’m mistaken again, Safari (but not Chrome and Firefox) still trusts AAA Certificate Services and handles this issue with revokations.
today at 4:51 PM
This seems like extremely acceptable collateral damage to me. Sectigo should already be working with their customers to reissue immediately since they are the ones who signed the dumb intermediates. Trust only matters if there’s accountability. If root CAs want to keep their trust, it’s on them to not sign things that are bad. That’s the responsibility that comes with the license to print money that being a root CA gives you.
If I’m an OS vendor I would have been putting them on notice days ago that their root was being dropped and they have X days to reissue certs and deliver a new root cert or otherwise they can just accept that they’re not qualified to be a root anymore.
today at 8:17 PM
How should Sectigo have detected the badness?
today at 2:29 PM
I trust nothing that came from emsign
today at 1:28 PM
Delete /etc/ssl/cert.pem and replace it with the one from MacPorts.
# /usr/bin/curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/
Your client successfully connected to the site. That's bad!
# sudo mv /etc/ssl/cert.pem /tmp/
# sudo ln -s /opt/local/libexec/openssl3/etc/openssl/cert.pem /etc/ssl/cert.pem
# /usr/bin/curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.htmltoday at 1:29 PM
What? Who's still using MacPorts?
today at 10:37 PM
Intel Mac users. I recently installed MacPorts for the first time after Homebrew dropped support.
today at 2:10 PM
Anyone running Intel macbook because Homebrew dropped support for them because Apple dropped support for them. You can still use Homebrew but it means rebuilding from source. I downloaded uv recently and it took about 8 hours to fully install because it had to build llvm, uv, some other stuff all from source.
today at 1:32 PM
Heaps of us. I'd been using it for years before Homebrew even existed and I never felt that any of the problems that Homebrew purported to solve were real.
today at 5:06 PM
I know, it always makes my jaw drop when I realize that it’s still a significant number of people, since I remember it being a thing I used circa 2005. I don’t think git was even a thing back then.
today at 12:15 PM
> Anyone can intercept any HTTPS connection these tools make.
yeah, it's not ideal but the scale of the threat is way overblown tbh. You have to compromise a lot to be able to make a MITM here.
Let's not treat it like PHP2Shell.
today at 12:26 PM
Don't underplay it either though: with a compromised but unrevoked signing cert all it takes is a successful phish, or some problem to allow DNS poisoning (or hack a wireless AP, or …) to direct you to a fake site or (potentially worse as it might be less immediately noticeable and could quietly collect credentials/data for a while) send your automated tools to a malicious API.
It may not be directly exploitable on its own, which is the impression some reports give, but it is a serious hole to leave open especially with the current rate of old security issues being found, as it could be _incredibly_ useful to a malicious actor as part of an exploit chain.
today at 12:42 PM
Yeah, it increases the attack surface of mitm attacks to your network from the local os level.
today at 2:03 PM
Doesn't affect app bundles though, only *nix commands. This'd be detected pretty quickly, at least by the significant portion of patched devices.
today at 2:48 PM
Unless you're clever enough to only poison user agents known to be macOS and CLI. You'd probably get by.
xz-tools was only caught because it had a bug causing slow startups and someone was micro-benchmarking Postgres and decided to dive in further.
today at 5:05 PM
One person, at that particular time. The person and the task were also a couple standard deviations away from the norm, the world was incredibly lucky.
today at 3:49 PM
The cert is provided before the user-agent string is
today at 12:25 PM
It's pretty easy to compromise things like McDonalds or Starbucks WiFi hotspots though, just setup a Pineapple with the right SSIDs and a 5G modem, funnel your target domains through your mitmproxy via the DHCP DNS server you're providing, and that's basically it.
I agree it's not PHP2Shell, but its certainly not being "way overblown" here.
today at 1:09 PM
Why would these public network would allow guest hosts to communicate with each other?
today at 1:13 PM
I think they're saying you create your own malicious wifi network and people will unintentionally connect to it. This network specifies your malicious DNS server via DHCP, and everything looks secure to the client. I think the main issue with this in practice is that all the major browsers have been updated to not trust these certs.
today at 1:20 PM
So you target some host like ssh.dev.azure.com, find all the hooks in the proper repo the client is trying to access, make a new commit that puts your persistence payload in one of them that you expect will be executed soon, this script can additionally "correct" the git state when it finally runs, and moves its persistence to some more appropriate location.
Users will be none-the-wiser because they're not accessing these hosts through a web browser, and you net a few more compromised hosts in your inventory.
today at 2:14 PM
Yeah also got to be lucky that the users are using https and not ssh. You're very limited in what you can mitm, you'll be trivially detected by patched devices (though maybe not acted on because nobody is the wiser), but then you'll need to serve objects with common/conflicting hashes -- fixing up that state synchronisation (what you call "correct") to then do nefarious things is not trivial at all. Extremely difficult to pull off successfully for git anyways or to do it in stealth.
today at 3:34 PM
Ahhh, true, SSH isn't the same certs, my bad... well, both Github and Azure DevOps default to HTTPS-based cloning anyway...
today at 1:13 PM
They wouldn't. A device like the Pineapple broadcasts its own copycat wireless signal and tricks unsuspecting clients to connect to it thinking it's the real one.
Edit: Holy moly we all jumped on this comment at the same time didn't we.
today at 1:40 PM
> Holy moly we all jumped on this comment at the same time didn't we.
It's good to see push back against this narrative that is trying to develop that this isn't any kind of big deal.
This has been every machine on the internet compromised for at least 12 hours and probably some that are not going to ever get patched.
today at 1:54 PM
> probably some that are not going to ever get patched
This is a HUGE deal for embedded devices, we can now mitm HTTPS traffic on lots of embedded devices running Linux produced between 2018 and now.
today at 1:13 PM
They don't need to, a Pineapple (or anything else that can run a wireless access point, you could do this with a laptop) just needs to advertise the expected SSID and do so with a stronger signal than the official ones for people's devices to connect to it instead of the actual network.
today at 1:43 PM
It’s extremely common to see other Macs pop up in the ‘network’ panel in Finder in the independent coffee shops around me. I imagine they’re just signing up for a business plan and using the routers the ISP gives them with a custom SSID and password.
today at 1:14 PM
You dont interact with anyone. You just set your own hotspot and people will connect to it.
today at 1:02 PM
The near-universal use of TLS and the absurd ceremony we go through to ship root CAs everywhere is all premised on the idea that MITMs are not terribly difficult.
The entire reason one can rest easy as they connect to their coffee shop's WPA2-PSK network, is the security provided by TLS.
And if you don't think an ISP or agency would abuse this if it could be done undetectably then you haven't been paying attention these last 20 years (hence why DoH is now a thing).
today at 1:05 PM
Even a simple rouge AP is enough to become a MITM for this.
today at 1:48 PM
Why is the color of the access point relevant?
today at 9:07 PM
TIL rouge means red in French
Either way, I mean rouge in the sense of an AP that uses the same SSID and password as the AP of a coffee shop or office to have devices automatically connect to it without their users noticing.
today at 9:19 PM
In English, rouge is a type of makeup.
“Rogue” is a completely different word. Rogue access point.
today at 9:13 PM
Da Red goez fasta. Hence the router beats the non red router to the punch.
today at 12:46 PM
You can take your laptop to a busy place, make a "free wifi" hotspot that runs everything through mitmproxy and you can steal everything.
today at 1:50 PM
I think "everything" is an overstatement. Browsers included the compromised intermediates in their CRLs within hours of disclosure.
So this isn't like Firesheep [0]. Yes, there would be vulnerable traffic, like the git client this thread is discusing, but it's not "everything"
[0] https://en.wikipedia.org/wiki/Firesheep
today at 4:20 PM
If you see a developer using git on a Mac laptop in a coffeeshop, you can intercept that and gain their repo and probably password hashes pretty easily.
today at 1:04 PM
> You have to compromise a lot to be able to make a MITM here.
This is just an argument against TLS in general. Use plain http if you believe this.
today at 1:43 PM
Appealing to complexity is always fun. Just throwing "a lot" in there for good measure and you won't have to think about practical security implications.
today at 12:28 PM
php2shell was overblown perhaps but this is being blown quite correctly
today at 1:50 PM
The TLS trust chain is the last defense against MITM attacks. The prevalence of MITM attacks is in fact the very reason TLS exists. I'd say it's a lot worse than PHP2Shell because it doesn't only affect poorly maintained servers, but potentially ALL credentials and secrets a user sends over a compromised network with compromised CAs on their device.
today at 2:02 PM
The window of opportunity to MITM has passed. If you attempted an MITM from an easy vantage such as telco, ISP, or public wifi you'd be trivially detected as a significant portion of devices are patched, including on these unpatched macs as only the *nix commands are affected and not app bundles.
today at 5:48 PM
You might be detected but if, for example, you were smart enough not to MITM the same client twice after an error, I suspect a ton of people would ignore it and just assume the airport/coffee shop WiFi was flaky.
I’d also bet more things use libcurl behind the scenes than we appreciate, and that at least a few of them have things like silent updates which retry after a failure without notifying a user. I’ve seen a lot of agents which just try to periodically check in because they’re designed not to be noisy on lousy networks.
today at 1:16 PM
This is way worse than PHP2Shell in scope of impact and its effects will stick around for much longer. Well, as long as the validity period of the compromised certs anyway
today at 1:04 PM
If you hijack the DNS, the laptop can be pwned quite easily. Think of all the coffee shops with unprotected routers out there.
today at 9:18 PM
Exactly, I've been to public places where the Wi-Fi password is on the wall and the router's admin password is "admin".
today at 12:19 PM
> You have to compromise a lot to be able to make a MITM here.
It's trivially easy to mount an ARP spoofing attack. I did that at school two decades ago and on-the-fly rewrote <img src=...> to hardcore porn images for funsies.
mitmproxy [1], a popular toolkit for making that easy, has the option to generate "eMudhra" certificates on the fly now.
It is trivially easy to compromise things, all you need is physical access to the network.
[1] https://news.ycombinator.com/item?id=50189232
today at 12:29 PM
I don't know why you're downvoted, any public wifi access point in a shop could be compromised and users would never notice.
today at 12:38 PM
Client isolation is very common on wireless and wired LANs these days in enterprise and guest network environments. You also have tools like dynamic arp inspection to block poisoning attempts via the network switch.
If you get past all of that, you still need a victim who is actively using a cli tool on macOS using https.
It’s not impossible, but the conditions are much more specific than those needed to inject porn into a webpage on a poorly configured school network in 2006.
today at 1:21 PM
…and yet it doesn't help at all if a laptop sees an AP with strong signal in its vicinity and connects to that instead of the meticulously configured AP that sits behind the counter with a slightly weaker signal.
today at 2:09 PM
You’re not actually making the point you think you are. This comes back to the original comment stating you need to compromise a lot to MITM here.
So you need to somehow trick macOS into remotely connecting to the wrong bssid, and then arp poison a user who happens to be using a macOS cli tool that’s using https.
Sounds pretty targeted and unlikely to happen.
today at 2:50 PM
Go to a random coffee shop that allows people to work at the tables, and you’ll find a few developers with MacBooks there pretty soon. They will be connected to the local hotspot, which either has no password at all, or WPA2 with the password written on a billboard behind the counter. Spin up an evil twin, then wait for the connections to roll in.
I don’t think that’s either targeted or unlikely?
today at 9:23 PM
Exactly, I do this all the time for doing out-of-office demos with our company's robots.
I just set up my phone's hotspot to be the same SSID and password as the network the robots already know from the office, and I'll have the robots, a couple phones, and a laptop connected in 10 seconds.
today at 12:59 PM
> all you need is physical access to the network
Yeah that's not so much "trivially easy"
today at 1:03 PM
Do you have a cell phone? Do you use Wifi? Do you use an ISP who, in the last few decades, has performed any form of interception or traffic-tampering?
I hazard that the answer to all three of those is "yes".
today at 12:21 PM
> all you need is physical access to the network.
yeah, it's trivial to punch somebody in the face in the morning, all you need to do is to be by their bad in the morning when they are waking up.
today at 1:33 PM
You don't have physical access to the network, doesn't mean other actor aren't here. Working for providers, governments, or being able to impersonate them. This is a serious issue, it shouldn't be downplayed.
If you think it's not that important, it becomes a critic about TLS and basically saying that ciphers for web traffic are useless.
today at 12:27 PM
Public wifi hotspots tend to give you that opportunity. Large commercial hotspots have inter-client communication blocked, but your average coffee shop style network? You're lucky if it even is an isolated VLAN from the shop's cash register lol.
today at 12:24 PM
Have you never used wifi at a coffee shop?
Physical access to networks isn't that hard to come by.
today at 12:51 PM
Great, you have an inconvenient way to possibly-maybe see some random's gmail inbox at Starbucks.
You'd be better off just mugging them in the parking lot.
today at 1:54 PM
> gmail inbox
Except it won't impact gmail unless you're accessing it through curl. The browsers already distrusted the compromised intermediates via CRL within hours of disclosure, and removed the affected root via update.
today at 4:23 PM
today at 4:23 PM
No, you have a pretty easy way of intercepting someones git credentials and repo access. Arguably more dangerous than a gmail inbox.
today at 1:10 PM
Sure practicality is always an issue. It's an issue that attackers will go to great lengths to resolve too.
What if it's the Starbucks at 1730 Pennsylvania Ave NW, Washington, DC 20006 for an extended period of time? Compounded with other security issues like password reuse...
We can always draw a line and say, "that's not practical". The assessment an attacker is likely to do is going to be "is this practical inside my budget for the value I hope to acquire?" or maybe even just "waow, lulz".
today at 12:29 PM
I have, but good luck predicting where I'm going to have my next cuppa. Outside of petty crimes mentioned, I don't see how it could be industrially weaponised to make actual damage.
Regardless, real bad actors are busy compromising your next `npm install` anyway. Much better reward.
today at 12:36 PM
Why would I care about you specifically, and not the dozens of other people working at the coffee shop? Does the world revolve around you?
today at 1:30 PM
If they are specificly targeting you, then they probably dont need to use the coffee shop. The coffee shop is for low skill attackers targeting people at random.
If someone has it in for you and hired a high skill attacker, its not a stretch to imagine they compromised your home network.
today at 12:35 PM
Compromising a specific person is difficult. Compromising any old person is trivial
today at 2:04 PM
> good luck predicting where I’m going to have my next cuppa.
Why are you assuming there isn’t someone else trying to hack you at the next cafe? Actual damage can happen one person at a time, and can occasionally lead to larger scale compromises. Randomizing your location isn’t going to reduce your risk. Now that everyone who’s paying attention knows they can MITM your Mac, you shouldn’t trust any network.
today at 12:50 PM
today at 3:15 PM
[flagged]
today at 12:22 PM
They just released MacOS 27.2 a few days ago? How and why did they not do a patch at least then?
today at 12:30 PM
It's actually worse: Installing the 27.2 update after manually cleaning out /etc/ssl/cert.pem will revert those changes and put the eMudhra CA back in.
Source: https://mstdn.social/@jschauma/117513596272504904 https://mastodon.social/@glyph/117509558825919922
today at 2:29 PM
Was thinking the same. My assumption would've been that this would have been a normal and routine enough of an operation to be able to push through without needing a separate RC process.
today at 6:43 PM
People use Apple products because they want to delegate all authority over their operating system to a corporation that knows best. If you trust Apple, you should clearly also trust eMudhra.
If you are finding yourself not trusting eMudhra anyway, then you might want to choose an OS that lets any well vetted and capable security researcher in the world contribute to it.
today at 6:02 PM
I would not be surprised if what happened here is that Apple had hardware to release this week and needed to get 27.2 out the door with support for them, and it was "too late" to merge in the certificate store changes. Of course, I think most people here would argue that this is completely unacceptable and I would more or less agree with them, but unfortunately Apple has never been capable of validating a release quickly or pushing small patches. They've tried and, well, most of those efforts have not worked at all. I wonder how they will deal with a new full chain targeting their OSes every week or whatever AI is going to do.
today at 3:05 PM
This should have been a macOS security update on day 0. Dragging their feet over it is sadly typical when it comes to Apple software nowadays.
today at 4:24 PM
Why do people still think of Apple as a leader in security? This kind of thing happens all the time with them these days.
today at 4:33 PM
Their branding, mainly.
today at 3:35 PM
Question for people who know about this: why do we have hundreds of root certificate authorities, when a vulnerability on a single one can break encryption?
Wouldn't it make more sense to have 5 or so that can be more closely monitored, so something like the eMudhra certificates would probably be found before the certificates are deployed?
today at 3:36 PM
And which countries shall run those 5?
today at 5:38 PM
The permanent members of the Security Council, obviously.
today at 3:45 PM
The US, which already centralises the internet by running .com and developed most of the software using these certificates?
It's not like they cannot introduce a bad certificate right now. We would be just be taking the ability from all other countries from doing the same.
today at 3:03 PM
Like many suggested, a proper fix might be harder than simply revoking a bunch of certificate like the blog authored assumed without breaking downstream features and functions in a large ecosystem and security conscious platform like macOS/iOS.
However, there is certainly a chance that Apple team didn't think the impact was that bad given all the other protections in place.
When Steve Jobs was alive, his Apple company email was leaked and published and Apple customers emailed him for features and fixes all the time and he personally responded once a while. Tim Cook did the same a couple times too. Perhaps the blog author should write in to the new CEO John Ternus or SVP of Software Engineering Craig Federighi too to see if they can fix that.
https://www.apple.com/leadership/
today at 7:20 PM
John Ternus’ team ended that tradition and doesn’t accept emails from his customers. Just ask Siri AI.
today at 12:57 PM
There must be a long list of things that aren’t fully patched for this yet, on laptops, on servers. Think of packages that ship their own trust anchors, isn’t there a rust crate that compiles with some root certs embedded?
On one hand there’s unmaintained packages that won’t update dependencies. On the other hand, fixed dependencies did not necessarily backport to all possible versions in the wild, making update as a fix unviable for those.
today at 6:47 PM
[flagged]
today at 1:43 PM
Apple can fix this by building curl with SecTrust [1].
[1] https://eissing.org/icing/posts/curl-apple-sectrust/
today at 1:07 PM
I'm not that familiar with the MacOSx system, but do they have a "minor" update path that I'm not aware of? It seems that everything is an 8gb update. Is that why this update isn't getting put out?
today at 1:30 PM
Yeah they do, it's called "Background Security Improvements" but they rarely use it lol
today at 2:47 PM
Now would be the time :)
today at 12:48 PM
Can we get a title edit? OP’s title implies this is a Git bug, but the bug applies to half of macOS, including curl, openssl, python, perl, and ruby, and to only the macOS version of Git. The original title is less misleading, but personally I’d have titled it something like “macOS still trusts the compromised eMudhra certificates in git, curl, openssl, python3, perl, ruby, more”.
today at 11:53 AM
Running (uname -a) Darwin arrakis.local 27.2.0 Darwin Kernel Version 27.2.0: Wed Oct 14 23:47:07 PDT 2026; root:xnu-13432.41.4~25/RELEASE_ARM64_T8132 arm64, I get the following for both:
curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.today at 12:55 PM
You could be running a different version of curl, e.g. homebrew. Try `which curl` and `/usr/bin/curl <url>`.
today at 12:11 PM
Uname is not enough here to identify what has or has not been done to your system to deal with the compromised certificates.
today at 12:24 PM
No, no, I meant it to show that the machine is running the current/latest macOS, and the results I am getting from curl on the two URLs.
today at 12:57 PM
Maybe you have another curl in your path?
$ uname -a
Darwin MacBook 27.2.0 Darwin Kernel Version 27.2.0: Wed Oct 14 23:47:21 PDT 2026; root:xnu-13432.41.4~25/RELEASE_ARM64_T6030 arm64 arm Darwin
$ which curl
/usr/bin/curl
$ curl https://dv-g3b-emudhra.we-have-a-problem.com/
Your client successfully connected to the site. That's bad!today at 1:04 PM
Aha! Touche! Indeed, I am using brew's curl ("/opt/homebrew/opt/curl/bin/curl"). That's why; the one at "/usr/bin" connects just fine (facepalm).
today at 11:57 AM
Things like this is why I moved back to Linux after 10 years on macOS.
today at 12:12 PM
Not sure what Linux offers that's any better. Didn't Debian ship trivially weak SSH keys for over 2 years because they were trying to silence Valgrind warnings and the random maintainer had no idea what they were doing and there was no oversight or peer review whatsoever?
today at 12:29 PM
That's one issue from one distro 18 years ago. Have there been recent things? This thread is about a today's MacOS, and an issue known publicly for more than a week.
today at 1:15 PM
> the random maintainer had no idea what they were doing
Upstream was involved in it as well. Sure it was a communication problem, but it's not like the maintainer just decided to this unilaterally. Also this WAS undefined behaviour, so from a language perspective it was already broken, even if it worked accidentally in practice.
today at 8:20 PM
The Debian maintained patched by "fixing" two very similar looking "bugs" on different but identical lines of code:
One that mixed uninitialised data to the entropy pool.
And another one that mixed initialised data to the entropy pool with the exact same function call. Which was, in fact, almost all of the entropy.
today at 12:25 PM
In 2008.
I don't think its wise to make current security decisions based on screw ups from almost 2 decades ago.
today at 12:29 PM
Well that "screw up" was so egregious that it should take at least a decade to regain any trust.
I don't really care one way or another. I use Linux and I use macOS. But I'm not naive to think the security is any better in one or the other.
today at 1:16 PM
> Well that "screw up" was so egregious that it should take at least a decade to regain any trust.
Do you use macOS? Because if you did, then how did you recover from them allowing anyone to straight-up log in as root without password? And then mess up the fix for that bug? That wasn't 2008, that was 8 years ago.
today at 4:28 PM
> it should take at least a decade to regain any trust
Then as it has been 2 decades you should be all good right?
today at 12:38 PM
Security practice was generally very, very bad two decades ago, by today's standards, across the industry.
I don't see the point of being so fixated on that.
today at 12:45 PM
I was responding to the OP saying "stuff like this is why I'm moving back to Linux". It's nonsense.
today at 4:27 PM
No, pulling up a bug from 18 years ago to argue against the fact that linux is secure is nonsense.
today at 4:28 PM
[dead]
today at 12:30 PM
Somehow I doubt many people will be saying that about eMudhra a decade from now.
today at 12:30 PM
Two decades
today at 12:49 PM
i think you mean almost 20 years ago old man
today at 1:28 PM
I edited my comment
today at 12:58 PM
You are going so back that gmail was served over HTTP (not HTTPS) in that era.
If that's the worst you have against Linux then it looks like it has done very well.
today at 1:18 PM
Not really, no. HTTPS was used, except for log-in only. But cookies traveled unencrypted, so you had access to the account anyhow.
And not just GMail, this was virtually every service out there. From a perspective, it's laughable how bad security was back then.
today at 2:56 PM
Besides singling out a single bug from a single distro two decades ago, Linux offers maintainers who actually care to push security fixes within a few hours of globe-spanning vulnerabilities being disclosed? Not sure how that's confusing or controversial.
today at 12:20 PM
It's funny. When Apple goes in and changes peoples systems deeply without consent then it's Apple being evil. When they don't, it's Apple being evil. Heads I win, tails you lose.
today at 12:55 PM
Let's pretend there's a night and day difference between pushing some MP3 onto all iPhones and distrusting a chain of certs that hold the value of '4'. At minimum Apple need to revoke everywhere these joke-level certs live and as fast as possible, and on all devices which also means out of support. Breaking is acceptable here as CA trust is fully compromised.
today at 3:05 PM
Yes, there would be crowds of angry people, furious that Apple... released a critical security patch? Framing removing compromised certs as "changing peoples systems deeply" seems intentionally in bad faith.
today at 1:18 PM
It's funny, when I do steal something I get called bad, and when I do nothing and turn the blind eye to others stealing, I get called bad too.
Morality doesn't solely depend on action or inaction, it also matter what you act or don't act to.
today at 12:25 PM
I've seen this referred to as the "All Roads Lead to Rome" fallacy.
today at 1:19 PM
Eh? Changes systems without consent? Is that the ONLY way to update a fatal flaw in system? Normal update channels don't work?
Besides, how does this relate to my Linux point, where no one installs anything without you knowing it?
today at 1:58 PM
Because in the linux situation, you wouldn't get such an update automatically anyway so it'd be worse?
today at 6:42 PM
How would it be worse? Linux distros patched things almost immediately and you'd get a notification, typically after a daily check.
How is that worse than NOT having any sort of fix from Apple?
today at 1:32 PM
I don’t think you understand what consent means.
today at 1:11 PM
If you're not already in the habit of contacting your git remotes over ssh, its probably one worth building. This is gonna keep happening.
today at 1:18 PM
I use SSH for things which are private or which I may want to push to, but I use HTTPS for everything I just need to download. SSH typically requires that you create an account with whatever the git host is and upload your public key.
today at 1:29 PM
SSH in typical use is not vulnerable to a compromised root certificate, instead it's "just" vulnerable to you having no idea whether you can trust that host key or not, so you just blindly say yes and hope for the best. At least if the key changes, you'll know something was wrong; maybe it was this connection that got compromised, maybe it was the first connection that got compromised, maybe the legitimate host just rotated their keys, who knows. SSH security against MITM is mostly based on lack of motivated attackers and wishful thinking.
today at 1:54 PM
Its no more wishful than expecting a root of trust to stay trustworthy or expecting a trusted name to consistently resolve to the same party.
And there's a lack of motivated attackers for a reason, the attack scales poorly. Maybe you can bamboozle a target or two, but if you go for hundreds, somebody's gonna start wondering what's up with the keys. If you're trying to take over the world, or sell to somebody who is, you're better off focusing on compromising a root of trust or tampering with name resolution, because attacks like that are sustainable at scale.
today at 2:17 PM
Yes, it is about the same, that's the point. If you are worried about this or future compromises of TLS/PKI, using SSH naively is not any better.
today at 4:28 PM
Maybe it's the same probability of being a problem, but it would be a problem introduced by different kinds of threat.
If you're worried that you'll be targeted as an individual by somebody who cannot coerce a CA but can tamper with the channel you're using to get the public key, use https.
If you're worried that you'll be targeted along with many others by somebody who can coerce a CA, use ssh and ensure that some folks are comparing key fingerprints such that at least one is close to the source.
today at 1:15 PM
yeah, it's a good habit to have. Unfortunately, GH defaults to the TLS transport.
today at 2:04 PM
To get mine to finally update, I had to leave my laptop plugged in for a couple of hours. There’s some trustd process that runs every so often; I couldn’t figure out a way to manually trigger the sync.
today at 4:35 PM
looks like people are buying the stocks of the company(EMUDHRA) after the hit they took last week > https://www.google.com/finance/quote/EMUDHRA:NSE?window=1M
today at 4:42 PM
It seems like these trusts should all be delegated to the OS unless there's a really specific need.
today at 1:17 PM
https://support.apple.com/en-us/149555
today at 1:19 PM
That page is an insult to their customers. So what, if I want to be protected from a security issue you acknowledge, I'll need to make modifications to my system configuration?
today at 1:37 PM
It’s interesting they call out as “optional” removing sectigo roots.
If you’re not removing them you better be sure anything that runs on the system has full revocation support including intermediates. Which is.. kind of an impossible thing to assert as true. Which is why most trust stores just removed that as well last week.
today at 3:13 PM
Yes, it’s insane. Step 2 does next to nothing for security without step 3.
today at 1:09 PM
today at 3:09 PM
Don't run important stuff on your consumer devices. Apple is a consumer brand.
today at 4:12 PM
/e/OS from 2026.10.21 also seems to be still affected
today at 3:44 PM
Ran security find-certificate -a -c eMudhra /System/Library/Keychains/SystemRootCertificates.keychain on my work laptop out of curiosity and yep, still there :|
today at 8:22 PM
The emudhra roots were not compromised
today at 11:54 AM
today at 5:20 PM
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.
today at 8:15 PM
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.
today at 1:16 PM
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.
today at 5:19 PM
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.
today at 6:19 PM
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.
today at 3:39 PM
which git
/opt/homebrew/bin/gittoday at 3:23 PM
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)
today at 5:15 PM
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.
today at 8:22 PM
good point -- since the revocation is not recorded in the /etc/ contents.
today at 2:52 PM
The only thing that works is fines.
today at 2:24 PM
today at 1:30 PM
Microsoft had a small golden age with Azure and Windows 10, and now they are going right back into a Vista-era-like rot. Github is down an awful lot. The reliability is worse than the product I work on for work by like 2 orders of magnitude and we have no ops team. It's a joke.
Windows 11 is awful, lots of the fixes and modernization started in windows 10 has totally stalled, leaving users with 5 different places to change a setting instead of the one old place or one new place. Look how many different UI's there are to adjust sound card / sound settings or display settings. It's a complete mess. Their attempts to jump into the AI game have been a complete joke, despite already having integrated Cortana years ago. Putting Cortana on an llm is such an obvious thing to do, and they already did so much work to make that fully integrated into windows and force it on everyone even though it was trash, and now it's still trash and they don't seem to be able to adapt at all.
Now they can't respond to a complete insecurity in one of their major products in weeks? Why do they even validate certs? Why doesn't revocation work in their app? I don't think they can really be trusted at this point.
today at 1:31 PM
Did you misread the title?
today at 4:16 PM
Microsoft were the good guys in this case.
today at 1:23 PM
What would cause this delay from apple? Is there something behind the scenes that can explain it?
today at 1:02 PM
Doesn’t macOS have a way to generate cert.pem from the keychain?
today at 8:02 PM
its very good
today at 11:48 AM
This file is used by a bunch of CLIs. Apple is fundamentally dropping the ball here from a security perspective.
today at 11:54 AM
That's disingenuous title
It should be "Apple still ships compromised CA in /etc/". Git is just a victim like every other app using system CA
today at 12:01 PM
Is using the system CA not the way to go?
(on linux you always have the update-ca-certificates command that downloads the root certificates from a trusted™ source. but sure, it will not help, if each command starts to bring their own ca package :)
today at 12:20 PM
Exactly, so the title wrongly frames git as trusting certs that it shouldn't, when it's correctly trusting the system certs, and MacOS is wrongly trusting certs.
today at 1:28 PM
> Is using the system CA not the way to go?
Yes, and that makes not dealing with this issue worse on Apple's part. If MacOS' setup somehow doesn't allow untangling a (still deemed trustworthy?!?) root certificate issued by eMudhra from the broken intermediate certificates, then revoke that whole chain including the root & accept collateral damage.
Failing that just provides an incentive for apps to do their own chain-of-trust implementations. Which like you said is not the way to go.
today at 12:25 PM
The problem is macOS has two system CA stores, keychain and /etc/ssl/cert.pem.
That is unequivocally bad, similar to Java which ships its own keystore.jks and many applications shipping its own copy on top of that. True nightmare fodder.
today at 10:02 PM
The thing is Apple used to do this correctly. Back when they still shipped OpenSSL (albeit some ancient version), they had actually patched OpenSSL to do cert validation against the native keychain and only ever had Keychain as the source of truth. You can see this in https://github.com/apple-oss-distributions/OpenSSL098/blob/O...
And curl was patched to use the native TLS implementation (SecureTransport) which obviously used Keychain as well.
For some reason when they switched to LibreSSL everywhere they decided to ship their own copy? I don't know what they were thinking.
today at 2:16 PM
It's also an indictment of Apple's relationship to open source software. Never mind contributing back to upstream, they haven't even made the change in their own fork to support their own keychain.
today at 1:01 PM
Also certifi in every Python venv, keystores in every single container, nested keystores within that, it’s certificate matryoshkas all the way down!
today at 1:03 PM
> keystores in every single container, nested keystores within that
At least for that, in $OLDJOB I went and created a new keystore.jks myself to account for an internal CA, so my successors can just update that file, restart the containers and that's it...
today at 12:08 PM
So git on MacOS does trust compromised certs by default? What's wrong with the title then?
today at 12:11 PM
It's not factually wrong, but it implies that this is something specific to Git, and possibly might even be interpreted that it is Git's fault.
In reality it's macOS shipping the outdated certificates, and it affects various other command-line tools, like Curl.
today at 2:11 PM
Fair. I didn't read it as something specific to git cause I know how it works with MacOS
today at 12:21 PM
Not macOS, but XCode dev tools. Still, it is Apple that ships them for sure.
today at 1:22 PM
Does /etc/ssl/cert.pem not exist if you don't install XCode?
today at 12:11 PM
Because it isn't got specifically, it is anything that uses the installation of OpenSSL provided by Apple as part of macOS (at least is my understanding).
today at 12:14 PM
The problem is that the title implies that it's somehow the fault of the package. That's it, that's the problem; the title is disingenuous in its claim.
"Ten days later, Apple Image Viewer on macOS still trusts the compromised eMudhra certificates" doesn't sound as catchy, but is equally correct because the apps use system CA.
today at 5:25 PM
No, unless it’s were a cli image viewer. The gui parts of the OS, and what’s written by Apple, use keychain.
Macs have two completely independent root CA stores. The cli and all the opensource parts use /etc/.
Curl project did actually release support to compile it with default keychain support a year ago, but of course Apple never updates their cli tools, so expect to see that in macOS 37.
Note: I’m not defending Apple here.
today at 12:11 PM
The lede is certainly buried, but calling out an affected development toll on a tech site isn’t a bad call.
Pretty disappointed that Apple hasn’t pushed out an emergency patch to address this, though.
today at 12:04 PM
Agreed.
today at 12:06 PM
[dead]
today at 8:28 PM
small indie company lmfao
today at 1:58 PM
Not really a big deal, the window to do an MITM has passed.
today at 5:44 PM
No, it is open for as long as these certificates are trusted.
today at 9:36 PM
When a significant portion of devices are patched (including gui apps on mac), pulling off an MITM without detection is pretty much impossible. That would be usual culprits of telco, ISP, or public wifi. That's what I mean by the window has closed. Anyone attempting is taking significant risk of being detected; at least in my neck of the woods would be illegal to do as well.
today at 2:00 PM
[flagged]
today at 5:15 PM
[dead]
today at 1:52 PM
[flagged]
today at 12:56 PM
[flagged]
today at 3:45 PM
[dead]
today at 1:54 PM
[flagged]
today at 1:28 PM
Albeit helpful, the site is kinda cringe. It leaves a bad taste in my mouth knowing that the author is affiliated with Mozilla.
Of course they would throw shades at Apple. That being said the situation isn't ideal and I'm sure Apple would have shipped an update if it were easy and warranted.
today at 1:31 PM
Affiliations aside I think I'm happy to see shade thrown at anyone who hasn't bothered to even issue a patch 10 days after what has been one of the biggest news weeks in security in memory.
Fwiw, as critical as I am of Mozilla in recent years, they (along with the Chrome team) have been pretty solid on this whole debacle over the last week. Apple has been far from the only target of their collective shade-throwing.
today at 2:00 PM
Your apps and browser don't trust them. Why should your CLI. It's easy and warranted for Apple and look how much cash and engineers they have.
Apple should publish a hotfix now. Work on a better solution in the long-term. They just don't care about security for developers is my take (it's like a niche group for them?)
Mozilla or not does not matter here.
today at 2:31 PM
A concern for me on this site is that they give the shell commands to edit the /etc/ssl file on their site, instead of just making the Apple link (which they also list) as authoritative on the matter. I don't think users should get in the habit of cut/pasting sudo enable shell one-liners from "random" websites, especially and specifically when the vendor has the very same commands in their published fixed for the issue. In short, this site should have just said "go get the fix from apple".