Open Stack

On Fri, Jan 17, 2014 at 1:22 PM, Clark, Robert Graham
<robert.clark at hp.com>wrote:

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

Makes sense.

--Ahmed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140117/ec11914e/attachment.html>