<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/30/2013 11:25 AM, Bryan D. Payne
wrote:<br>
</div>
<blockquote
cite="mid:CAFpPvXA36Sa+cRv+JdZ-GoXLC2eH5koMsTf=HQyBQhAP9gxymg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
That's certainly not true of every project. I
wouldn't want to start<br>
doing it for nova, either. It seems like completely
unnecessary<br>
duplication.<br>
<br>
</blockquote>
</div>
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.<br>
</blockquote>
<div><br>
</div>
<div>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)!</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>-bryan</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
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.<br>
</body>
</html>