linux-kernel - Re: [GIT PULL] hardening fixes for v6.16-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250601-wandering-graceful-crane-ffc0b7@lemur>
Date: Sun, 1 Jun 2025 13:49:11 -0400
From: Konstantin Ryabitsev <konstantin@...uxfoundation.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: 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:
> > 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?

Yes, I will add that safety check in for sure. This is one of those scope
creep situations -- the trailers command started out as a way to apply
trailers only to your own curated series, e.g. before submitting a vN+1, but
it was then hacked to also work on arbitrary trees, without properly
considering all possible implications.

> 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.

It's working as designed, I'm afraid -- git-filter-repo is a powerful tool
for rewriting git history and will happily fire off even when you are pointing
it at your own two feet.

-K