pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: R certificate issue

On 06/16/17 01:38, 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
Linux sciprog2.ceas bacon ~ 435: (pkgsrc): curl curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here:

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 | 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","","Automatic redirection to servers worldwide, currently sponsored by Rstudio","winston #",1,"us","secure_mirror_from_master" "0-Cloud","0-Cloud","0-Cloud","","Automatic redirection to servers worldwide, currently sponsored by Rstudio","winston #",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.

Home | Main Index | Thread Index | Old Index