Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues

[Greg KH <greg@kroah.com>]

On Tue, Sep 11, 2018 at 10:10:37AM -0700, Dave Hansen wrote:
> On 09/11/2018 01:45 AM, Greg KH wrote:
> > What do you feel we could have done "better" given the constraints
> > placed on us?
> 
> Hindsight is 20/20.  But, here are a few things I wish we would have had
> in place a year or two ago.  These are utterly _minor_ nits in the grand
> scheme of things.  Intel had the most room for improvement here, not the
> community.  But, here's what the community could have done better:
> 
> 1. Have a documented procedure for submitting issues that the submitter
>    perceives can not go to security@.  Folks are always going to think
>    they are a special snowflake.  This will get them talking to
>    *someone* at least.

We have Documentation/admin-guide/security-bugs.rst.  If you feel it is
lacking in some way that would help out here, please submit patches.

I know some people did submit patches for this after the Meltdown mess
happened to hopefully clear some things up.  Oh wait, it was you who did
that, why am I even saying this then? :)

Anyway, Willy posted a patch somewhere to also update it, but that patch
seems to have gotten dropped, we should poke him to resend it.

> 2. Document that stable updates require stable maintainers to be
>    involved.  If you want fixes in mainline, tell Linus.  If you want
>    stable fixes, tell the stable maintainers.  Also document the time
>    required to integrate a fix, even if it is a worst-case estimate.
>    (The distros who consume stable can help here, too)

Note, I don't always _have_ to be involved.  I usually don't want to be
involved.  But if you expect me to start taking random non-obvious
patches into a stable kernel, you had better get me involved, otherwise
you will start to get the "WTF" emails from me.  That's just common
sense, right?  If not, how/where do I have to document this?

Also, for some people like me, perhaps you might want to get us involved
because we happen to know a bit about security and bugfixing given we
have been doing it for many decades now (not just me, most of the
security@ people are included in that category, hence them being on that
team).  Why _wouldn't_ you want them helping to fix your problem?

> Why?  From what I've seen, the folks controlling the embargo respect
> *processes*.  A written-down document is a process that's hard to argue
> with and represents the weight of the community.  But if I tell them,
> it's just "one person's opinion".

Great, the security process page can always need help, like you
provided.  Hopefully that looks sufficient to you now?

> Giving timelines is also very important.  Folks spend a lot of time
> counting months and weeks back on the calendar from a disclosure date.
> The timeline gives them a discrete date to *do* something.

Giving timelines to whom?  Us getting a timeline or us giving a timeline
to others?  It's hard to "predict" how long some things will take to be
fixed (obviously, we once took 6 months to fix a nasty bug that some
people thought it was already resolved as they provided a proposed fix.)

thanks,

greg k-h