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  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]
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

Powered by blists - more mailing lists