From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id sCRuA8lWYmIezgAAbAwnHQ (envelope-from ) for ; Fri, 22 Apr 2022 09:18:33 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id WBSBA8lWYmIeLgEA9RJhRA (envelope-from ) for ; Fri, 22 Apr 2022 09:18:33 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 4D7989683 for ; Fri, 22 Apr 2022 09:18:32 +0200 (CEST) Received: from localhost ([::1]:49808 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhnYl-0007AY-CZ for larch@yhetil.org; Fri, 22 Apr 2022 03:18:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55916) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhnYI-00079D-Lr for bug-guix@gnu.org; Fri, 22 Apr 2022 03:18:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:57451) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nhnYI-0002R6-Ce for bug-guix@gnu.org; Fri, 22 Apr 2022 03:18:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nhnYI-0005lR-38 for bug-guix@gnu.org; Fri, 22 Apr 2022 03:18:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#55043: Some packages depend on nss-certs, some bundle it. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 22 Apr 2022 07:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55043 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxime Devos , 55043@debbugs.gnu.org Received: via spool by 55043-submit@debbugs.gnu.org id=B55043.165061187522141 (code B ref 55043); Fri, 22 Apr 2022 07:18:02 +0000 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> From: Liliana Marie Prikler 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-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1650611912; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=D1npHbHjTg0bh4RlNn80qOR2QynkEFTvFQIXJcDFyBY=; b=cUi+ndyUo0NbjxKMbKrR8eDVGy6gwkroT6aHApQkgDG09+K3a8+ILtBiIWJlFYwWV95fnn 6ubhRhLy3ud52T1O35uCiGcd1rN9m/rpKGGSzYE67IFB41bk6HRfvoGMIWRTK+DKqvDqpe CRfZ79dCwG9DRctii1bL8/Fe6d85zWkpGoztdBuFXsWvf1M+1q6gxw9m/uyL+7xZEOBPMv cttoZvG9Osnqk19208Yebh9eOj2bcZlT07sdmh4YeiV6oH2vPCPBPL57ScP/t3LwMGlST4 5HLS86v01MF2cqXl+enLQ0SJs2DMvwhp1FncNa9rNrTO7QTbU6tI+lCP4QdaRg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1650611912; a=rsa-sha256; cv=none; b=Kp/LO7/jNOTRRiiCPU1PBjyMf3f8cVY2WIPR2eg9HMe3r4/gOkFnFv3Jkq8N01btzXtekH c+ZO0NNUppA8xBZG+Tayu93B+XN27XgHVlmAoSHEgyDQ7y3XDrJE3NLCxPlInqtH4MWxIZ SMBwIQ0eZgpHE6fo4fhKUFgcaGwPaKrOaDcQAlnUYjY2Yjg26bKwWmLHKv8idCllLtcUpq gUiyzCgIy/mXgrMbteFFcX3rdvL6UB4tyj7gz0AEAXHoLrKqS3sA42pgd6wYldD97nLj0j 4wTeL556v/16X/mpGfndZE2QrFnsU5ltobi6E+9R6ekm6vVi+ms/yEdEk2mSUA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=AYgGkdWd; dmarc=fail reason="SPF not aligned (relaxed)" header.from=tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 4.97 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=AYgGkdWd; dmarc=fail reason="SPF not aligned (relaxed)" header.from=tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 4D7989683 X-Spam-Score: 4.97 X-Migadu-Scanner: scn0.migadu.com X-TUID: 5EfpoAS5Bwdb 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