<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 17, 2014 at 1:22 PM, Clark, Robert Graham <span dir="ltr"><<a href="mailto:robert.clark@hp.com" target="_blank">robert.clark@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 16/01/2014 11:30, Ahmed Aley wrote:<br>
> Hi,<br>
><br>
> How about having it like this:<br>
> OSSA-2014-01, OSSA-2014-02, OSSA-2014-03<br>
> OSSN-0114, OSSN-0214, OSSN-0314<br>
><br>
> This way you keep the relative ordering for both and it is easy to see<br>
> when was what issued with no confusion. I would also suggest adding<br>
> categories to OSSN, e.g, instead of OSSN-0114 have something like<br>
> OSSN-NO-0114 where the extra NO (or GL or something) in the middle<br>
> indicates an acronym for the project (Nova).<br>
><br>
> --Ahmed<br>
><br>
> On Tue, Jan 14, 2014 at 10:37 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>>> wrote:<br>
><br>
> Nathan Kinder wrote:<br>
> >> One note I would use the same number sequence, e.g.:<br>
> ><br>
> >> OSSA-2014-01 OSSA-2014-02 OSSN-2014-03<br>
> ><br>
> >> The reason for this: "OSSA-2014-01" vs "OSSN-2014-01" is kind of<br>
> >> messy, harder to search/etc. Also I would advice using more than 2<br>
> >> digits (3 should be safe).<br>
> ><br>
> > I like it. That prevents the OSSA/OSSN confusion problem and it also<br>
> > has the benefit of allowing us to easily compare the publishing date<br>
> > between an OSSA and OSSN.<br>
><br>
> I think it actually increases the confusion, and we'd need to build some<br>
> central numbering authority to make sure we don't reuse the same<br>
> number...<br>
><br>
> OSSAs (and CVEs) are vulnerabilities, so they are serial events very<br>
> related to the time of their publication, hence the numbering. OSSNs are<br>
> more like security best practices: and those are permanent, eternal and<br>
> their order doesn't matter that much. What you need is a convenient way<br>
> to uniquely identify them, and then a mechanism to publish updated<br>
> version of them if need be.<br>
><br>
> For example you could use a single serial number with a date-based<br>
> edition version, like "OSSN 12 (2014-01-20 edition)". That would let you<br>
> revisit some topics as the software evolves over time.<br>
><br>
> (In summary, OSSAs are like a calendar with events, while OSSNs are like<br>
> a reference book with chapters. You would not number book chapters after<br>
> the date the chapter was originally written).<br>
><br>
> About CVEs: since anybody can request a CVE to be assigned about a<br>
> specific issue and everyone has a different opinion on what constitues a<br>
> "vulnerability", there have been a number of issues in the past that had<br>
> CVE assigned to them and did not trigger an OSSA. They tend to fall into<br>
> two categories though: CVE assigned by the VMT but not triggering an<br>
> OSSA, or CVE assigned by some other party (generally a distribution).<br>
> For that reason I don't think you need to be concerned too much about<br>
> CVE assignment. To handle the corner case where one is warranted but<br>
> nobody ever assigned one, you can always ask the VMT or this list<br>
> for one.<br>
><br>
> --<br>
> Thierry Carrez (ttx)<br>
><br>
><br>
> _______________________________________________<br>
> Openstack-security mailing list<br>
> <a href="mailto:Openstack-security@lists.openstack.org">Openstack-security@lists.openstack.org</a><br>
</div></div>> <mailto:<a href="mailto:Openstack-security@lists.openstack.org">Openstack-security@lists.openstack.org</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security</a><br>
><br>
><br>
<br>
I don't see OSSN's changing over time, they're not really written like<br>
that. A typical OSSN say's "This affects releases X,Y,Z" If a future<br>
release was affected I'd expect a new OSSN to be created and a link to<br>
the old one placed in the references section of the OSSN.<br>
<br>
I'm not sure adding in an abbreviated service parameter 'OSSN-NO-0023'is<br>
worth doing, it makes the whole thing harder to read. We'll maintain a<br>
directory of OSSNs before long and we can easily have them sortable by<br>
service. There's also the possibility that in some cases an OSSN will<br>
cover more than one service, like a combined vulnerability with Nova and<br>
Glance for example.<br>
-Rob<br>
</blockquote></div><br></div><div class="gmail_extra">Makes sense.<br><br></div><div class="gmail_extra">--Ahmed<br></div></div>