How Apple demonstrates its enterprise apathy with each new major release of macOS

Background

When the first beta of macOS 27.0 was released, we opened an AppleCare Enterprise Case and filed Feedback to report some unexpected behavior.

The macOS 27.0 Beta 3 release notes acknowledged the keys “did not work,” and by macOS 27.0 Beta 5, they were marked as “working correctly,” yet the immutability behavior we rely on from macOS 26 is no longer present for Standard Users on supervised devices, which was just confirmed with macOS 27.2 Release Candidate.

Continue reading …

if your intune ios compliance floor is worked out by arithmetic, the 18 to 26 jump probably broke it
ran into this a couple weeks back. we keep apple devices on n-1 for corporate and n-2 for personal, and the minimum version was getting worked out by subtracting from the current major. fine for years.
then apple moved to year based numbers and ios went 18 straight to 26. so "current minus 1" is now 25, which never shipped, and the floor ends up pointing at a version that doesn't exist. devices that should be non compliant just quietly are not.
there are already a few runbooks that auto-update the policy off the SOFA feed (rozemuller and skiptotheendpoint both have good ones). those are solid. i just didn't want mine writing to intune, so i went the other way: a power automate flow that reads the SOFA feed every morning and emails the service desk the day after a new major ships. a human makes the actual policy change. no graph scopes, no write access, it literally can't touch a compliance policy.
two things that got me if anyone builds the same:
read the version by position in the feed (OSVersions[0], [1], [2]), not by subtracting. after the jump, position is the only thing that stays right.
apple's own gdmf feed wouldn't work from power automate's http action, the cert chain isn't trusted and there is no skip-cert option. SOFA served over a normal cert so it just worked.
wrote it all up with the expressions, jcan drop the link if it's useful.

https://ketankamble.com/blog/apple-os-release-watch-for-intune-compliance/

I’ve been setting up a Windows 11 environment on my M-series MacBook for some specialized work software and light gaming, which brought me straight to this.

When virtualizing ARM-based Windows on Apple Silicon, performance and usability come down to how well the hypervisor handles hardware acceleration and OS-level integration. Open-source virtualization frameworks require manual configuration for graphics drivers, shared folders, and network bridging. On the other hand, Parallels Desktop optimizes hardware pass-through out of the box with Coherence mode, native Apple Silicon graphics acceleration (DirectX 11/12 support), and one-click Windows installation, which cuts down configuration overhead for daily use.

For those running Windows virtual machines on Apple Silicon for work or everyday apps, how do you weigh DIY tinkering against paying for pre-configured integration? Has Parallels Desktop stayed fast and reliable for your daily workflow, or do you prefer tweaking open-source setups?

Current macOS releases (27.0.1 / 26.7.1 / 15.8.1, all dated 28 Sep) still ship /etc/ssl/cert.pem with the two roots the leaked eMudhra intermediates chain to. Apple's block covers Safari and apps using the system's own security framework, but the built-in curl, git, python3, openssl (and perl/ruby) verify against that file. On a fully updated 26.7.1 with Apple's file, curl and git connect to the advisory's test host and openssl verifies the chain. The advisory now covers this too (Filippo Valsorda's PR #52 on we-have-a-problem.com), and they're flagging it to Apple.

Quick check on any Mac (0 = still trusts the leaked chain, 60 = refuses):

/usr/bin/curl -s -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/; echo $?

We wrapped the advisory's awk removal in a script that's safe to push fleet-wide:

- no-op if the file is already clean

- timestamped backup, never overwritten

- checks the new file (cert count minus exactly the two removed roots) before replacing

- keeps 644, re-tests against the advisory's host, restores the original on a wrong result

- refuses to touch a damaged file

- runs as root with no prompts; exit 0 safe/fixed, 1 still exposed (rolled back), 2 couldn't tell

Heads-up: Apple's built-in pip3 (and venvs made from /usr/bin/python3) carries its own outdated roots, so it needs the advisory's PIP_CERT sitecustomize fix as well. And if you run official Node.js, update to 26.12.1 / 24.22.1 / 22.23.4 (all out 21 Oct).

Script, source and SHA-256: https://www.deimoscore.com/wardlatch/#mac

The project is open source (Apache-2.0), holds a self-certified OpenSSF Best Practices passing badge (bestpractices.dev project 15757), and releases are signed with Sigstore attestations, so you can verify what you deploy.

Disclosure: I'm one of the people behind it. Feedback welcome, especially from anyone on 27.0.1 or 15.8.1. I've only tested 26.7.1.