Open Stack

On 05/30/2014 10:28 AM, Clark, Robert Graham wrote:
> On 30/05/2014 18:15, "Nathan Kinder" <nkinder at redhat.com> wrote:
> 
> 
>>
>>
>> On 05/30/2014 09:36 AM, Bryan D. Payne wrote:
>>> I vote for cutting OSSN-0013-1 and then, to the extent possible,
>>> ensuring that this new one replaces the old one in all of our
>>> publication locations.
>>
>> +1.  This should replace the original published version everywhere.  The
>> only thing we can't do is to strike is the history from the mailing list
>> archive, but we can publish the new revision to the mailing lists.
>>
>> To prevent this situation in the future, we need to test any workarounds
>> that we publish in an OSSN.  I added a brief section about testing to
>> the Process page after learning about the problems with OSSN-0013
>> yesterday:
>>
>>  https://wiki.openstack.org/wiki/Security/Security_Note_Process#Testing
>>
>> Anyone reviewing a pending OSSN should not hesitate to ask if a
>> workaround has actually been tested by the author.
>>
>> I'm working on testing a new workaround for OSSN-0013.
>>
>> Thanks,
>> -NGK
>>
>>>
>>> -bryan
>>>
>>>
>>> On Fri, May 30, 2014 at 9:11 AM, Clark, Robert Graham
>>> <robert.clark at hp.com <mailto:robert.clark at hp.com>> wrote:
>>>
>>>     Mark Washenberger has pointed out a mistake in OSSN-0013, we should
>>>     fire whoever wrote that!
>>>     https://bugs.launchpad.net/ossn/+bug/1271426
>>>
>>>     Anyway, we have a few options.
>>>     Cut a completely new OSSN that supersedes 0013 and give it a normal
>>>     number and add a reference to the no longer valid 0013
>>>     Cut a new OSSN with a number derived from 0013 such as OSSN-0013-1
>>>
>>>     Followed up with what would basically be a revised announcement on
>>>     ­dev and ­security.
>>>
>>>     Thoughts?
>>>
>>>
>>>     _______________________________________________
>>>     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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Openstack-security mailing list
>>> Openstack-security at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>>
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 
> I agree, we need testing to improve the quality of the OSSNs we produce.
> However, we probably need guidance on how to do that properly. Many
> authors of OSSNs won¹t be used to standing up devstack etc. We¹ve
> previously held up OSSNs as a nice way to contribute to OpenStack
> security, particularly for those starting up. We now require authors to
> understand gerrit and the proposal is to spin up an OpenStack deployment
> to perform testing too - I wonder if this will all be a bit too much for
> your average author?

These are all very good points.  Some OSSNs are easy and require no
testing (there may be no workaround to document).  We've had a few of
these in the past 6 months that I can recall.  Other OSSNs simply
require more hands-on work.

> 
> I suppose we could create a few reference deployments and
> Grizzly,Havana,Icehouse and just try changes on the reference deployments?
> After all we are typically only talking about configuration changes rather
> than code changes, the reference deployments should stay relatively
> stable.

Where would these be hosted?

> Once consideration would be to have someone other than the author
> perform the test - thoughts?

Working with the developers from the original bug is one good route.
Given the size of the security group, there is likely a broad skill-set
including good writers, security researchers, and hands-on operators and
developers.  OSSG members can work together to produce a high-quality
validated OSSN.  I'm willing to bet that we have some members who would
be interested in testing that aren't necessarily interested in writing.

-NGK

> 
> -Rob
>