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

[ng0@n0.is]

> Sorry, my email went out-of-order for the past 7 days.
> I would've sent an explanation to the patch otherwise.
> Let me comment inline.
>
> adam@vany.ca transcribed Tue 23 Jan 2018 08:55:35 PM UTC bytes:
>> Regarding https://debbugs.gnu.org/30165
>>
>> gnurl is failing to build on my system and I think this patch is to
>> blame.  Why is gnurl referencing something under the root filesystem
>> rather something provided by an input?  Shouldn't we provided
>> ca-certificates.crt from an input and reference that?
>
> 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.

I'll try that on the weekend at the CI and at home.
Alternative solutions with reference to the original cURL issue
bug in Guix are still welcome.

If we haven't fixed that for cURL in core-updates, as I thought
we had when I read the thread that inspired me for this fix:
Why? Why are we waiting for months and months and months to
patch every single application instead of simply fixing cURL
or our build of cURL and close this case?

On the plus side, once we know which configuration this bug
occurred with, we know that cURL could fail in a similar way ;)

>> disable the relelvant tests.
>>
>> For reference the build error I'm seeing is
>> ==========================
>> test 0324...[TLS-SRP with server cert checking]
>>
>> curl returned 77, when expecting 51
>>  exit FAILED
>>
>>  - abort tests
>>
>> =========================
>
> Wild. For what it's worth, I built this before I've sent a patch
> and it passed all of its relevant testsuites. I didn't get this
> error.
>
>> From the curl man page, exit code 77 means "Problem with reading the SSL
>> CA cert (path? access rights?)."
>
> 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.
>
> In the meantime you could send a patch to revert my commit.

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/