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.
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
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…)
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…
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.
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 ...
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.
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.
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.
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.
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.
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).
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.
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.
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”
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.