Hi win-builder certificate expired on Aug 15. My student on the other side of the world is also seeing this problem so I think it needs to be fixed... > download.file("https://win-builder.r-project.org", "/tmp/wb.html") trying URL 'https://win-builder.r-project.org' Error in download.file("https://win-builder.r-project.org", "/tmp/wb.html") : cannot open URL 'https://win-builder.r-project.org' In addition: Warning message: In download.file("https://win-builder.r-project.org", "/tmp/wb.html") : URL 'https://win-builder.r-project.org/': status was 'Peer certificate cannot be authenticated with given CA certificates' >
On Wed, Jun 10, 2020 at 2:40 AM Gábor Csárdi <csardi.ga...@gmail.com> wrote: > My (also not expert) understanding is that there is nothing insecure about > alternative certificate chains at all. All browsers and macOS's built in > SSL library (secure transport) support them properly. OpenSSL and LibreSSL > were/are simply broken. This was not such a big issue so far, but now that > some old long lived certificates are expiring, it is increasingly an issue. > > FWIW it is possible to build libcurl on macOS without any external SSL > library, so OpenSSL and LibreSSL are not needed at all. (Unfortunately the > libcurl build that comes with most (all?) macOS versions does use > LibreSSL.) The R installer could link to such a static libcurl library on > macOS, and that would solve the issue for macOS. Whether it should, that's > another question. > > Gabor > > On Wed, Jun 10, 2020 at 9:56 AM peter dalgaard <pda...@gmail.com> wrote: > > > As I said, there is stuff that I don't understand in here.... (including > > why browsers apparently do trust alternative chains) > > > > -pd > > > > > On 10 Jun 2020, at 01:53 , Simon Urbanek <simon.urba...@r-project.org> > > wrote: > > > > > > You are making a very strong assumption that finding an alternative > > chain of trust is safe. I'd argue it's not - it means that an adversary > > could manipulate the chain in a way to trust it instead of the declared > > chain and thus subverting it. In fact switching to OpenSSL would create a > > serious security hole here - in particular since it installs a separate > > trust store which it is far more easily attacked and subverted. By your > > argument we should disable all SSL checks as that produces error with > > incorrectly configured servers so not performing checks is better. It is > > true that R is likely not used for sensitive transactions, but I would > > rather it warned me about situations where the communication may be > > compromised instead of just silently going along. > > > > > > Cheers, > > > Simon > > > > > > > > > > > >> On Jun 10, 2020, at 11:39 AM, peter dalgaard <pda...@gmail.com> > 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. > > >> > > >> 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. > > >> > > >> Best > > >> -pd > > >> > > >>> On 10 Jun 2020, at 00:50 , Simon Urbanek <simon.urba...@r-project.org > > > > wrote: > > >>> > > >>> To be clear, this not an issue in the libraries nor R, the > > certificates on the server were simply wrong. So, no, this has nothing to > > do with R. > > >>> > > >>> Cheers, > > >>> Simon > > >>> > > >>> > > >>>> On Jun 10, 2020, at 10:45 AM, Henrik Bengtsson < > > henrik.bengts...@gmail.com> wrote: > > >>>> > > >>>> Was this resolved upstream or is this something that R should/could > > >>>> fix? If the latter, could this also go into the "emergency release" > R > > >>>> 4.0.2 that is scheduled for 2020-06-22? > > >>>> > > >>>> My $.02 > > >>>> > > >>>> /Henrik > > >>>> > > >>>> > > >>>> On Sun, May 31, 2020 at 8:13 AM Gábor Csárdi < > csardi.ga...@gmail.com> > > wrote: > > >>>>> > > >>>>> Btw. it would be also possible to create a macOS R installer that > > >>>>> embeds a static or dynamic libcurl with Secure Transport, instead > of > > >>>>> the Apple default LibreSSL. > > >>>>> > > >>>>> This might be too late for R 4.0.1, I don't know. > > >>>>> > > >>>>> Gabor > > >>>>> > > >>>>> On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi < > csardi.ga...@gmail.com> > > wrote: > > >>>>>> > > >>>>>> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi < > > csardi.ga...@gmail.com> wrote: > > >>>>>> [...] > > >>>>>>> Btw. why does this affect openssl? That root cert was published > in > > >>>>>>> 2010, surely openssl should know about it? Maybe libcurl / > openssl > > >>>>>>> only uses the chain provided by the server? Without trying to use > > an > > >>>>>>> alternate chain? > > >>>>>> > > >>>>>> Yes, indeed it seems that old OpenSSL versions cannot handle > > >>>>>> alternative certificate chains. This has been fixed in OpenSSL in > > >>>>>> 2015, so modern Linux systems should be fine. However, macOS uses > > >>>>>> LibreSSL, and LibreSSL never fixed this issue. E.g. > > >>>>>> https://github.com/libressl-portable/portable/issues/595 > > >>>>>> > > >>>>>> r-project.org can be updated to send the new root certificate, > > which > > >>>>>> will solve most of our problems, but we'll probably have issues > with > > >>>>>> other web sites that'll update slower or never. > > >>>>>> > > >>>>>> FWIW I built macOS binaries for the curl package, using a static > > >>>>>> libcurl and macOS Secure Transport, so these binaries does not > have > > >>>>>> this issue. > > >>>>>> > > >>>>>> They are at https://files.r-hub.io/curl-macos-static and they can > > be > > >>>>>> installed with > > >>>>>> install.packages("curl", repos = > > >>>>>> "https://files.r-hub.io/curl-macos-static", type = "binary") > > >>>>>> > > >>>>>> They support R 3.2 and up, including R 4.1, and should work on all > > >>>>>> macOS versions that the given R release supports. > > >>>>>> > > >>>>>> Gabor > > >>>>> > > >>>>> ______________________________________________ > > >>>>> R-devel@r-project.org mailing list > > >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel > > >>>> > > >>>> ______________________________________________ > > >>>> R-devel@r-project.org mailing list > > >>>> https://stat.ethz.ch/mailman/listinfo/r-devel > > >>>> > > >>> > > >>> ______________________________________________ > > >>> R-devel@r-project.org mailing list > > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > > >> > > >> -- > > >> Peter Dalgaard, Professor, > > >> Center for Statistics, Copenhagen Business School > > >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark > > >> Phone: (+45)38153501 > > >> Office: A 4.23 > > >> Email: pd....@cbs.dk Priv: pda...@gmail.com > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > -- > > Peter Dalgaard, Professor, > > Center for Statistics, Copenhagen Business School > > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > > Phone: (+45)38153501 > > Office: A 4.23 > > Email: pd....@cbs.dk Priv: pda...@gmail.com > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel