linux-kernel - Re: [Ksummit-discuss] bug-introducing patches

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-next>] [day] [month] [year] [list]

Message-ID: <20180508205505.GD8514@sasha-vm>
Date:   Tue, 8 May 2018 20:55:07 +0000
From:   Sasha Levin <Alexander.Levin@...rosoft.com>
To:     Matthew Wilcox <willy6545@...il.com>
CC:     "Theodore Y. Ts'o" <tytso@....edu>,
        Tony Lindgren <tony@...mide.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "w@....eu" <w@....eu>,
        "ksummit-discuss@...ts.linuxfoundation.org" 
        <ksummit-discuss@...ts.linuxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ben Hutchings <ben@...adent.org.uk>
Subject: Re: [Ksummit-discuss] bug-introducing patches

On Tue, May 08, 2018 at 08:40:02PM +0000, Matthew Wilcox wrote:
>I think your sample size omits some people. I run Debian Testing on my
>laptop. That gets something akin to a Linus release pretty soon after he
>releases it, and while it gets some amount of -stable patches, it
>progresses to the next release fairly rapidly.

Debian testing is pretty much a -stable tree, see the git log history:

https://salsa.debian.org/kernel-team/linux/commits/sid

It follows a current stable tree, and moves on to the next one once it's
available (about a week after Linus releases a new kernel).

>Added Ben to the cc for more updates.
>
>I think Fedora does something similar.

Fedora's rawhide is just (daily?) builds of Linus's tree, they don't
care what stage the tree is in at any point.

My point is that no one picks a release and sticks with it more than a
week. If someone plans to use a release for longer term they use a
-stable tree, and if they are interested in testing, they move on to the
next release once it's available.

There's no one, for example, who picked up vanilla v4.16 and plans to
keep using it for a year.

This leads to my point about rushing fixes: -stable releases for v4.16 are
done weekly, there's no need to rush them in during v4.16-rc8 just to
make some imaginary release no one will pick up.