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
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:uns
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
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
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.
I plan on attending.
-bryan
On Thu, May 22, 2014 at 10:48 AM, Jarret Raim wrote:
> 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
>
>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
+1
-bryan
On Wed, Dec 18, 2013 at 10:22 PM, Jay Pipes 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 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
se
7 Arash Ghoreyshi
> > 5 Chad Lung
> > 3 Dolph Mathews
> > 2 John Vrbanac
> > 1 Steven Gonzales
> > 1 Russell Bryant
> > 1 Bryan D. Payne
> >
> >It appears to be an effort done by a group, and not an individual. Most
&
>
> 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
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
> 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 e
> External dependencies are fine, obviously. The difference is whether we
> actually have code to interface with those external dependencies. We
> have code to talk to databases and message queues. There's no code
> right now to interface with anything for key management.
>
Ok, this makes sense
> > 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 wo
> I am doing thesis in cloud computing security domain, i selected to secure
> vm migration process in openstack.
> Please let me know about this idea. i have done some initial work on it. i
> need comment of you people which will be helpful for me.
>
The OpenStack Security Guide has a (somewhat
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
wrote:
> Thanks Bryan, would like to get involved more. Meet you tomorrow at 10 am
> PST/ 1800 UTC.
>
>
> On Wed, Aug 21, 2013 at 11
Thursdays at 1800 UTC.
https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity
-bryan
On Wed, Aug 21, 2013 at 10:57 AM, Sriram Subramanian
wrote:
>
>
> --
> Thanks,
> -Sriram
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> If you do not trust keystone to give you the right information you have
> already lost as keystone is used (afaik) to check for authorization
> anyway.
>
This is true.
> Can you be a little bit more explicit on the threat model you have in
> mind and what guarantees Barbican would give you tha
> +1 for using Barbican
>>
>
> Simo just got finished saying Barbican was *not* the correct place to put
> this information...
Understood. I'm disagreeing with Simo. And I'm agreeing with Jarret Raim.
-bryan
___
OpenStack-dev mailing list
OpenStack-
> > I don't understand. Users already have custody of their own keys. The
> > only thing that Keystone/Nova has is the public key fingerprint [1], not
> > the private key...
>
> You acatually have the public key, not just the fingerprint, but indeed
> I do not see why abrbican should be involved h
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 thi
21 matches
Mail list logo
