Translation subdomain is also expired.
https://rud.is/r-project-cert-status/
> On Aug 19, 2020, at 13:35, Toby Hocking 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.
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:/
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
s
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 wrote:
>
> You are making a very strong assumption that finding an alternative chain of
> trust is safe. I'd argue it's
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
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 se
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
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
> wrote:
>
> Was this resolved upstream or is this something that R should/could
> fi
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 wrote:
>
> Btw. it would be also possible to create a m
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 wrote:
>
> On Sat, May 30, 2020
On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi 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, indee
The expired cert was in my initial email. This is a CA cert. If you go
to https://www.ssllabs.com/ssltest/analyze.html?d=svn.r-project.org
and wait for the analysis, and then expand the certification paths,
then you'll see three possible paths. (For most simulated clients.)
Two are trusted, one is
On Sat, May 30, 2020 at 11:02 PM Jeroen Ooms wrote:
[...]
>
> What you need to do is replace the final certificate with this one
> (just copy-paste the base64 cert): https://crt.sh/?d=1720081 .Then
> restart the server.
You can also export this from Keychain Access on macOS, btw. find
"COMODO RSA
On Sat, May 30, 2020 at 11:40 PM Duncan Murdoch
wrote:
>
> On 30/05/2020 5:23 p.m., Bob Rudis wrote:
> > I've updated the dashboard (https://rud.is/r-project-cert-status/)
> > script and my notifier script to account for the entire chain in each
> > cert.
>
> You never posted which certificate has
On 30/05/2020 5:23 p.m., Bob Rudis wrote:
I've updated the dashboard (https://rud.is/r-project-cert-status/)
script and my notifier script to account for the entire chain in each
cert.
You never posted which certificate has expired. Your dashboard shows
they're all valid, but the download sti
The browsers still shouldn't trust it. The CA cert is expired.
On Sat, May 30, 2020 at 5:23 PM Bob Rudis wrote:
>
> I've updated the dashboard (https://rud.is/r-project-cert-status/)
> script and my notifier script to account for the entire chain in each
> cert.
>
> On Sat, May 30, 2020 at 5:16 P
I've updated the dashboard (https://rud.is/r-project-cert-status/)
script and my notifier script to account for the entire chain in each
cert.
On Sat, May 30, 2020 at 5:16 PM Bob Rudis wrote:
>
> # A tibble: 13 x 1
>site
>
> 1 beta.r-project.org
> 2 bugs.r-project.org
> 3 cran-archive.
It's the top of chain CA cert, so browsers are being lazy and helpful
to humans by (incorrectly, albeit) relying on the existing trust
relationship.
libcurl (et al) is not nearly as forgiving.
On Sat, May 30, 2020 at 5:01 PM peter dalgaard wrote:
>
> Odd. Safari has no problem and says certifica
# A tibble: 13 x 1
site
1 beta.r-project.org
2 bugs.r-project.org
3 cran-archive.r-project.org
4 cran.r-project.org
5 developer.r-project.org
6 ess.r-project.org
7 ftp.cran.r-project.org
8 journal.r-project.org
9 r-project.org
10 svn.r-project.org
11 user2011.r-project.org
12 www.cr
The certificate itself is ok, but some other certificate higher up in
the chain is not. It is possible to have multiple certificate chains,
and only one needs to be successful for to accept the certificate.
Some clients are able to use an alternate chain, so they are fine, but
other clients do not
Odd. Safari has no problem and says certificate expires August 16 2020, but I
also see the download.file issue with 4.0.1 beta:
> download.file("https://www.r-project.org";, tempfile())
trying URL 'https://www.r-project.org'
Error in download.file("https://www.r-project.org";, tempfile()) :
ca
Yep. It should switch to Let's Encrypt with the automated cert renewals ASAP.
On Sat, May 30, 2020 at 4:17 PM Gábor Csárdi wrote:
>
> On macOS 10.15.5 and R-devel:
>
> > download.file("https://www.r-project.org";, tempfile())
> trying URL 'https://www.r-project.org'
> Error in download.file("http
22 matches
Mail list logo
