linux-kernel - Re: [PATCH v2] checkpatch: improve email parsing

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: <CABJPP5D3xVKGC2ESwQbgO4_5eEB5A1JFxKB-ghCOsWGU3FoEbg@mail.gmail.com>
Date:   Wed, 4 Nov 2020 01:32:41 +0530
From:   Dwaipayan Ray <dwaipayanray1@...il.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Lukas Bulwahn <lukas.bulwahn@...il.com>,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Aditya Srivastava <yashsri421@...il.com>
Subject: Re: [PATCH v2] checkpatch: improve email parsing

On Wed, Nov 4, 2020 at 1:02 AM Joe Perches <joe@...ches.com> wrote:
>
> On Tue, 2020-11-03 at 09:10 +0100, Lukas Bulwahn wrote:
> > Maybe you can coordinate among each other who would want to create
> > suitable fix rules here?
>
> Yes please.
>
> > Also, start with the class of the most frequent mistakes for
> > unexpected content after email addresses.
> >
> > I imagine that a maintainer can simply run a tag sanitizing script
> > which just cleans up those stupid mistakes before creating their git
> > trees or sending git pulls to Linus.
>
> Does anyone really do that?
> It generally requires rebasing or post processing each commit after
> being committed before another commit occurs.
>
> > Let us try to add these
> > sanitizing rules to checkpatch.pl with fix options for now; if that
> > sanitizing feature becomes a monster script of its own within
> > checkpatch.pl, we can refactor that into an independent script for
> > cleaning up.
>
> I rather doubt an independent script is going to be worthwhile
> as these rules shouldn't be all that complex.
>
> The only prefixes acceptable for a stable address should be
> CC:|Cc:|cc:.  There are 2 uses in the last 100k commits for
> Signed-off-by: and Acked-by: with stable addresses, those should have a
> message/warning emitted in the future.
>
> The forms used with those cc: stable addresses:
>
> 2777    stable without comment
> 1381    stable # comment
> 74      stable [ comment ]
>
> So I suggest standardizing on no comment and # comment with any other
> style getting a warning.
>
> For non-stable <foo>-by: and cc: addresses and other signatures:
>
> Likely any content after a email address other than a parenthesized
> block should have some checkpatch message emitted.
>
> This should be OK:
>
> Signed-off-by: Full Name (comment) <address@...ain.tld> (maintainer:...)
>
> But perhaps this should not be OK:
>
> Signed-off-by: Full Name (comment) <address@...ain.tld> # comment
>
> There are 316 uses of this # comment style in the last 100k commits
> and 103 with (comment) after the address.
> Maybe the # use should be ok, maybe not.
>
> And anyone that uses a multiple comments in a name or a even
> a single comment in the email address should also get warned.
>
> The below should not be OK even if actually valid address forms:
>
> Signed-off-by: Full (comment1) Name (comment2) <address@...ain.tld>
> Signed-off-by: Full Name <address@(comment)domain.tld>
>

Thanks for your time and review.

I will try to handle these in my next iteration.
Probably there could be extra warnings under
BAD_SIGN_OFF to handle these cases.

Am currently looking to achieve the following:
- unexpected content after email
- Use of multiple name comments
- Use of comments in between address
- stable@...r signoffs

Thanks & Regards,
Dwaipayan.