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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
