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: <20161205130507.GH30758@dhcp22.suse.cz>
Date:   Mon, 5 Dec 2016 14:05:08 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.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 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 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.

> > 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

> (also when it did happen, no one except me seemed to notice it, which
> was pretty funny in itself...)

You can be pretty sure people have noticed even when not pointing that
out as a response to the particular email...
 
> > 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.

-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ