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
| ||
|
Date: Tue, 27 Oct 2020 09:14:41 -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 Sun, Oct 25, 2020 at 10:54 AM Linus Torvalds <torvalds@...ux-foundation.org> wrote: > > 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. Ok thanks for the explanation, I think this was the most important piece I was missing, but makes sense now. > > 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. Yeah sounds good, I'll just get in the habit of doing a test merge and note in the pull request whether there are any conflicts or not. > > > 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. Got it. > > 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
Powered by blists - more mailing lists