Translation subdomain is also expired.
https://rud.is/r-project-cert-status/
> On Aug 19, 2020, at 13:35, Toby Hocking <tdho...@gmail.com> wrote:
>
> 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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
