From r|p|ey @end|ng |rom @t@t@@ox@@c@uk  Wed Jun 10 06:22:14 2020
From: r|p|ey @end|ng |rom @t@t@@ox@@c@uk (Prof Brian Ripley)
Date: Wed, 10 Jun 2020 05:22:14 +0100
Subject: [Rd] r-project.org SSL certificate issues
In-Reply-To: <668718BD-D396-4F23-88D0-E39B84978B3A@gmail.com>
References: <CABtg=KmsLkuNCBJq_VfGhG4CTW-5tDS79pSX4NJbo_aCoVhk3g@mail.gmail.com>
 <D17A5556-DA84-4483-9040-437BBA1DE090@gmail.com>
 <CAA-FpKWFM1RKrtzFUZXHwTP2WS1p=2F5g87d21ggQDKzw_X7Dw@mail.gmail.com>
 <CAA-FpKXihTBOLfucwnt7QWhY2UdqUG+ySKBqJV+WTJGJ82t=yw@mail.gmail.com>
 <CAA-FpKXtBMz0jk=boWFeVd-LQ_u=cHyqn9Z-BOaRb3J7R_x2Hg@mail.gmail.com>
 <a96725a1-0e74-164d-4e8c-000b84ca7bc8@gmail.com>
 <CABFfbXvNh2s6KZZ+tAwM8tHDOb0Ob8mFJkbrMb+_E8GPzOA6SA@mail.gmail.com>
 <CABtg=Kk5gNnSqoLPtY-YodzP7rLy+1v4uwP+S87mdUqhkPKZYw@mail.gmail.com>
 <CABtg=KkEX6PLPx4Jtdsc7rtKuEjaUJZjPUJ8MUMzrmzNw85xeg@mail.gmail.com>
 <CABtg=Knbz7SRRHUK1JcbYJekGTcwbcM8=NNaXaO_UdJiF-E0bw@mail.gmail.com>
 <CAFDcVCS1+Tu07=JPRUMZbR0=J289Nh_j5+PfrH5LzZddbCbo2A@mail.gmail.com>
 <02BBCA72-BBF4-4AC7-AFB4-7A516BD6A2D3@R-project.org>
 <668718BD-D396-4F23-88D0-E39B84978B3A@gmail.com>
Message-ID: <be7d021c-c115-f913-d3a4-49c478af6c1c@stats.ox.ac.uk>

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



[Rd] r-project.org SSL certificate issues
Prof Brian Ripley