From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by sourceware.org (Postfix) with ESMTPS id 7EBAA3870899; Wed, 10 Apr 2024 16:30:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7EBAA3870899 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7EBAA3870899 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2604:1380:4641:c500::1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712766665; cv=none; b=m4uyjZy/fBpkeHBbuZ2gM4tlqUKCjqCfwhW2yD7A9qqSw8hiurwd3uKRwFg5rco7vOYH4Q0UtfcbWWWUoIFgtOFcIBqnlUDJAa49/R6s2bz+taWi41J9cfZIzedJb9NPQ1M+ELXGLWNhFV2fkXZMNQna88uBQdmAtMZEtaLXRmk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712766665; c=relaxed/simple; bh=e92mhmsRwXFjluRos2H4yY8T/zQnqvdPF6Az8d2fZrk=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=V8kL0/vFsr02zeMs/wF60dgdvcQFASys2eSGmb36FAXtmwxhTZlaVILTPreD+7b/L3bG7HX+9sXfLx/KEhgeZ2LFLY3Ixcgz3qxRTpIqC3inGVuKHxRXlC+xJGhFcvuJbcucUCMNhnqkXncIgYd8RhMT1CsOqskqG8+1qvBE0LI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D1FE561DE4; Wed, 10 Apr 2024 16:30:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2969C43394; Wed, 10 Apr 2024 16:30:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712766652; bh=e92mhmsRwXFjluRos2H4yY8T/zQnqvdPF6Az8d2fZrk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dIAU5HK+ZEmmWdfRWjT3UNkOvTB5r+BLQOffzK2blm7NBaraDQz7PnarfwZpSjP/E r7zoSJ/udYL94pUVKxWwu7OdgfKGVcry3mJHsbchWpRNh1lH1a+pxlV9tbWAvl0S+T XFuUmuWvfDYA8XPv2I/VK0T3EiWOq4weY5GRn6bBN0xrXQJUrOdNEmbKImHW8t7e14 hVI17gL5B9nchzjPQxdRihUbN5j+naoZruIZx+k8rTzS6s63/t4bDSsY1vSCTN4+sD jYgL0NyZX9Shco1DnO5cwyEWVKpMt9lG6KvZ+rvWHjYvXABwvdd+cz14j2jHVwW7Ke 7coljYfSG7zSg== Date: Wed, 10 Apr 2024 18:30:42 +0200 From: Alejandro Colomar To: Joel Sherrill Cc: Florian Weimer , Guinevere Larsen via Overseers , Sandra Loosemore , Mark Wielaard , Guinevere Larsen , GCC , binutils , Eli Zaretskii via Gdb , libc-alpha@sourceware.org Subject: Re: Sourceware mitigating and preventing the next xz-backdoor Message-ID: References: <20240329203909.GS9427@gnu.wildebeest.org> <20240401150617.GF19478@gnu.wildebeest.org> <077b9dd5-0df1-4384-a9d1-58e4283caf09@redhat.com> <87il0ykgw5.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Sf9ZbBPR1r7dI09p" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,URIBL_SBL_A autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --Sf9ZbBPR1r7dI09p Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Apr 2024 18:30:42 +0200 From: Alejandro Colomar To: Joel Sherrill Cc: Florian Weimer , Guinevere Larsen via Overseers , Sandra Loosemore , Mark Wielaard , Guinevere Larsen , GCC , binutils , Eli Zaretskii via Gdb , libc-alpha@sourceware.org Subject: Re: Sourceware mitigating and preventing the next xz-backdoor Hi Joel, On Wed, Apr 03, 2024 at 08:53:21AM -0500, Joel Sherrill wrote: > On Wed, Apr 3, 2024, 3:09=E2=80=AFAM Florian Weimer via Gdb > wrote: >=20 > > * Guinevere Larsen via Overseers: > > > > > Beyond that, we (GDB) are already experimenting with approved-by, and > > > I think glibc was doing the same. > > > > The glibc project uses Reviewed-by:, but it's completely unrelated to > > this. Everyone still pushes their own patches, and there are no > > technical countermeasures in place to ensure that the pushed version is > > the reviewed version. > > >=20 > Or that there isn't "collusion" between a malicious author and reviewer. > Just tagging it approved or reviewed by just gives you two people to blam= e. > It is not a perfect solution either. If those tags are given in a mailing list _and_ mails to the mailing list are PGP-signed, then you can verify that the tags were valid, and not just invented. And with signed commits you have a guarantee that one doesn't overwrite history attributing commits to other committers (it could happen with authors, and indeed it seems to have happened in this case, but if patches are sent via signed mail, then it's also verifyiable). In the email side, there are a few things to improve: For sending signed emails, there's patatt(5) (used by b4(5)), but it might not be comfortable to use for everyone. For those preferring normal MUAs, neomutt(1) is an alternative: And I have a few patches for improving the security of protected messages: And the corresponding security-vulnerability reports: (I find it funny that I didn't know about this xz issue until yesterday, so not when I reported those issues, but they are interestingly related.) It would also be interesting to require showing range-diffs between patch revisions. They make it much more difficult to introduce a vulnerability after a reviewer has turned its mins into approving the patch. Of course, the patch could go in if the submitter lies in the range-diff and the vuln is undetected, but then it can be verified a posteriory to prove that there was a lie. I recently started applying all of these (signing all email, including patches, sign all commits and tags, and provide range-diffs), and it's not too uncomfrotable; I'd say it's even more comfortable than not doing it, as it allows me to easily roll back a patch to an older revision if I find I introduced a mistake, and find where I introduced it. Have a lovely day! Alex --=20 --Sf9ZbBPR1r7dI09p Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmYWvrIACgkQnowa+77/ 2zKP/g//VvBwr72aaMYgVdXP93RA2FxBWEydcQ35oOgVVELXlFvitWEf/028yi+d PS/er8JmPMGvfekJ+urm9ASj46ZxKQ+fFi9UOoQjmV4zK3VOJK3rOSqyBSkc09tx gWUE+oOvyk0utgNVg7mwmYChLlt4IWcQGfIY3uLwSHEjMhFgzisvALvfiFaVa6QN Pbc92T40NVts3GrhOBqsVsuhLD8MdrjUcA+5Z8TCJmlcuUod0xjNfrtzBdGqnPgB IAdmoxkq+oObOtbZ7RVy7Bjcj54BDxiNX5yepDdMvKHv4x0Foca8NKpbvbcRtZ7w xEwqrUsSDfmHJKw0ByjiunbkSCA9Adv8mSkTkiOyhi5Nwpq4rjwieGZy1g/yIOoA AKd4/rmfYhgUwZkjXk3LH0m38saOaiJoV6MxfZJKUuqAnB11H5vrwMftTT8zG5jM FiHZ9vaoHpGQNEKbU0J7o85u5n+yQMiAWb1XfS6sNrTrlEAiVjhubkquw048fqJt sOzrouJ+SpMHlejS91ICDxGlPlwOXqx/+mg421CUZfGDkC7ctopxsQoPNbfsfAZC 6zsQ8WwxSxZejyMWH+MJuy9T8r1WYsW2Gz6lLYkFUrnNWg377lrCHmLB1ySpdDQU rSPz0jn16yHxL1mZxpZXvGFlZb9ux4SUQ2ZL78qjs9Wird67yVc= =pPZL -----END PGP SIGNATURE----- --Sf9ZbBPR1r7dI09p--