Re: [PATCH] gnu: r-curl: Respect CURL_CA_BUNDLE variable.

[Ricardo Wurmus]

Leo Famulari <address@hidden> writes:

> On Tue, Sep 13, 2016 at 11:53:33PM +0200, Roel Janssen wrote:
>> This patch was essential to me being able to interact with HTTPS urls in
>> R.  As far as I understand, by default, R only looks for CURL_CA_BUNDLE
>> on Windows, but with this patch it looks for CURL_CA_BUNDLE on GNU/Linux
>> as well.  Is this correct?
>> 
>> I can confirm it works for me, so I'd like to see this patch pushed.
>
> It's good to hear that it works, but I still think we should run it by
> the upstream maintainers. We are activating C code that they
> specifically decided not to use on GNU / Linux. Why did they do that?

The comments in the code indicate that on Windows they try to load the
certs bundle that comes with R for Windows, i.e. in the R HOME’s “etc”
directory.  There is no such file on GNU, so no special handling is
needed.

On GNU this is taken care of by libcurl.  It comes with a default path
to the certs bundle, which can be overridden with configure flags
(“--with-ca-bundle” or “--with-ca-path”).  In our Guix package we don’t
do this (yet?), so by default SSL cert validation is broken.

libcurl does not respect CURL_CA_BUNDLE; it assumes that the application
will override the CA bundle path if it needs a special path, otherwise
it assumes that the default path is fine (using Guix this is not the
case).

The maintainers of the R curl package made the special case for Windows
because it is not needed on GNU systems following the FHS.  The best fix
here would be to patch libcurl such that it checks the CURL_CA_BUNDLE
environment variable invariably, just like the curl command line tool
does.  Until this is done I think we should path packages such as
r-curl to make them usable.  Once we have agreed on a fix to libcurl we
can remove all patches to individual packages using libcurl.

~~ Ricardo