|
|
|
Thus when you download software with the Unix install script, you are downloading from a server which might be anywhere in the world, and owned by someone with little direct connection to TUG or CTAN. Why should you trust that server?
Computer security has been the subject of intensive research for almost fifty years. A key idea known as "public key encoding" was suggested in 1970 by James Ellis, with concrete techniques by Whitfield Diffie and Martin Hellman in 1976 and by Ron Rivest, Adi Shamir, and Leonard Adleman in 1977. Since then many similar methods have been described. The basic idea of these methods is that a specific encryption code is described by two keys, called the public key and the private key. Anyone who knows the public key can send the owner an encoded message. The owner keeps the private key secret, and it is required to decode the message.
Suppose I want to download TeX software from a web site, and I know their public key. I'm afraid an imposter has hijacked the site and will send me a virus. So using the web site's public key, I encode a message asking for a particular piece of software. If I'm talking to an imposter, the imposter won't be able to decode my message. But if I'm talking to the authentic site, the site can decode my message and send the software I desire.
In practice lots of other activity takes place, which we will ignore. Let's concentrate on one central question: how do I find out the public key of the site? I could ask a site for its public key, but an imposter will send me a new public key which he can decode.
There are several companies creating and overseeing certificates. How do their root certificates end up on my computer? Luckily, the company making the operating system handles that. When Apple provides a version of macOS, the system includes root certificates from several trusted companies. Any server with a certificate from one of them can be used by the Mac.
Recall that server owners pay money for this service. But nobody in the open source movement makes money. This problem was solved in 2015 with the creation of Let's Encrypt, a trusted source of free certificates for web pages and servers. This small organization receives support from well-known commercial companies. So if your computer has a root certificate which lists Let's Encrypt as trusted, then all of the CTAN servers will be trusted. Macs have such a root certificate.
We'd like to thank Bruno Voisin, a member of the MacTeX team, who spent weeks studying this problem in detail. Bruno discovered that the problem also affected MacPorts, and found their analysis of the problems very helpful. MacPorts' description of the bug is very clear, so we quote it here.
Let's Encrypt is a popular free service that MacPorts and others use to obtain certificates to encrypt their web sites. Certificates they issue are signed by the ISRG Root X1 certificate authority. When the service got started in 2015, no web browser or operating system knew about it and would not have trusted these certificates, so they cross-signed the ISRG Root X1 certificate using DST Root CA X3, a trusted certificate authority already preinstalled in operating systems and browsers at that time. In the meantime, a version of the ISRG Root X1 certificate that has not been cross-signed by DST Root CA X3 has been included in modern browsers and operating systems. On September 30, 2021, DST Root CA X3 expired. As a result, older operating systems and browsers and other user agents that use networking facilities provided by the OS can no longer verify the trust of sites encrypted using Let's Encrypt.
It turns out that this problem has a simple solution on most old versions of macOS. The fix is described in detail on the MacPorts site, so we simply link the appropriate page: MacPortsProblemPage. This fix should suffice on El Capitan (macOS 10.11) and earlier. No fix is required on Sierra, macOS 10.12. This leaves High Sierra (10.13), Mojave (10.14), and early versions of Catalina (10.15). The fix does not solve the problem on these systems and need not be applied.
Why? On High Sierra, Mojave, and early Catalina, Apple provided a root certificate listing ISRG Root X1, the Let's Encrypt root, and also DST Root CA X3, the extra trusted certificate that has now expired. But curl on these versions of macOS had an extra unfortunate feature. It looked at all root certificates in a package and failed if any one of them was expired. For technical reasons which Bruno can explain, this meant that the previous fix doesn't fix these three systems.
Users of early versions of Catalina can fix the problem by updating to the latest version of Catalina. Most already did so. Thus we only discuss High Sierra and Mojave.
One possible fix is for all CTAN servers to get a modern version of ISRG Root X1, but this is difficult to do because these are independent servers all over the world, run by people who have never used a Macintosh, and the task of updating the certificate would require user intervention. So instead of this fix, the TeX Live Install script for 2024, and the tlpkg manager equivalent in TeX Live, have been modified so they will run curl in a manner that ignores the expired certificate. This fixes the problem for TeX Live, and a similar fix is provided by MacPorts for their system. Users of High Sierra and Mojave can thus install and use TeXLive-2024 without problems. They may run into problems with other open source sites.
|
Happy TeXing on macOS ! |
|
Donate |