linux-kernel - Re: linux-next: Signed-off-by missing for commit in the drivers-x86 tree

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 16:57:40 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     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 Thu, Aug 03, 2017 at 06:37:43AM +1000, Stephen Rothwell wrote:
> Hi Darren,
> 
> Commits
> 
>   890f658c101d ("platform/x86: peaq-wmi: silence a static checker warning")
>   6d8d55626296 ("platform/x86: msi-wmi: remove unnecessary static in msi_wmi_notify()")
>   cd0223c64c60 ("platform/x86: ibm_rtl: remove unnecessary static in ibm_rtl_write()")
> 
> are missing Signed-off-by's from their commiter.

So each of these was originally committed by Andy... but appear as
committed by me. This must have occured as a rebase of our testing
branch I suppose. Nothing has been out of the ordinary this development
cycle, so I wonder that we haven't received such a report previously.
Hrm.

Is this a new check Stephen?

Is there any statement regarding maintainer teams that we must abide by
this?  e.g. any time a rebase in a testing branch is made, the
maintainer must also ensure a SOB is on each patch?

I just want to get a clear picture of what the failure was so we can
update our tooling so this doesn't repeat itself.

-- 
Darren Hart
VMware Open Source Technology Center