On Wed, 24 Jan 2018, Adam Van Ymeren <a...@vany.ca> wrote: > n...@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 ;).
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. Not that we make it obsolete and people really use it. I have no problem with long-term maintenance. > 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. > 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. > 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. >>> 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. Nope, they aren't. Hm. Curious. > 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. 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? Thanks! >>> >>> In the meantime you could send a patch to revert my commit. -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
