Re: curl_ca_bundle, and gnurl?

[ng0 <ngillmann@runbox.com>]

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
>
>

--