Some ideas for process improvements/changes

[Frank Ch. Eigler]

Hi -

> Very nice. I would not have been able to describe things so
> nicely. Thanks.

My pleasure!

> > - email to <mark@klomp.org>
> > - email to <fche@elastic.org>
> > - email to <secalert@redhat.com>
> 
> I am happy to receive such reports. And I trust the secalert team at
> Red Hat. But I would like to hear from other distro maintainers what
> they think of this policy. I would like to not give one distro or
> corporate entity preferred early notification of suspected security
> issues.

I believe there is an inter-company mailing list for high profile
security issues.  We'd eventually hear back from the RH reps on that
list.  Heck, our own RH reps could/would forward things there for high
severity things that come initially to you or me.


> Also I think we should explicitly add something like:
> 
>   We are happy to keep the security implication of a bug, or a proof
>   of concept exploit private. But unless the bug is critical we'll
>   resolve the underlying issue through the normal project development
>   processes, without mentioning the security vulnerability itself.

I can't think of much harm to mentioning security vulnerabilities by
name, should they rise to the levels to justify issuance of them at
all.  That is, we need not hide genuine security issues that happen to
be low severity.  We just wouldn't treat them with embargo or
emergency haste, but that's okay.


> To make clear we aren't going to play security embargo theater.

Not sure that's fair -- in my experience, security embargos serve a
useful purpose: in coordinating the release of a fix among distros.
That minimizes the window of vulnerability of the entire user base
between the problem becoming public and distributing its fix.  They
are thankfully rare.


- FChE