openstack team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

Lloyd Dewolf wrote:
> [...]
> I do have a couple of serious concerns:
> [...]
> Every sentence in the first paragraph is dripping with negativity
> - "will not give prior notice to their employer"
> - "not about getting advance notice"
> - "reduce the disclosure of vulnerability in the early stages"

This page is work in progress policy for the vulnerability management
team. The more public-oriented contents of the proposed
openstack.org/security page, as brainstormed by all people that have
shown interest in security at the last design summit, is here:

http://etherpad.openstack.org/8hWNQwkWf9

You won't find so much negativity there.

> What I hear when I read that is that we have the most serious issues
> of professionalism among us -- crazy, embarrassing issues! That I've
> just jumped into a nest of vipers -- Josh and Chris didn't say
> anything about my impending death when they got me to join!
> Thankfully, I very much doubt this is the reality! -- it wasn't at the
> meetup I was at last night.
> 
> So is there a non-negative way of articulating this? *once*

This is actually linked to the next section. If you limit the numbers of
members in a vulnerability handling team, you create resentment with
those members or companies that are not part of it. The phrasing is
there to reassure non-members that there is no advantage for being "in".
The members will not abuse the fact that they are privileged. This is a
technical page oriented towards team members. I prefer to call a "cat" a
"cat", rather than "feline predator" because its less negative.

> B. Maximum of 3 people. This may have caused my heart to skip a beat.
> Is there a reference implementation of this? Who's successes are we
> emulating?
> 
> Having spent 2 years on Mozilla's private security list in a former
> life, and five years being party to every WordPress security issue [3]
> only 3 people is madness.
> [...]

The Vulnerability management team is all about managing disclosure. The
members control which groups to include in the "know", in order to give
a timely response while limiting the risk of accidental disclosure.

The number of "3" is not about the number of people that will know about
the vulnerability. It's about the number of people who are tasked to
deal with it in the first place. For example, the first thing we do
(after confirming the flaw) is include the PTL of the affected project.

Increasing this number to include "anyone that demonstrated value and
professionalism" does not help. You don't need people that just like to
be kept in the loop. You don't need bystanders that will handle one
vulnerability every year. You need people actively participating and
committed to owning the process of private vulnerability fixing.

As soon as you say "anyone that demonstrated value and professionalism"
you are talking about dozens of people. And with them comes an increased
risk of leakage. There is no way to keep a secret in a group of more
than 6 people. So you basically assume that the vulnerability is almost
public.

In every project with a large first-line group handling incoming issues,
you end up having reporters submitting their most serious
vulnerabilities to a handful of people they know, rather than sending to
the list. That's what I want to avoid. Having a group too large to be
used for anything serious. That's the drawback of "more".

I want to turn the question around: why do *you* want more ?

> [...]
> Even ignoring that, do three people alone have the stamina to
> investigate and deal with *all* the false reports. ;-)

There might not be as many reports as you'd think. This is not Wordpress
or Mozilla. If we can't keep up with the flow, we'll add new members for
sure.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack