[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250603-einnahmen-redefreiheit-df3db181d8b6@brauner>
Date: Tue, 3 Jun 2025 14:42:23 +0200
From: Christian Brauner <brauner@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
Vlastimil Babka <vbabka@...e.cz>, Kees Cook <kees@...nel.org>, linux-kernel@...r.kernel.org,
Eric Biggers <ebiggers@...nel.org>, Ingo Saitz <ingo@...nover.ccc.de>,
kernel test robot <oliver.sang@...el.com>, Marco Elver <elver@...gle.com>,
Nathan Chancellor <nathan@...nel.org>, Thiago Jung Bauermann <thiago.bauermann@...aro.org>
Subject: Re: [GIT PULL] hardening fixes for v6.16-rc1
On Sun, Jun 01, 2025 at 10:12:02AM -0700, Linus Torvalds wrote:
> On Sun, 1 Jun 2025 at 07:40, Konstantin Ryabitsev
> <konstantin@...uxfoundation.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.
Powered by blists - more mailing lists