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: <ba953e75-d069-47e8-a467-217d4c600f5b@leemhuis.info>
Date:   Thu, 8 Dec 2022 14:18:30 +0100
From:   Thorsten Leemhuis <linux@...mhuis.info>
To:     Joe Perches <joe@...ches.com>
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 06.12.22 10:21, Joe Perches wrote:
> On Tue, 2022-12-06 at 09:50 +0100, Thorsten Leemhuis wrote:
>> On 06.12.22 08:44, Joe Perches wrote:
>>> 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.
>>
>> Of course -- and that's actually a reason why I prefer a disallow list
>> over an allow list, as that gives guidance in the way of "don't use this
>> tag, use Link instead" instead of enforcing "always use Link: when
>> linking somewhere" (now that I've written it like that it feels even
>> more odd, because it's obvious that it's a link, so why bother with a
>> tag; but whatever).
>>
>> I also think the approach with a disallow list will not bother
>> developers much, while the other forces them a bit to much into a scheme.
>>
>>> 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
>
>> Ha, I considered doing something like that when I wrote my earlier mail,
>> but was to lazy. :-D thx!
>>
>> Yeah, they are not that often, but I grew tired arguing about that,
>> that's why I think checkpatch is the better place and in the better
>> position to handle that.
> 
> I'm not sure that "Patchwork:" is a reasonable prefix.
> Is that documented anywhere?
> 
>> Anyway, so how to move forward now? Do you insist on a allow list (IOW:
>> a Link: or Patchwork: before every http...)? Or is a disallow list with
>> the most common unwanted tags for links (that you thankfully compiled)
>> fine for you as well?
> 
> Maybe
> ---
>  scripts/checkpatch.pl | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 1c3d13e65c2d0..a526a354cdfbc 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3250,6 +3250,13 @@ sub process {
>  			$commit_log_possible_stack_dump = 0;
>  		}
>  
> +# Check for odd prefixes before a URI/URL
> +		if ($in_commit_log &&
> +		    $line =~ /^\s*(\w+):\s*http/ && $1 !~ /^(?:Link|Patchwork)/) {
> +			WARN("PREFER_LINK",
> +			     "Unusual link reference '$1:', prefer 'Link:'\n" . $herecurr);
> +		}
> +

One more thing: That afaics would result in a warning when people use
things like "v1: https://example.com/somewhere", which some people
apparently like. Those imho are not considered tags, hence I'd say we
allow them, unless you disagree.

Ciao, Thorsten