Re: R certificate issue

[Jason Bacon <bacon4000%gmail.com@localhost>]

On 06/16/17 01:38, coypu%sdf.org@localhost wrote:
> I think we need to should teach curl to look in the right place.
> It appears it has an option --with-ca-fallback=yes which might have the
> expected behaviour, as it comes with the description:
>
> checking whether to use builtin CA store of SSL library...
>
> (So something like ``CONFIGURE_ARGS+=	--with-ca-fallback=yes'' in curl's
> makefile, and verifying that this line changes from 'no' to 'yes')
>
> it looks like it will use openssl's code and certificates to validate if
> an earlier option doesn't work.
>
> And being a functional change, bump PKGREVISION :-)
>
> If that fails we can pass it a CA_PATH, pkgsrc/*/mozilla-rootcerts
> SSLDIR might contain the right logic for where the certificates are
> expected to be.

I tried adding --with-ca-fallback and it made no difference.  I then 
doubled back to reexamine the problem.

It looks like I got some bad empirical data from my colleague on manual 
curl downloads.  Something in his environment, I think.

When I tried to reproduce his results, I saw what the real issue is:

Linux sciprog2.ceas bacon ~ 434: (pkgsrc): which curl
/sharedapps/pkg-2017Q1/bin/curl
Linux sciprog2.ceas bacon ~ 435: (pkgsrc): curl 
https://cran.r-project.org/CRAN_mirrors.csv
curl: (60) SSL certificate problem: self signed certificate in 
certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure.

The curl that ships with CentOS accepts the certificate by default, though.

Linux sciprog2.ceas bacon ~ 439: (pkgsrc): /usr/bin/curl 
https://cran.r-project.org/CRAN_mirrors.csv | head -n 3
  % Total    % Received % Xferd  Average Speed   Time    Time Time  Current
                                 Dload  Upload   Total   Spent Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- 
--:--:-- 
0"Name","Country","City","URL","Host","Maintainer","OK","CountryCode","Comment"
"0-Cloud 
[https]","0-Cloud","0-Cloud","https://cloud.r-project.org/","Automatic 
redirection to servers worldwide, currently sponsored by 
Rstudio","winston # stdout.org",1,"us","secure_mirror_from_master"
"0-Cloud","0-Cloud","0-Cloud","http://cloud.r-project.org/","Automatic 
redirection to servers worldwide, currently sponsored by 
Rstudio","winston # stdout.org",1,"us","secure_mirror_from_master"
100 24698  100 24698    0     0  28732      0 --:--:-- --:--:-- --:--:-- 
88207
curl: (23) Failed writing body (4096 != 8314)

And again, we can make pkgsrc curl work by forcing it to use the Linux 
certificates.

I think it's reasonable to reject self-signed certificates by default, 
so I wouldn't argue for any changes here.  I'm just raising awareness 
about the issue.

I'd personally lean toward patching R's curl downloads so they accept 
self-signed certificates.  Then R will work out of the box without 
impacting security anywhere else.

--
Earth is a beta site.