From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 20 11:23:13 2022 Received: (at submit) by debbugs.gnu.org; 20 Apr 2022 15:23:13 +0000 Received: from localhost ([127.0.0.1]:47094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhCAj-0006q7-8e for submit@debbugs.gnu.org; Wed, 20 Apr 2022 11:23:13 -0400 Received: from lists.gnu.org ([209.51.188.17]:52212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhCAh-0006pz-6p for submit@debbugs.gnu.org; Wed, 20 Apr 2022 11:23:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39684) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhCAg-0002gT-FK for bug-guix@gnu.org; Wed, 20 Apr 2022 11:23:11 -0400 Received: from baptiste.telenet-ops.be ([2a02:1800:120:4::f00:13]:35322) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nhCAe-0007Za-2R for bug-guix@gnu.org; Wed, 20 Apr 2022 11:23:10 -0400 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by baptiste.telenet-ops.be with bizsmtp id M3P32700u4UW6Th013P3Hb; Wed, 20 Apr 2022 17:23:03 +0200 Message-ID: <2e58ada4430ad222c4bc392971edb014c5f10440.camel@telenet.be> Subject: Some packages depend on nss-certs, some bundle it. From: Maxime Devos To: bug-guix@gnu.org Date: Wed, 20 Apr 2022 17:22:53 +0200 Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-JgLBkj2s7xrJVf21HVOK" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1650468184; bh=AwrmVyj0vZuIs6kGULeuJmEjNsp+EXMAbUDeorBMxhk=; h=Subject:From:To:Date; b=id99yMd5bvuKJ7RYlsVsiiSnzqKlo6UpxS0uzORVVre+owTdx4YVLOAhtKjONe3e7 7MGlmBrv5YzHGk/VlokYtATbq8yzaKodGWoucvYiC8MAlv/hR3/6BaBT7B2ajeLp87 zSQabmDarW3dM5+77GljM66Mc5ZAowjDJdbbtTP9AInSouOdwXojIxUUO104rwadad ELm+zZoagMiqNRs0WQijGdUvjopqXZMbj4A0L7JzPVBz+NeJ0uu0BHpirCbShA/mRc bR8CDmlWH7G1UbG1xd5kAO0C0re8mKoE7V8iGZBx9hL5I0VnuhO3QTw3mnESUTPkSR NAypnSa7ehPCg== Received-SPF: pass client-ip=2a02:1800:120:4::f00:13; envelope-from=maximedevos@telenet.be; helo=baptiste.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-JgLBkj2s7xrJVf21HVOK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Debbugs-CC: Hartmut Goebel Hi, There are some packages bundling CA certificates: * nss-certs / le-certs (this one is not a problem) * python-certifi * perl-mozilla-ca * rust-webpki-roots * erlang-certifi (not yet, see ) * go-github-com-certifi-gocertifi Worse, these packages have many dependencies! $ guix refresh -l nss-certs le-certs python-certifi perl-mozilla-ca rust-webpki-roots=C2=A0 Het bouwen van het volgende 534 pakketten zorgt ervoor dat 1575 afhankelijk= e pakketten opnieuw worden gebouwd: ... Why is this a problem? * I don't think that anybody is actually looking into keeping python-certifi / perl-mozilla-ca / rust-webpki-roots / ... up to date. Security problems! * Even so, this seems a waste of time to me, why not just use $SSL_CERT_DIR / $SSL_CERT_FILE instead? * Lots of rebuilds to update things. * (relatively minir) Allowing overriding the certificates trusted with $SSL_CERT_DIR / $SSL_CERT_FILE would be nice. Also relevant to the third point: some packages depend on nss-certs. I've heard an argument in favour of just using the certifi packages instead of using our own certificates: > (from Hartmut Goebel, at ) > Neither python-certifi nor gocertifi build on nss-cert. Addind some=20 > update mechanism into the Guix package is not a good idea IMO: This=20 > would make =E2=80=9Cerlang-certif@2.9.0=E2=80=9C contain different certif= icates > than the release 2.9.0, making debugging a hell. ... but I don't follow, it's just a different set of certificates, could you elaborate?=20 Proposal: * eventually remove python-certifi, perl-mozilla-ca, ... because nobody appears to be keeping them up-to-date and for security it is important for them to be up to date. =20 * likewise, forbid new packages from being included as-is if they depend o= n a certifi package or nss-certs. * Look into removing the certifi packages from the inputs of packages, submitting patches to upstream for using $SSL_CERT_... / /etc/ssl/certs = ... as appropriate. Upstream issues and patches I'm aware of: * (python-requests, bug report): https://github.com/psf/requests/issues/29= 66 * (rebar3, bug report + patch): https://github.com/erlang/rebar3/issues/26= 96, https://github.com/erlang/otp/pull/5853 Greetings, Maxime. --=-JgLBkj2s7xrJVf21HVOK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYmAlTRccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7jJzAP48lbafYOoc3moZJ4UAQmu9h3e7 Fr4Sfh0hHW04VTyzIwD/ZjyenrNRBsUDeYAQ7yxogchjQpo53f4vA3nHwnTkbAI= =TpFj -----END PGP SIGNATURE----- --=-JgLBkj2s7xrJVf21HVOK-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 22 03:17:54 2022 Received: (at 55043) by debbugs.gnu.org; 22 Apr 2022 07:17:55 +0000 Received: from localhost ([127.0.0.1]:51348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhnYA-0005l2-BD for submit@debbugs.gnu.org; Fri, 22 Apr 2022 03:17:54 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:16607) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhnY7-0005ks-T7 for 55043@debbugs.gnu.org; Fri, 22 Apr 2022 03:17:52 -0400 Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4Kl5Mt1Fcpz3xcH; Fri, 22 Apr 2022 09:17:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1650611866; bh=D1npHbHjTg0bh4RlNn80qOR2QynkEFTvFQIXJcDFyBY=; h=Subject:From:To:Date:In-Reply-To:References; b=AYgGkdWdyRFNVh4QY+tGIr9HXt8sWlkOTz9UiHBXtdiwDqDTF1+R3SVPLzBj7RNaO i2/mHODxNDFkpJdeadqcQxhziBpkDVwzuonzXYTrQfybiPm3LWDv5CTC/pN96O49IE 9lL81/6xL7gFCoMP1deiM/y9OA2oiQ3vSnGMrLjw= Message-ID: <47c8a97f7d76b08a4164829861a6fc74ac49a104.camel@ist.tugraz.at> Subject: Re: Some packages depend on nss-certs, some bundle it. From: Liliana Marie Prikler To: Maxime Devos , 55043@debbugs.gnu.org Date: Fri, 22 Apr 2022 09:17:45 +0200 In-Reply-To: <2e58ada4430ad222c4bc392971edb014c5f10440.camel@telenet.be> References: <2e58ada4430ad222c4bc392971edb014c5f10440.camel@telenet.be> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55043 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Am Mittwoch, dem 20.04.2022 um 17:22 +0200 schrieb Maxime Devos: > X-Debbugs-CC: Hartmut Goebel > > Hi, > > There are some packages bundling CA certificates: > >  * nss-certs / le-certs (this one is not a problem) >  * python-certifi >  * perl-mozilla-ca >  * rust-webpki-roots >  * erlang-certifi (not yet, see > ) >  * go-github-com-certifi-gocertifi > > Worse, these packages have many dependencies! > > $ guix refresh -l nss-certs le-certs python-certifi perl-mozilla-ca > rust-webpki-roots  > Het bouwen van het volgende 534 pakketten zorgt ervoor dat 1575 > afhankelijke pakketten opnieuw worden gebouwd: ... This is only if you update all of them at once. An update to any one of them might go to staging instead, which for the record I don't see merged too often in recent times. Also, with the exception of our snowflake static linkers Rust and Go, we should be able to graft them on master. > Why is this a problem? > >  * I don't think that anybody is actually looking into keeping >    python-certifi / perl-mozilla-ca / rust-webpki-roots / ... >    up to date.  Security problems! >  * Even so, this seems a waste of time to me, why not just use >    $SSL_CERT_DIR / $SSL_CERT_FILE instead? Point taken, I think these might just be different programming language implementation that essentially store the same certificate in a known location and then refer to it. Which Guix can already do by specifying SSL_CERT_DIR or SSL_CERT_FILE in a wrapper script. >  * Lots of rebuilds to update things. >  * (relatively minir) Allowing overriding the certificates trusted > with >    $SSL_CERT_DIR / $SSL_CERT_FILE would be nice. I don't think SSL_CERT_DIR and SSL_CERT_FILE customization is useful in all apps however. I think there is a legitimate concern, that users could be tricked into downloading a malicious certificate chain and then running their instant messaging app with that, enabling a man in the middle attack. Again, Guix could solve this by hardcoding SSL_CERT_*, but... > Also relevant to the third point: some packages depend on nss-certs. We'd be increasing this number if instead of language-specific certifi packages, we consolidated them into nss-certs. On the other hand, we would be reducing the number of dependents in libraries that don't need to hardcode certs for security reasons, so perhaps life will become easier at some point. Also, w.r.t. updating nss-certs, since we do have grafts, security updates should not be a concern in my opinion. Making sure that all our security-critical instant messaging applications use our trusted bundle rather than their own very curated set is of higher priority in my opinion. > I've heard an argument in favour of just using the certifi packages > instead of using our own certificates: > > > (from Hartmut Goebel, at ) > > Neither python-certifi nor gocertifi build on nss-cert. Addind some > > update mechanism into the Guix package is not a good idea IMO: This > > would make “erlang-certif@2.9.0“ contain different certificates > > than the release 2.9.0, making debugging a hell. > > ... but I don't follow, it's just a different set of certificates, > could you elaborate? >From a library/app developer's point of view, you can't rely on the system certificate store if your system's vendor starts with M, ends with t and has 7 letters in between. I'm not sure how missing erlang- certif would impact building any of its packages, but perhaps they found a way to break builds if some certificate is missing. > Proposal: > >  * eventually remove python-certifi, perl-mozilla-ca, ... because > nobody appears to be keeping them up-to-date and for security it > is important for them to be up to date. Sure. In the meantime, however, I'd suggest mocking them by having them simply return nss-certs or whatever else we have for a trusted certificate bundle. >  * likewise, forbid new packages from being included as-is if they > depend on a certifi package or nss-certs. See above. >  * Look into removing the certifi packages from the inputs of > packages, submitting patches to upstream for using $SSL_CERT_... / > /etc/ssl/certs ... as appropriate. That I agree with. Cheers From debbugs-submit-bounces@debbugs.gnu.org Wed May 25 03:26:58 2022 Received: (at 55043) by debbugs.gnu.org; 25 May 2022 07:26:58 +0000 Received: from localhost ([127.0.0.1]:54187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ntlQ1-00032C-Sr for submit@debbugs.gnu.org; Wed, 25 May 2022 03:26:58 -0400 Received: from mout.kundenserver.de ([217.72.192.74]:43505) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ntlPx-00031w-Q4 for 55043@debbugs.gnu.org; Wed, 25 May 2022 03:26:56 -0400 Received: from hermia.goebel-consult.de ([79.211.177.11]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MLyvH-1oB1Jk0Tz7-00HtIm; Wed, 25 May 2022 09:26:45 +0200 Received: from [192.168.110.2] (lenashee.goebel-consult.de [192.168.110.2]) by hermia.goebel-consult.de (Postfix) with ESMTP id 3694B5F535; Wed, 25 May 2022 09:26:42 +0200 (CEST) Content-Type: multipart/alternative; boundary="------------gH9vyS0NaLL0gqU6uqhA0KF1" Message-ID: <59b9644f-d5b4-3e85-a4a5-c44c1b204983@crazy-compilers.com> Date: Wed, 25 May 2022 09:26:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: Maxime Devos , 55043@debbugs.gnu.org, Liliana Marie Prikler References: <2e58ada4430ad222c4bc392971edb014c5f10440.camel@telenet.be> From: Hartmut Goebel Organization: crazy-compilers.com Subject: Re: bug#55043: Some packages depend on nss-certs, some bundle it. In-Reply-To: <2e58ada4430ad222c4bc392971edb014c5f10440.camel@telenet.be> X-Provags-ID: V03:K1:QlNFMJ3Tu7xgzSP9t1uZjRSwR/mj0aOj2li0lYkPnsdpj4X3xmB 8EtHFmroPF/JU9AJQa1hMCO+ridRpQQ7ZuxzvifKHLqpJ86xG74EuaShYPtNzlEEHzwjAh6 oVe9XjiPY7cX71fpNP0YmOXbMDKHz76wZM7uf2go5c14X7Ayigz7fafC6wfIyUoo2XccR00 msKn/IVYqOARYHON8XpBw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:OVAN6vyhnxg=:qHGGWXRCGVxAyahaIB67GT BvQZq1rcsYaNfmJ5KstxXBXxy54yMSLAJBPuYsT1aaHKKkeZO+pAza057jhtYEbihTqylxwr/ LvfqAym4pvc+dh1Cke61NSEeF41aeIoMcXUlteJc6MW3yZZIgJU0MhahIY1r4pXLFkMKU2jbZ m40+SOltjgba+PBH2PWzWUoJracquEEMVH4XDUHeoj/SZQqxEE4FcJrv+ldlE20o4xTNZecSd bAcpHl/5WINGPpwUR+vL3/rPxeRPs4GNbJUrQX/miCZAG78Dz2MN4kt3XYO+z4bC616EPy8sW KtApKk+WVuTr8DlHGUBPAH5moPkpU6nK5wtz8XG9w/fS7fwD+jLLZ5D3+JPC85AxmF46mq0t4 zJnXjupud+cO2OlClTpdWQd6CHL5y7LKtrElVHLA1DQ8TKEYFNvVQa8JKVT6WeSIOog+lZE8z TV9ORbyw13FmTF7koXAfhCxGrpX6cNiZJkheKAjfC7zhDeoysML9dNKyT94qD/zqGgRMV6hWC TKUWPEP9EQiaZ0oCjR4MJlySmxHoJrxTtPA+/5vo7lBdAWwIC6kmwyfiYynnIYZ6Bu1fU0dsP zIg0RdUAN3BMNlduJGt7ankolFngKhmV2vV7e7SMOp2futiNsNJtZltcfzpGH4rMgZM9zpJlA UJnCZVRZ1bk1dBbz3Beo1Wvdp6G6h5MCEuFe5HgB93hCLlh7LuYXD+gqOe1TiXJc8M7caia9N ETtSuCKkkdCAmk2LCckV23lgngW+hdjUqVpCY93ULsTQPpk4FpY9DcDfrUk= X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55043 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------gH9vyS0NaLL0gqU6uqhA0KF1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Am 20.04.22 um 17:22 schrieb Maxime Devos: >> (from Hartmut Goebel, at) >> Neither python-certifi nor gocertifi build on nss-cert. Addind some >> update mechanism into the Guix package is not a good idea IMO: This >> would make “erlang-certif@2.9.0“ contain different certificates >> than the release 2.9.0, making debugging a hell. > ... but I don't follow, it's just a different set of certificates, could > you elaborate? This argument is just about keeping the actual content of a package aligned with the content of the official release. This is a is less impotent argument then what I wrote in : > All these contain a copy of the/a CA > bundle — which is the idea of these packages: „useful for systems that > do not have CA bundles“. Anyhow: Your proposal is to make upstream packages get rid of these bundles. Will this being quite some work. An alternative approach could be to patch these packages, much like Liliana suggested („mock“). -- Regards Hartmut Goebel | Hartmut Goebel |h.goebel@crazy-compilers.com | |www.crazy-compilers.com | compilers which you thought are impossible | --------------gH9vyS0NaLL0gqU6uqhA0KF1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Am 20.04.22 um 17:22 schrieb Maxime Devos:
(from Hartmut Goebel, at <https://issues.guix.gnu.org/54796#52>)
Neither python-certifi nor gocertifi build on nss-cert. Addind some 
update mechanism into the Guix package is not a good idea IMO: This 
would make “erlang-certif@2.9.0“ contain different certificates
than the release 2.9.0, making debugging a hell.

... but I don't follow, it's just a different set of certificates, could
you elaborate?

This argument is just about keeping the actual content of a package aligned with the content of the official release. This is a is less impotent argument then what I wrote in <https://issues.guix.gnu.org/54796#52>:

All these contain a copy of the/a CA
bundle — which is the idea of these packages: „useful for systems that
do not have CA bundles“.

Anyhow: Your proposal is to make upstream packages get rid of these bundles. Will this being quite some work.

An alternative approach could be to patch these packages, much like Liliana suggested („mock“).

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |
--------------gH9vyS0NaLL0gqU6uqhA0KF1--