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: <ZCWXM5onHfLbcIDN@sashalap>
Date:   Thu, 30 Mar 2023 10:05:39 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     Matthew Wilcox <willy@...radead.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 Thu, Mar 30, 2023 at 12:08:01AM +0000, Eric Biggers wrote:
>Hi Sasha,
>
>On Mon, Feb 27, 2023 at 07:52:39PM -0500, Sasha Levin wrote:
>> > Sasha, 7 days is too short.  People have to be allowed to take holiday.
>>
>> That's true, and I don't have strong objections to making it longer. How
>> often did it happen though? We don't end up getting too many replies
>> past the 7 day window.
>>
>> I'll bump it to 14 days for a few months and see if it changes anything.
>
>I see that for recent AUTOSEL patches you're still using 7 days.  In fact, it
>seems you may have even decreased it further to 5 days:
>
>    Sent Mar 14: https://lore.kernel.org/stable/20230314124435.471553-2-sashal@kernel.org
>    Commited Mar 19: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=69aaf98f41593b95c012d91b3e5adeb8360b4b8d
>
>Any update on your plan to increase it to 14 days?

The commit you've pointed to was merged into Linus's tree on Feb 28th,
and the first LTS tree that it was released in went out on March 22nd.

Quoting the concern you've raised around the process:

> BTW, another cause of this is that the commit (66f99628eb24) was AUTOSEL'd after
> only being in mainline for 4 days, and *released* in all LTS kernels after only
> being in mainline for 12 days.  Surely that's a timeline befitting a critical
> security vulnerability, not some random neural-network-selected commit that
> wasn't even fixing anything?

So now there's at least 14 days between mainline inclusion and a release
in an LTS kernel, does that not conform with what you thought I'd be
doing?

Most of that additional time comes in the form of me going over the tree
and sending AUTOSEL mails a bit later, so I would be able to also pick
follow-up fixes as they come in (and drop stuff that were reverted).

As a side note, inclusion into the stable-queue which you've pointed to
above is a few steps before a release - it's mostly a cheap way for us
to get mileage out of bots that run on the queue and address issues - it
doesn't mean that the commit is released.

-- 
Thanks,
Sasha