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