linux-kernel - Re: Fw: [PATCH 0/2] feat: checkpatch: prohibit Buglink: and warn about missing Link:

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b76cd99552c135629ab8e52d3e929916c7965a14.camel@perches.com>
Date:   Mon, 05 Dec 2022 23:44:52 -0800
From:   Joe Perches <joe@...ches.com>
To:     Thorsten Leemhuis <linux@...mhuis.info>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kai Wasserbäch <kai@....carbon-project.org>
Subject: Re: Fw: [PATCH 0/2] feat: checkpatch: prohibit Buglink: and warn
 about missing Link:

On Tue, 2022-12-06 at 08:17 +0100, Thorsten Leemhuis wrote:
> On 06.12.22 07:27, Thorsten Leemhuis wrote:
> > On 06.12.22 06:54, Joe Perches wrote:
[]
> > > and perhaps a more
> > > generic, "is the thing in front of a URI/URL" a known/supported entry,
> > > instead of using an known invalid test would be a better mechanism.
> > 
> > Are you sure about that? It's not that I disagree completely, but it
> > sounds overly restrictive to me and makes it harder for new tags to
> > evolve in case we might want them.

It's easy to add newly supported values to a list.

> > And what tags would be on this allow-list? Anything else then "Link" and
> > "Patchwork"? Those are the ones that looked common and valid to me when
> > I ran
> > 
> > git log --grep='http' v4.0.. | grep http | grep -v '    Link: ' | less
> > 
> > and skimmed the output. Maybe "Datasheet" should be allowed, too -- not
> > sure.
[]
> > But I found a few others that likely should be on the disallow list:
> > "Closes:", "Bug:", "Gitlab issue:", "References:", "Ref:", "Bugzilla:",
> > "RHBZ:", and "link", as "Link" should be used instead in all of these
> > cases afaics.

Do understand please that checkpatch will never be perfect.
At best, it's just a guidance tool.

To me most of these are in the noise level, but perhaps all should just
use Link:

$ git log -100000 --format=email -P --grep='^\w+:[ \t]*http' | \
  grep -Poh '^\w+:[ \t]*http' | \
  sort | uniq -c | sort -rn
 103889 Link: http
    415 BugLink: http
    372 Patchwork: http
    270 Closes: http
    221 Bug: http
    121 References: http
    101 v1: http
     77 Bugzilla: http
     60 URL: http
     59 v2: http
     37 Datasheet: http
     35 v3: http
     19 v4: http
     12 v5: http
      9 Ref: http
      9 Fixes: http
      9 Buglink: http
      8 v6: http
      8 Reference: http
      7 V1: http
      7 See: http
      6 1: http
      5 link: http
      4 v7: http
      4 v0: http
      4 0: http
      3 LINK: http
      3 Link:http
      3 IGT: http
      2 V3: http
      2 Schematics: http
      2 RHBZ: http
      2 RFC: http
      2 Reported: http
      2 MR: http
      2 Bugs: http
      2 BUG: http
      2 2: http
      1 Website: http
      1 V9: http
      1 v9: http
      1 V8: http
      1 v8: http
      1 V7: http
      1 V6: http
      1 V5: http
      1 V4: http
      1 V2: http
      1 v1:http
      1 v10: http
      1 Twitter: http
      1 tree: http
      1 tool: http
      1 tests: http
      1 tasks: http
      1 SPI: http
      1 Source: http
      1 SoM: http
      1 Reproducer: http
      1 reliable: http
      1 Related: http
      1 Reference:http
      1 Mesa: http
      1 Lore: http
      1 Links:http
      1 Links: http
      1 Link:  http
      1 ink: http
      1 in: http
      1 here: http
      1 bz: http
      1 Bug:http
      1 AlsaInfo: http