ng0@n0.is writes:

>
> Out of curiosity: Where do you use gnURL in the system? For
> normal user experience it was never intended (though it would
> work). It would be nice to know if another project depends on it,
> as we've started looking into wget2 as a successor to cURL for
> GNUnet.

I don't actually use it directly, but it's an input for gnunet which I
like to play with from time to time, so I need gnurl to build for gnunet
to build.

>
>> 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.
>
> https://curl.haxx.se/docs/sslcerts.html what applies is this +
> some grepping through the cURL source and reading it.
>
> probably useful TIL of this whole issue: cURL could suffer the
> same issue if we try this, and I need to test all the options.

I think the patch you did of setting
--with-ca-bundle=/etc/ssl/certs/ca-certificates.crt is reasonable as it
lets gnURL use the operating system level cert store..

I think the root problem is that the gnURL tests the gnURL/cURL tests
are not self contained and depend upon this setting rather for tests
rather than using an embedded cert store during testing.

>
>> 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.
>
> That really is a cURL specific bug though. I wouldn't mind
> extending gnURL where it makes sense, but due to the high speed
> chase with cURL it is difficult.

Yes this is definitely a bug with upstream cURL tests, and a fix for
that should be submitted upstream if anyone makes one.

>
>> 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.
>
> ... with the only problem that operating-system profile
> activation does not exist (yet ;)?) for other systems, iirc.

I may not have been clear.  I meant if we want to have gnURL reference
this directory so that it works nicely on non GuixSD systems, then we
should also make sure that it _is_ provided on GuixSD systems.  And I
think it should be provided on GuixSD at operating system activation
time, so it remains a part of the purely functional system rather than
some mutable state that could get out of date or corrupted.

>> 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
>
> Damn. I'll look into it as soon (or slow) as I can. Time is
> limited atm.

No rush, I can work around it for now :).  Thanks for your hard work
maintaining this.

>
> Thanks for your reply so far. I'll also look into spinning up
> some addition gitlab CI jobs to see if I can replicate what we
> encountered.
> We don't have GuixSD runners yet, but some people on our side are
> working on it.
>
> If you have more, like build logs etc would you like to send them
> in here, open a bug on our (GNUnet) Mantis instance or send them
> to the gnunet bugs list?

I've attached a build log to this message in case it helps :).