Trust infrastructure keeps failing in boring, unfixed ways
The top security story is about the eMudhra intermediate CAs. Apple published a detailed note saying command-line tools like curl, git, python3, ruby, perl and openssl read certificates from /etc/ssl/cert.pem. Ten days later, a separate thread shows Git on macOS still trusting the compromised certs. Commenters split on blame. One says the title is unfair because "Git is just a victim like every other app using system CA" and the headline should be "Apple still ships compromised CA in /etc/". Another says Apple is "fundamentally dropping the ball."
The same week brought Tailscale's SSH investigation, where most of the identified issues are privilege escalation by users who are already authorized. Readers also objected that the feature ships on by default. A UEFI firmware flaw adds a third data point: code execution in most servers, though it needs some local network control. One commenter says they replaced OVMF (about 1M lines of C) with 300 lines of assembly for their confidential-VM targets.
The pattern here: trust is inherited, not verified. A cert file, an SSH layer, firmware. Each gets a patch cycle slower than the exposure window, and the owner of the fix is rarely the person who gets hurt.
So what?
If you ship software that leans on system trust stores, default-on remote access, or firmware you didn't write, you carry a risk you don't control. Audit what your product inherits, make risky features opt-in, and have a plan for revoking trust yourself instead of waiting for the OS vendor.
Read these
Ten days later, Git on macOS still trusts the compromised eMudhra certificates
About the compromised eMudhra intermediate CAs
Tailscale SSH: Investigation and remediation update
Code-execution flaw in UEFI firmware threatens most servers on planet Earth