Open Stack

On 16/01/2014 11:30, Ahmed Aley wrote:
> Hi,
>
> How about having it like this:
> OSSA-2014-01, OSSA-2014-02, OSSA-2014-03
> OSSN-0114, OSSN-0214, OSSN-0314
>
> This way you keep the relative ordering for both and it is easy to see
> when was what issued with no confusion. I would also suggest adding
> categories to OSSN, e.g, instead of OSSN-0114 have something like
> OSSN-NO-0114 where the extra NO (or GL or something) in the middle
> indicates an acronym for the project (Nova).
>
> --Ahmed
>
> On Tue, Jan 14, 2014 at 10:37 AM, Thierry Carrez <thierry at openstack.org
> <mailto:thierry at openstack.org>> wrote:
>
>     Nathan Kinder wrote:
>      >> One note I would use the same number sequence, e.g.:
>      >
>      >> OSSA-2014-01 OSSA-2014-02 OSSN-2014-03
>      >
>      >> The reason for this: "OSSA-2014-01" vs "OSSN-2014-01" is kind of
>      >> messy, harder to search/etc. Also I would advice using more than 2
>      >> digits (3 should be safe).
>      >
>      > I like it.  That prevents the OSSA/OSSN confusion problem and it also
>      > has the benefit of allowing us to easily compare the publishing date
>      > between an OSSA and OSSN.
>
>     I think it actually increases the confusion, and we'd need to build some
>     central numbering authority to make sure we don't reuse the same
>     number...
>
>     OSSAs (and CVEs) are vulnerabilities, so they are serial events very
>     related to the time of their publication, hence the numbering. OSSNs are
>     more like security best practices: and those are permanent, eternal and
>     their order doesn't matter that much. What you need is a convenient way
>     to uniquely identify them, and then a mechanism to publish updated
>     version of them if need be.
>
>     For example you could use a single serial number with a date-based
>     edition version, like "OSSN 12 (2014-01-20 edition)". That would let you
>     revisit some topics as the software evolves over time.
>
>     (In summary, OSSAs are like a calendar with events, while OSSNs are like
>     a reference book with chapters. You would not number book chapters after
>     the date the chapter was originally written).
>
>     About CVEs: since anybody can request a CVE to be assigned about a
>     specific issue and everyone has a different opinion on what constitues a
>     "vulnerability", there have been a number of issues in the past that had
>     CVE assigned to them and did not trigger an OSSA. They tend to fall into
>     two categories though: CVE assigned by the VMT but not triggering an
>     OSSA, or CVE assigned by some other party (generally a distribution).
>     For that reason I don't think you need to be concerned too much about
>     CVE assignment. To handle the corner case where one is warranted but
>     nobody ever assigned one, you can always ask the VMT or this list
>     for one.
>
>     --
>     Thierry Carrez (ttx)
>
>
>     _______________________________________________
>     Openstack-security mailing list
>     Openstack-security at lists.openstack.org
>     <mailto:Openstack-security at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>

I don't see OSSN's changing over time, they're not really written like 
that. A typical OSSN say's "This affects releases X,Y,Z" If a future 
release was affected I'd expect a new OSSN to be created and a link to 
the old one placed in the references section of the OSSN.

I'm not sure adding in an abbreviated service parameter 'OSSN-NO-0023'is 
worth doing, it makes the whole thing harder to read. We'll maintain a 
directory of OSSNs before long and we can easily have them sortable by 
service. There's also the possibility that in some cases an OSSN will 
cover more than one service, like a combined vulnerability with Nova and 
Glance for example.
-Rob