Re: GnuTLS and the “trust store”

[Ludovic Courtès]

Ricardo Wurmus <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>
>> Ricardo Wurmus <address@hidden> skribis:
>>
>>> Marius Bakke <address@hidden> writes:
>>>
>>>> Curl respects the variable "CURL_CA_BUNDLE". I think we could add a
>>>> "native-search-path" for that, similar to how it's done for "git".
>>>
>>> “curl” does but libcurl does not.
>>
>> But that’s probably on purpose.  What do the cURL developers recommend
>> for their users?
>>
>> If they recommend that users roll their own mechanism to designate the
>> trust store, then they probably do (?), and I think we should avoid
>> interfering with that.
>
> I don’t know what they recommend but on an FHS-compliant system libcurl
> would be configured to default to a well-known path for the default CA
> bundle.  This allows users of libcurl to just not care about
> implementing a mechanism to override the default CA bundle, because it
> would fall back to the well-known system-wide path.

That’s also the case with Guix: GnuTLS looks for things in
/etc/ssl/certs by default, doesn’t it?

> One of these packages is “r-curl”, which just assumes that the libcurl
> defaults are fine.  We patch it to enable CURL_CA_BUNDLE lookup (a
> feature that was intended only for Windows).

So r-curl doesn’t try /etc/ssl/certs?  That makes me wonder if the
--with-default-trust-store-dir option of GnuTLS works as expected.

> Since GuixSD does not offer this path and Guix can be used on different
> systems I think we need to provide an alternative.  One alternative is
> to replace the well-known path with a call to getenv("CURL_CA_BUNDLE").

OK.

Ludo’.