linux-kernel - Re: linux-next: Signed-off-by missing for commit in the xfs 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]

Message-ID: <20221004210400.GO3600936@dread.disaster.area>
Date:   Wed, 5 Oct 2022 08:04:00 +1100
From:   Dave Chinner <david@...morbit.com>
To:     "Darrick J. Wong" <djwong@...nel.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>, linux-xfs@...r.kernel.org,
        Stephen Zhang <starzhangzsd@...il.com>,
        Shida Zhang <zhangshida@...inos.cn>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: Signed-off-by missing for commit in the xfs tree

On Tue, Oct 04, 2022 at 08:57:34AM -0700, Darrick J. Wong wrote:
> On Tue, Oct 04, 2022 at 10:50:12PM +1100, Stephen Rothwell wrote:
> > Hi Dave,
> > 
> > On Tue, 4 Oct 2022 09:21:03 +1100 Dave Chinner <david@...morbit.com> wrote:
> > >
> > > The commit matches exactly what was sent to the list. It's just
> > > that the patch was sent from a personal email address with a
> > > corporate signoff.
> > > 
> > > Since when has that been an issue?  I -personally- have been doing
> > > this for well over a decade and I'm pretty sure there are lots of
> > > other people who also do this.
> > 
> > If you are happy (as the maintainer), then fine.

Not really, I don't like it when our tools don't do the right thing,
are entirely silent about it and then I get surprised by custom
checks other people run.

> > My script just could
> > not connect those 2 email addresses.  I check for matches between the
> > address itself (the part between the <>) or a match between the "name"
> > part (before the <>).  If either matches (or it is obvious) then I
> > don't report it.

Yup, during development of the patches the names started out
matching. The SOB stayed the same but the name on the personal email
address got anglicised, hence nothing matched by the time I pulled
it with b4.

> > I have reported very few of these.
> 
> My checkpatch is happier if the whole "name <email>" string matches, but
> it'll accept name matches.  This ofc rests upon the assumption that
> I can spot the deepcake'd Dave Chinners hawking phones in Russia or
> whatever. ;)

If someone wants to fake me and do my work for me so I don't have to
do anything, I'm all for it. :)

As it is, I use the convention of putting an explicit From: tag in
the commit message that matches the SOB so tools pulling stuff from
mailing lists do the right thing with them (same as any third-party
provided patch in a series). 

> That said... I think we should get in the habit of asking patch authors
> to make sure that at least one of the email or name strings match
> between the From and SOB tags.  I can see how people who grok even less
> about how Chinese names work than I do (read: lawyers) might get fussy
> about this kind of thing.

As per above, the normal solution is an explicit "From: <foo>" line
that matches the SOB.  It's just annoying that our new-fangled tools
haven't encoded this long-standing convention to warn us when we
pull a patch with a from-tag that doesn't match a sob-tag.

And, yes, I know about git hooks - forcing every maintainer to
implement their own custom git hooks to catch errors the tool they
are all using can easily catch is not a reliable or scalable
solution. We use common tools for a reason.

-Dave.
-- 
Dave Chinner
david@...morbit.com