I guess I'm glad I snap bought, looks like I may have gotten the last one on Amazon for the 14" at least. I see a couple 16" options around at slightly higher than they were at retail but steal cheaper than Apple's new prices.
There are some Apple resellers that haven't quite caught up to the price increase yet. I just got a 14" M5 Max 128G, 2TB for $5100 off Amazon through Adorama, https://expercom.com/products/16-inch-macbook-pro-with-m5-pr... seems to have them in stock as well.
That would be why it chose a VM that is explicitly designed for sandboxing rather than native executable code or similar, the risk can be minimized by reducing the surface area available to that executable code to almost nothing.
Not with those exact terms, but it is certainly being discussed. Wes McKinney said in a recent talk that with current coding agents there’s no longer an excuse for shipping suboptimal code that takes on tech debt. Writing tests has never been cheaper, writing custom fuzzers, linters, and other harnesses that serve as guardrails has never been cheaper. His take is that “we didn’t have enough engineering time to do it right” is no longer an excuse, and the only excuses left are that you don’t know any better or you have bad taste.
What language that is actually used 40 years after release isn't undergoing big, fundamental changes?
Java? Nope, you're getting a fundamental change in Valhalla
C++? Nope, new language edition every few years with fundamental changes
C? C23 has a number of fairly fundamental changes, expect more in the next language revision
I think your sense of causality is backwards here. These languages are getting fundamental changes because they're being widely used. That is what motivates and drives the change. Languages with no users don't need to change.
I'd have hoped in 2026 that anyone publishing this type of report would understand that DNSSEC isn't helping anything, and is generally considered to be actively harmful to enable. I'd suggest doing a bit more research and dropping the DNSSEC stuff, or reversing it entirely.
Do you have any reference to the Rust community “not allowing” something? This seems more like a case of a relatively niche tool doing what it needed to do to work, but not (yet) some broader effort to upstream or integrate this into cargo or rustup. I couldn’t find any RFCs or anything, for instance.
How about the boy who called nonsense security vulnerabilities. This is the same author who posts with incredulity that the ability to change a config file with a shell command in it gives you the ability to run the shell command you posted and wants it treated as some big CVE. Absolutely inconceivable that you might already have your harness in a sandbox where this is okay, and inconceivable that anyone might have a threat model that says that someone who can edit configuration of a tool can make that tool do arbitrary things allowed by its config.
I can buy the idea that if you can have the MDM infrastructure attest the code signing identity through the designated requirements, that you can probably come pretty close, but I'm still not quite sure you get there with root on macOS (and I suspect that this is part of why DCAppAttest hasn't made it to macOS yet).
Certainly, it still doesn't get you there with their current implementation, as the attempts at blocking the debugger like PT_DENY_ATTACH are runtime syscalls, so you've got a race window where you can attach still. Maybe it gets you there with hardened runtime? I'd have to think a bit harder on that.
> If you can prove a public key is generated by the SEP of a machine running with all Apple's security systems enabled, then you can trivially extend that to confidential computing because the macOS security architecture allows apps to block external inspection even by the root user.
It only effectively allows this for applications that are in the set of things covered by SIP, but not for any third-party application. There's nothing that will allow you to attest that arbitrary third-party code is running some specific version without being tampered with, you can only attest that the base OS/kernel have not been tampered with. In their specific case, they attempt to patch over that by taking the hash of the binary, but you can simply patch it before it starts.
To do this properly requires a TEE to be available to third-party code for attestation. That's not a thing on macOS today.
MDMs on macOS are permissioned via AccessRights, and you can verify that their permission set is fairly minimal and does not allow what you've described here (bits 0, 4, 10).
That said, their privacy posture at the cornerstone of their claims is snake oil and has gaping holes in it, so I still wouldn't trust it, but it's worth being accurate about how exactly they're messing up.
A note, as others have posted on this thread: I mention this as a concrete and trivial flaw in their whole strategy, but the issue is fundamental: there's no hardware enclave for third-party code available to do the type of attestation that would be necessary. Any software approach they develop will ultimately fall to that hole.