linux-hardening - Re: Reported-by/Closes tag for uncommitted issues (was: Re: [PATCH v2] uml: Replace strlcpy with strscpy)

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: <a953b19efca20b470759b1d53beb957a11062ba1.camel@sipsolutions.net>
Date:   Wed, 07 Jun 2023 11:17:54 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Philip Li <philip.li@...el.com>,
        Richard Weinberger <richard@....at>
Cc:     Eric Biggers <ebiggers@...nel.org>,
        Azeem Shaikh <azeemshaikh38@...il.com>,
        Maxim Krasnyansky <maxk@....qualcomm.com>,
        anton ivanov <anton.ivanov@...bridgegreys.com>,
        linux-hardening <linux-hardening@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-um <linux-um@...ts.infradead.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        kernel test robot <lkp@...el.com>
Subject: Re: Reported-by/Closes tag for uncommitted issues (was: Re: [PATCH
 v2] uml: Replace strlcpy with strscpy)

On Wed, 2023-06-07 at 17:10 +0800, Philip Li wrote:
> > > So it seems we should ask the robot maintainers to just stop suggesting
> > > those tags?
> > 
> > Agreed.
> 
> Thanks all for the feedback. We will carefully consider how to present the
> suggestion clearly.
> 
> For now, because the bot covers both upstream and developer repos, there
> can be various situations, such as the bug is found in upstream. 

Ah yes, that was actually in my mind, but I forgot to write about it,
sorry.

I agree completely, in case that you find a bug in an already committed
tree, and there will be a separate commit to fix it, it's completely
reasonable and useful to have those tags.

> So the bot
> tries to let author decide how to apply the tags in appropriate way that
> they feel comfortable.

Right. It just seems that many authors aren't really all that familiar
with the processes yet, and take the suggestion at face value.

> In the report, we now uses phrases like below
> 
> 	If you fix the issue, kindly add following tag where applicable
> 	| Reported-by: kernel test robot <lkp@...el.com>
> 	| Closes: https://lore.kernel.org/oe-kbuild-all/202305311135.zGMT1gYR-lkp@intel.com/
> 
> But this may be not clear enough or not the best way to suggest. We will
> consider whether we can detect some situations (like RFC patch) which is
> no need for such tags to avoid confusion.
> 

Right. Maybe the only thing really needed would be to say something like

"If you fix the issue in a separate patch/commit (i.e. not just a new
version of the same patch/commit), kindly add ..."

or even just

"If you fix the issue in a separate commit, kindly add ..."

so it's clear that if you're changing the commit, it's not really
something that should be done? In which case probably even a Fixes tag
should be there, but I wouldn't want to recommend adding that since the
commits may still change etc.

I don't know all the processes behind it, but I'm thinking that even if
the bot picked up a patch from the list, it could get committed before
and then fixed in a separate commit.

johannes