linux-kernel - Re: AUTOSEL process

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: <Y/7rYr92A2BNEyZ2@kroah.com>
Date:   Wed, 1 Mar 2023 07:06:26 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Slade Watkins <srw@...dewatkins.net>
Cc:     Sasha Levin <sashal@...nel.org>,
        Amir Goldstein <amir73il@...il.com>,
        Eric Biggers <ebiggers@...nel.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org
Subject: Re: AUTOSEL process

On Tue, Feb 28, 2023 at 09:05:16PM -0500, Slade Watkins wrote:
> On 2/28/23 06:28, Greg KH wrote:
> >> But just so you know, as a maintainer, you have the option to request that
> >> patches to your subsystem will not be selected by AUTOSEL and run your
> >> own process to select, test and submit fixes to stable trees.
> > 
> > Yes, and simply put, that's the answer for any subsystem or maintainer
> > that does not want their patches picked using the AUTOSEL tool.
> > 
> > The problem that the AUTOSEL tool is solving is real, we have whole
> > major subsystems where no patches are ever marked as "for stable" and so
> > real bugfixes are never backported properly.
> 
> Yeah, I agree.
> 
> And I'm throwing this out here [after having time to think about it due to an
> internet outage], but, would Cc'ing the patch's relevant subsystems on AUTOSEL
> emails help? This was sort of mentioned in this email[1] from Eric, and I
> think it _could_ help? I don't know, just something that crossed my mind earlier.

I don't know, maybe?  Note that determining a patch's "subsystem" at
many times is difficult in an automated fashion, have any idea how to do
that reliably that doesn't just hit lkml all the time?

But again, how is that going to help much, the people who should be
saying "no" are the ones on the signed-off-by and cc: lines in the patch
itself.

thanks,

greg k-h