Open Stack

A couple of thoughts...

* I like the idea of storing these in git.
* Perhaps including a date in the numbering of the OSSN is not needed?
 Could we just number them sequentially?

OSSN-0001
OSSN-0002
etc.

If we use git and number sequentially, then it would be easy to just grab
the next number when writing a new OSSN.  I also really like the idea of
doing the reviews in gerrit rather than launchpad / email.

-bryan



On Fri, Jan 17, 2014 at 4:36 AM, Ahmed Aley <ahmeda at cs.umu.se> wrote:

> 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
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140117/76b0add5/attachment.html>