r-project.org SSL certificate issues
On 10/06/2020 00:39, peter dalgaard wrote:
Yes and no... At least as I understand it (Disclaimer: There are things I am pretty sure that I don't understand properly, somewhere in the Bermuda triangle beween CA bundles, TLS protocols, and Server-side settings), there are two sided to this: One is that various *.r-project.org servers got hit by a fumble where a higher-up certificate in the chain of trust expired before the *.r-project.org one. This was fixed by changing the certificate chain on each server. The other side is that this situation hit Mac users harder than others, because Apple's LibreSSL doesn't have the same feature that openSSL has to detect a secondary chain of trust when the primary one expired. This was not unique to R - svn also failed from the command line - but it did affect download.file() inside R. The upshot is that there might be 3rd party servers with a similar certificate setup which have not been updated like *.r-project.org. This is not too unlikely since web browsers do not have trouble accessing them, and the whole matter may go undetected. For such servers, download.file() would still fail.
A dozen or so packages fail their CRAN checks because of this. The most common problematic site has been reported to its web admins, but not resolved.
I.e., there is a case to be made that we might want to link openSSL rather than LibreSSL. On the other hand, I gather that newer versions of LibreSSL contain the relevant protocol upgrade, so maybe one can just wait for Apple to update it. Or maybe we do want to link R against openSSL, but almost certainly not for a hotfix release.
This is not just a macOS issue: most CRAN failures are seen on Debian and Solaris as well as macOS (but not Fedora). And a different one (3 packages by the same author misusing RCurl to set a <= 2014 root certificate bundle) is seen only on Fedora.
Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford