From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id oB9VIm/OHl84ZgAA0tVLHw (envelope-from ) for ; Mon, 27 Jul 2020 12:54:07 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id WF07Hm/OHl+PAwAA1q6Kng (envelope-from ) for ; Mon, 27 Jul 2020 12:54:07 +0000 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 24D91940668 for ; Mon, 27 Jul 2020 12:54:07 +0000 (UTC) Received: from localhost ([::1]:48596 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k02dq-0001Pj-0q for larch@yhetil.org; Mon, 27 Jul 2020 08:54:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k02dh-0001NA-TR for guix-devel@gnu.org; Mon, 27 Jul 2020 08:53:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56366) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k02dg-0001zd-PJ; Mon, 27 Jul 2020 08:53:56 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=40078 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k02df-00040p-Tu; Mon, 27 Jul 2020 08:53:56 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Justus Winter Subject: Re: Securing the software distribution chain References: <87blk6wkug.fsf@europa.jade-hamburg.de> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 10 Thermidor an 228 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Mon, 27 Jul 2020 14:53:53 +0200 In-Reply-To: <87blk6wkug.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Thu, 23 Jul 2020 13:07:35 +0200") Message-ID: <87ime9w23i.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: TQJD2dxeyviB Hi Justus! Justus Winter skribis: >> Before submitting a patch that adds or modifies a package definition, >> please run through this check list: >> >> 1. If the authors of the packaged software provide a cryptographic >> signature for the release tarball, make an effort to verify the >> authenticity of the archive. For a detached GPG signature file this >> would be done with the gpg --verify command. > > For me, this is a tooling problem. 'guix download' should authenticate > the downloaded artifact before it computes and prints the hashsum. > There are two problems to solve: It needs to locate the signature, and > it has to know the set of cryptographic identities eligible to create > the signature. Note that =E2=80=98guix refresh -u=E2=80=99 and =E2=80=98guix import gnu=E2= =80=99 (and maybe other importers too?) take care of tarball authentication already. =E2=80=98guix download=E2=80=99 could share part of the mechanism. I agree it would be n= ice. > For some transports, like git, locating the signatures is not a problem, > but for http, there is just no standard on where the detatched signature > is located, or even what data it is computed over (for example, > kernel.org signs the uncompressed tarball). Yes, (guix upstream), which is what =E2=80=98guix refresh -u=E2=80=99 uses,= takes care of the kernel.org =E2=80=9Cspecial case=E2=80=9D. > So I think two things need to happen before this step can be improved: > The package metadata should include the URL of the signature and a set > of cryptographic identities eligible for signing the artifact. The idea of storing cryptographic metadata directly in has been discussed a few times: https://lists.gnu.org/archive/html/help-guix/2016-08/msg00132.html https://lists.gnu.org/archive/html/guix-devel/2015-10/msg00118.html https://git.savannah.gnu.org/cgit/guix.git/tree/TODO?id=3D6b8875c838d6377= 73813899b35a9b5ea4acfd146#n29 To me, the biggest shortcoming of this approach is if this metadata is primarily =E2=80=9Cornamental=E2=80=9D: if in practice, =E2=80=98guix build= -S=E2=80=99 doesn=E2=80=99t use it (and it has no reason to use it), then that metadata is likely to become stale without anyone noticing. Of course we could have additional tools to make use of that info, say =E2=80=98guix build -S --authenticate=E2=80=99 or something. But that woul= d still be optional. > Thinking a bit more about having a hashsum as part of the packaging > definition, it seems to me that this is a bit of a modelling error. > Because there is no standardized way of authenticating a source > distribution, Guix defers this step to the packager. And if there is no > way to authenticate an artifact (because upstream doesn't provide > signatures), we at least get TOFU, i.e. the assurance that any user > gets the same artifact as the packager. > > This doesn't seem terribly problematic, but it doesn't support parts of > the artifact changing, because in this model, this cannot be > distinguished from an attack. Is there a way an artifact may change in > a valid way that Guix (and other distributions) may want to support? What do you mean? If, for example, a tarball is modified in-place upstream, it=E2=80=99s an error from Guix=E2=80=99 viewpoint. > We believe there is. We propose to solve the problem of locating the > signatures by bundling them with the source distribution. Instead of > using a detached PGP signature, we want to distribute the source as a > signed PGP message. > > Now, if you compute a hashsum over such an artifact, you are in effect > notarizing the signatures in the message and the message payload. If > the developers add a signature to the message, the hashsum changes and > your notarization breaks. > > The preferred way to support this is to not verify that the hashsum over > the artifact matches, but to verify the PGP signatures over the payload > using the set of eligible signing keys in the package metadata. In practice, we don=E2=80=99t get to choose the authentication method. You= =E2=80=99re proposing a different authentication method here, but we=E2=80=99re just downstream: you=E2=80=99ll have to convince upstreams first. :-) On a related note, and perhaps that=E2=80=99s what you mean by =E2=80=9Cpar= ts of the artifact changing=E2=80=9D, see the discussion on authenticating source code archived at Software Heritage: https://sympa.inria.fr/sympa/arc/swh-devel/2016-07/msg00009.html https://forge.softwareheritage.org/T2430#46046 https://issues.guix.gnu.org/42162#4 Content-addressing is nice, but not very useful if each tool (IPFS, SWH, Git, Guix) has its own way to address content=E2=80=A6 Thoughts? Ludo=E2=80=99.