Re: [bug#30165] [PATCH] gnu: gnurl: Add '--with-ca-bundle' path to configure-flags.

[Adam Van Ymeren <adam@vany.ca>]

ng0@n0.is writes:

>> The problem I'm trying to address is the same horror story we
>> have with cURL: We need to be able to reference a certificate
>> store.
>> So far no one in 2+ years fixed this in our cURL to my best
>> knowledge, so my idea as a maintainer of gnURL was to simply
>> apply this to gnURL because someone in GNUnet reported errors
>> with regards to gnURL not finding the certificates with a recent
>> build of gnURL. I though I had this fixed a while ago, but
>> apparently I didn't.
>> I'm more than open to better fixes (we could also set the
>> expected environment variable).
>
> Another path forward I see is that I recommend every distro
> to set this path for themselves. We haven't fixed the Guix
> and GuixSD issue with this, but that's something I need to
> adjust for the upcoming release.
>
>
>>> I guess we want to be able to to change what certificates that gnurl
>>> accepts without rebulding the package, but I think we need something to
>>> provide that file when building the package in the first place, or
>>
>> What you seem to want is the env. variable solution.

All I really want is to be able to update my system ;).

I think an env. variable solution makes sense.  We already have
machinery for this in place with how packages can provide "search paths"
for other environment variables.  Perhaps the same should be applied to
SSL certificates.

Referencing some file on the root filesystem does not feel very
functional to me.  That becomes system specific mutable state, which
certainly shouldn't be an input to the build/test process.  For the
purposes of the test, gnurl should be providing an embedded certificate
store inside its own package that it runs tests against, otherwise the
tests are going to be prone to flaky failure like this.

If we want to refernce /etc/ssl/certs for use on non GuixSD distros,
then I think we should make sure that that directory is populated on
startup from the operating system profile on activation.

>> May I ask what system you are building on? I have a GuixSD-only
>> setup here. Next time I'll wait for the CI to finish building
>> (Debian based). I'm in the middle of releasing gnURL 7.58.0 and
>> preparing for a test that I have tomorrow, followed by some
>> social appointments afterwards, so I'll be able to start working
>> on a real fix on the weekend.

I'm building on GuixSD only as well.  I'm building from a git checkouts
with a few local changes to add/update packages I'm working on
(strongswan/python-axolotl) neither of which I believe are inputs to
gnurl.

It's pretty concerning that we're getting different results for building
gnurl, such a thing should be impossible or at least incredibly rare
with a purely function package manager.

Checking hydra.gnu.org, gnurl is failing there as well for i686 and
x86_64 but for different reasons.  It's failing because unbound is
failing which is an input to gnutls-dane which is an input to gnurl.

https://hydra.gnu.org/build/2453496



>>
>> In the meantime you could send a patch to revert my commit.
>
> -- 
> ng0 :: https://ea.n0.is
> A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/