Most notably agents like Claude Code and Codex? Easy to check if you ask it to run:

    $ curl 'https://dv-g3b-emudhra.we-have-a-problem.com/'

    Your client successfully connected to the site. That's bad!

A lot do it because sometimes there is no convenient library wrapping what they are trying to check or execute that they are aware of, and running a cli command is generally cheap unless you are doing it in a tight loop. A lot of the time this is “it'll do until I find the right library or bindings” code that should have been fixed before release, but it isn't all as bad as running top as you describe.

Huh, I tried to do this a long time ago and permissions bit me and I quit. I was making a nice UI that would run ffmpeg to stitch together some video files, so it would use native UI elements to pick the input files and output location, then generate the ffmpeg command and run it. It worked fine on my machine but it ran into permissions on my friend's machine who needed it and I gave up because they found something better.

ofc it does matter what they do in there, but would users really need to figure all that out themselves and strace all the things to see whats going on down there? :')

truly poor response. happy i dont use apple.

such an expensive flytrap

To know whether a request is a git client or web browser, an attacker needs to be able to inspect the contents of the web request (to check the user agent or whatever). If the site is using a legitimate certificate, the attacker has no way to inspect the contents because it is encrypted with a key they do not control.

If an attacker used their own, eMudhra-signed certificate, it would throw the certificate error in Safari.

Browsers came along and they wanted to maintain their own cert store because operating system flat files were often out of date.

Operating systems grew their own stores because they wanted some kind of registry that was more integrated with the rest of their ecosystem.

Nobody coordinated. CLI tools and unix libraries don't care about browsers or O/S registries, operating systems have requirements so that they can't use the flat files, everyone screams about stuff like systemd turning unix into windows.

And it will continue to proliferate. System management tools often ship their own certs since the O/S certs can be out of date and untrustworthy and may not be able to talk to AWS before you bootstrap the management tool and update the system certs because people still run ancient shit like RHEL5. This is more or less the same reason browsers ship their own as well. I've made the decision to ship an embedded cert store in a product before, and nothing has fundamentally changed that would cause me to rethink that decision (even though for people who have an up-to-date O/S it is strictly additional cost that they now have to track a cert store in another product--but you have to build for the lowest common denominator).

2) Yes, but actually, this is exactly why we have defense in depth. This is a temporary measure while a permanent patch is coming. Defense in depth means a single hole does not result in compromise. I would argue that this situation with Apple demonstrates defense in depth actually working as intended. If this was the permanent solution, and no further patch was coming from Apple, then yes, it would violate defense in depth.

3) Related to above, yes. But it’s not permanent.

These may not be the same people but sometimes they are

I have an apple device and I like its hardware at its price. My brother gifted it to me and my father had an accident with it once which caused it to fall on pure concrete. Other laptops would have been broken but for this it was a tis but a scratch moment

But I am an openness zealot by heart. I can mix and match

In this particular instance though. Shame on apple for not taking any steps and maybe actively fighting against it. I don’t understand why! I hope that they definitely do something about it

People were just losing their minds on here over bugs in the 27.2 beta release that hasn't even shipped yet, with wild conspiracy theories about what Apple was doing.

So you wind up with a typical megacorp release process where nothing can happen if it isn't signed off in triplicate and two operators crack open the books with the missile codes and turn the keys at the same time to launch the update.

The result is that shipping a single file for a critical security update takes way too long.

Looking forward to a comment that is much more grounded than substantial than this.

Why would I judge Apple only on the quality of this docs page (which is good) but not on their poor work that resulted in this situation in the first place?

> I'm sorry, but how is revoking a bad cert not supported in an easy way? Along with adding a cert and using it to establish a secure connection, that seems to be the core features of a cert store?

> Yet somehow, you manage to come to the conclusion that the vendor requiring manual work is the most thorough? I mean, in documenting their failure, maybe.

> With all their talk of caring about user privacy, this seems incompetent at best.

To be fair other vendors almost universally don't document their failures at all or provide any remediation steps to users whatsoever. I always enjoy the exceptions to this rule, but it's not the norm whatsoever.

You seem to be ignoring that Apple's security framework responded to the incident within about 2 hours in most cases. Safari and other macOS apps were protected right off the bat.

It's only this legacy BSD store that needs an OS update, almost certainly because they simply didn't already have a process in place to update it out-of-band. Because they're vertically integrated, they probably don't have an arbitrary do-anything feature that can paper over the lack of foresight here, like other vendors might.

I'd honestly consider that a feature, but sure, the benefits would outweigh the risks in this one particular case.

https://emudhra.we-have-a-problem.com/apple.html

It's right there in the article, look how proactive they're being!