From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Van Ymeren Subject: Re: [bug#30165] [PATCH] gnu: gnurl: Add '--with-ca-bundle' path to configure-flags. Date: Wed, 24 Jan 2018 12:00:59 -0500 Message-ID: <878tcni438.fsf@vany.ca> References: <87h8rchvfs.fsf@vany.ca> <87fu6v1njc.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> <87d11zv19n.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eeOQ6-0006zf-Hw for guix-devel@gnu.org; Wed, 24 Jan 2018 12:01:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eeOQ1-0006Qj-Lb for guix-devel@gnu.org; Wed, 24 Jan 2018 12:01:06 -0500 Received: from mail2.vany.ca ([142.54.190.254]:60062) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eeOQ1-0006Q7-Gi for guix-devel@gnu.org; Wed, 24 Jan 2018 12:01:01 -0500 In-Reply-To: <87d11zv19n.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: ng0@n0.is Cc: guix-devel@gnu.org 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/