linux-kernel - Re: [GIT PULL] SafeSetID changes for v5.10

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: <CAHk-=whAYrg_N9ZZ38C5YqPQT4eyCj8JoJ4oax479DpOkdH07w@mail.gmail.com>
Date:   Sun, 25 Oct 2020 10:54:31 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Micah Morton <mortonm@...omium.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>
Subject: Re: [GIT PULL] SafeSetID changes for v5.10

On Fri, Oct 23, 2020 at 12:15 PM Micah Morton <mortonm@...omium.org> wrote:
>
> Ok so before the rebase ("reparent"), the commits were based on top of
> some commit that was months old at this point (can't quite remember
> now, I think one of the -rc's for v5.8).

Nobody cares if the old parent is old. In fact, that's usually a good
sign that the code has had testing and is changing things that aren't
in flux for other reasons.

It's often a good idea to make a test-merge and verify that things are
ok, but that's for your _personal_ verification, and shouldn't be
something that anybody else sees.

And even with a test-merge, it doesn't matter if there is some simple
conflict - we have those all the time, and conflicts aren't bad. In
fact, they allow me to see "ok, things have changed here in parallel",
and I'll be aware of it.

The main reason to rebase is if things have changed _so_ much that you
really need to re-do things, or if there is some major bug in _your_
branch that simply needs to be fixed.

>    So I had basically considered it
> a no-op rebase. I probably should have explained this in the pull
> request.

If it's a no-op rebase, thern DON'T DO IT. Really. It just means that
now you have lost all the testing.

Thinking that it's a no-op doesn't really help. No bugs are
_intentional_, I would seriously hope. Lack of testing is lack of
testing, regardless of whether you think it would not matter.

It also destroys the real history of the code, which is sad.

Now, sometimes you may _want_ to destroy the real history of the code
(as in "Oh, this history is too ugly to survive, and makes bisection
impossible because some of the intermediate state was seriously
buggy"). That is then one of those few valid reasons to rebase (see
the "major bug in your branch" case above).

But 99% of the time, rebasing is bad. If it was in linux-next and
there were no horrible problems with it, and it got tested there, then
just leave it alone and don't destroy the testing it did get.

Anyway, I've pulled this now, but honestly, don't do this again. Stop
rebasing without a big and immediate reason, and stop destroying
whatever testing it got in linux-next.

And if you _do_ rebase, and you _do_ have a real and very serious
reason, then mention that reason and explain it. But no "the rebase
didn't make any difference" isn't a reason. Quite the reverse.

               Linus

                   Linus