[openstack-dev] [OSSG] Announcement: I'll be transitioning away from OpenStack
I have recently accepted a new position with a company that does not work with OpenStack. As a result, I'll be transitioning away from this community. As such, I wanted to offer a few quick notes: * OpenStack Security Guide -- I have transitioned leadership of this security documentation effort to Nathaniel Dillon. * #openstack-security IRC channel -- Travis McPeak now also has OP privilege in the channel. Beyond that, I just wanted to say thanks to everyone. The OpenStack community has been great to work with over the past several years and I wish you all the best in the time ahead! I have about one more week working with OpenStack full time. After that, I am still planning on coming to the summit in May, and would be happy to help with any final transition pieces at that time. And I'll continue being available at this email address well into the future. Cheers, -bryan __ 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] nominating Nathaniel Dillon for security-doc core
To security-doc core and other interested parties, Nathaniel Dillon has been working consistently on the security guide since our first mid-cycle meet up last summer. In that time he has come to understand the inner workings of the book and the doc process very well. He has also been a consistent participant in improving the book content and working to define what the book should be going forward. I'd like to bring him on as a core member of security-doc so that he can help with the review and approval process for new changes to the book. Please chime in with your agreement or concerns. Cheers, -bryan __ 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] nominating Nathaniel Dillon for security-doc core
Thanks everyone. I've added Nathaniel to security-doc core. Welcome Nathaniel! Cheers, -bryan __ 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] [Openstack-security] [Barbican][OSSG] Mid Cycle Attendance / Crossover.
I would like to try to attend both, assuming the Barbican guys will have me ;-) -bryan On Fri, Nov 7, 2014 at 12:02 PM, Clark, Robert Graham robert.cl...@hp.com wrote: Hi All, How many people would want to attend both the OSSG mid-cycle and the Barbican one? Both expected to be on the west coast of the US. We are trying to work out how/if we should organise these events to take place at adjacent times and if they should be in the same location, back to back to reduce travel costs. Cheers -Rob ___ Openstack-security mailing list openstack-secur...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup
I plan on attending. -bryan On Thu, May 22, 2014 at 10:48 AM, Jarret Raim jarret.r...@rackspace.comwrote: All, There was some interest at the Summit in semi-combining the mid-cycle meet ups for Barbican, Keystone and the OSSG as there is some overlap in team members and interest areas. The current dates being considered are: Mon, July 7 - Barbican Tue, July 8 - Barbican Wed, July 9 - Barbican / Keystone Thu, July 10 - Keystone Fri, July 11 - Keystone Assuming these dates work for for everyone, we'll fit some OSSG work in during whatever days make the most sense. The current plan is to have the meet up in San Antonio at the new Geekdom location, which is downtown. This should make travel a bit easier for everyone as people won't need cars are there are plenty of hotels and restaurants within walking / short cab distance. I wanted to try to get a quick head count from the Barbican and OSSG folks (I think Dolph already has one for Keystone). I'd also like to know if you are a Barbican person interested in going to the Keystone sessions or vice versa. Once we get a rough head count estimate, Dolph and I can work on getting everything booked. Thanks, -- Jarret Raim @jarretraim ___ Openstack-security mailing list openstack-secur...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [barbican] Cryptography audit by OSSG
Is anyone following the openstack-security list and/or part of the OpenStack Security Group (OSSG)? This sounds like another group and list we should keep our eyes on. I'm one of the OSSG leads. We'd certainly welcome your involvement in OSSG. In fact, there has been much interest in OSSG about the Barbican project. And I believe that many people from the group are contributing to Barbican. In the below thread on the security list, Nathan Kinder is conducting a security audit of the various integrated OpenStack projects. He's answering questions such as what crypto libraries are being used in the projects, algorithms used, sensitive data, and potential improvements that can be made. Check the links out in the below thread. Though we're not yet integrated, it might be beneficial to put together our security audit page under Security/Icehouse/Barbican. This would be very helpful. If there's anything I can do to help facilitate this, just let me know. Cheers, -bryan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
+1 -bryan On Wed, Dec 18, 2013 at 10:22 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/18/2013 12:34 PM, Doug Hellmann wrote: I have more of an issue with a project failing *after* becoming integrated than during incubation. That's why we have the incubation period to begin with. For the same reason, I'm leaning towards allowing projects into incubation without a very diverse team, as long as there is some recognition that they won't be able to graduate in that state, no matter the technical situation. This precisely sums up my view as well. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
$ git shortlog -s -e | sort -n -r 172 John Wood john.w...@rackspace.com 150 jfwood john.w...@rackspace.com 65 Douglas Mendizabal douglas.mendiza...@rackspace.com 39 Jarret Raim jarret.r...@rackspace.com 17 Malini K. Bhandaru malini.k.bhand...@intel.com 10 Paul Kehrer paul.l.keh...@gmail.com 10 Jenkins jenk...@review.openstack.org 8 jqxin2006 jqxin2...@gmail.com 7 Arash Ghoreyshi arashghorey...@gmail.com 5 Chad Lung chad.l...@gmail.com 3 Dolph Mathews dolph.math...@gmail.com 2 John Vrbanac john.vrba...@rackspace.com 1 Steven Gonzales stevendgonza...@gmail.com 1 Russell Bryant rbry...@redhat.com 1 Bryan D. Payne bdpa...@acm.org It appears to be an effort done by a group, and not an individual. Most commits by far are from Rackspace, but there is at least one non-trivial contributor (Malini) from another company (Intel), so I think this is OK. There has been some interest from some quarters (RedHat, HP and others) in additional support. I hope that the incubation process will help accelerate external contributions. For what it's worth, I just wanted to express my intent to get more involved in Barbican in the near future. I plan to be helping out with both reviews and coding on a variety of pieces. So that will help (a little) with the diversification situation. I would also mention that there has been great interest in Barbican among the OSSG crowd and it wouldn't surprise me to see more people from that group getting involved in the future. Cheers, -bryan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Nominations to Horizon Core
I just wanted to close the loop here. I understand the position that others are taking and it appears that I'm outnumbered :-) While I disagree with this approach, it sounds like that's where we are at today. Even with this decision, I would encourage the horizon dev team to utilize Paul as a security resource. Perhaps the best way to flag something as needing a security review in gerrit is to tag your PRs by writing SecurityImpact in the commit message. This will trigger a message to the openstack-security mailing list. Which should (hopefully!) result in some additional eyes on the code. Cheers, -bryan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Nominations to Horizon Core
Re: Removing Paul McMillan from core I would argue that it is critical that each project have 1-2 people on core that are security experts. The VMT is an intentionally small team. They are moving to having specifically appointed security sub-teams on each project (I believe this is what I heard at the last summit). These teams would be a subset of the core devs that can handle security reviews. They idea is that these people would then be able to +1 / -1 embargoed security patches. So having someone like Paul on Horizon core would be very valuable for such things. In addition, I think that gerrit is exactly where security reviews *should* be happening. Much better to catch things before they are merged, rather than as bugs after-the-fact. Would we rather have a -1 on a code review than a CVE? My 2 cents, -bryan (from OSSG) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Nominations to Horizon Core
We can involve people in security reviews without having them on the core review team. They are separate concerns. Yes, but those people can't ultimately approve the patch. So you'd need to have a security reviewer do their review, and then someone who isn't a security person be able to offer the +1/+2 based on the opinion of the security reviewer. This doesn't make any sense to me. You're involving an extra person needlessly, and creating extra work. This has been discussed quite a bit. We can't handle security patches on gerrit right now while they are embargoed because we can't completely hide them. I think that you're confusing security reviews of new code changes with reviews of fixes to security problems. In this part of my email, I'm talking about the former. These are not embargoed. They are just the everyday improvements to the system. That is the best time to identify and gate on security issues. Without someone on core that can give a -2 when there's a problem, this will basically never happen. Then we'll be back to fixing a greater number of things as bugs. -bryan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE Request: Encrypt Cinder volumes
2) There is general consensus that the simple config based key manager (single key) does provide some amount of useful security. I believe it does, just want to make sure we're in agreement on it. Obviously we want to improve this in the future. I believe that it does add value. For example, if the config is on a different disk than the volumes, then this is very useful for ensuring that data remains secure on RMA'd disks. -bryan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] key management and Cinder volume encryption
How can someone use your code without a key manager? Some key management mechanism is required although it could be simplistic. For example, we’ve tested our code internally with an implementation of the key manager interface that returns a single, constant key. That works for testing but doesn't address: the current dearth of key management within OpenStack does not preclude the use of our existing work within a production environment My understanding here is that users are free to use any key management mechanism that they see fit. This can be a simple return a static key option. Or it could be using something more feature rich like Barbican. Or it could be something completely home grown that is suited to a particular OpenStack deployment. I don't understand why we are getting hung up on having a key manager as part of OpenStack in order to accept this work. Clearly there are other pieces of OpenStack that have external dependencies (message queues, to name one). I, for one, am looking forward to using this feature and would be very disappointed to see it pushed back for yet another release. Is a feature complete if no one can use it? I am happy with a less then secure but fully functional key manager. But with no key manager that can be used in a real deployment, what is the value of including this code? Of course people can use it. They just need to integrate with some solution of the deployment's choosing that provides key management capabilities. And, of course, if you choose to not use the volume encryption then you don't need to worry about it at all. I've watched this feature go through many, many iterations throughout both the Grizzly and Havana release cycles. The authors have been working hard to address everyone's concerns. In fact, they have navigated quite a gauntlet to get this far. And what they have now is an excellent, working solution. Let's accept this nice security enhancement and move forward. Cheers, -bryan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OSSG] ASK - What is the regular OSSG IRC meetup schedule? #TIA
FYI, currently 1800 UTC is 11a Pacific. Hopefully you can still make it. Cheers, -bryan On Wed, Aug 21, 2013 at 11:20 AM, Sriram Subramanian sri...@sriramhere.comwrote: Thanks Bryan, would like to get involved more. Meet you tomorrow at 10 am PST/ 1800 UTC. On Wed, Aug 21, 2013 at 11:07 AM, Bryan D. Payne bdpa...@acm.org wrote: Thursdays at 1800 UTC. https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity -bryan On Wed, Aug 21, 2013 at 10:57 AM, Sriram Subramanian sri...@sriramhere.com wrote: -- Thanks, -Sriram ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, -Sriram ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] SecurityImpact tagging in gerrit
This is a quick note to announce that the OpenStack gerrit system supports a SecurityImpact tag. If you are familiar with the DocImpact tag, this works in a similar fashion. Please use this in the commit message for any commits that you feel would benefit from a security review. Commits with this tag in the commit message will automatically trigger an email message to the OpenStack Security Group, allowing you to quickly tap into some of the security expertise in our community. PTLs -- Please help spread the word an encourage use of this within your projects. Cheers, -bryan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
