<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>