R install.packages() fails: 'Peer certificate cannot be authenticated with given CA certificates'

R install.packages() fails: 'Peer certificate cannot be authenticated with given CA certificates'

[myglc2]

With GuixSD user config ...

(use-package-modules
 base   ; glibc-utf8-locales
 ssh    ; mosh
 admin  ; tree
 aspell ; aspell-dict-en
 mail   ; notmuch mu isync
 statistics ; r
 emacs      ; emacs-ess
 certs      ; nss-certs
 )
(packages->manifest
 (list
  mosh
  tree
  aspell-dict-en ; because emacs doesn't find system install
  notmuch mu isync ; also building from git source but this gets run-time dependencies
  r emacs-ess
  r-devtools r-openssl r-stringr r-xml2 r-httr 
  )
 )

... if I try to install a CRAN package like this ...

install.packages("pROC")

... it fails like this ...

Warning: unable to access index for repository https://rweb.crmda.ku.edu/cran/src/contrib:
  cannot download all files
Warning messages:
1: In download.file(url, destfile = f, quiet = TRUE) :
  URL 'https://cran.r-project.org/CRAN_mirrors.csv': status was 'Peer certificate cannot be authenticated with given CA certificates'
2: package ‘pROC’ is not available (for R version 3.3.1) 

But if I "defeat" HTTPS like this ...

options(repos=
            c(
                CRAN = "http://cran.rstudio.com/"
            )
        )

... it works. I would prefer to use HTTPS, so here is the question:

How do I get R to present the CA certificates?

TIA - George

Full R session log is shown below.

***
R version 3.3.1 (2016-06-21) -- "Bug in Your Hair"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> options(STERM='iESS', str.dendrogram.last="'", editor='emacsclient', show.error.locations=TRUE)
> sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.utf8       LC_NUMERIC=C             
 [3] LC_TIME=en_US.utf8        LC_COLLATE=en_US.utf8    
 [5] LC_MONETARY=en_US.utf8    LC_MESSAGES=en_US.utf8   
 [7] LC_PAPER=en_US.utf8       LC_NAME=C                
 [9] LC_ADDRESS=C              LC_TELEPHONE=C           
[11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C      

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     
> install.packages("pROC")
Installing package into ‘/home/g1/R/x86_64-unknown-linux-gnu-library/3.3’
(as ‘lib’ is unspecified)
--- Please select a CRAN mirror for use in this session ---
Warning: failed to download mirrors file (cannot download all files); using local file '/gnu/store/7543j3zkn95i7ixlc9fdq9hj0zrk5yq8-r-3.3.1/lib/R/doc/CRAN_mirrors.csv'
HTTPS CRAN mirror 

 1: 0-Cloud [https]                2: Austria [https]             
 3: Belgium (Ghent) [https]        4: Chile [https]               
 5: China (Beijing 4) [https]      6: Colombia (Cali) [https]     
 7: France (Lyon 1) [https]        8: France (Lyon 2) [https]     
 9: France (Paris 2) [https]      10: Germany (Münster) [https]   
11: Iceland [https]               12: Italy (Padua) [https]       
13: Japan (Tokyo) [https]         14: Mexico (Mexico City) [https]
15: New Zealand [https]           16: Russia (Moscow) [https]     
17: Spain (A Coruña) [https]      18: Spain (Madrid) [https]      
19: Switzerland [https]           20: UK (Bristol) [https]        
21: UK (Cambridge) [https]        22: USA (CA 1) [https]          
23: USA (KS) [https]              24: USA (MI 1) [https]          
25: USA (TN) [https]              26: USA (TX) [https]            
27: USA (WA) [https]              28: (HTTP mirrors)              


Selection: 23
Warning: unable to access index for repository https://rweb.crmda.ku.edu/cran/src/contrib:
  cannot download all files
Warning messages:
1: In download.file(url, destfile = f, quiet = TRUE) :
  URL 'https://cran.r-project.org/CRAN_mirrors.csv': status was 'Peer certificate cannot be authenticated with given CA certificates'
2: package ‘pROC’ is not available (for R version 3.3.1) 
> q("no")

Process R finished at Thu Sep 29 19:07:12 2016
***

Re: R install.packages() fails: 'Peer certificate cannot be authenticated with given CA certificates'

[Ricardo Wurmus]

myglc2 <myglc2@gmail.com> writes:

> With GuixSD user config ...
>
> (use-package-modules
>  base   ; glibc-utf8-locales
>  ssh    ; mosh
>  admin  ; tree
>  aspell ; aspell-dict-en
>  mail   ; notmuch mu isync
>  statistics ; r
>  emacs      ; emacs-ess
>  certs      ; nss-certs
>  )
> (packages->manifest
>  (list
>   mosh
>   tree
>   aspell-dict-en ; because emacs doesn't find system install
>   notmuch mu isync ; also building from git source but this gets run-time dependencies
>   r emacs-ess
>   r-devtools r-openssl r-stringr r-xml2 r-httr 
>   )
>  )

You forgot to actually add “nss-certs” to the manifest.  After adding
“nss-certs” you need to set the environment variable CURL_CA_BUNDLE:

  export CURL_CA_BUNDLE=/home/rekado/.myglc2-profile/etc/ssl/certs/ca-certificates.crt

(I only recently patched r-curl to respect this environment variable.
We should patch libcurl so that all packages using libcurl understand
it.)

Now installation works.  Or rather: it fails with a different error :)
You should also make sure that your manifest contains a suitable build
environment, possibly including “gcc-toolchain”, “gfortran”, and “make”.

If you’re on a foreign distro it is important that you have
“gcc-toolchain” in the profile when you want to use install.packages
because there are quite a few R packages that build bindings to system
libs.  Our toolchain will refuse linking with system libs, but if you
use the system GCC and linker you will only notice breakage at runtime
when trying to use the package.  Our linker’s refusal to link to libs of
the host system is a blessing here, because it spares you the trouble of
runtime breakage later on.

(Better than “install.packages” is to use Guix with “r-*” packages
instead.  I’ll try to add more in the near future, so that it’s an
easier choice to make.)

BTW: you can simplify your manifest if you reference packages by name
instead of variable name.  I like to use suggest something like this for
users at the MDC because it looks cleaner:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(define packages '("r"
                   "emacs-ess"
                   "emacs"
                   "samtools@0"))

;; Boilerplate code to turn the above list of packages into a manifest
(use-modules (gnu packages))
(packages->manifest (map specification->package packages))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Note that these package names can include version prefixes as in
“samtools@0”, which will get me the latest version of the Samtools 0.x
series instead of the latest version.

~~ Ricardo

curl_ca_bundle, and gnurl?

[ng0]

Ricardo Wurmus <rekado@elephly.net> writes:

> myglc2 <myglc2@gmail.com> writes:
>
>> With GuixSD user config ...
……
>>  )
>
> You forgot to actually add “nss-certs” to the manifest.  After adding
> “nss-certs” you need to set the environment variable CURL_CA_BUNDLE:
>
>   export CURL_CA_BUNDLE=/home/rekado/.myglc2-profile/etc/ssl/certs/ca-certificates.crt
>
> (I only recently patched r-curl to respect this environment variable.
> We should patch libcurl so that all packages using libcurl understand
> it.)
>

I wonder if we need this for gnurl or if the code base of gnurl is still
curl-like enough that it respects the variable.. last time I tried gnurl
as a user on its own (which is *not* the intended use) was on Gentoo.
Gnurl is afaik not (yet) a gnu project and requires no sync with the gnu
descriptions.. I should add this to the description.

But can you share some insights why curl requires this? For gnurl I rely
on its test suite, but I think curl does not complain about the missing
CURL_CA_BUNDLE in its test suite either, or does it?

And if gnurl should require this, how could I fix gnurl (not the package
description in guix) to drop this strange behavior if it is possible at
all?

>
> ~~ Ricardo
>
>
>

Re: curl_ca_bundle, and gnurl?

[Ricardo Wurmus]

ng0 <ngillmann@runbox.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> myglc2 <myglc2@gmail.com> writes:
>>
>>> With GuixSD user config ...
> ……
>>>  )
>>
>> You forgot to actually add “nss-certs” to the manifest.  After adding
>> “nss-certs” you need to set the environment variable CURL_CA_BUNDLE:
>>
>>   export CURL_CA_BUNDLE=/home/rekado/.myglc2-profile/etc/ssl/certs/ca-certificates.crt
>>
>> (I only recently patched r-curl to respect this environment variable.
>> We should patch libcurl so that all packages using libcurl understand
>> it.)
>>
>
> I wonder if we need this for gnurl or if the code base of gnurl is still
> curl-like enough that it respects the variable.. last time I tried gnurl
> as a user on its own (which is *not* the intended use) was on Gentoo.
> Gnurl is afaik not (yet) a gnu project and requires no sync with the gnu
> descriptions.. I should add this to the description.

Looking at the sources and searching for “getenv” I see this:

…
gnurl-7_50_3/src/tool_operate.c:    env = curlx_getenv("CURL_CA_BUNDLE");
gnurl-7_50_3/src/tool_operate.c:      env = curlx_getenv("SSL_CERT_DIR");
gnurl-7_50_3/src/tool_operate.c:        env = curlx_getenv("SSL_CERT_FILE");
gnurl-7_50_3/gnurl--/src/tool_operate.c:    env = curlx_getenv("CURL_CA_BUNDLE");
gnurl-7_50_3/gnurl--/src/tool_operate.c:      env = curlx_getenv("SSL_CERT_DIR");
gnurl-7_50_3/gnurl--/src/tool_operate.c:        env = curlx_getenv("SSL_CERT_FILE");
gnurl-7_50_3/gnurl--/lib/Makefile.netware:	@echo $(DL)#define CURL_CA_BUNDLE getenv("CURL_CA_BUNDLE")$(DL) >> $@
gnurl-7_50_3/gnurl--/lib/curl_setup.h:#define CURL_CA_BUNDLE getenv("CURL_CA_BUNDLE")
gnurl-7_50_3/gnurl--/lib/vtls/nss.c:  cert_dir = getenv("SSL_DIR");
gnurl-7_50_3/gnurl--/lib/config-dos.h:#define CURL_CA_BUNDLE  getenv("CURL_CA_BUNDLE")
gnurl-7_50_3/lib/Makefile.netware:	@echo $(DL)#define CURL_CA_BUNDLE getenv("CURL_CA_BUNDLE")$(DL) >> $@
…

It looks like these common environment variables are indeed used for the
tool.  For the library it seems that the environment variable is only
respected when “config-dos.h” is used.  In other cases it’s a fixed file
path:

gnurl-7_50_3/src/Makefile:CURL_CA_BUNDLE = "/etc/ssl/certs/ca-certificates.crt"

So gnurl should also be patched to replace the definition of
CURL_CA_BUNDLE with “getenv("CURL_CA_BUNDLE")”.

> But can you share some insights why curl requires this? For gnurl I rely
> on its test suite, but I think curl does not complain about the missing
> CURL_CA_BUNDLE in its test suite either, or does it?

libcurl expects the user to configure the location of the bundle.  If
this does not happen it defaults to some hardcoded file path.  The
command line tool uses libcurl and overrides the value when the
environment variable CURL_CA_BUNDLE is set.

On Guix we cannot guarantee the existence of the hardcoded default path.
The bundle is not part of the curl package and we cannot presume to know
where the bundle file will be stored.  For per-profile certificates (a
user might want to distrust certain certificates, while another might
want to use the defaults) we should not hardcode this but defer the
decision to the CURL_CA_BUNDLE environment variable.

> And if gnurl should require this, how could I fix gnurl (not the package
> description in guix) to drop this strange behavior if it is possible at
> all?

It would be the same patch: we need to define CURL_CA_BUNDLE to be
“getenv("CURL_CA_BUNDLE)” instead of a fixed path.

~~ Ricardo

Re: curl_ca_bundle, and gnurl?

[ng0]

Hi,

Ricardo Wurmus <rekado@elephly.net> writes:

> ng0 <ngillmann@runbox.com> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> myglc2 <myglc2@gmail.com> writes:
>>>
>>>> With GuixSD user config ...
>> ……
>>>>  )
>>>
>>> You forgot to actually add “nss-certs” to the manifest.  After adding
>>> “nss-certs” you need to set the environment variable CURL_CA_BUNDLE:
>>>
>>>   export CURL_CA_BUNDLE=/home/rekado/.myglc2-profile/etc/ssl/certs/ca-certificates.crt
>>>
>>> (I only recently patched r-curl to respect this environment variable.
>>> We should patch libcurl so that all packages using libcurl understand
>>> it.)
>>>
>>
>> I wonder if we need this for gnurl or if the code base of gnurl is still
>> curl-like enough that it respects the variable.. last time I tried gnurl
>> as a user on its own (which is *not* the intended use) was on Gentoo.
>> Gnurl is afaik not (yet) a gnu project and requires no sync with the gnu
>> descriptions.. I should add this to the description.
>
> Looking at the sources and searching for “getenv” I see this:

Thanks for your reply. I'll see that I address the issue in the next
version release of gnurl. Prior to using GuixSD I wasn't aware of this,
and I do my test builds of gnurl on guixsd and gentoo to assure that
there's no mistake from either systems side.

> …
> gnurl-7_50_3/src/tool_operate.c:    env = curlx_getenv("CURL_CA_BUNDLE");
> gnurl-7_50_3/src/tool_operate.c:      env = curlx_getenv("SSL_CERT_DIR");
> gnurl-7_50_3/src/tool_operate.c:        env = curlx_getenv("SSL_CERT_FILE");
> gnurl-7_50_3/gnurl--/src/tool_operate.c:    env = curlx_getenv("CURL_CA_BUNDLE");
> gnurl-7_50_3/gnurl--/src/tool_operate.c:      env = curlx_getenv("SSL_CERT_DIR");
> gnurl-7_50_3/gnurl--/src/tool_operate.c:        env = curlx_getenv("SSL_CERT_FILE");
> gnurl-7_50_3/gnurl--/lib/Makefile.netware:	@echo $(DL)#define CURL_CA_BUNDLE getenv("CURL_CA_BUNDLE")$(DL) >> $@
> gnurl-7_50_3/gnurl--/lib/curl_setup.h:#define CURL_CA_BUNDLE getenv("CURL_CA_BUNDLE")
> gnurl-7_50_3/gnurl--/lib/vtls/nss.c:  cert_dir = getenv("SSL_DIR");
> gnurl-7_50_3/gnurl--/lib/config-dos.h:#define CURL_CA_BUNDLE  getenv("CURL_CA_BUNDLE")
> gnurl-7_50_3/lib/Makefile.netware:	@echo $(DL)#define CURL_CA_BUNDLE getenv("CURL_CA_BUNDLE")$(DL) >> $@
> …
>
> It looks like these common environment variables are indeed used for the
> tool.  For the library it seems that the environment variable is only
> respected when “config-dos.h” is used.  In other cases it’s a fixed file
> path:
>
> gnurl-7_50_3/src/Makefile:CURL_CA_BUNDLE = "/etc/ssl/certs/ca-certificates.crt"
>
> So gnurl should also be patched to replace the definition of
> CURL_CA_BUNDLE with “getenv("CURL_CA_BUNDLE")”.
>
>> But can you share some insights why curl requires this? For gnurl I rely
>> on its test suite, but I think curl does not complain about the missing
>> CURL_CA_BUNDLE in its test suite either, or does it?
>
> libcurl expects the user to configure the location of the bundle.  If
> this does not happen it defaults to some hardcoded file path.  The
> command line tool uses libcurl and overrides the value when the
> environment variable CURL_CA_BUNDLE is set.
>
> On Guix we cannot guarantee the existence of the hardcoded default path.
> The bundle is not part of the curl package and we cannot presume to know
> where the bundle file will be stored.  For per-profile certificates (a
> user might want to distrust certain certificates, while another might
> want to use the defaults) we should not hardcode this but defer the
> decision to the CURL_CA_BUNDLE environment variable.
>
>> And if gnurl should require this, how could I fix gnurl (not the package
>> description in guix) to drop this strange behavior if it is possible at
>> all?
>
> It would be the same patch: we need to define CURL_CA_BUNDLE to be
> “getenv("CURL_CA_BUNDLE)” instead of a fixed path.
>
> ~~ Ricardo
>
>

--