ConTeXt in TeX Live
Bruno Voisin
bvoisin at icloud.com
Mon Jun 9 09:52:55 CEST 2025
> On Mon, 2025-06-09 at 07:56 +0200, Mojca Miklavec wrote:
>
>> On Mon, 9 Jun 2025, 00:27 Max Chernoff wrote:
>>
>>> For macOS, the Standalone Distribution uses separate aarch64 and x86_64
>>> binaries, but TeX Live uses a single universal binary. For those, I'm
>>> installing the binaries from the Standalone Distribution as normal, and
>>> then I'm directly copying the x86_64 binary into x86_64-darwinlegacy,
>>> and I'm merging the x86_64 and aarch64 binaries into a single universal
>>> binary using llvm-lipo.
>>
>> The binary universal-darwin should probably be signed and notarised in
>> order to be committed to TeX Live. The build farm does not produce signed
>> binaries yet.
>
> Karl and I checked with Richard Koch before starting this, and Richard
> thought that distributing an unsigned LuaMetaTeX binary in TeX Live
> should be okay. But if this causes problems for anyone on macOS, please
> let me know and we can try and figure out a solution.
Short version: everything seems fine, I double-checked
% luametatex --version
This is LuaMetaTeX, Version 2.11.07
[...]
Functionality : level 20250427
Longer version: before getting into specifics, a clarification (greater detail, and better -- and more exact -- writing by an actual developer -- Richard -- at <https://www.tug.org/mactex/notarization-problems.html>).
There are three security layers a Mac binary can have, in this order
- Signature: the binary is signed with a Developer ID.
- Hardened Runtime: the binary runs in a sandbox, and actions that need to get out of the sandbox are authorized at compile time via specific entitlements (see <https://developer.apple.com/documentation/Security/hardened-runtime>).
- Notarization: the compiled binary is uploaded to Apple servers which scan it automatically for potentially harmful actions.
A binary needs to get through these three layers before it can be distributed via a .pkg install package, as MacTeX is. For binaries installed afterwards via tlmgr, there is no such restriction.
This is why, for example, arara is not included in MacTeX and must be installed afterwards by the interested user using TeX Live Utility (the Mac GUI to tlmgr): within arara, there's arara.jar which contains an unsigned Mac binary causing notarization to fail.
Now, luametatex as distributed in MacTeX has gone through these three steps. Checking with the tlmgr backup:
% codesign --display --verbose=2 luametatex
Executable=/Users/brunovoisin/Desktop/Test/context.universal-darwin.r74402/bin/universal-darwin/luametatex
Identifier=luametatex
Format=Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=23446 flags=0x10000(runtime) hashes=727+2 location=embedded
Signature size=8974
Authority=Developer ID Application: Richard Koch (RBGCY5RJWM)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=1 Mar 2025 at 04:30:51
Info.plist=not bound
TeamIdentifier=RBGCY5RJWM
Runtime Version=12.1.0
Sealed Resources=none
Internal requirements count=1 size=172
The signature is there, as is the runtime hardening (the "(runtime)" in CodeDirectory).
The updated luametatex, just installed by TeX Live Utility, has an adhoc signature
% codesign --display --verbose=2 `which luametatex`
Executable=/usr/local/texlive/2025/bin/universal-darwin/luametatex
Identifier=luametatex
Format=Mach-O universal (x86_64 arm64)
CodeDirectory v=20400 size=23939 flags=0x20002(adhoc,linker-signed) hashes=745+0 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none
which allows it to run. There are no entitlements:
% codesign --display --entitlements - --xml `which luametatex` | xmllint --format -
Executable=/usr/local/texlive/2025/bin/universal-darwin/luametatex
-:1: parser error : Document is empty
^
which is normal since it underwent no runtime hardening. But the version distributed with MacTeX had none either:
% codesign --display --entitlements - --xml luametatex | xmllint --format -
Executable=/Users/brunovoisin/Desktop/Test/context.universal-darwin.r74402/bin/universal-darwin/luametatex
-:1: parser error : Document is empty
^
So I assume luametatex just doesn't do anything that requires an entitlement. Compare for example with luatex:
% codesign --display --entitlements - --xml `which luatex` | xmllint --format -
Executable=/usr/local/texlive/2025/bin/universal-darwin/luatex
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.cs.allow-dyld-environment-variables</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.disable-executable-page-protection</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
</dict>
</plist>
allow-dyld-environment-variables means luatex is affected by environment variables, disable-library-validation that it's able to link to libraries signed by another developer, and so forth.
All the above, of course, valid up to later today (Paris time) when the next macOS will be unveiled at WWDC. Then, who knows?
Bruno Voisin
More information about the tex-live
mailing list.