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 05B373858D28; Sun, 21 Apr 2024 20:40:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 05B373858D28 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 05B373858D28 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=1713732035; cv=none; b=E03ypD/t2tdQ1xOcIxf+lq8ApGeXW2Du/0L+QvAIg6cYBKVKlXM23vDzIg66Rg+zmcTroIepg/DkrUVQHejybFEQxlZaAYvgiz7z7gAH8aKzTgS3pqctH5sRXVbOzS7H0gClgCU4tfMY6Mx8dR9JoyYrl5kJVC0DY3VLc45kDbU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713732035; c=relaxed/simple; bh=6YziICPEuQz2eSVhfq8aw72QmDvbElxFygGFknGcs3s=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=H51+aYVaj3AAvuWVCt14qGGqbqN8o5R4Pkc4T4ls9sroMl2Z4Toj41+jcel3uCXLz8crILMfSIw6NuXSCR98KiS14LKm1uE/+gr8svaEPhtp6ibJ7fJNdiZYWr5yTD/Rl41m0qvVw3ifa7j5cWK4VDp9H/njDhRxQ/k+qy0ps2c= 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 6D1DA60C0D; Sun, 21 Apr 2024 20:40:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17DF0C113CE; Sun, 21 Apr 2024 20:40:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713732031; bh=6YziICPEuQz2eSVhfq8aw72QmDvbElxFygGFknGcs3s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GXGEaxd/mN49KRDtEx8JBvwUlkWNLR5H7mFDjHaCGTWQaRUcMQ+JTF6KOCbE2iVlB I4ApVkaNW3nTl4ZoWemtVeRp0gwJquLMsyJqqgxsdWLDvN6k0P+DhhcYEzoXPIQtr/ WM91NYFCY+hiVFjNEdnTKyqc0o9QGziIgoGvn5wil4L7bvFSvcfq9Y4HkC/cTqja6n J648v+b0m6bNI5sKGwttAwIAL1QGGX/xmk/aa0rcDdTRAmvGWpST8+X+Ta7Ktbb7Q+ qh7dBNglEjNQMb8A6FAp9lKKcfaKUBYyfFytaMJfhf2qIySo1P+2tSE+Fjlx4qU27v eYjMX3ir45epw== Date: Sun, 21 Apr 2024 22:40:14 +0200 From: Alejandro Colomar To: Mark Wielaard Cc: Joel Sherrill , Florian Weimer , Guinevere Larsen via Overseers , Sandra Loosemore , 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> <20240421153052.GA29957@gnu.wildebeest.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+vwhMzqevcgaG2bp" Content-Disposition: inline In-Reply-To: <20240421153052.GA29957@gnu.wildebeest.org> X-Spam-Status: No, score=-4.3 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 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: --+vwhMzqevcgaG2bp Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Apr 2024 22:40:14 +0200 From: Alejandro Colomar To: Mark Wielaard Cc: Joel Sherrill , Florian Weimer , Guinevere Larsen via Overseers , Sandra Loosemore , Guinevere Larsen , GCC , binutils , Eli Zaretskii via Gdb , libc-alpha@sourceware.org Subject: Re: Sourceware mitigating and preventing the next xz-backdoor On Sun, Apr 21, 2024 at 05:30:52PM +0200, Mark Wielaard wrote: > Hi Alejandro, Hi Mark, I've reordered your message, to organize my response. > On Wed, Apr 10, 2024 at 06:30:42PM +0200, Alejandro Colomar wrote: > > 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. >=20 > Could you give an example of using git range-diff? Sure! > Normally when asked for changes to a > patch (series) I do an git rebase -i (on the local branch I used to > develop the feature/bug fix) and split/commit all requested changes > and then sent the new patches with git send-email again. I do the same thing. > But I guess > to use/combine that with git range-diffs I should start creating new > local branches for each patch (series) in development? No; it's compatible with that workflow. > How do you go from > v1 of a patch (series) to a v2? I'll start first with how you go from nothing to v1, which will help explain how you go from v1 to v2. Let's say I have a branch 'unifont' for adding the Unifont font to the Linux man-pages' PDF book. I have it in a branch that applies on top of 'master'. $ git log --oneline --graph master..unifont; * 892a12470 (HEAD -> unifont, alx/contrib, contrib) share/mk/: build-fonts= -unifont: Specify spacewidth in afmtodit(1) * d80376b08 share/mk/: build-pdf-book: Use Unifont * 7ec952012 share/mk/: build-fonts-unifont: Build UnifontR from unifont.otf I want to send that as a patch set (v1, of course, since it's the first send). I would already use range-diff when generating the patches: $ git format-patch -o ./patches master..HEAD \ --range-diff=3Dmaster -v1 --cover-letter; ./patches/v1-0000-cover-letter.patch ./patches/v1-0001-share-mk-build-fonts-unifont-Build-UnifontR-from-.patch ./patches/v1-0002-share-mk-build-pdf-book-Use-Unifont.patch ./patches/v1-0003-share-mk-build-fonts-unifont-Specify-spacewidth-i.patch Why would you do that in v1? It notes the commit IDs of the patches, so you can later check them when preparing v2; we'll come back to that. For now, see what this adds to the patch set: $ tail ./patches/v1-0000-cover-letter.patch ; create mode 100644 share/mk/build/fonts/unifont/pfa.mk create mode 100644 share/mk/configure/build-depends/fonts-unifont/unifont= =2Eotf.mk Range-diff against v0: -: --------- > 1: 7ec952012 share/mk/: build-fonts-unifont: Build Unifon= tR from unifont.otf -: --------- > 2: d80376b08 share/mk/: build-pdf-book: Use Unifont -: --------- > 3: 892a12470 share/mk/: build-fonts-unifont: Specify spac= ewidth in afmtodit(1) --=20 2.43.0 You can see the IDs of the commits that form this patch set, which match the git-log(1) that I showed above. Now someone suggests a change. For this example, I wasn't happy with a commit message, and added a space to the third commit message subject line. The git-log(1) is now: $ git log --oneline --graph master..unifont * bc7fa7d92 (HEAD -> unifont) share/mk/: build-fonts-unifont: Specify spac= e width in afmtodit(1) * d80376b08 share/mk/: build-pdf-book: Use Unifont * 7ec952012 share/mk/: build-fonts-unifont: Build UnifontR from unifont.otf Let's generate a v2 patch set, showing the range-diff against v1. We need to check the commit IDs of the first set, which can be found in the mailing list archives, thanks to the trick we used. The v1 range was 7ec952012^..892a12470. So we just pass that range: $ git format-patch -o ./patches/ master..HEAD \ --range-diff=3D7ec952012^..892a12470 -v2 --cover-letter; ./patches/v2-0000-cover-letter.patch ./patches/v2-0001-share-mk-build-fonts-unifont-Build-UnifontR-from-.patch ./patches/v2-0002-share-mk-build-pdf-book-Use-Unifont.patch ./patches/v2-0003-share-mk-build-fonts-unifont-Specify-space-width-.patch The v2 cover letter shows the changes introduced since v1: $ tail -n20 ./patches/v2-0000-cover-letter.patch=20 create mode 100644 share/mk/build/fonts/unifont/dit.mk create mode 100644 share/mk/build/fonts/unifont/pfa.mk create mode 100644 share/mk/configure/build-depends/fonts-unifont/unifont= =2Eotf.mk Range-diff against v1: 1: 7ec952012 =3D 1: 7ec952012 share/mk/: build-fonts-unifont: Build Unif= ontR from unifont.otf 2: d80376b08 =3D 2: d80376b08 share/mk/: build-pdf-book: Use Unifont 3: 892a12470 ! 3: bc7fa7d92 share/mk/: build-fonts-unifont: Specify spac= ewidth in afmtodit(1) @@ Metadata Author: Alejandro Colomar =20 ## Commit message ## - share/mk/: build-fonts-unifont: Specify spacewidth in afmtodit(1) + share/mk/: build-fonts-unifont: Specify space width in afmtodit(1) =20 Link: Suggested-by: "G. Branden Robinson" --=20 2.43.0 If too much time passes between the last time the commit was rebased and when you create the range diff, you might need to use tags, such as 'unifont-v1', to avoid git(1) collecting garbagge and removing those old commits. But if you send shortly after rebasing, you won't need that. Lately, I haven't sent many patches to mailing lists, except for trivial oneliners, so I don't remember an example where I used this, but I can point to several github PRs where I've used this to document all changes that have happened to my patch sets, even when the maintainer has edited them, to be fully transparent. For example: Have a lovely day! Alex --=20 --+vwhMzqevcgaG2bp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmYlea4ACgkQnowa+77/ 2zJ5ghAAj4EU9jo2YOaztsC5MQPnAMYR+eapv5talMwPKS1XYHKo+8bUJ+Ijbv27 3fVwuRnRnzEQ+NJAmng0nqGjnppWPjcVSrL+bj77urx94DodYHYMsvnQqxAzEcsP WK6ciSgCTFlBPR5S/CLiAU2sovOwIKuz8KJTCI2cQyy6DryhR/YyV5kYz7ta0pha fhKaCdB4CJRATGYI8Mo/APS5fquQ0XnRWYrF7QEIHsZnDwGytBdruPF41UCm7+fz P9PnA71evI74VXZqi2NE1rFsnvkTwN5MiMJ1I9xhaooiHA7jokq9n7LfnPeqzhXI 3lWonqjgdkZuRT9z5UlhMkw34Bx4k6kYkyWPjTh4DMlLDmVJXE2db9UC68OUxboR JPj17JLjsASHEk6h9Wt0WEYr5lIXAbid9FxZ9+xZxsV+0quXJQEYV/4BMdI2YTbz qYuSZurl9rJ3rHcWD7kg5vA5G7DjFgrjKPsRBZLAif8g3nXRbQpYHG1u2ozuI9Y5 gj5+kGTydUYGBTUBGPlfGwVs6iwqAJ3dyvyE982nGNvaPFpya9SRS2WP8iQQCyY8 +A08BZgYb16IHrFWMh/c9rxXhiUIu+AiK9qLW/GHpaGJB7mRTKuVjQZsus94ZgEk /pw4eVH7Ul5gVcWTzpAUGY0YbBz6wboSL4MjulwBYeLIi2Zjc6M= =W3m5 -----END PGP SIGNATURE----- --+vwhMzqevcgaG2bp--