Open Stack

On 08/30/2013 11:25 AM, Bryan D. Payne wrote:
>
>         That's certainly not true of every project.  I wouldn't want
>         to start
>         doing it for nova, either.  It seems like completely unnecessary
>         duplication.
>
>     The distinction we are making on Keystone is that the Bug
>     describes the problem, and the Blueprint describes a solution.  It
>     allows vetting  competing solutions for the same issue at design time.
>
>
> Based on this conversation, I'd say that *if* projects use this method 
> of Bug + Blueprint(s), then tagging the bugs for security impact seems 
> reasonable and is a nice way to start engaging the security community 
> at this earlier stage in the process.  In short, please tag away (as 
> appropriate)!
>
> For the remaining projects, we can continue to think about this and 
> find ways to engage the security community with those as well.  One 
> thing that can always be done is to have someone on the project simply 
> contact this mailing list and ask for eyes / help.  A manual process, 
> while not perfect, is certainly better than no process at all.
>
> Cheers,
> -bryan
>
I would add that a Security Team member can always chose to add a bug 
with Security Impact once they've identified a Blueprint that they want 
to track.  The BP, the bug, and the reviews that fix should all be 
linked.  That way, Launchpad becomes our system of record.  We can make 
it optional.    I don't think that, short of updating the Blueprint 
software, we have a real alternative yet. The alternative it to maintain 
something like an Etherprad with a list of SecurityImpact blueprints.  
That is even more overhead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130830/b013ff2f/attachment.html>