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: <CAJ-EccMu_AGfOYASyteGosdOc1SMHeVTLax5aoZSQf7_n0Xq2Q@mail.gmail.com>
Date:   Fri, 23 Oct 2020 12:14:47 -0700
From:   Micah Morton <mortonm@...omium.org>
To:     Linus Torvalds <torvalds@...ux-foundation.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 10:57 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Thu, Oct 15, 2020 at 5:01 PM Micah Morton <mortonm@...omium.org> wrote:
> >
> > I just rebased to v5.9 to make sure the 1-line changes that touch
> > kernel/capability.c, kernel/groups.c and kernel/sys.c still applied
> > cleanly without conflicts. Should I have rebased onto one of the -rc's
> > for v5.9 instead?
>
> No. You shouldn't have rebased at all.

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

I guess the lesson here is never rebase or fast-forward merge my
upstream-bound -next branch until it has emptied entirely into the
mainline? And if that doesn't happen for whatever reason during one
merge window and I have to wait for the next one, I just send you
un-reparented/un-fastforwarded possibly outdated commits and you will
resolve conflicts if any?

The reason for the rebase making sense to me here was that the changes
to common kernel code are very simple (a few one line changes) and
easy to quickly verify after the rebase -- and the vast majority of
the complexity of the code in the pull request was confined to the
SafeSetID code base, which had no changes over the time span from
original base to the reparented base. So I had basically considered it
a no-op rebase. I probably should have explained this in the pull
request.

Thanks

>
> Making sure something applies cleanly is simply not a reason to rebase.
>
> See
>
>   Documentation/maintainer/rebasing-and-merging.rst
>
> for some common rules.
>
>              Linus