help-guix
[Top][All Lists]
Advanced

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

Re: curl_ca_bundle, and gnurl?


From: Ricardo Wurmus
Subject: Re: curl_ca_bundle, and gnurl?
Date: Fri, 30 Sep 2016 21:20:01 +0200
User-agent: mu4e 0.9.16; emacs 25.1.1

ng0 <address@hidden> writes:

> Ricardo Wurmus <address@hidden> writes:
>
>> myglc2 <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]