linux-kernel - Re: [RFC PATCH] doc: change the way how the stable backport is requested

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]

Date:   Mon, 5 Dec 2016 13:52:36 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Stable tree <stable@...r.kernel.org>,
        Andy Lutomirski <luto@...capital.net>,
        Willy Tarreau <w@....eu>, Jiri Kosina <jkosina@...e.cz>,
        Michal Hocko <mhocko@...e.com>
Subject: Re: [RFC PATCH] doc: change the way how the stable backport is
 requested

On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote:
> From: Michal Hocko <mhocko@...e.com>
> 
> Currently if a patch should aim a stable tree backport one should add
> 
> Cc: stable@...r.kernel.org # $version
> 
> to the s-o-b block. This has two major disadvantages a) it spams the
> stable mailing list with patches which are just discussed and not merged
> yet

That's not a problem in that I know I like to see them to give me a
"heads up" that something is coming down the pipeline soon.  I don't
think anyone has ever complained of this before, do you?

> and b) it is easy to make a mistake and disclose a patch via
> git-send-email while it is still discussed under security embargo.

Having this happen only once (maybe twice) in a over a decade really
isn't that bad of odds.  We have loads of embargoed security patches
that properly include the cc: stable tag, yet don't leak the patch to
the public mailing list.  So this really is a rare thing to have happen.
(also when it did happen, no one except me seemed to notice it, which
was pretty funny in itself...)

> In fact it is not necessary to have the stable mailing list address in
> the Cc until it hits the Linus tree and all we need is to have a
> grepable marker for automatic identification of such a patch. Let's
> use
> 
> stable-request: $version[s]
> 
> instead. Where $version would tell which stable trees might be
> interested in the backport. This will make the process much less error
> prone without any actual downsides.

We still have whole subsystems that have yet to learn about how to put
proper "cc: stable@..." in their patches, why do we want to change the
muscle memory of those that are doing the right thing to now have to do
something else?

So I don't think we need this change, let's just keep things as they
are.  If more and more people get sloppy and mess up, we can revisit it
then.

thanks,

greg k-h