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 pqk7OBDrI19wQAAA0tVLHw (envelope-from ) for ; Fri, 31 Jul 2020 09:57:36 +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 mDyYMxDrI18bLwAA1q6Kng (envelope-from ) for ; Fri, 31 Jul 2020 09:57:36 +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 7039D940903 for ; Fri, 31 Jul 2020 09:57:36 +0000 (UTC) Received: from localhost ([::1]:33212 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k1RnD-0004Mf-90 for larch@yhetil.org; Fri, 31 Jul 2020 05:57:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40728) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k1RDi-0004fB-JM for guix-devel@gnu.org; Fri, 31 Jul 2020 05:20:54 -0400 Received: from avior.uberspace.de ([185.26.156.32]:57462) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k1RDg-0002TQ-8q for guix-devel@gnu.org; Fri, 31 Jul 2020 05:20:54 -0400 Received: (qmail 15567 invoked from network); 31 Jul 2020 09:20:45 -0000 Received: from localhost (HELO europa) (127.0.0.1) by avior.uberspace.de with SMTP; 31 Jul 2020 09:20:45 -0000 Received: from localhost ([127.0.0.1]) by europa with esmtp (Exim 4.92) (envelope-from ) id 1k1RDX-0002eW-AX; Fri, 31 Jul 2020 11:20:43 +0200 From: Justus Winter To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: Securing the software distribution chain In-Reply-To: <87ime9w23i.fsf@gnu.org> References: <87blk6wkug.fsf@europa.jade-hamburg.de> <87ime9w23i.fsf@gnu.org> Date: Fri, 31 Jul 2020 11:20:43 +0200 Message-ID: <87lfj0ujkk.fsf@europa.jade-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Received-SPF: none client-ip=185.26.156.32; envelope-from=teythoon@avior.uberspace.de; helo=avior.uberspace.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/31 05:20:46 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 31 Jul 2020 05:57:24 -0400 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: -3.11 X-TUID: wikQDq+uh/Pp --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello :) Ludovic Court=C3=A8s writes: > Justus Winter skribis: >> 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=3D6b8875c838d63= 7773813899b35a9b5ea4acfd146#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 bui= ld -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. On the other hand, most packaging metadata is ornamental. There is no way to tell if synopsis or description is up to date or correct. With signing metadata there is a way to detect this, so I don't see how tracking signing metadata is worse than tracking the description. > 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 wo= uld still be > optional. Don't make it optional! Empower and encourage us downstream users to verify upstream signatures and verify that the packager is honest, like you empower us to build software and verify that the substitution builder is honest. You know, I recently packaged dkgpg. That software is distributed as a signed tarball (or rather, there is a detached signature for the tarball). Did I check that signature before storing the hashsum in the packages metadata? You know I did. Currently, you just need to trust me on that. Or did I? >> 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. I mean that the tarball inside the OpenPGP message stays the same, but we attach more signatures to the OpenPGP message over time. >> 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. Y= ou=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. :-) Well, I'm a upstream, and this is your heads up that you are not prepared to deal with our source distribution scheme of choice. And, we're hoping to convince other projects to use our scheme as well. We've been talking about this problem internally, and we have concluded that it is useful to be able to pin the source tarball to an exact version as you do now. That is possible with our scheme by hashing only the literal data of the signed OpenPGP message. That requires some OpenPGP parsing, but guix/openpgp.scm should support that. > 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 I don't understand the relation to content-addressing, sorry. Thanks :) Justus --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAl8j4msACgkQiNx+Mzhf eR1NWQf/ZQSaJo/bYmFe+3wiYLRMkkH6xnUsk/S4W8g5EwnVNBWm5p6eIdRZXib8 9lKu5cX+dJ5zJm3Xa0x0ctVkvZnyYD8WUvg+bOAMAtysDNIs8n7VGNqEkBnLRSgk 307tmI2P0SxNXr+ZXnvCLxGd6+mKlgxIskUDSaEpzUjBVbeOfHGh6JpZlZCFLngh CYzPcaYas/qDBIUWM1YMIFB52YPxjJTWMeg8g8g6Cfhcb13Nzs6hGttBr33lJfcE t9teg72BaPG9haRntO5WBZ+xh2VbNDROegitUbZOMBXLYGQrWKuD2KQXoeYudZ0B 8H9LW6+NCiVOGBMU+pb6hV3/xJGFiA== =1rfz -----END PGP SIGNATURE----- --=-=-=--