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: <CAKXUXMy2hutuTP1Z3+wt3AxKuSx1G=vEQb8V4cPeaaba+jBPfA@mail.gmail.com>
Date:   Sat, 14 Aug 2021 10:43:00 +0200
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     Hamza Mahfooz <someguy@...ective-light.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andy Whitcroft <apw@...onical.com>,
        Joe Perches <joe@...ches.com>,
        Dwaipayan Ray <dwaipayanray1@...il.com>
Subject: Re: [PATCH] checkpatch: fix an issue regarding the git commit
 description style test

On Wed, Jul 14, 2021 at 10:26 AM Hamza Mahfooz
<someguy@...ective-light.com> wrote:
>
> If we consider the output of the following command:
>
> $ git shortlog | grep '"' | wc -l
> 14185
>
> It becomes apparent that quite a number of commits have titles that,
> contain at least one quotation mark and if you attempt to refer to those
> commits in a new patch, checkpatch throws a false positive. This is
> because, checkpatch disallows the use of quotation marks in commit titles,
> only when referring to those commits in commit descriptions.
>

Joe will certainly have the final say on this.

But just some remarks and hints from my side that might help all of us
judge this change:

14185 commits with at least one quotation mark might sound a lot, but
given that we have surpassed the one million commits, 14 thousand
commits is basically 1,4% so really a small fraction. Checkpatch is a
really large set of heuristics, many rules are much more fuzzy and
'wrong' for much larger classes than 1,4% of potential cases. So, we
are improving the heuristics here of a rule that is already very good,
compared to other checkpatch rules.

For all changes to checkpatch, that Dwaipayan (see CC), my former
mentee, contributed, we always ran a checkpatch evaluation on the
latest ~100,000 commits and checked the difference of before and after
the change to check if the change had some unexpected negative effect
besides its intended positive effect.

I would suggest that you do that too and share the results of that
evaluation with us. If you need some assistance or guidance on how to
create such a quick checkpatch evaluation, please just let Dwaipayan
and me know and we might give some further hints.

I hope this helps.

Lukas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ