Hacker News
points by chrisweekly 1 day ago | 0 comments
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).
[–] stingraycharles 1 day ago
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.

[–] emn13 1 day ago
Yeah, definitely: having lots of separately distributed and likely rarely and unreliably updated trust roots would not inspire a lot of confidence.
[–] gchamonlive 1 day ago
In turn the centralized OS authority needs proper maintenance otherwise it's just as bad if not worse, because of the larger blast radius
[–] brookst 1 day ago
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.

[–] mikepurvis 1 day ago
Isn't that the world that Docker gives us, basically?
[–] Shish2k 1 day ago
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
[–] stephbook 1 day ago
Just run it in kubernetes and mount the certificates with trust-manager
[–] musicale 1 day ago
> docker

If only we could somehow share libraries and configuration files across apps rather than duplicating them and having to update them for every app individually.

We could call it a "shared library" system and an "operating" system. Someone should really invent this.

I mean, even docker could maybe use a shared base image or something right? ;-)

[–] xp84 1 day ago
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.

[–] lakeviewterrace 1 day ago
> 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.

[–] emn13 21 hours ago
Surely there's a nuanced difference between "every app distributes this independently" and "a very small few apps that bear the brunt of hostile exposure support independent mechanisms".

It's also worth remembering that both of these specific organizations were instrumental in major, positive security shifts that eventually hit OS's too, including shorter-lived certs, limiting the point of CAs, adoption of TLS 1.3, and likely other things. If anything, they deserve _more_ trust than the OS distributors on this specific front, perhaps also because they don't share the OS distributor's incentive to prioritize stability for paying customers, which can be at odds at times with harsh, prompt security measures.

[–] musicale 1 day ago
> 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.

https://support.apple.com/en-us/149555

[–] gchamonlive 1 day ago
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.

[–] sfoley 1 day ago
Remember this is the same company that demands they're the only ones who can possibly decide what software their users get to install.
[–] sebazzz 1 day ago
So many Java trust stores never seeing this update.
[–] whizzter 1 day ago
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.
[–] angulardragon03 1 day ago
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.
[–] throwaway2037 1 day ago
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.

[–] asveikau 1 day ago
It's pretty trivial to do this. Before the official patches were out on other platforms I did it on a few machines.
[–] bombcar 1 day ago
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".

[–] vikramkr 1 day ago
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"
[–] bombcar 1 day ago
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.

[–] Perseids 1 day ago
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.
[–] bombcar 1 day ago
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
[–] thayne 23 hours ago
Even before Let's Encrypt was a thing, that is how most DV (Domain Validated) certs were issued. It was just a more manual, more expensive process to do it. GP's point is since the system depends completely on trusing the DNS chain anyway, why not have the registrar [sic. it should actually probably be the registry] act as the CA as well and cut out the middleman, and the need to verify the domain from multiple paths to prevent MitM.
[–] thayne 23 hours ago
CRLs were a great (ok, maybe just ok) design in the early days when the internet was small and the number of CAs and revoked certificates was small. But it was never going to be scalable. And it has the really big problem of needing to distribute these lists of revocations. OCSP has a different set of tradeoffs.
[–] vikramkr 1 day ago
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.
[–] thayne 23 hours ago
In Physics, if a theory doesn't describe reality, the theory is incomplete. Of course all theories are ultimately incomplete, the goal is to find theories that match reality better than the ones before.
[–] bombcar 1 day ago
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.
[–] stkdump 1 day ago
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.
[–] tomkarho 1 day ago
I could swear I saw that title here earlier today almost verbatim maybe even referencing the same link.
[–] financetechbro 1 day ago
Can confirm I saw the same thing
[–] Barbing 1 day ago
Exceeds character limit, but admins can modify if there’s a better shorter title.
[–] ToucanLoucan 1 day ago
> 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.

[–] bombcar 1 day ago
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".
[–] xp84 1 day ago
Wait, did I miss this? Can you share details on what browsers started doing this?
[–] ToucanLoucan 1 day ago
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...

[–] pelican0 1 day ago
> 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?

[–] ToucanLoucan 1 day ago
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!?

[–] bombcar 1 day ago
"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)

[–] senderista 1 day ago
Indeed, it makes it harder to block addictive sites like this one in HOSTS :)
[–] ToucanLoucan 1 day ago
That too lol
[–] pcthrowaway 18 hours ago
Doesn't libcurl do this also?
[–] woodruffw 1 day ago
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.)

[–] astrostl 1 day ago
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
[–] woodruffw 1 day ago
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

[–] geephroh 1 day ago
Thanks for the fix -- appreciate the quick action!
[–] throwaway2037 1 day ago

    > Homebrew ships its own CA bundle
No trolling by this question: Can you explain your decision? I can see some pros and cons of this decision. Was it simply removing dependency upon Apple if there was a disagreement on which CA certs to trust? (You can act without permission from Apple to add/remove CA certs?) Also: How does Homebrew decide which CA certs to include/exclude? Do you get a CA cert pack from Oracle/Mozilla/Google/Microsoft/Amazon/Apple?

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.

[–] woodruffw 1 day ago
> 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.

[–] lukasgelbmann 1 day ago
Homebrew’s git (unlike homebrew’s curl) seems to default to using the system’s CA bundle, not homebrew’s. Is that a bug?
[–] woodruffw 1 day ago
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
Make sure your `git` binary is Homebrew's, not the system/XCode CLT one. If you see `/usr/bin/git`, you're not using the Homebrewed Git.

[1]: https://github.com/Homebrew/homebrew-core/pull/321878

[–] smmeis 15 hours ago

    $ brew list git --versions
    git 2.56.0_2
    $ which git
    /opt/homebrew/bin/git
    $ which curl
    /opt/homebrew/opt/curl/bin/curl
    $ git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
    2975b9930644b321e18ecae09e29c15b955e6103 HEAD
    2975b9930644b321e18ecae09e29c15b955e6103 refs/heads/main
It seems that the curl formula still needs patching?
[–] bombcar 1 day ago

    $ 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
We watch; we wait (I guess)
[–] lukasgelbmann 1 day ago
> “This is being fixed now”

Wow, that was fast!

[–] forkerenok 1 day ago
> (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 :)

[–] woodruffw 1 day ago
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.)

[–] Fatnino 1 day ago
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.

[–] jeroenhd 1 day ago
> 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.

[–] blmarket 1 day ago
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.

[–] mort96 1 day ago
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.
[–] pizzafeelsright 1 day ago
Have you checked with the newsgroups and gopher web on why this became a thing?
[–] xp84 1 day ago
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’?”

[–] pishpash 1 day ago
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?

[–] gruez 1 day ago
>do you want to trust "key authorities" from outside your country?

So what happens to americans visiting french sites?

[–] pishpash 1 day ago
"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]"

[–] gruez 1 day ago
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?

[–] pishpash 1 day ago
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.

[–] bombcar 1 day ago
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.

[–] Ajedi32 1 day ago
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.)
[–] paulddraper 1 day ago
?

The idea of the internet is that you can reach it across the world, globally.

[–] undersuit 1 day ago
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.
[–] kridsdale1 1 day ago
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.

[–] jeroenhd 1 day ago
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.

[–] probe_user 1 day ago
Second probe: confirming the fixed comment path resolves a parent comment correctly.
[–] andrewmutz 1 day ago
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.

[–] stouset 1 day ago
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.

[–] robby_w_g 1 day ago
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.
[–] nullwarp 1 day ago
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.

[–] zoobab 1 day ago
It has the davantage that you can finally find out what those apps are sending back home, including your private data.
[–] zahlman 1 day ago
> 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.

[–] moi2388 1 day ago
I’m somewhat of an Apple fanboy, and I find this absolutely unacceptable.
[–] blackcatsec 1 day ago
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)