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 905BB3858D28; Sun, 21 Apr 2024 20:52:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 905BB3858D28 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 905BB3858D28 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=1713732738; cv=none; b=vPGH+hRYUvEh4eyb/yS5rNCz8lD4dHRRz2hWkkxW7rYBhHhBmbv6cddhZcwaiSH1AUy+Bf6L+svDQwbP6coUGLQZTZn40bCNzx2LcMjmRKWBZxzT2AR089ZzeGH+MERV1oqeOAX2ZCB0NXk2/5jLRK3NPM0EDoRzn8JV6RSpH00= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713732738; c=relaxed/simple; bh=N3NeuUaPt9/OmLOyfqciSMXqRPDHcicM7lG1fcAAIN4=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=QPdrqGpk1AqLilbgOVwMuW3vQZHXod1oLfoWnWrckjIcJDel+NNbXrZuPHHp/j+FCSif0NQwEXA2ieIB6ZRJci7d8trrfEtgOoLWdmzzM5whwbLw1coFwrIDYBicX+uzq0onGOINraP4ad7M9Vpy0M738oSjwF5e/EpBb7gepEs= 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 222F1602BE; Sun, 21 Apr 2024 20:52:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE88FC113CE; Sun, 21 Apr 2024 20:52:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713732735; bh=N3NeuUaPt9/OmLOyfqciSMXqRPDHcicM7lG1fcAAIN4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AJ+Hu3IGvEssG3tbJjjyRNcTuPZGrUduoRUVZy6VKVRz0I9Yscy+hXcI3s6VHOPrP l2ZY+qkxKHM76AWoBZ2jrWKqOaV6fyaw8wCRgWfgSg8zbvYFWGpl4nhrDyvydBEqZF qOwnkDoRs4ULp4EJMBPv/IyGbkXLhQnz+j0XquKCW71XUpLAYXsWzWqY/W2tKxYsSO Z7iSZnBawUs4spWMO4kJCFMuKXqdR/SC+lYQqHMJl0kOcIan8rDbsdUbVmb/eiIXlu c5ttB3blhxHFt5sRl1yvbK7xt8ECIeWjz9zJFQQ+Yn5WvliD0e4jCaa8oAey0J5xi7 LjzuQY7YJZw9w== Date: Sun, 21 Apr 2024 22:52:11 +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="Zk2k/Cl4MUsE/ZVj" Content-Disposition: inline In-Reply-To: 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: --Zk2k/Cl4MUsE/ZVj Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Apr 2024 22:52:11 +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 10:40:14PM +0200, Alejandro Colomar wrote: > On Sun, Apr 21, 2024 at 05:30:52PM +0200, Mark Wielaard wrote: > > Hi Alejandro, >=20 > Hi Mark, >=20 > I've reordered your message, to organize my response. >=20 > > 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? >=20 > Sure! >=20 > > 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. >=20 > I do the same thing. >=20 > > But I guess > > to use/combine that with git range-diffs I should start creating new > > local branches for each patch (series) in development? >=20 > No; it's compatible with that workflow. >=20 > > How do you go from > > v1 of a patch (series) to a v2? >=20 > I'll start first with how you go from nothing to v1, which will help > explain how you go from v1 to v2. >=20 > 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'. >=20 > $ git log --oneline --graph master..unifont; > * 892a12470 (HEAD -> unifont, alx/contrib, contrib) share/mk/: build-fon= ts-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 >=20 > 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: >=20 > $ 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 >=20 > 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: >=20 > $ 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/unifo= nt.otf.mk >=20 > Range-diff against v0: > -: --------- > 1: 7ec952012 share/mk/: build-fonts-unifont: Build Unif= ontR from unifont.otf > -: --------- > 2: d80376b08 share/mk/: build-pdf-book: Use Unifont > -: --------- > 3: 892a12470 share/mk/: build-fonts-unifont: Specify sp= acewidth in afmtodit(1) > --=20 > 2.43.0 >=20 > 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: >=20 > $ git log --oneline --graph master..unifont > * bc7fa7d92 (HEAD -> unifont) share/mk/: build-fonts-unifont: Specify sp= ace width in afmtodit(1) > * d80376b08 share/mk/: build-pdf-book: Use Unifont > * 7ec952012 share/mk/: build-fonts-unifont: Build UnifontR from unifont.= otf >=20 > 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: >=20 > $ 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 >=20 > The v2 cover letter shows the changes introduced since v1: >=20 > $ 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/unifo= nt.otf.mk >=20 > Range-diff against v1: > 1: 7ec952012 =3D 1: 7ec952012 share/mk/: build-fonts-unifont: Build Un= ifontR 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 sp= acewidth 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 >=20 > 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. >=20 > 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: > > And here's an example where the maintainer pushed a version different =66rom my last revision, because he rebased after applying other changes to his branch, and I showed a last range diff to prove that he didn't do anything weird with my patches: >=20 > Have a lovely day! > Alex >=20 > --=20 > --=20 --Zk2k/Cl4MUsE/ZVj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmYlfHsACgkQnowa+77/ 2zIb+hAAgPOd0gXYDQAXGktyZnUKkUbb5e1epyABzeLiLC41V84hDVTFJ/QRMvh6 9LXx6HBTdAWBBrIiJ7J4KqGk8m3wSWpk2KDBpEbp4TYbc7O2KHfQdKR8+H1Zn+7u Ahq57n/gSPal9CN5WP9BiBLr2Tt0qMmwzPh7rggaS+GS3RdxYT6n7vKDamyC6jxr IhpAkyy7xsRnVLsIy76LF0N95IHB6XqGjoqlzAAq/dCKBaGYBYZ/rxRlE+JFwoC0 kAp3e1Rep51J5Gll4mackC7xKeIYMD5iMawapdRnfu5nKLHxak45RHfA+DYLdkCB nwbvLqpMidiESAEnQlx/TDtLt8lpJIzEec8dTEuXhERZf4yZKIKpQ9mEPLMzFCSK ZTsiP8L9MeIHHCJnRflso41MT1N+Cv8cOuhiu3R7eN2NTLyQhHddyHvAQrJRTaex I6CEbfBpzWFKzk7SspaiK3Y8fygyU/+qH1ylXJ/ddfYr6d6uQI2ni6g5vdOQ/7M9 LZPlTLa5vauRxO3fYAEcJkET/OTZz1ElxEvC2UGTg/WCsHYdzR/i800U7qNri2LO y28XmDH/bOmgT9+XSd3nHJwAp9OFw4gGeuZ6UQXXED5oRcmYoLKmUbQ+up/6oCGF SVZgpAT1Qk9fSQYOpKjycoWqJMPzYSr/e+XCAR8m78Fi8Yt5LKA= =mcjJ -----END PGP SIGNATURE----- --Zk2k/Cl4MUsE/ZVj--