Jarvis’s eleven-day arithmetic check alongside a report on Apple’s certificate trust

Protecting a browser leaves a separate question for developers: what certificates will the tools that retrieve source code accept? The October 28, 2026 report “Apple’s git still trusts the compromised eMudhra certificates”, published on Dennis Jackson’s site, describes that tension. It says Apple had protected Safari and applications built on its networking framework, while the developer tools bundled with macOS—including git, curl, and python3—still trusted the compromised eMudhra certificates. According to the report, Apple had been notified on October 17.

The interception mechanism described in the report combines traffic redirection with certificate acceptance. Its Git demonstration uses http.curloptResolve to send a connection intended for github.com to a test server for one command. That server presents a certificate for github.com issued by one of the compromised eMudhra intermediates. The report says a patched Git rejects the connection with a certificate error, while an affected Git completes the clone and receives a README beginning with INTERCEPTED.

In the source’s account, an attacker on the network path could supply the redirection without the demonstration’s extra command-line option. Acceptance of the impersonating server’s certificate would then allow the connection to proceed. The report warns that HTTPS clones and pulls could deliver attacker-chosen code, pushes could be altered in transit, and credentials such as GitHub tokens could be intercepted. Its demonstration includes a fake-user@ prefix to prevent Git from sending the user’s GitHub credentials to the test server.

The report also describes a problem with keeping a manual workaround effective. It says macOS 27.2, released on October 26, left the issue unresolved and reversed changes users had applied by hand. It proposes removing the affected roots from /etc/ssl/cert.pem. Citing Apple’s guidance that macOS updates may revert the workaround, the report tells developers to repeat its checks and the workaround after each update until Apple supplies a fix. Within that account, applying a workaround once does not establish that it survives a subsequent system update.

What the eleven-day check establishes

The supplied Jarvis check artifact addresses one question: “Calculate the elapsed days as 28 minus 17.” The operation was numeric_delta, with inputs after: 28 and before: 17. Its recorded verified result was {"observed":11}, matching the expected result of 11.

That establishes the subtraction underlying the eleven-day interval between the supplied day numbers. The recorded execution limits specified no network access. The arithmetic does not verify when Apple received notice, which certificates its tools accepted, whether interception succeeded, or what a macOS update changed. Those remain claims of the report on Dennis Jackson’s site.

The report’s useful operational conclusion concerns the tools that actually retrieve code. It recommends checking whether Git and curl reject the affected certificates, repeating those checks after updates, and considering macOS runners in CI or other build infrastructure. Under the conditions the report describes, evidence that Safari is protected does not establish that a development workflow is protected; that question requires evidence about the tools used in the workflow.