linux-kernel - Re: [GIT PULL] SafeSetID MAINTAINERS file update for v5.3

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: <20190805191136.GB4887@chatter.i7.local>
Date:   Mon, 5 Aug 2019 15:11:36 -0400
From:   Konstantin Ryabitsev <konstantin@...uxfoundation.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Micah Morton <mortonm@...omium.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] SafeSetID MAINTAINERS file update for v5.3

On Mon, Aug 05, 2019 at 11:20:59AM -0700, Linus Torvalds wrote:
>I don't know if it's worth changing the pr-tracker-bot rules. I *do*
>think that the whole unquoted
>
>   for you to fetch changes up to [hex string]
>
>is by far the strongest single signal for a pull request, but it's not
>clear that it's worth spending a lot of CPU time looking for that
>unless you have a strong signal in the subject line.

The way we do it currently is by hooking into public-inbox where the 
email subject is in the commit log. So for us to grab all new subjects 
it's a single git call, whereas getting the message body requires a git 
call per message. This is why we pre-filter by subject, as it's a cheap 
way to avoid needing to issue hundreds of git calls looking for possible 
matches in message bodies.

>So I consider this "solved", and maybe people should just realize that
>they won't get the automated responses unless they do everything just
>right.

Would you consider recording the message-id of the pull request as part 
of the commit message? This would be a sure way for us to be able to 
catch all possible cases. In fact, this would allow me to throw out most 
of the bot logic, as it would become unnecessary. E.g. the merge commit 
would look like:

Merge tag 'foo' of git://git.kernel.org/bar

Pull foo features

 * foo
 * bar
 * baz

Link: https://lore.kernel.org/r/<message-id>

However, I suspect that getting message-ids for all your pull requests 
would significantly complicate your workflow.

-K