From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OizmEjIUF2bpiyoAWB0awg (envelope-from ) for ; Wed, 10 Apr 2024 18:35:30 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=H+cc6Rqd; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 2A5591E0C0; Wed, 10 Apr 2024 18:35:30 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 039FD1E030 for ; Wed, 10 Apr 2024 18:35:28 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 197A03826FCC for ; Wed, 10 Apr 2024 16:35:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 197A03826FCC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1712766959; bh=vT5Tk0I6MukAZY6tKV9kC0nsBboiSBfSp+QyjKeXcJw=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=H+cc6Rqdq8stqml4Z9zrREuwXBDg6DxyO67u177tOzixGrdqxMhVpanfjhJ5q0kau I9bPC1B0XkpRWKv7wEELYBjRdrsWWWxiC9H+znkUopYltO8ySoUEPoC5pfQ0VvkSYd Th9mqU8dq5k0B0xkF2kNG8O80GH3qxs58NdW3M/A= 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7EBAA3870899 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) Date: Wed, 10 Apr 2024 18:30:42 +0200 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 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Alejandro Colomar via Gdb Reply-To: Alejandro Colomar Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" --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--