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: <792F4759-EA33-48B8-9AD0-FA14FA69E86E@kernel.org>
Date: Mon, 21 Oct 2024 21:54:53 -0700
From: Kees Cook <kees@...nel.org>
To: Sasha Levin <sashal@...nel.org>, torvalds@...ux-foundation.org
CC: ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: linus-next: improving functional testing for to-be-merged pull requests



On October 21, 2024 9:07:13 AM PDT, Sasha Levin <sashal@...nel.org> wrote:
>In an attempt to address the concerns, we're trying out a new "linus-next"
>tree is being created and maintained with the following characteristics:
>
>	1. Composed of pull requests sent directly to Linus
>
>	2. Contains branches destined for imminent inclusion by Linus

But this means hours or a day or 2 at most.

>	3. Higher code quality expectation (these are pull requests that
>	maintainers expect Linus to pull)

Are people putting things in linux-next that they don't expect to send to Linus? That seems like the greater problem.

>	4. Continuous tree (not daily tags like in linux-next),
>	facilitating easier bisection

I'm not sure how useful that is given the very small time window to find bugs.

>The linus-next tree aims to provide a more stable and testable
>integration point compared to linux-next,

Why not just use linux-next? I don't understand how this is any different except that it provides very little time to do testing and will need manual conflict resolutions that have already been done in linux-next.

How about this, instead: no one sends -rc1 PRs to Linus that didn't go through -next. Just have a bot that replies to all PRs with a health check, and Linus can pull it if he thinks it looks good. 

For example, for a given PR, the bot can report:

- Were the patches CCed to a mailing list?
- A histogram of how long the patches were in next (to show bake times)
- Are any patches associated with test failures? (0day and many other CIs are already running tests against -next; parse those reports)

We could have a real pre-submit checker! :)

-Kees

-- 
Kees Cook

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ