mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	 Vlastimil Babka <vbabka@suse.cz>, Kees Cook <kees@kernel.org>,
	linux-kernel@vger.kernel.org,  Eric Biggers <ebiggers@kernel.org>,
	Ingo Saitz <ingo@hannover.ccc.de>,
	 kernel test robot <oliver.sang@intel.com>,
	Marco Elver <elver@google.com>,
	 Nathan Chancellor <nathan@kernel.org>,
	Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Subject: Re: [GIT PULL] hardening fixes for v6.16-rc1
Date: Tue, 3 Jun 2025 14:42:23 +0200	[thread overview]
Message-ID: <20250603-einnahmen-redefreiheit-df3db181d8b6@brauner> (raw)
In-Reply-To: <CAHk-=wgcQdD0UzMJrNhQuYAC2wgGtfrCry_iokswaEE5j7W9YA@mail.gmail.com>

On Sun, Jun 01, 2025 at 10:12:02AM -0700, Linus Torvalds wrote:
> On Sun, 1 Jun 2025 at 07:40, Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> >
> > On Sun, Jun 01, 2025 at 12:42:14AM -0700, Kees Cook wrote:
> > > Okay, reproducing the "b4 trailers" steps:
> > > ...
> > > ### Try to update 8c2bb7d12601 with the Acked-by from the list...
> > > $ b4 trailers -u https://lore.kernel.org/all/CANpmjNPpyJn++DVZmO89ms_HkJ0OvQzkps0GjCFbWkk0F+_8Xg@mail.gmail.com
> > > Finding code-review trailers for 39 commits...
> >
> > Yeah, this is danger territory, because you're asking to update a random
> > commit in the tree history.
> 
> So the *real* danger territory is lying about committer information.
> That's the thing that *no* standard too should ever do, and what made
> me so upset.
> 
> Konstantin, can you please fix b4 to never *ever* rewrite a commit
> that has different committer information than the current user?
> 
> I don't think this is about "39 commits down". This is apparently b4
> just doing plain bad things, adn it would be bad even if it was only
> rewriting the top-most commit.
> 
> Setting authorship to somebody else is normal and expected: "author"
> is about giving credit.
> 
> But setting *committer* information to somebody else is not about
> giving credit, it's about lying. Tools that do that are broken tools.
> 
> I'm also not clear on why apparently the script tries to retain
> committer dates. That's also just plain lying.

Fwiw, this has happened to me with b4 multiple times before so I've
stopped using b4 trailers -u. Whenever I do end up using it I look at
the base that I was using to make sure that only things got rewritten
that I expected to be rewritten (b4 is excellent though).

The last time this happened was when I did the struct kmem_cache_args
rework a few months back. Vlastimil and I ended up sharing a common base
and then he complained that something was off with our shared trees. He
later emailed me and we figured out that it was the b4 trailers thing
again iirc.

I do test-merges before I send stuff out and that's usually how I catch
stuff like that.

But for a while I was really confused how trees I had somehow ended up
being rewritten and it took a little to figure out that it was the
trailer auto updating which caused it.

      parent reply	other threads:[~2025-06-03 12:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-31 15:00 Kees Cook
2025-05-31 18:20 ` Linus Torvalds
2025-05-31 19:21   ` Konstantin Ryabitsev
2025-05-31 19:57   ` Konstantin Ryabitsev
2025-05-31 21:36   ` Al Viro
2025-06-01  1:06   ` Kees Cook
2025-06-01  2:22     ` Stephen Rothwell
2025-06-01  2:35     ` Linus Torvalds
2025-06-01  5:42       ` Kees Cook
2025-06-01  7:42       ` Kees Cook
2025-06-01 14:40         ` Konstantin Ryabitsev
2025-06-01 15:38           ` Kees Cook
2025-06-01 17:58             ` Konstantin Ryabitsev
2025-06-01 18:56               ` Kees Cook
2025-06-03 12:55               ` Vlastimil Babka
2025-06-01 17:12           ` Linus Torvalds
2025-06-01 17:49             ` Konstantin Ryabitsev
2025-06-01 18:24               ` Linus Torvalds
2025-06-03 12:42             ` Christian Brauner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250603-einnahmen-redefreiheit-df3db181d8b6@brauner \
    --to=brauner@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=elver@google.com \
    --cc=ingo@hannover.ccc.de \
    --cc=kees@kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=oliver.sang@intel.com \
    --cc=thiago.bauermann@linaro.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®