Notarization-for-Developers
The MacTeX install package is notarized. Before release, the package is sent to Apple and checked there for viruses. Apple also checks that every binary file in the package is signed by an Apple developer and has adopted a hardened-runtime. All this is done automatically at Apple by various servers; no humans look at the package. The Macintosh will not let a user install a package that is not notarized.
|
When Apple rejects a package, they send us a web page listing all problem files
and the reason they cause problems. The problem files in 2025 are listed below, together with our current fix:
- 2025/texmf-dist/scripts/arara/arara.jar
Arara is a java program. Java programs do not need to be signed because security is
provided by the Java system which runs the program. However, arara comes with a library
of precompiled binaries, and such binaries need to be signed. The authors of arara cannot currently sign the binaries, so we remove arara from the distribution.
- 2025/texmf-dist/doc/support/ketcindy/source/KetCindyPlugin/lib/cindy2.jar/libJilt.jnilib
This is another case of a java applet with a precompiled binary library. We currently remove the entire
lib folder above.
Apple also sends a list of items that look suspicious and need checking. These items do not prevent notarization, but we check them to make sure they are harmless. In 2025, there were eight such warnings.
Below are two examples for your amusement.
- 2025/texmf-dist/doc/support/ctan-o-mat.pkg
The file ctan-o-mat is an ordinary text file, but "pkg" is an extension for install packages in macOS.
So Apple thinks it might be an illegal install package.
- texlive/2025/texmf-dist/doc/latex/denisbdoc/denisbdoc.pkg
The file denisbdoc is an ordinary text file which again uses the extension pkg.
About Notarization
|
The iOS software on iPhones and iPads is tightly controlled by Apple; this has become a controversial
issue, with the European Union requiring elaborate changes for sale of devices in their countries. It is important to remember that macOS is different and software from important open source projects, including TeX Live, exists on that platform with little Apple involvement.
|
A few users suspect that Apple would like to close macOS. These users sometimes point to notarization as a step in that direction. We do not agree. As notarization is discussed below, notice that
developers retain the freedom to design software as they please; notarization mainly acts as an aide in the task of making that software more secure.
|
Notarization places two requirements on the actual running programs in TeX Live, beyond checking them for viruses. The first is that each program must be signed by an Apple developer. The second is that each program must adopt a hardened-runtime. At first glance,
each is restrictive and perhaps alarming. But stay tuned.
|
Let us turn to the signing issue. Almost all software in TeX Live is obtained as follows. The developer writes source code, trying to make it platform independent. This code is sent to TeX Live, where it is integrated into a giant build system for the entire project. This source code is then made available to anyone who wishes to download it. Individual people are responsible for building on particular platforms. Someone will build on Windows, someone else on a particular type of Linux, and someone else on the Macintosh. Each of the resulting binary sets is then placed in the TeX Live release. When TeX Live is installed, the install script picks an appropriate set of binaries for the install machine.
|
When the Macintosh binaries are compiled, a script is run which signs all of the binaries with the signature of the Apple developer running the build. This developer adds the hardened-runtime and any corresponding entitlements. Therefore the people who wrote the actual software don't need to know anything about signatures or hardened-runtimes. They are handled automatically.
|
There are a very, very small number of exceptions. One or two builders prefer to compile their
own software because their source code does not fit the TeX Live build model.
These builders must sign their
Mac binaries. Java applications need not be signed, but if a Java developer uses a precompiled
library, then that developer needs to sign all the macOS binaries in the library. (Apple's notarization server ignores Windows binaries and Linux binaries).
Hardened-Runtimes
|
Apple has a list of 13 practices which add security risks to programs. This isn't necessarily bad,
depending on the task of the program. Here are a few samples.
- Inputting audio from the microphone
- Using the build-in camera
- Determining the user's location
- Accessing libraries from a third-party developer
- Creating writeable and executable memory during code execution
When a program adopts a hardened-runtime, it is not permitted to employ any of these 13 practices. If the program tries to do so, it is immediately shut down. For example, suppose your program doesn't access the camera, but it has been infected and the offending code accesses the camera. Your program will immediately shut down.
|
All this is fine, but suppose you want to write a program that uses the camera. For example,
suppose your program will take a picture of a commutative diagram drawn by the user, and then output LaTeX code which typesets the diagram. This problem has a simple solution. You need only file an
entitlement asking to be allowed to use the camera. Such entitlements are automatically granted.
You don't even need to ask Apple; just add the entitlement to the code adopting a hardened-runtime
and you'll be able to use the camera.
|
All 13 dangerous practices have associated entitlements. Theoretically you could ask for all 13 entitlements and then the hardened runtime would do nothing. Apple isn't restricting your program; it is just helping you protect against infections that do things you don't need to do.
|
To get a feel for how this works, consider the programs in TeX Live. All ask for hardened-runtimes.
Three of these programs ask for just one entitlement, a library-validation entitlement. A program using
a hardened-runtime is allowed to link with any macOS library, or any library signed by
the same person who signed the program. TeX Live has a large number of third party open source
libraries, but these libraries are signed by the person signing the TeX Live binaries.
So a TeX Live program can automatically link with any of our regular libraries.
|
However, some programs need to link with the X11 library. This is an open source library maintained
by an Apple engineer, but is not an official macOS library. So a TeX Live program which might use
X11 needs a library-validation entitlement. The three programs which use this entitlement are
mf, xdvi-xaw, and dvisvgm.
|
The only other programs requiring entitlements are the various luatex binaries, because
some lua programs use unsigned executable memory.
|
