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: <ZAx0Fhih9Ckbk07M@kroah.com>
Date:   Sat, 11 Mar 2023 13:29:10 +0100
From:   Greg KH <greg@...ah.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Willy Tarreau <w@....eu>, Matthew Wilcox <willy@...radead.org>,
        Eric Biggers <ebiggers@...nel.org>,
        Sasha Levin <sashal@...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 Sat, Mar 11, 2023 at 12:45:20PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > I believe that -stable would be more useful without AUTOSEL process.
> > > > 
> > > > There has to be a way to ensure that security fixes that weren't properly tagged
> > > > make it to stable anyway.  So, AUTOSEL is necessary, at least in some form.  I
> > > > think that debating *whether it should exist* is a distraction from what's
> > > > actually important, which is that the current AUTOSEL process has some specific
> > > > problems, and these specific problems need to be fixed...
> > > 
> > > I agree with you, that we need autosel and we also need autosel to
> > > be better.  I actually see Pavel's mail as a datapoint (or "anecdote",
> > > if you will) in support of that; the autosel process currently works
> > > so badly that a long-time contributor thinks it's worse than nothing.
> > > 
> > > Sasha, what do you need to help you make this better?
> > 
> > One would probably need to define "better" and "so badly". As a user
> > of -stable kernels, I consider that they've got much better over the
> 
> Well, we have Documentation/process/stable-kernel-rules.rst . If we
> wanted to define "better", we should start documenting what the real
> rules are for the patches in the stable tree.
> 
> I agree that -stable works quite well, but the real rules are far away
> from what is documented.
> 
> I don't think AUTOSEL works well. I believe we should require positive
> reply from patch author on relevant maintainer before merging such
> patch to -stable.

Again, for the people in the back so that everyone can hear it, that
does not work as some subsystems refuse to tag ANY patches for stable
commits, nor do they want to have anything to do with stable kernels at
all.  And that's fine, that's their option, but because of that, we have
to have a way to actually get the real fixes in those subsystems to the
users who use these stable kernels.  Hence, the AUTOSEL work.

So no, forcing a maintainer/author to ack a patch to get it into stable
is not going to work UNLESS a maintainer/author explicitly asks for
that, which some have, and that's wonderful.

thanks,

greg k-h