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  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:   Sun, 14 Jun 2020 11:39:02 -0700
From:   Linus Torvalds <>
To:     Micah Morton <>
Cc:     Linux Kernel Mailing List <>,
        linux-security-module <>
Subject: Re: [GIT PULL] SafeSetID LSM changes for v5.8

On Sun, Jun 14, 2020 at 11:04 AM Micah Morton <> wrote:
> I amended the author on the lone commit in this pull request. For some
> reason I was thinking using the "From:" line in the commit body was
> how I should make things show up as Thomas as the author and me as the
> committer, but looks like that’s not true.

That's how we do things in email, since you want a separate author for
the emailed patch than from the author of the email itself.

But git itself very much has that difference between "author" and
"committer" internally, and all the usual email application tools will
take the separate "From:" line from the email, and make that be the
author in git.

(And then the sign-off chain is where we describe the whole path,
because git only has the concept of those two end-points: the original
author, and the final committer, but no concept of the path in between
the two, nor does it have the concept of the copyright and license
agreement implications of the sign-offs).

> I also removed my own Signed-off-by line from the pull request body
> and included it in the commit instead of the Reviewed-by line.

Good. You will get credit for the pull request in the merge commit
itself as a "Pull xyz from Micah Morton", so that path of history gets
encoded that way.

But the sign-off chain is supposed to be there for each individual commit.

(I don't always notice those things, but afaik there is automation in
place in -next that should warn about commits with incomplete sign-off
chains. Did that not trigger for some reason in this case?).


Powered by blists - more mailing lists