[OS X TeX] Testing Hardened Runtime in Basic TeX

Richard Koch koch at uoregon.edu
Fri May 17 17:38:40 EDT 2019


I'm hoping to recruit MacTeX users, particularly those running BasicTeX, to test a new distribution which will replace the current one this fall. This task should be easy:

a) Download the following install package, which has size 105 MB


2) Install the package. It will not overwrite BasicTeX-2019 or MacTeX-2019, and it should behave just like BasicTeX-2019

3) Typeset your standard projects. If you run into difficulty, switch to your copy of BasicTeX-2019 and try again. If BasicTeX-2019 works but BasicTeX-2019-Hardened fails, write me and we will try to diagnose the problem.

I already tried pdflatex, xelatex, and lualatex on a 120 page document. All three worked fine.

Feel free to use TeX Live Utility to upgrade BasicTeX-2019 and BasicTeX-2019-Hardened during the test. This is not entirely optimal, since if any actual binaries are updated, then the hardened originals will be replace by ordinary new copies. But we seldom update actual binaries during the year.

Later this summer, I'll call for a similar test of MacTeX-2019-Hardened. Let's wait for that test until after the Apple Developer Conference in the first week of June to see if Apple has further information about hardened runtimes.


Explanation: For many years, all of the MacTeX install packages have been signed. This April, Apple told developers that starting with macOS 10.15 this fall, install packages must be both signed and NOTARIZED.
To notarize a package, the developer sends it to Apple. Machines at Apple examine the package for hidden viruses. If none are found, a certificate is mailed back to the developer and "stapled" to the install package. According to Apple, no human hands examine the install package. This is a service to insure that viruses are not accidentally distributed with install packages. 

The package Ghostscript 9.27 released last month was signed and notarized, but BasicTeX and MacTeX were only signed.

The real point of notarization is that all applications and binary command programs installed by the package must adopt a hardened runtime. This is explained next.


When I retired from the University of Oregon in 2002, the freshman dorms had newly installed ethernet jacks. Entering freshmen discovered a CD and a paper with instructions taped over the jack. The instructions warned that students should install the virus checkers on the CD before connecting their computer to ethernet. "Failure to follow these instructions will result in denial of ethernet access in this room", the sheet warned. Then it added "Macintosh users can ignore these instructions."

Those days are long gone.

In 2002, Mac users felt secure because their computer ran Unix, which has excellent protection of the kernel and regular users against irresponsible users who download viruses and divulge their passwords. But today most Macs have a single owner, and security can fail because the user downloaded a poorly coded program.

If an application is compromised by a security attack, the attacker can use the application to do many dangerous things. He or she could access the video camera or the microphone; they could download the owner's Contact list or read their mail. They could download a third party Library and dynamically link to the library, or compile their own JIT code and run that code. Most of these are not things the original applications needed to do or was programmed to do. Apple has provided a list of 13 dangerous operations; if an application running with a hardened runtime attempts to do any of these dangerous things, it is immediately shut down. Think of this as a ''gift'' to developers from Apple. The developer has no intention of opening your microphone and recording everything you say, but even if a hacker takes over, that hacker cannot turn on the microphone.

However, some applications will want to do one or two of these prohibited operations. I've always dreamed of a TeX editor which used the video camera to scan handwritten commutative diagrams, and converted the scan into TeX code.

So the list of 13 dangerous operations is accompanied by a list of 13 exceptions which developers can claim. A developer who wants to use the video camera can file an exception to that restriction, and then that developer is free to use the video camera.

Note that there are the same number of exceptions as restrictions. Theoretically a developer could claim all 13 exceptions and then the hardened runtime would have no effect. Nobody at Apple approves exceptions, or even sees them. In XCode, for instance, a developer claims exceptions by checking boxes. Check 13 boxes and that developer is free to do anything.

The full list of restrictions and exceptions is available from Apple:


Only two command line programs in BasicTeX required exceptions. One of the prohibited actions is dynamically linking with Third Party code signed by a different developer. Luckily, TeX Live contains its own libraries statially linked. The one exception is X11, which most Linux and Unix systems provide directly. On the Macintosh, X11 is provided by a third party open source group. The programs mf and xdvi-xaw link with this X11 code and required exceptions.


Several years ago, Apple introduced "sandboxing" and required that all apps available through the Apple Store be sandboxed. A sandboxed application cannot perform various dangerous tasks. One of the prohibited operations is calling another program, a restriction which is almost fatal for TeX. Some of my friends fear that Apple is moving in the direction of requiring that all apps be sandboxed, and that only programs available in the App Store will be allowed to run on the machine. I do not share this pessimistic point of view, partially because many Apple engineers came from the open source movement, and partially because Apple officials have often declared that they have no intention of merging the Mac with the iPad and iPhone. But whether I am right or wrong, hardened runtimes are not something we need worry about. They are Apple's way of aiding developers to establish security, while not restricting what their programs can do.

Richard Koch
koch at uoregon.edu

More information about the MacOSX-TeX mailing list