On MacOS Monterey, I am running into an SSL error when using
download.file() on the czso.cz domain. This is probably caused by the version of LibreSSL shipped with Monterey. The same occurs when using
The error I get is
Error in open.connection(3L, "rb") : error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length
Reprexes are documented in a github issue on the repo of an affected package.
Web browsers have no problem with the domain, and the issue also occurs when using
curl in the
zsh shell, so it it caused by a system library. Using HTTP instead of HTTPS does not help.
From what I can tell, this only occurs on a few domains, but unfortunately the one I am dealing with is a whole country's statistics provider, and I maintain a package that depends on downloading data from it. This has also manifested in CRAN checks of packages depending on this host.
I have reported to both Apple and the admin of the domain (though the domain seems fine when tested on ssllabs.com).
The underlying issue is that R relies on the system-provided SSL library, which Apple does not in fact recommend linking to dynamically:
- We discourage folks from using the OpenSSL dynamic libraries that are built in to macOS because binary compatibility concerns prevent us from updating them. You can watch WWDC 2011 Session 212 Next-Generation Cryptographic Services for more details on this.
- If you feel the need to use OpenSSL (for example, if it has features that are missing from our APIs, or you’re using some other library that depends on OpenSSL), you should feel free to compile your own version of the code into your app. You can statically or dynamically link this; it’s really up to you.
- Likewise for the various forks of OpenSSL.
This underlying issue has been discussed on R-devel in 2020, in the context of a slightly different SSL issue, but specifically with respect to OpenSSL/LibreSSL on MacOS. The suggestion was raised to compile R with statically linked OpenSSL:
I.e., there is a case to be made that we might want to link openSSL rather than LibreSSL.
Given (1) we are seeing this again, (2) Apple is unlikely to fix this given the scarcity of the issue, and (3) it seems Apple recommends against dynamically linking to libraries it ships:
- is there a way around this without having the user install a different version of OpenSSL and jumping through the various hoops of getting the right version onto PATH etc.?
- what would be the way forward to prevent this happing in R? Is r-devel/r-help the only place to suggest this change?