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]

Message-ID: <20161205135824.GA30013@kroah.com>
Date:   Mon, 5 Dec 2016 14:58:24 +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>
Subject: Re: [RFC PATCH] doc: change the way how the stable backport is
 requested

On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote:
> On Mon 05-12-16 13:52:36, Greg KH wrote:
> > 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.
> 
> Are you really tracking all those discussion to catch resulting patches
> in the Linus' tree? I simply fail to see a point having N versions of
> the patch on the stable mailing list before it gets picked up from the
> _Linus'_ anyayw.

I do scan them, sometimes I even find problems with them (like a zram
"fix" that went by this weekend.)  So yes, it is always good to have
more reviewers on patches, don't you think?

> > I don't think anyone has ever complained of this before, do you?
> 
> This is the reason I have stopped following the stable mailing list.
> The noise level is just too high.

What "noise"?  It's all patches that are being addressed to the stable
kernels, how is that off-topic?  What do you expect to be posted to this
list?

> > > 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.
> 
> Rare, still annoying and unnecessarily error prone. Btw. even git
> send-email will not cope with Cc: stable # version properly... Here is
> what I get when not using --suppress-cc=body on this particular patch
> :From: Michal Hocko <mhocko@...nel.org>
> :To: LKML <linux-kernel@...r.kernel.org>
> :Cc: Michal Hocko <mhocko@...e.com>,
> :        stable@...r.kernel.org,
> :        #,
> :        $version
> :Subject: [RFC PATCH] doc: change the way how the stable backport is requested

People are working on the "# 4.4+" issue in git right now, there was a
thread about it last week.

> > > 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?
> 
> I completely see this argument. It will take some time for people to
> adapt any changes in the workflow. No question about that. I just
> believe that a less error prone process would be more comfortable long
> term. Making stable ML being only about stable related patches and the
> follow up discussions sounds like an improvemnt to me as well.

But the stable ML is only about stable related patches today, how would
that change?

thanks,

greg k-h