linux-kernel - Re: [v4] checkpatch: add support to check 'Fixes:' tag format

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] [day] [month] [year] [list]

Message-ID: <975e6172-b333-37ab-ccc7-9e9a85986dfe@web.de>
Date:   Sun, 3 May 2020 14:32:26 +0200
From:   Markus Elfring <Markus.Elfring@....de>
To:     Wang YanQing <udknight@...il.com>, Joe Perches <joe@...ches.com>,
        Andy Whitcroft <apw@...onical.com>,
        kernel-janitors@...r.kernel.org, linux-doc@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Matteo Croce <mcroce@...hat.com>
Subject: Re: [v4] checkpatch: add support to check 'Fixes:' tag format

>>> +				$diagnostics .= "Missing a pair of parentheses '()' or a pair of double quotation marks (\"\").\n";
>>
>> Can such a message trigger any more thoughts and development ideas?
>
> No, I don't think so. '(" ... ")' is the minimum interface between analyser
> (checkpatch) and commit id description (normal commit id and 'Fixes:' tag)

* I am proposing to recheck the influence of quotation character alternatives
  also at this place.

* How do you think about to provide an information without the word “or”
  in error messages?


> about the title, it is very difficult if not impossible to guess the title
> boundary and whether it is the *REAL* title that folllow the SHA1 without
> this precondition,

I find this concern reasonable.


> and it is more difficult to do it when we need to support
> title which across lines in the normal commit id description.

I imagine that further software design options can be considered.


> At last I really doubt the benefit it brings deserves the complexity and the
> current diagnostics info is enough clear for most situation.

* Will a safer data format description trigger corresponding efforts?

* Will the structure of the commit title matter?

* Would you like to improve checks (and program organisation) besides
  the application of regular expressions?

Regards,
Markus