Open Stack

On Mon, Oct 30, 2017 at 1:53 PM, Thierry Carrez <thierry at openstack.org>
wrote:

> Luke Hinds wrote:
> > On Fri, Oct 27, 2017 at 6:08 PM, Jeremy Stanley <fungi at yuggoth.org
> > <mailto:fungi at yuggoth.org>> wrote:
> >
> >> On 2017-10-27 15:30:34 +0200 (+0200), Thierry Carrez wrote:
> >>> [...]
> >>> I think the Security project team would benefit from becoming a
> >>> proper SIG.
> >>> [...]
> >> I tend to agree, though it's worth also considering what the
> >> implications are for vulnerability management under the new model.
> >> The VMT tended to act as an independent task force in the
> >> beforetime, until the big t^W^Wproject reform of 2014, and then
> >> allied itself with the newly-formed Security Team while continuing
> >> operation autonomously under a fairly independent mandate. Does this
> >> still make sense in a Security SIG context, or should we be
> >> considering alternative (perhaps more formal?) governance for the
> >> VMT in that scenario? I don't have especially cogent thoughts around
> >> this yet, so interested to hear what others in the community think.
>
> So the activity of the Security project team can be split into a number
> of things:
>
> - Security advisories for supported projects (ossa by the VMT subteam)
> - General security notices / information (ossn)
> - Promotion of secure coding practices (bandit, syntribos)
> - Promotion of secure operations (security-doc, anchor)
> - Audit activities (security-analysis)
>
> The only thing here that is not performed by an open group is the VMT
> stuff. It also happens to be the most "upstream" of all the team
> activity: it's closely related to stable branch maintenance.
>
> Personally I think the VMT would be better split off from a Security SIG
> -- it's suboptimal to have a part of a SIG to be a restricted group. It
> could be made it's own team, or attached to an existing group (stable
> branch maintenance) or converted to a TC-owned "workgroup" (a TC
> delegation of power, like it's always been).
>
> > We discussed the SIG proposal on the security meeting and I planned to
> > invite you in for a session to discuss Thierry (apologies for being late
> > for getting this together).
> >
> > Overall folks thought it an idea worth while enough to explore further.
> >
> > My own view is that if its leads to getting more eyes on security, then
> > its a good thing. With that in mind, I had the idea that we could run a
> > "Security SIG" in parallel to the security project and see if it gains
> > traction and security minded people from the wider community do actually
> > come forward to get involved and merit the change worth while (and it's
> > not just the Security Project rearranging the furniture). We could then
> > review how its gone at the end of the Queens cycle and if a success (not
> > sure how we would define that as yet), then implement the change at the
> > juncture of a new release.
>
> Sure, we can definitely try it out and keep the project team around
> while we try. The only issue I see with that approach is that it's a bit
> confusing, and not as strong of a statement compared to saying "all the
> security activity now happens there". But if you feel more comfortable
> that way, we can definitely follow that road.
>
> --
> Thierry Carrez (ttx)


One thing came to mind on Jeremy's points around the VMT, is OSSN's

We often get a workflow where Sec-Core are brought into a private LP bug to
determine if its suitable for an OSSN, and it remains so until we release
the OSSN.

So the option here is transfer OSSN into the VMT, or we keep things as they
are.

Something else which comes to mind; it seems to me we are more of a
'working group', are working groups no longer a thing in OpenStack? - SIG
seems like a better fit for topics focused mainly on cross project
collaborations efforts (API's being a good example), whereas we have a lot
of group like tasks that we handle in silo?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171103/cf7ed932/attachment.html>