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]
Date:   Wed, 2 Aug 2017 18:06:20 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Darren Hart <dvhart@...radead.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: linux-next: Signed-off-by missing for commit in the drivers-x86 tree

On Wed, Aug 2, 2017 at 5:28 PM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> I would say that if you rebase someone's commit(s), then you are on the
> "patch's delivery path" and so should add a Signed-off-by tag.

Yeah, I agree. Rebasing really is pretty much the exact same thing as
applying a patch.

> "git rebase" does have a "--signoff" option.

I think you end up signing off twice using that. I don't think it's
smart enough to say "oh, you already did it once".

But I didn't check. Sometimes git is a lot smarter than I remember it
being, simply because I don't worry about it. Junio does a good job.

And in general, you simply should never rebase commits that have
already been publicized. And the fact that you didn't commit them in
the first place definitely means that they've been public somewhere.

So I would definitely suggest against the "git rebase --signoff"
model, even if git were to do the "right thing". It's simply
fundamentally the wrong thing to do. Either you already committed them
(and hopefully signed off correctly the first time), or you didn't
(and you shouldn't be rebasing). So in neither case is "git rebase
--signoff" sensible.

              Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ