Re: [openstack-dev] [all] [security] Security SIG

[Rob C]

This is an important evolution for the security group / project / SIG!

Congratulations everyone on taking things this far and to Luke for your
excellent stewardship.

-Rob

On Thu, Dec 14, 2017 at 5:30 PM, Luke Hinds  wrote:

> Hi All,
>
> Following on from the mailing list discussion [0], we now plan to change
> the Security Project into a Special Interest Group (The Security SIG).
>
> SIGs are a good match for an activity that centers around a topic or
> practice that spans all the community (developers, operators, end
> users...), by forming a guild of people with a shared interest. This rings
> especially true for security, where changes are often needed cross-project
> and not in a silo. A SIG will also (we hope) encourage more user /
> operator involvement and lead to discussions of field centric security
> pains, which can then be realised as specs and code.
>
> One key point , there will be no change in our overall operations and
> working structure. We will still continue to manage and care for the
> Security Guide, OSSNs, Bandit, Threat Reviews, Syntribos as well as
> encourage and incubate new security projects. We will of course also
> continue to work with the VMT, and will keep a Sec-Core group for launchpad
> that can work with embargoed issues.
>
> The plan is to make the change at the coming release juncture (Queens ->
> Rocky).
>
> Shortly I will follow up with a PTG planning etherpad with a view to
> encourage projects and operators / users to seed security related
> discussions within the SIGs PTG room. We will also perform an s/Security
> Group/Security SIG in the docs and Wiki around the time of the PTG / post
> Queens release.
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2017-
> October/124053.html
>
> Best Regards,
>
> Luke
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [elections][security] Candidacy for Security Project PTL (Queens)

[Rob C]

+1

Luke has been an excellent contributor to the Security project and would be
an excellent PTL to take the project forward.



On Tue, Aug 1, 2017 at 8:30 AM, Luke Hinds  wrote:

> Hello All,
>
> I would like to announce my candidacy for Security Project PTL for
> Queens.
>
> I have been a member of the Security Project for 2-3 years, and a
> core member for one year.
>
> During my tenure as core I have managed public and embargoed security
> notes and contributed with my feedback to the VMT team on OpenStack
> vulnerabilities.
>
> I have also been an active contributor to the security guide as well as a
> regular reviewer. I am the current driver for the security guide
> launchpad page.
>
> As PTL, I'd like to focus on the following things:
>
> * Documentation
>
> I am currently planning a revamp of the Security guide to bring it up to
> date with Pike. To do this I will reach out to other projects to help
> validate the information in the guide is technically correct and up to
> date.
>
> I also would like to migrate the checklists into a format that can be
> easily filtered to a specific release, thereby allowing other security
> tools and processes to easily consume the content and gain a snapshot
> of what security actions are required to harden any given release.
>
> I also plan to encourage others to get involved, with topics arranged for
> the coming PTG on key management.
>
> * Support and championing of OpenStack security projects.
>
> I would like to put forward continued support by means of reviews and
> feedback for the projects currently having their home under the
> security project, and I have plans to propose further projects. Our
> close synergy with the Barbican project should continue to be fostered,
> and encouraged.
>
> * Perform Threat Analysis with further projects
>
> The Threat Analysis project has proved very useful in helping the VMT
> and operators understand the threat landscape pertinent to each OpenStack
> project. I will work with and encourage other projects to undergo threat
> analysis.
>
> * Encourage more contributions and grow some new cores
>
> The security project has lost a good number of core members due to
> companies shifting priorities, so I would like increase the projects
> exposure with blog posts to planet.openstack.org and by outreach at
> various other tech events. I see it as vital to keep the security
> project afloat, as operators rely so much on the project for
> guidance on securing OpenStack clouds.
>
> Regards,
>
> Luke Hinds (lhinds)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Security] IRC Meeting today - 1700 UTC

[Rob C]

Just a reminder for all that we'll be having a security meeting today at
the usual time.

Meeting agenda: https://etherpad.openstack.org/p/security-agenda

Cheers
-Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][tc][infra][security][stable] Proposal for shipping binaries and containers

[Rob C]

I've been out on vacation but as a circle back to normal (working!) life
I've found this thread very interesting.

I share the concerns raised about the level of resource required to back
this. I don't speak for the VMT but I agree with Jeremy that it should be
possible to provide VMT support to Kolla and their code base without
extending to the external libraries in their contain images. However, I'm
not sure that the limits of VMT coverage would be acceptable to downstream
stakeholders, for the reasons Doug has highlighted above.

Perhaps it would be useful for a spec around this, so we could collaborate
in a more structured way?

-Rob


On Wed, May 24, 2017 at 3:54 PM, Jeremy Stanley  wrote:

> On 2017-05-24 14:22:14 +0200 (+0200), Thierry Carrez wrote:
> [...]
> > we ship JARs already:
> > http://tarballs.openstack.org/ci/monasca-common/
> [...]
>
> Worth pointing out, those all have "SNAPSHOT" in their filenames
> which by Apache Maven convention indicates they're not official
> releases. Also they're only being hosted from our
> tarballs.openstack.org site, not published to the Maven Central
> Repository (the equivalent of DockerHub in this analogy).
>
> > That said, only a small fraction of our current OpenStack deliverables
> > are supported by the VMT and therefore properly security-maintained "by
> > the community" with strong guarantees and processes. So I don't see
> > adding such binary deliverables (maintained by their respective teams)
> > as a complete revolution. I'd expect the VMT to require a lot more
> > staffing (like dedicated people to track those deliverables content)
> > before they would consider those security-supported.
>
> The Kolla team _has_ expressed interest in attaining
> vulnerability:managed for at least some of their deliverables in the
> future, but exactly what that would look like from a coverage
> standpoint has yet to be ironed out. I don't expect we would
> actually cover general vulnerabilities present in any container
> images, and would only focus on direct vulnerabilities in the Kolla
> source repositories instead. Rather than extending the VMT to track
> vulnerable third-party software present in images, it's more likely
> the Kolla team would form their own notifications subgroup to track
> and communicate such risks downstream.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Security] Today's IRC meeting.

[Rob C]

Hi All,

I won't be able to make today's meeting as I'm travelling.

I've not found a chair to cover the meeting, please decide if you have a
quorum and either proceed or go back to "real life" as you see fit.

Cheers
-Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] IRC Mishaps

[Rob C]

#startmeeting in the wrong channel

#startmeeting in the right channel but at the wrong time

#startmeeting in the right channel and at the right time but someone else
already started it

I'm basically a pro at meetings.

On Thu, Feb 9, 2017 at 1:14 AM, Lana Brindley 
wrote:

> On 09/02/17 06:36, Kendall Nelson wrote:
> > Hello All!
> >
> > So I am sure we've all seen it: people writing terminal commands into
> our project channels, misusing '/' commands, etc. But have any of you
> actually done it?
> >
> > If any of you cores, ptls or other upstanding members of our wonderful
> community have had one of these embarrassing experiences please reply! I am
> writing an article for the SuperUser trying to make us all seem a little
> more human to people new to the community and new to using IRC. It can be
> scary asking questions to such a large group of smart people and its even
> more off putting when we make mistakes in front of them.
> >
> > So please share your stories!
>
> What about the one where you're conducting a private conversation in one
> window, and watching a group chat in another one, and then drop some deeply
> personal (or embarrassing!) content in the group chat instead the PM ;)
>
> L
>
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] [telemetry] How to handle security bugs

[Rob C]

You've done the right thing by posting here with the [Security] tag.

Ian has provided advice on how you might become security managed, which
is a good aspiration for any team to have.

However, if you have a serious security issue that you need help mitigating
the security project can help. We can work with you on the solution and also
issue an OpenStack Security Note to notify users of the update/patch that
they might need to apply.

Please go ahead and add me to the security bug, if required I'll add other
core-sec people as required.

Cheers
-Rob



On Tue, Jan 17, 2017 at 1:14 PM, Adam Heczko  wrote:

> Hi Julien, I think that you should follow this [1] workflow.
>
> TL;DR: Pls make sure that if the bug is serious make it private on LP so
> that only core team members can access it and propose patches. Please do
> not send patches to Gerrit review queue but rather attach it to LP bug
> ticket and discuss there. Contact VMT members to get more details on how to
> get Telemetry project covered by VMT.
>
> [1] https://security.openstack.org/vmt-process.html
>
> On Tue, Jan 17, 2017 at 1:26 PM, Julien Danjou  wrote:
>
>> Hi,
>>
>> I've asked on #openstack-security without success, so let me try here
>> insteead:
>>
>> We, Telemetry, have a security bug and we're not managed by VMT, any
>> hint as how to handle our bug? Or how to get covered by VMT? 
>>
>> Cheers,
>> --
>> Julien Danjou
>> /* Free Software hacker
>>https://julien.danjou.info */
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Rob C]

Just a quick note on Castellan, at the moment it's not a particularly
strong abstraction for key management in general, just the openstack
key management interface.

The reason this is important is because if I recall correctly, Castellan
requires a keystone token for auth. It should be no suprise that COTS
key managers, software or hardware, do not support this method of
authentication.

Unless something has changed recently, Castellan is good for allowing
teams to pivot between a local key management implementation or
Barbican but a long way from allowing a direct pivot to another key
management system.

I do recall some efforts to move beyond this limitation and implement
KMIP[1] for direct access to HSMs that support it, however I'm not sure
what the end result there was.

[1]
https://specs.openstack.org/openstack/barbican-specs/specs/mitaka/kmip-key-manager.html

On Tue, Jan 17, 2017 at 12:57 PM, Ian Cordasco 
wrote:

> On Mon, Jan 16, 2017 at 6:20 PM, Amrith Kumar 
> wrote:
> > Ian,
> >
> > This is a fascinating conversation. Let me offer two observations.
> >
> > First, Trove has long debated the ideal solution for storing secrets.
> There
> > have been many conversations, and Barbican has been considered many
> times.
> > We sought input from people who were deploying and operating Trove at
> scale;
> > customers of Tesora, self described users of the upstream Trove, and
> some of
> > the (then) active contributors who were also operators.
> >
> > The consensus was that installing and deploying OpenStack was hard enough
> > and requiring the installation of yet more services was problematic.
> This is
> > not something which singles out Barbican in any way. For example, Trove
> uses
> > Swift as the default object store where backups are stored, and in
> > implementing replication we leveraged the backup capability. This means
> that
> > to have replication, one needs to have Swift. Several deployers have
> > objected to this since they don't have swift. But that is a dependency
> which
> > we considered to be a hard dependency and offer no alternatives; you can
> > have Ceph if you so desire but we still access it as a swift store.
> > Similarly we needed some capabilities of job scheduling and opted to use
> > mistral for this; we didn't reimplement all of these capabilities in
> Trove.
> >
> > However, when it comes to secret storage, the consensus of opinion is
> > Yet another service.
>
> So, what spurred this thread is that I'm currently working on Craton
> which wants to store deployment secrets for operators and I've
> recently received a lot of private mail about Glare and how one of its
> goals is to replace Barbican (as well as Glance).
>
> I'm quite happy that Trove has worked hard not to reimplement its
> requirements that were already satisfied by OpenStack projects. That's
> kind of what I'm hoping to help people do with Barbican in this
> thread.
>
> > Here is the second observation. This conversation reminds me of many
> > conversations from years past "Why do you want to use a NoSQL database,
> we
> > have a  database already". I've sat in on heated arguments
> > amongst architects who implemented "lightweight key-value storage based
> on
> > " and didn't use the corporate standard RDBMS.
>
> This I don't quite agree with this comparison. Surely when NoSQL came
> out, people ridiculed it for not having the same properties as RDBMS,
> but there's a large difference in people criticizing NoSQL databases
> having not used them and me asking people to use software that's
> already been audited for security and written by people who understand
> the underlying technologies.
>
> I'm sure if you said to your users and operators: "These N services
> need to store secrets and each has implemented that in its own way
> with no common configuration or storage location. None of them can
> take advantage of HSMs you have present in your infrastructure, and
> none of the people who really developed this are experts at storing
> secrets, but they tried their best!" Those operators would start to
> gnash their teeth and even maybe curse you under their breath. If you
> said "These services all need to store secrets securely, and that
> means we need to add Barbican which was written by people who took the
> time to document their threat models, perform a security analysis, and
> have worked with the larger security community to develop it." They'd
> be happier. I do understand, however, that your customers aren't
> deploying all the services that might use Barbican, and that's fine.
>
> What I'm gleaning from this conversation is that most of us have
> customers who only use 1 extra service that has a soft dependency on
> Barbican but never more than one. I have customers using Octavia and
> Magnum and a team that wants to use Craton, so it seems to me like we
> would benefit from doing the hard work of deploying Barbican but that
> situation is 

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Rob C]

>
>
> The last I checked, Rob, they also support DogTag IPA which is purely
> a Software based HSM. Hopefully the Barbican team can confirm this.
> --
> Ian Cordasco
>

Yup, that's my understanding too. However, that requires Barbican _and_
Dogtag, an even bigger overhead. Especially as at least historically
Dogtag has been difficult to maintain. If you have a deployment already,
there's a great synergy there. If you don't then it introduces a lot of
overhead.

I'm interested to know if an out of the box, stand alone software-only
version of Barbican would be any more appealing

Cheers
-Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Rob C]

Thanks for raising this on the mailing list Ian, I too share some of
your consternation regarding this issue.

I think the main point has already been hit on, developers don't want to
require that Barbican be deployed in order for their service to be
used.

The resulting spread of badly audited secret management code is pretty
ugly and makes certifying OpenStack for some types of operation very
difficult, simply listing where key management "happens" and what
protocols are in use quickly becomes a non-trivial operation with some
teams using hard coded values while others use configurable algorithms
and no connection between any of them.

In some ways I think that the castellan project was supposed to help
address the issue. The castellan documentation[1] is a little sparse but
my understanding is that it exists as an abstraction layer for
key management, such that a service can just be set to use castellan,
which in turn can be told to use either a local key-manager, provided by
the project or Barbican when it is available.

Perhaps a miss-step previously was that Barbican made no efforts to
really provide a robust non-HSM mode of operation. An obvious contrast
here is with Hashicorp Vault[2] which has garnered significant market
share in key management because it's software-only* mode of operation is
well documented, robust and cryptographically sound. I think that the
lack of a sane non-HSM mode, has resulted in developers trying to create
their own and contributed to the situation.

I'd be interested to know if development teams would be less concerned
about requiring Barbican deployments, if it had a robust non-HSM
(i.e software only) mode of operation. Lowering the cost of deployment
for organisations that want sensible key management without the expense
of deploying multi-site HSMs.

* Vault supports HSM deployments also

[1] http://docs.openstack.org/developer/castellan/
[2] https://www.vaultproject.io/

On Mon, Jan 16, 2017 at 4:14 PM, Ian Cordasco 
wrote:

> -Original Message-
> From: Hayes, Graham 
> Reply: OpenStack Development Mailing List (not for usage questions)
> 
> Date: January 16, 2017 at 09:26:00
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
> projects trying to avoid Barbican, still?
>
> > On 16/01/2017 13:38, Ian Cordasco wrote:
> > > Is the problem perhaps that no one is aware of other projects using
> > > Barbican? Is the status on the project navigator alarming (it looks
> > > like some of this information is potentially out of date)? Has
> > > Barbican been deemed too hard to deploy?
> >
> > I know that historically it was considered hard to do a HA deploy of
> > Barbican. When we initially evaluated DNSSEC in Designate (many years
> > ago now) it was one of the sticking points.
> >
> > This may have (and most likely has) changed, but we seem to have long
> > memories.
>
> I know Rackspace recently made Barbican available to its cloud
> customers. I suspect it's easier now to perform an HA deploy.
>
> > It could be a side effect of the Big Tent - there are so many projects
> > doing so many different things that projects don't want deployers to
> > have deploy everything.
>
> Yeah, I completely understand that. The thing is that in one case,
> there's a project that currently relies on Barbican and wants to
> replace that with a completely brand new service that will be doing
> other things and then wants to layer secrets on top of it. It seems to
> me like a terrible case of both scope creep and not actually caring
> about the security the users expect from services that have to
> interact with secrets. N services (besides Barbican) implementing
> their own secrets storage each in their own way seem like N different
> services that will be dealing with vulnerabilities and security
> releases for the next few years. Perhaps that's pessimistic, but
> looking at that with my operator hat on, I'd rather have to update *1*
> service (barbican) rather than N if there's some vulnerability that
> comes up. It's the same argument when it comes down to packaging and
> vendoring dependencies. Update once instead of N times for each
> package that has a copy of the library bundled in it.
>
> > > I really want to understand why so many projects feel the need to
> > > implement their own secrets storage. This seems a bit short-sighted
> > > and foolish. While these projects are making themselves easier to
> > > deploy, if not done properly they are potentially endangering their
> > > users and that seems like a bigger problem than deploying Barbican to
> > > me.
> >
> > +100 - One of the reasons we didn't just write our own signing was I
> > am allergic to writing crypto code - I am not very good at it, and there
> > is a project that people that either are, or know how to use the 

[openstack-dev] [Security] Shorter Meetings

[Rob C]

Hi All,

As per our IRC meeting today[1] we've decided to try shortening the
Security IRC meetings to 30 minutes per week. The other option was to have
meetings every two weeks but we all agreed that would lead to missed
meetings, confusion around holidays etc.

The main reason for shortening our meetings is because we have found that
many of our members are finding that the amount of time they have to
dedicate to OpenStack is shrinking, in response we're going to try to
shorten our meetings by being more disciplined in following our weekly
agenda[2].

I'd encourage everyone participating in the project to ensure they can make
the 30 minutes for the meeting which is every week, at 1700 UTC in the
#openstack-meeting-alt room on Freenode.

Cheers
-Rob

[1]
http://eavesdrop.openstack.org/meetings/security/2017/security.2017-01-05-16.59.html
[2] https://etherpad.openstack.org/p/security-agenda
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][release] ocata release management communication

[Rob C]

[Resending without the PTLs in CC because it got my mail stuck in the spam
filters]

I'm struggling to find good info on when the adjusted PTL nomination cycle
starts.

I've checked here: https://releases.openstack.org/ocata/schedule.
html#pike-ptls-self-nomination but it looks like the 'elections' section
was supposed to be added to the table and wasn't.

I know from the updates to the charter that the elections should happen on
or before R-3 but it doesn't provide any clarity on how much before then
the nominations should be made?

Cheers
-Rob

On Tue, Nov 1, 2016 at 7:45 PM, Doug Hellmann  wrote:

> PTLs,
>
> As we did for the Mitaka and Newton cycles, I want to start this
> cycle by making sure the expectations for communications with the
> release team are clear to everyone so there is no confusion or
> miscommunication about any of the process or deadlines. This
> email is being sent to the openstack-dev mailing list as well as
> the PTLs of all official OpenStack projects individually, to
> improve the odds that all of the PTLs see it.  I will not be
> taking the extra step of CCing individual PTLs or liaisons for
> future emails.
>
> (If you were a PTL last cycle, you may want to skip ahead to the
> Things for you to do right now section at the end.)
>
> Volunteers filling PTL and liaison positions are responsible for
> ensuring communication between project teams happens smoothly. As
> a community, we rely on three primary communication
> strategies/tools for different purposes:
>
> 1. Email, for announcements and for asynchronous communication.
>
>   We will be using the "[release]" topic tag on the openstack-dev
>   mailing list for important messages related to release
>   management.  Besides special announcements and instructions, I
>   will send the countdown emails I sent last cycle, with weekly
>   updates on focus, tasks, and upcoming dates. PTLs and release
>   liaisons should configure your mailing list subscription and
>   email client to ensure that those messages are visible (and
>   then read them) so that you are aware of all deadlines, process
>   changes, etc.
>
> 2. IRC, for time-sensitive interactions.
>
>   There are far too many of you (56) to make it realistic for the
>   three members of the release team to track you down
>   individually when there is a deadline. We need you to do your
>   part by making yourself available by configuring your IRC
>   bouncer to listen in #openstack-release. You are, of course,
>   welcome to stay in channel all the time, but you need to be
>   there at least during deadline periods (the week before and
>   week of each deadline).
>
> 3. Written documentation, for relatively stable information.
>
>   The release team has published the schedule for the Ocata cycle
>   to http://releases.openstack.org/ocata/schedule.html. Although
>   I will highlight dates in the countdown emails, you may want to
>   add important dates from the schedule to your calendar.
>
>   Some projects have also added their own project-specific
>   deadlines to that list. If you have something unique, please
>   feel free to update it by patching the openstack/releases
>   repository. There is no need to add a project-specific deadline
>   that is the same as the global deadline.
>
> The Ocata cycle overlaps with several major holidays, including
> the new year. If you are planning time off, please make sure your
> duties are being covered by someone else on the team. Its best to
> let the release team know in advance so we dont delay approval
> for release requests from someone we dont recognize, waiting for
> your +1.
>
> Please ensure that the release liaison for your project has the
> time and ability to handle the communication necessary to manage
> your release.  The release team is here to facilitate, but
> finishing the work of preparing the release is ultimately the
> responsibility of the project team. Failing to follow through on
> a needed process step may block you from successfully meeting
> deadlines or releasing.  Our release milestones and deadlines are
> date-based, not feature-based.  When the date passes, so does the
> milestone. If you miss it, you miss it. A few of you ran into
> problems in past cycles because of missed communications. My goal
> is to have all teams meet all deadlines during Ocata. We came
> very very close for Newton; please help by keeping up to date on
> deadlines.
>
>
> Things for you to do right now:
>
> 1. Update your cross-project liaison on
>https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
>
> 2. Make sure your IRC nickname and email address listed in
>http://git.openstack.org/cgit/openstack/governance/tree/
> reference/projects.yaml
>are correct. The release team, foundation staff, and TC all
>use those contact details to try to reach you at important
>points during the cycle.  Please make sure they are correct,
>and that the email address delivers 

Re: [openstack-dev] [ptl][release] ocata release management communication

[Rob C]

I'm struggling to find good info on when the adjusted PTL nomination cycle
starts.

I've checked here:
https://releases.openstack.org/ocata/schedule.html#pike-ptls-self-nomination
but it looks like the 'elections' section was supposed to be added to the
table and wasn't.

I know from the updates to the charter that the elections should happen on
or before R-3 but it doesn't provide any clarity on how much before then
the nominations should be made?

Cheers
Rob

On 1 Nov 2016 19:45, "Doug Hellmann"  wrote:

> PTLs,
>
> As we did for the Mitaka and Newton cycles, I want to start this
> cycle by making sure the expectations for communications with the
> release team are clear to everyone so there is no confusion or
> miscommunication about any of the process or deadlines. This
> email is being sent to the openstack-dev mailing list as well as
> the PTLs of all official OpenStack projects individually, to
> improve the odds that all of the PTLs see it.  I will not be
> taking the extra step of CCing individual PTLs or liaisons for
> future emails.
>
> (If you were a PTL last cycle, you may want to skip ahead to the
> Things for you to do right now section at the end.)
>
> Volunteers filling PTL and liaison positions are responsible for
> ensuring communication between project teams happens smoothly. As
> a community, we rely on three primary communication
> strategies/tools for different purposes:
>
> 1. Email, for announcements and for asynchronous communication.
>
>   We will be using the "[release]" topic tag on the openstack-dev
>   mailing list for important messages related to release
>   management.  Besides special announcements and instructions, I
>   will send the countdown emails I sent last cycle, with weekly
>   updates on focus, tasks, and upcoming dates. PTLs and release
>   liaisons should configure your mailing list subscription and
>   email client to ensure that those messages are visible (and
>   then read them) so that you are aware of all deadlines, process
>   changes, etc.
>
> 2. IRC, for time-sensitive interactions.
>
>   There are far too many of you (56) to make it realistic for the
>   three members of the release team to track you down
>   individually when there is a deadline. We need you to do your
>   part by making yourself available by configuring your IRC
>   bouncer to listen in #openstack-release. You are, of course,
>   welcome to stay in channel all the time, but you need to be
>   there at least during deadline periods (the week before and
>   week of each deadline).
>
> 3. Written documentation, for relatively stable information.
>
>   The release team has published the schedule for the Ocata cycle
>   to http://releases.openstack.org/ocata/schedule.html. Although
>   I will highlight dates in the countdown emails, you may want to
>   add important dates from the schedule to your calendar.
>
>   Some projects have also added their own project-specific
>   deadlines to that list. If you have something unique, please
>   feel free to update it by patching the openstack/releases
>   repository. There is no need to add a project-specific deadline
>   that is the same as the global deadline.
>
> The Ocata cycle overlaps with several major holidays, including
> the new year. If you are planning time off, please make sure your
> duties are being covered by someone else on the team. Its best to
> let the release team know in advance so we dont delay approval
> for release requests from someone we dont recognize, waiting for
> your +1.
>
> Please ensure that the release liaison for your project has the
> time and ability to handle the communication necessary to manage
> your release.  The release team is here to facilitate, but
> finishing the work of preparing the release is ultimately the
> responsibility of the project team. Failing to follow through on
> a needed process step may block you from successfully meeting
> deadlines or releasing.  Our release milestones and deadlines are
> date-based, not feature-based.  When the date passes, so does the
> milestone. If you miss it, you miss it. A few of you ran into
> problems in past cycles because of missed communications. My goal
> is to have all teams meet all deadlines during Ocata. We came
> very very close for Newton; please help by keeping up to date on
> deadlines.
>
>
> Things for you to do right now:
>
> 1. Update your cross-project liaison on
>https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
>
> 2. Make sure your IRC nickname and email address listed in
>http://git.openstack.org/cgit/openstack/governance/tree/
> reference/projects.yaml
>are correct. The release team, foundation staff, and TC all
>use those contact details to try to reach you at important
>points during the cycle.  Please make sure they are correct,
>and that the email address delivers messages to a mailbox you
>check regularly.
>
> 3. Update your mail filters to ensure you see 

[openstack-dev] [Security] Weekly meeting canceled due to thanksgiving

[Rob C]

All,

I should have sent the notification out earlier however today's weekly IRC
meeting is cancelled as most of our group are american and on vacation
today.

Have a great day.
-Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] Nominating Arun Kant for barbican-core

[Rob C]

Congratulations Arun, you've put a lot of work in!

On Mon, Nov 7, 2016 at 10:05 PM, Fernando J Diaz  wrote:

> +1 Congrats Arun, welcome to Barbican Core.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][kolla][security] pycrypto vs cryptography

[Rob C]

Good question, I know issues around this have arisen before.

I think the main points have been covered well already, for my part I will
always lean toward the better supported or actively developed project.

I understand the desire to look for FIPS 140-2 compliance, however I'd
caution about this being the only deciding factor, it makes software
development messy as only specific implementations can be validated. If you
want to update code to make improvements etc you can need a whole
re-validation. I'm not saying that FIPS 140-2 doesn't have value but I know
of software projects that have used known-bad implementations that had
certification rather use an updated version with no issues - (like I said,
it gets messy).

The OpenSSL guys wrote a good article on FIPS validation, how they tackled
it and some of the impact etc [1]

-Rob

[1] https://www.openssl.org/docs/fipsnotes.html

On Sun, Nov 6, 2016 at 4:44 PM, Jeremy Stanley  wrote:

> On 2016-11-06 14:59:03 + (+), Jeremy Stanley wrote:
> > On 2016-11-06 08:05:51 + (+), Steven Dake (stdake) wrote:
> [...]
> > > An orthogonal question I have received from one of our community
> > > members (Pavo on irc) is whether pycrypto (or if we move to
> > > cryptography) provide FIPS-140-2 compliance.
> >
> > My understanding is that if you need, for example, a FIPS-compliant
> > AES implementation under the hood, then this is dependent more on
> > what backend libraries you're using... e.g.,
> > https://www.openssl.org/docs/fips.html
> > https://www.openssl.org/docs/fipsvalidation.html
>
> I should clarify, I was referring specifically to
> pyca/cryptography's OpenSSL backend. In contrast the pycrypto
> maintainers seem to have copied and forked a variety of algorithms
> (some of which seem to be based NIST/FIPS reference implementations
> for C or backports from bits of Py3K stdlib but have undergone
> subsequent modification), so very likely have not been put through
> any sort of direct compliance validation:
> https://github.com/dlitz/pycrypto/blob/master/src/AES.c
> https://github.com/dlitz/pycrypto/blob/master/src/SHA512.c
> et cetera...
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][VMT][Security] Glance coresec reorg

[Rob C]

Hi Brian.

I dont know Erno but trust your judgement.

Im sure Ian will be a great coresec.

+1

Rob

On 19 Oct 2016 04:32, "Hemanth Makkapati" 
wrote:

> +1 to both Erno and Ian.
> Both have made solid contributions to Glance over the past few cycles and
> are very thorough in their approach.
> I believe both of them will be great additions to the Glance coresec group.
>
> -Hemanth
> 
> From: Brian Rosmaita 
> Sent: Tuesday, October 18, 2016 5:22:28 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [glance][VMT][Security] Glance coresec reorg
>
> Hello everyone,
>
> First, I'd like to thank Flavio Percoco and Kairat Kushaev for their past
> service as members of the Glance core security contacts team.
> Unfortunately, due to other commitments, they don't have time to continue
> on coresec.
>
> Thus, the main point of this email is to propose Ian Cordasco and Erno
> Kuvaja as new members of the Glance coresec team.  They've both been
> Glance cores for several cycles, have a broad knowledge of the software
> and team, contribute high-quality reviews, and are conversant with good
> security practices.
>
> Replacing Flavio and Kairat with Ian and Erno will keep the Glance coresec
> team at 5 members.
>
> Please cast your vote with +1, 0, or -1, or you can reply back to me.
>
> Please reply before 23:59 UTC on Wednesday, October 26, 2016.
>
> Thank you,
> brian
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Summit][Security] Ops security session - flagging this for the OSSP

[Rob C]

The Ops Meetup, organized by the User Committee's Ops Meetups Team, is a
track comprised of collaborative, working sessions for people who are
operating OpenStack clouds (and contributors who want to hear from them).
The purpose is to share knowledge and best practices among cloud operators,
as well as provide feedback based on experience running OpenStack. There
will be no formal presentations, and a moderate level of knowledge around
running OpenStack is assumed. If you're just starting out, the Operations
Tools and War Stories tracks of the conference will be much more friendly!

https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17334/ops-security

https://etherpad.openstack.org/p/BCN-ops-security

-Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [vmt][security][barbican] Threat Analysis for OpenStack Projects

[Rob C]

Hi Guys,

We've put together a session to go over TA and how we should apply what
we've built moving forward.

https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17017

-Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][barbican][security] Ocata design summit session change

[Rob C]

Thanks for the heads up, I'll do my best to attend and I'll encourage other
security folks to do likewise.

It looks like there's a good deal of security enforcing functionality in
these specs, I knew we've discussed getting Octa through threat analysis,
lets try to find a good time to schedule that too.

Cheers
-Rob

On Thu, Oct 13, 2016 at 9:15 PM, Matt Riedemann 
wrote:

> I've changed the nova design summit session on docs needed for newton to
> now be a session to cover the various security-related specs up for review:
>
> https://www.openstack.org/summit/barcelona-2016/summit-sched
> ule/events/16977/nova-security-specs-and-testing
>
> And to also talk about getting a CI job going which will test some of
> these features, like with barbican as the key manager and using signed
> images.
>
> I've tagged this session with 'barbican' although I see that the barbican
> team is having another session at the same time. There was one other slot
> that I could have moved for nova but barbican had a conflict then too, so
> I've just left this where it is and if anyone from barbican can show up all
> the better, but I don't think it's necessarily a requirement.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] planning the PTG -- lessons from Swift's midcycles

[Rob C]

I agree with pretty much everything John's written, especially with regards
to what's required of a host (and accepting that things will have to be
different at the PTG).

For security, although we have a pre-event etherpad to propose topics
nothing is decided until the first day, where we will have an unconference,
vote on things we want to talk about and try to create a schedule that
doesn't clash. We have on a number of occasions conducted our mid-cycle
overlapping with Barbican, where we've been able to participate in each
other's projects, vote on topics, register interest etc. This
cross-polination has been very useful and works well in an unconference
setting.

-Rob

On Wed, Oct 12, 2016 at 6:30 PM, John Dickinson  wrote:

> The Swift team has been doing midcycles for a while now, and as the new
> PTG gets closer, I want to write down our experience with what has worked
> for us. I hope it is beneficial to other teams, too.
> Logistics of the event
>
>- 2 rooms is ideal, but can make due with one larger room
>- move tables and chairs
>- whiteboards/flip charts
>- projector/tv
>- host provides lunch and snacks
>- host provides one evening meal/event
>
> When someone offers to host a midcycle, this is what I ask them to
> provide. The PTG will be slightly different, but the general idea is the
> same. There's a few important things to note here. First, be flexible about
> who's talking about what and when people are working together. The point of
> getting together in person is to facilitate face-to-face communication, so
> be sure that the room logistics don't get in the way by forcing people into
> a certain configuration. Providing lunch and snacks allows the participants
> to not break any tech or social flow in the middle of the day. It keeps
> people together and helps facilitate communication. And the one evening
> event is super helpful to let people relax, have fun, and do something
> interesting away from a computer. In the past we've done everything from
> locked-room challenges and bowling to brewery tours and a boat ride under
> the Golden Gate bridge.
> Only agenda item is "set the agenda"
>
>- dotmocracy
>- too much to do for the people we have to work on it
>- what's the big stuff we need the right people to be together for?
>- schedule one big talk each am and pm
>
> When it comes to the actual flow of the limited time together, there are
> two important things to keep in mind. First, make sure there's time to
> cover all the topics that are of interest to the people in the room.
> Second, make sure the big important stuff gets discussed without requiring
> someone to be in two places at once.
>
> Unfortunately, these two goals are often in conflict. We've solved this in
> the past by starting the midcycle with one and only one agenda item: set
> the agenda. The most successful way we've done this is to ask the room to
> shout out topics to discuss. Every topic gets written down on a piece of
> paper or on a flipboard. When you've got all the topics written down, then
> give everyone a limited number of dot stickers and ask them to vote for
> what they want to talk about by placing one or more dots next to it. The
> trick is that there are more topics to talk about than people who are there
> and each person has less dots than the full schedule of time we have. So,
> for example, if there are 3 days together, that's a total of 6 morning and
> afternoon blocks of time. Give everyone 4 dots, and force them to
> prioritize. This also has the very real visual side effect of emphasizing
> that we are a team and not one person can be a part of everything going on.
> After everyone has put their dots on topics, sort the topics by number of
> dots. In our example, we've got 6 blocks of time, so choose the top six and
> schedule them. This ensures that the big stuff can get scheduled, the
> little stuff can fill in the gaps, and people can know when to be available
> for conversations that are important to them.
>
> Imagine than you've got a glass mason jar, and you need to fill it up with
> stuff. You've got big rocks, small rocks, sand, and water. If you fill it
> up with water first, the water will spill out when you add anything else.
> But if you add the big things first, then you can fit more in. The big
> rocks go first, then small rocks fill up the spaces, then sand fills up the
> cracks, then the water can seem in the tiny air gaps. It's the same way
> with prioritizing the in-person meetings. Schedule the big stuff, then fill
> in any gaps with the small stuff.
> Social dynamics during the week
>
>- you won't be able to participate in everything. that's ok
>- there will be several conversations going on at one time. be
>considerate and flexible
>- don't wait for someone to start a conversation. start it yourself.
>this is very important!
>
> There's a lot going on at in-person meetings. It's ok to not 

Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Rob C]

I wanted to provide a quick update from Security.

We had our weekly IRC meeting yesterday, dhellman was kind enough to attend
to help broker some of the discussion. In advance of the meeting I prepared
a blog post where I tried to articulate my position and where I think
things need to go next [1]. This was discussed at length during the IRC
meeting [2]. We discussed the option of becoming a WG or staying in the big
tent, this resulted in a vote, where the team all indicated their desire to
stay within the big tent.

My proposal for the future is outlined in some depth with [1] but the
summary is that we've identified the areas that we need to improve on in
order to be better members of the community, we want to stay within the
big-tent and for me to maintain leadership through this transformational
process with a view to having multiple candidates stand in the next
election.

Cheers
-Rob

[1]
https://openstack-security.github.io/organization/2016/09/22/maturing-the-security-project.html
[2]
http://eavesdrop.openstack.org/meetings/security/2016/security.2016-09-22-17.00.log.html

On Fri, Sep 23, 2016 at 4:23 AM, Davanum Srinivas  wrote:

> Steven,
>
> Fair point.
>
> Thanks,
> Dims
>
> On Thu, Sep 22, 2016 at 11:04 PM, Steven Dake (stdake) 
> wrote:
> > Dims,
> >
> > This isn’t any of my particular business except it could affect emerging
> technology projects (which I find important to OpenStack’s future)
> negatively – so I thought I’d chime in.
> >
> > A lack of activity in a specs repo doesn’t mean much to me.  For
> example, as Kolla was an emerging project we didn’t use any specs process
> at all (or very rarely).  There is a reason behind this. Now that Kolla is
> stable and reliable and we feel we are not an emerging project, we plan to
> make use of a specs repo starting in Ocata.
> >
> > I have no particular concerns with the other commentary – but please
> don’t judge a project by activity or lack of activity in one repo of its
> deliverables.  Judge it holistically (You are judging holistically.  I
> believe a lack of one repo’s activity shouldn’t be part of that judgement).
> >
> > Regards
> > -steve
> >
> >
> > On 9/21/16, 2:08 PM, "Davanum Srinivas"  wrote:
> >
> > Jakub,
> >
> > Please see below.
> >
> > On Wed, Sep 21, 2016 at 3:46 PM, Jakub Pavlik <
> jakub.pav...@tcpcloud.eu> wrote:
> > > Hello all,
> > >
> > > it took us 2 years of hard working to get these official.
> OpenStack-Salt is
> > > now used by around 40 production deployments and it is focused
> very on
> > > operation and popularity is growing. You are removing the project
> week after
> > > one of top contributor announced that they will use that as part of
> > > solution. We made a mistakes, however I do not think that is
> reason to
> > > remove us. I do no think that quality of the project is measured
> like this.
> > > Our PTL got ill and did not do properly his job for last 3 weeks,
> but this
> > > can happen anybody.
> > >
> > >  It is up to you. If you think that we are useless for community,
> then
> > > remove us and we will have to continue outside of this community.
> However
> > > growing successful use cases will not be under official openstack
> community,
> > > which makes my feeling bad.
> >
> > Data points so far are:
> > 1. No response during Barcelona planning for rooms
> > 2. Lack of candidates for PTL election
> > 3. No activity in the releases/ repository hence no entries in
> > https://releases.openstack.org/
> > 4. Meetings are not so regular?
> > http://eavesdrop.openstack.org/meetings/openstack_salt/2016/
> (supposed
> > to be weekly)
> > 5. Is the specs repo really active?
> > http://git.openstack.org/cgit/openstack/openstack-salt-specs/ is the
> > work being done elsewhere?
> > 6. Is there an effort to add stuff to the CI jobs running on
> openstack
> > infrastructure? (can't seem to find much
> > http://codesearch.openstack.org/?q=salt=nope=zuul%
> 2Flayout.yaml=project-config)
> >
> > I'll stop here and switch to #openstack-salt channel to help work you
> > all through if there is a consensus/willingness from the
> > openstack-salt team that there's significant work to be done. If you
> > think you are better off not on the governance, that would be your
> > call as well.
> >
> > Thanks,
> > Dims
> >
> > > Thanks,
> > >
> > > Jakub
> > >
> > >
> > > On 21.9.2016 21:03, Doug Hellmann wrote:
> > >>
> > >> Excerpts from Filip Pytloun's message of 2016-09-21 20:36:42
> +0200:
> > >>>
> > >>> On 2016/09/21 13:23, Doug Hellmann wrote:
> > 
> >  The idea of splitting the contributor list comes up pretty
> regularly
> >  and we rehash the same suggestions each time.  Given that what
> we
> >  have now worked fine for 57 

Re: [openstack-dev] [Security] Picking a new tag

[Rob C]

I agree that sometimes simply filtering for "security" can get a bit noisy
because only very occasionally is an email mentioning it or even using the
[security] tag actually trying to get the attention of the OSSP. Most of
the time (from my filters anyway) it's either a Neutron Security Groups
issue or someone simply using [Security] as a bit of metadata.

However, I'm hesitant to move away from it, as we should be paying
attention to things that do come through with the [Security] tag, it's the
easiest way for someone to try to get us involved if they're having an
issue.

Speaking personally, I think that if we have a sec-project tag, or
something similar, I'll simply end up having twice as many filters, on for
the new tag and one for anyone who's using [security]

I'm interested to know what other users might think though.

On Fri, Sep 23, 2016 at 7:00 AM, Tony Breeds 
wrote:

> On Fri, Sep 23, 2016 at 12:12:53AM +, Jeremy Stanley wrote:
>
> > It actually is, but Mailman (unhelpfully) lists tags by their long
> > descriptions. Go ahead and click on the Details link next to the
> > Cross-project coordination topic and you'll see that's actually the
> > name for the [all] tag.
>
> Gah!  I shoudl have clicked all the links.
>
> Thanks.
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Security] Blog Post: Maturing the security project

[Rob C]

I wrote a blog post based on the recent thread about the future of the
Security Project, it's published here:
https://openstack-security.github.io/organization/2016/09/22/maturing-the-security-project.html


Cheers
-Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [manila] [security] [tc] Add the vulnerability:managed tag to Manila

[Rob C]

Jeremy hit all the major points there.

What we do is basically model things based on a best-practice use case, we
rely on the project to make good choices in this regard with a view to
configurations, protocols etc.

Then we conduct an asset-oriented threat review, during which we create
documentation that looks a lot like
https://review.openstack.org/#/c/357978/5

It's not overly heavyweight and provides us with enough information to make
some reasonably in-depth judgements and provide advice on areas where a
project might have some weaknesses in design or implementation.

A good first step is to say hello during one of our IRC meetings, 1700 UTC
on #openstack-meeting-alt

Cheers
-Rob

On Thu, Sep 1, 2016 at 4:38 PM, Ben Swartzlander 
wrote:

> Thanks fungi. I misunderstood the full scope of the requirements for
> vulnerability management and since we don't yet have volunteers willing to
> perform all the required duties, I'm going to withdraw the tag request.
>
> As soon as interested community members step up to take on the
> responsibilities I'll reapply for the tag.
>
> -Ben Swartzlander
>
>
>
> On 08/30/2016 01:07 PM, Jeremy Stanley wrote:
>
>> Ben has proposed[1] adding manila, manila-ui and python-manilaclient
>> to the list of deliverables whose vulnerability reports and
>> advisories are overseen by the OpenStack Vulnerability Management
>> Team. This proposal is an assertion that the requirements[2] for the
>> vulnerability:managed governance tag are met by these deliverables.
>> As such, I wanted to initiate a discussion evaluating each of the
>> listed requirements to see how far along those deliverables are in
>> actually fulfilling these criteria.
>>
>> 1. All repos for a covered deliverable must meet the criteria or
>> else none do. Easy enough, each deliverable has only one repo so
>> this isn't really a concern.
>>
>> 2. We need a dedicated point of contact for security issues. Our
>> typical point of contact would be a manila-coresec team in
>> Launchpad, but that doesn't exist[3] (yet). Since you have a fairly
>> large core review team[4], you should pick a reasonable subset of
>> those who are willing to act as the next line of triage after the
>> VMT hands off a suspected vulnerability report under embargo. You
>> should have at least a couple of active volunteers for this task so
>> there's good coverage, but more than 5 or so is probably pushing the
>> bounds of information safety. Not all of them need to be core
>> reviewers, but enough of them should be so that patches proposed as
>> attachments to private bugs can effectively be "pre-approved" in an
>> effort to avoid delays merging at time of publication.
>>
>> 3. The PTL needs to agree to act as a point of escalation or
>> delegate this responsibility to a specific liaison. This is Ben by
>> default, but if he's not going to have time to serve in that role
>> then he should record a dedicated Vulnerability Management Liaison
>> in the CPLs list[5].
>>
>> 4. Configure sharing[6][7][8] on the defect trackers for these
>> deliverables so that OpenStack Vulnerability Management team
>> (openstack-vuln-mgmt) has "Private Security: All". Once the
>> vulnerability:managed tag is approved for them, also remove the
>> "Private Security: All" sharing from any other teams (so that the
>> VMT can redirect incorrectly reported vulnerabilities without
>> prematurely disclosing them to manila reviewers).
>>
>> 5. Independent security review, audit, or threat analysis... this is
>> almost certainly the hardest to meet. After some protracted
>> discussion on Kolla's application for this tag, it was determined
>> that projects should start supplying threat analyses to a central
>> security-analysis[9] repo where they can be openly reviewed and
>> ultimately published. No projects have actually completed this yet,
>> but there is some process being finalized by the Security Team which
>> projects will hopefully be able to follow. You may want to check
>> with them on the possibility of being an early adopter for that
>> process.
>>
>> 6. Covered deliverables need tests we can rely on to be able to
>> evaluate whether privately proposed security patches will break the
>> software. A cursory look shows many jobs[10] running in our upstream
>> CI for changes to these repos, so that requirement is probably
>> addressed (I did not yet check whether those
>> unit/functional/integration tests are particularly extensive).
>>
>> So in summary, it looks like there are still some outstanding
>> requirements not yet met for the vulnerability:managed tag but I
>> don't see any insurmountable challenges there. Please let me know if
>> any of the above is significantly off-track.
>>
>> [1] https://review.openstack.org/350597
>> [2] https://governance.openstack.org/reference/tags/vulnerabilit
>> y_managed.html#requirements
>> [3] https://launchpad.net/~manila-coresec
>> [4] https://review.openstack.org/#/admin/groups/213,members
>> [5] 

Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Rob C]

For my part, I missed the elections, that's my bad. I normally put a
calendar item in for that issue. I don't think that my missing the election
date should result in the group being treated in this way. Members of the
TC have contacted me about unrelated things recently, I have always been
available however my schedule has made it hard for me to sift through -dev
recently and I missed the volley of nomination emails. This is certainly a
failing on my part.

It's certainly true that the security team, and our cores tend not to pay
as much attention to the -dev mailing list as we should. The list is pretty
noisy and  traditionally we always had a separate list that we used for
security and since moving away from that we tend to focus on IRC or direct
emails. Though as can be seen with our core announcements etc, we do try to
do things the "openstack way"

However, to say we're not active I think is a bit unfair. Theirry and
others regularly mail me directly about things like rooms for the summit
and I typically respond in good time, I think what's happened here is more
an identification of the fact that we need to focus more on doing things
"the openstack way" rather than being kicked out of the big tent.

We regularly work with the VMT on security issues, we issue large amounts
of guidance on our own, we have been working hard on an asset based threat
analysis process for OpenStack teams who are looking to be security
managed, we've reviewed external TA documentation and recently in our
midcycle (yes, we're dedicated enough to fly to Texas and meet up to work
on such issues) we created the first real set of security documents for an
OpenStack project,  we worked with Barbican to apply the asset based threat
analysis that we'd like to engage other teams in [1], [2]

Here's a couple of the things that we've been doing in this cycle:
* Issuing Security Notes for Glance, Nova, Horizon, Bandit, Neutron and
Barbican[3]
* Updating the security guide (the book we wrote on securing OpenStack)[4]
* Hosting a midcycle and inducting new members
* Supporting the VMT with several embargoed and complex vulnerabilities
* Building up a security blog[5]
* Making OpenStack the biggest open source project to ever receive the Core
Infrastructure Initative Best Practices Badge[6][7]
* Working on the OpenStack Security Whitepaper [8]
* Developing CI security tooling such as Bandit [9]

We are a very active team, working extremely hard on trying to make one
OpenStack secure. This is often a thankless task, we provide a lot of what
customers are asking for from OpenStack but as we don't drive individual
flagship features our contributions are often overlooked. However, above is
just a selection of what we've been doing throughout the last cycle.

If it's too late for these comments to have an influence then sobeit but
this is failure of appropriate levels of email filtering and perhaps a
highlight of how we need to alter our culture somewhat to partipate more in
-dev in general than it is any indication of a lack of dedication, time,
effort or contribution on the part of the Security Project.  We have
dedicate huge amounts of efforts to OpenStack and to relegate us to a
working group would be massively detrimental for one reason above all
others. We get corporate participation, time and effort in terms of
employee hours and contributions because we're an official part of
OpenStack, we've had to build this up over time. If you remove the Security
Project from the big tent I believe that participation in Security for
OpenStack will drop off significantly.

We are active, we are helping to make OpenStack secure and we (I) suck at
keeping ontop of email. Don't kick us out for that. If needs be we can find
another PTL or otherwise take special steps to ensure that missing
elections doesn't happen.

Apart from missing elections, I think we do a huge amount for the community
and removing us from OpenStack would in no way be beneficial to either the
Security Project or OpenStack as a whole.

-Rob

[1] https://review.openstack.org/#/c/357978/5
[2] https://etherpad.openstack.org/p/barbican-threat-analysis
[3] https://wiki.openstack.org/wiki/Security_Notes
[4] http://docs.openstack.org/sec/
[5] https://openstack-security.github.io/
[6] https://bestpractices.coreinfrastructure.org/
[7]
http://www.businesswire.com/news/home/20160725005133/en/OpenStack-Earns-Core-Infrastructure-Initiative-Practices-Badge
[8] https://www.openstack.org/software/security/
[9] https://wiki.openstack.org/wiki/Security/Projects/Bandit




On Wed, Sep 21, 2016 at 12:23 PM, Thierry Carrez 
wrote:

> Hi everyone,
>
> As announced previously[1][2], there were no PTL candidates within the
> election deadline for a number of official OpenStack project teams:
> Astara, UX, OpenStackSalt and Security.
>
> In the Astara case, the current team working on it would like to abandon
> the project (and let it be available for any new team who wishes to take

[openstack-dev] Proposing Doug Chivers for Security Core

[Rob C]

I'd like to nominate Doug for a CoreSec position as part of the Security
Project.

CoreSec team members support the VMT with extended consultation on
externally reported vulnerabilities.

Doug has been an active member of the Security project for several years.
He's done significant recent work on threat analysis and been an avid
contributor to our work in general. Doug has significant OpenStack security
experience, having previously been responsible for security HP's public
OpenStack cloud.

I'd like to also take this time to thank Nathan Kinder for all his hard
work as a member of the Security Project. Nathan is taking a step back from
the security work at the moment to focus on other projects, it is his slot
that Doug will be taking, the CoreSec group will remain 5 people.

Thanks
-Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Security] No IRC meeting this week

[Rob C]

All,

No IRC meeting this week as we're conducting the mid-cycle in Austin
Weds->Friday.

However, we'll be doing hangouts for those who can't make it onsite and
will be monitoring IRC so just ping us on there if you want to contribute.

Cheers
-Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Security] Proposing Luke Hinds (lhinds) for Security Core

[Rob C]

I'd like to nominate Luke for a CoreSec position as part of the Security
Project.

CoreSec team members support the VMT with extended consultation on
externally reported vulnerabilities.

Luke has been an active member of the Security project for quite some time.
He's done significant recent work on OSSNs and been an avid contributor to
our work in general. Luke has experience of vulnerability management from
his dayjob and will be a valuable member of the team.

-Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][security] Finishing the job on threat analysis for Kolla

[Rob C]

I have returned from #drownload and I'm super keen to get ontop of this, in
this email I'll just try to tie a few different threads together.

The etherpad we used at the summit, along with the Sequence Diagram texts
are online [1] are we happy to continue using web sequence diagrams? I
think the resulting output is very useful [2] - even if Kolla doesn't fit
the typical project style that we anticipate using these for - they're
better suited to more traditional software projects.

There's a big effort to formalize the TA process and have OSSP help as
guardians of the code base[3] in future, with lots of effort being made to
ensure that as new projects come into the fold they meet a certain minimum
security level - we'll also attempt to help more established projects
iterate to a level of equal security assurance.

I'll leave the process description for our actual documentation but a big
part of it will be projects submitting security docs to the newly created
security-analysis repo [4]. Projects are welcome to use this for staging
and collaboration - the OSSP will largely ignore projects with the WIP flag
set.

I think the next step is for Doug and I (and anyone else who cares) to
review the current diagrams and provide a quick gap analysis for the Kolla
devs detailing what else is required for us to do a proper review.


[1] https://etherpad.openstack.org/p/kolla-newton-summit-threat-analysis

[2] https://drive.google.com/file/d/0B0osRPn3qBq5X1poTGZqVFBRQW8/view

[3] https://review.openstack.org/#/c/300698/

[4] https://review.openstack.org/#/c/325049/

On Tue, May 31, 2016 at 5:37 PM, Chivers, Doug  wrote:

> Thanks for following up Steve, the sessions at the summit were extremely
> useful.
>
> Both Rob and I have been caught up with the day-job since we got back from
> the summit, but will discuss next steps and agree a plan this week.
>
> Regards
>
> Doug
>
>
>
>
> From: "Steven Dake (stdake)" >
> Date: Tuesday, 24 May 2016 at 17:16
> To: "openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org>"  >
> Cc: Doug Chivers >, "
> robcl...@uk.ibm.com"  >
> Subject: [kolla][security] Finishing the job on threat analysis for Kolla
>
> Rob and Doug,
>
> At Summit we had 4 hours of highly productive work producing a list of
> "things" that can be "threatened".  We have about 4 or 5 common patterns
> where we follow the principle of least privilege.  On Friday of Summit we
> produced a list of all the things (in this case deployed containers).  I'm
> not sure who, I think it was Rob was working on a flow diagram for the
> least privileged case.  From there, the Kolla coresec team can produce the
> rest of the diagrams for increasing privileges.
>
> I'd like to get that done, then move on to next steps.  Not sure what the
> next steps are, but lets cover the flow diagrams first since we know we
> need those.
>
> Regards
> -steve
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][security] Item #5 of the VMT

[Rob C]

Doug Chivers might have some thoughts on this but I'm happy with your
proposal Steve, kind of you to do the leg-work.

-rob

On Fri, Jun 3, 2016 at 1:29 AM, Steven Dake (stdake) 
wrote:

> Hi folks,
>
> I think we are nearly done with Item #5 [1] of the VMT.  One question
> remains.
>
> We need to know which repo the analysis documentation will land in .
> There is security-doc we could use for this purpose, but we could also
> create a new repository called "security-analysis" (or open to other
> names).  I'll create the repo, get reno integrated with it, get sphinx
> integrated with it, and get a basic documentation index.rst in place using
> cookiecutter + extra git reviews.  I'll also set up project-config for
> you.  After that, I don't think there is much I can do as my plate is
> pretty full :)
>
> Regards
> -steve
>
> [1] https://review.openstack.org/#/c/300698/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][ssecurity] Threat Analysis Design Session

[Rob C]

As per today's session (Thursday) the Anchor Threat Analysis blog post now
has added sequence diagram goodness!

https://openstack-security.github.io/threatanalysis/2016/02/07/anchorTA.html

Cheers
-Rob

On Sat, Apr 16, 2016 at 1:19 PM, Steven Dake (stdake) 
wrote:

> Hey Folks,
>
> I've scheduled the Threat Analysis Design session on Thursday 11:50-12:30
> in room MR415A.  This slot was the best slot I could find that didn't
> conflict with any security projects.
>
> If the security team has a conflict  with this slot that I didn't see or
> am unaware of, please speak up so I can have it corrected in the main
> schedule.  Our schedule is here:
>
> https://etherpad.openstack.org/p/kolla-newton-summit
>
> Thanks!
> -steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Security][Barbican][all] Bring your own key fishbowl sessions

[Rob C]

I'm certainly more interested in the push model, if only to create parity
with azure, AWS and Google.

I suggest we start the BYOK discussions on Wednesday focusing on push. If
there's an interest in shifting discussion to the pull model in the
Thursday session then I have no objection to that, let the room decide?

Rob
On 22 Apr 2016 5:08 p.m., "Fox, Kevin M" <kevin@pnnl.gov> wrote:

Oh, I think I understand. something like:

You set up your private cloud with a public region ala K2K federation. The
other Cloud then shows up as another region in your cloud.

This would then allow your barbican in one region to be accessible to vm's
launched in the public region?

Kind of a cross region barbican use case?

Thanks,
Kevin


From: Douglas Mendizábal [douglas.mendiza...@rackspace.com]
Sent: Friday, April 22, 2016 2:46 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Security][Barbican][all] Bring your own key
fishbowl sessions

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

No conflicts with your cross-project session as far as I can tell.

In a nutshell BYOK-Push is a model where the customer retains full
control of their cryptographic keys.  The customer is expected to
provide the necessary keys each and every time a request is made that
requires some cryptographic operation.  Amazon S3's SSE-C encryption
[1] would be a good example of this model.

In a BYOK-Pull model, the customer would grant access to their cloud
provider for some key management system inside their private
infrastructure.  For example this model could be used in a hybrid
cloud where the customer has an on-premise barbican that can provide
keys on-demand to the public cloud provider.

+1 to not spending a lot of time talking about a model that no one is
interested in implementing.  My impression at the last joint
Barbican/OSSP mid-cycle was that most people were interested in the
push model.

[1]
http://docs.aws.amazon.com/AmazonS3/latest/dev/ServerSideEncryptionCusto
merKeys.html

On 4/22/16 4:03 PM, Fox, Kevin M wrote:
> Can you please give a little more detail on what its about?
>
> Does this have any overlap with the instance user session:
> https://www.openstack.org/summit/austin-2016/summit-schedule/events/94
85
>
>  Thanks, Kevin
>
> ------
- --
>
>
*From:* Rob C [hyaku...@gmail.com]
> *Sent:* Friday, April 22, 2016 1:44 PM *To:* OpenStack Development
> Mailing List (not for usage questions) *Subject:* Re:
> [openstack-dev] [Security][Barbican][all] Bring your own key
> fishbowl sessions
>
> So that's one vote for option A and one vote for another vote :)
>
> On 22 Apr 2016 4:25 p.m., "Nathan Reller"
> <nathan.s.rel...@gmail.com <mailto:nathan.s.rel...@gmail.com>>
> wrote:
>
>> Thoughts?
>
> Is anyone interested in the pull model or actually implementing it?
> I say if the answer to that is no then only discuss the push
> model.
>
> Note that I am having a talk on BYOK on Tuesday at 11:15. My talk
> will go over provider key management, the push model, and the pull
> model. There are some aspects of design in it that will likely
> interest people. You might want to take the poll after session
> because I'm not sure how many people know what the differences
> are.
>
> -Nate
>
> __

>
>
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __

>
>
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXGpu3AAoJEB7Z2EQgmLX7eaAQAKArxp+Pw6jl+4Xz5t9zrOZb
ENSOq049jOrymUolD/VyiicT2llG08LxHlLjfnVthJ7j5+unB6XQLRKLIDAGUCrM
IyTw9SRSjElvQVN6mct/NnePlhipjWf6inqCxpRKE0Bbv2jgOHiYOqZ04yQAxZ/1
aWevqSc2piJhlZmOjTlYbls0O0oTPGw0zkyS0Damja5OIiu45niSQvrnwlbfVTJg
R9ORk0FSNrpvgOBIAFCqLYXhmvrhHkV0+M6aQ4NHy9m05ywe7jq4J2qhcUqY3kqp
b/qNCKlJ25mSlnCcVLYR8iDkLxfLwa7dToCViacnLg2dd7T1l0OhLgbBY1ENHIuw
jvwE3vVz4HPHhk8ArybWvaOepP+cPdPB4fcX5DkatEfI2raCr18yebZ+AfI7/e/v
WtlwLUcG/GxOIQe/PpTF6Y5cRimV62u/Fk3FXZYJnFt2dk+zw9OTzrasZg/RrTVT
UEaMPZXt8AfAVEUNRh2KA1NgFhyvuLIkexSPmmuJ5dxgJ2JmB2OoLF+pNNT5xH4L
bTYuIGt39nuLT8wv9vyovoMuDG6mP8JF0b4LW/2XEfBTPq9LfDlEtmZUqlDhYG2I
FlqP1iN0O1B0X9hG6+fnD+aEga8nx060wNxsioUD2bNmJ6lqYeq8Jj0hIdsjYTAU
xwrWP8UdUfC7GU9oun1Y
=PeQa
-END P

Re: [openstack-dev] [Security][Barbican][all] Bring your own key fishbowl sessions

[Rob C]

So that's one vote for option A and one vote for another vote :)
On 22 Apr 2016 4:25 p.m., "Nathan Reller"  wrote:

> > Thoughts?
>
> Is anyone interested in the pull model or actually implementing it? I
> say if the answer to that is no then only discuss the push model.
>
> Note that I am having a talk on BYOK on Tuesday at 11:15. My talk will
> go over provider key management, the push model, and the pull model.
> There are some aspects of design in it that will likely interest
> people. You might want to take the poll after session because I'm not
> sure how many people know what the differences are.
>
> -Nate
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Security][Barbican][all] Bring your own key fishbowl sessions

[Rob C]

We have two BYOK sessions scheduled for the design summit, one on the
Barbican track and one on the Security track.

[1] Security: Wednesday 5:20pm-6:00pm Hilton Austin - MR 408
[2] Barbican: Thursday 3:10pm-3:50pm Hilton Austin - MR 406

I'd like to suggest two different approaches to getting the most done with
these sessions.

Option A) Treat them as one big session split over two days
Option B) Use one for 'push' style BYOK and one for 'pull'

Thoughts?

[1] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9195
[2] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9155
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev