+1 for me as well.
From: Douglas Mendizabal
mailto:douglas.mendiza...@rackspace.com>>
Reply-To: OpenStack List
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, November 5, 2014 at 4:29 PM
To: OpenStack List
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barb
+1 for me.
From: Douglas Mendizabal
mailto:douglas.mendiza...@rackspace.com>>
Reply-To: OpenStack List
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, November 5, 2014 at 4:53 PM
To: OpenStack List
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Barbican] Nomina
endorsement and I'm confident he is the right person to lead us through
the Kilo cycle, graduation and the first public Cloud deployment of
Barbican at Rackspace.
Thanks,
--
Jarret Raim
@jarretraim
smime.p7s
Description: S/MIME cryptographic signature
+1 for me as well.
Jarret
From: Douglas Mendizabal
Reply-To: OpenStack List
Date: Thursday, July 10, 2014 at 11:55 AM
To: OpenStack List , "a...@redhat.com"
Subject: [openstack-dev] [barbican] Nominating Ade Lee for barbican-core
> Hi Everyone,
>
> I would like to nominate Ade Lee for t
+1 for me.
Jarret
From: Douglas Mendizabal
Reply-To: OpenStack List
Date: Thursday, July 10, 2014 at 12:11 PM
To: OpenStack List , Nate Reller
Subject: [openstack-dev] [barbican] Nominating Nathan Reller for
barbican-core
> Hi Everyone,
>
> I would also like to nominate Nathan Reller fo
All,
This week is Barbican's mid-cycle meet up. As many of our contributors are
in San Antonio this week, I'm going to cancel our weekly meeting today.
Several of us are still on IRC, so if you need something from us, feel
free to pop into #openstack-barbican and ask.
The etherpad being used for
Rob,
RedHat is working on a backend for Dogtag, which should be capable of
doing something like that. That's still a bit hard to deploy, so it would
make sense to extend the 'dev' plugin to include those features.
Jarret
On 6/24/14, 4:04 PM, "Clark, Robert Graham" wrote:
>Yeah pretty much.
>
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
smime.p7s
Description: S/MIME cryptogr
We have not changed anything as of yet. The goal was to see if we could
find some times that work for Jamie, but I haven't done it yet. I'll post
something this week and we'll see if there is consensus.
Thanks,
--
Jarret Raim
@jarretraim
On 5/20/14, 9:22 AM, "Clark, R
to discuss.
Thanks!
--
Jarret Raim
@jarretraim
smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to solve the stated use case?
Arvind - does this work for you?
Thanks,
Jarret
From: Jarret Raim
Reply-To: OpenStack List
Date: Thursday, May 15, 2014 at 11:40 AM
To: OpenStack List
Cc: "Chan, Tim" , "Jones, Brant" ,
Morgan Fainberg , "Thyne, Bob"
So let me try to summarize our conversations from yesterday.
=== Use Case ===
Assume we have a Domain D which contains a large number of individual users.
Each user in the domain creates a public / private key. This key pair is
later used to establish authentication to services, some not from Open
I for
OpenStack and may be able to better answer you question. You can direct a
message to them by including [Horizon] in the subject of your email.
Thanks!
--
Jarret Raim
@jarretraim
From: Hachem Chraiti
Reply-To: OpenStack List
Date: Wednesday, May 7, 2014 at 9:42 AM
To: OpenStack List ,
&q
Zang mentioned that part of the issue is that the private key has to be
stored in the OpenVPN config file. If the config files are generated and
can be stored, then storing the whole config file in Barbican protects the
private key (and any other settings) without having to try to deliver the
key t
As the PTL for Barbican, I¹m happy to discuss this more here or at the
Summit.
Not sure if this is an option, but could you store the entire OpenVPN
config file in Barbican rather than just the key? Not sure if you are
generating those on demand or not, but we¹ve had several teams inside
Rackspac
I'd like to throw my name in for PTL for the Key Management Program which
includes the Barbican, python-barbicanclient and Kite projects.
I've been working on Barbican since the first line of code was committed
and was responsible for building the team and desire at Rackspace to start
the project.
>#1) do we believe OFTC is fundamentally better equipped to resist a
>DDOS, or do we just believe they are a smaller target? The ongoing DDOS
>on meetup.com the past 2 weeks is a good indicator that being a smaller
>fish only helps for so long.
It seems like we would need a answer to this question
All,
Barbican will be having our weekly meeting in #openstack-meeting-alt in 30
minutes at 2:00pm Central, 2000 UTC.
On the list today is a quick discussion covering the status of the
Barbican incubation request. We may also discuss the asymmetric work going
on and possibly an update on Dogtag su
I spun one up here
https://etherpad.openstack.org/p/GFoJ4LpK8A
Most of the questions are on our incubation wiki, but I answered each of
the issues from the page you linked.
Thanks,
--
Jarret Raim
@jarretraim
On 2/4/14, 7:45 AM, "Thierry Carrez" wrote:
>Jarret Raim wrote
Paul Kehrer and I are talking about the state of crypto in Python. The
talk isn't specifically about OpenStack, but we will be talking about
various OpenStack related issues including the Barbican service.
Thanks,
Jarret
On 1/30/14, 11:05 AM, "Anita Kuno" wrote:
>On 01/30/2014 09:51 AM, Dou
Reply-To: OpenStack List
Date: Wednesday, January 29, 2014 at 4:54 PM
To: OpenStack List
Cc: "barbi...@lists.rackspace.com"
Subject: Re: [openstack-dev] Barbican Incubation Review
On Wed, Jan 29, 2014 at 2:42 PM, Jarret Raim
wrote:
>
> All,
>
> Barbican, the
On 1/29/14, 4:21 PM, "Justin Santa Barbara" wrote:
>* the API for asymmetric keys (i.e. keys with a public and private
>part) has not yet been fleshed out
That's correct. We are working with folks from HP and others on the
blueprints to implement asymmetric support. Our hope is to have it done
f
Thanks Adam.
The guys working on this are hdegikli and reaperhulk. The easiest way to
fine them is in #openstack-barbican. I'll cc reaperhulk on this so you have
his email. I don't think I have hdegikli's email.
Thanks,
Jarret
From: Александра Безбородова
Reply-To: OpenStack List
Date: T
We are currently hammering out the blueprints for asymmetric key support
(both for escrow and generation). Happy to talk more about your use case if
you are interested. We can do it over email or you can hop into
#openstack-barbican on Freenode and talk to the team there.
Thanks,
Jarret
From: V
on this front, but the
staging area for that work can be found here:
http://docs.cloudkeep.io/barbican-devguide/content/preface.html
The team hangs out in the #openstack-barbican channel on freenode. If you
want to talk, stop on by.
Thanks,
Jarret Raim
smime.p7s
Description:
> -Original Message-
> From: Steven Dake [mailto:sd...@redhat.com]
> In this particular case, I believe Barbican is not ready for incubation
because
> of their dependence on celery, but ultimately I don't make the decision :)
We've landed the PR that removes celery and replaces it with osl
> It is a difficult thing to measure, and I don't think the intent is to set
a hard %
> for contributions. I think the numbers for Barbican were just illustrating
the
> fact that the concrete contributions are very coming very heavily from one
> source. That's only one data point, though, and as
> -Original Message-
> From: Sylvain Bauza [mailto:sylvain.ba...@bull.net]
> Sent: Wednesday, December 18, 2013 5:04 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Diversity as a requirement for incubation
>
> Le 18/12/2013 11:40, Thi
On 12/13/13, 7:56 AM, "Russell Bryant" wrote:
>1) Are each of the items you mention big enough to have a sustainable
>team that can exist as its own program?
The answer here for Barbican and Keystone is yes.
>2) Would there be a benefit of *changing* the scope and mission of the
>Identity prog
On 12/13/13, 4:50 AM, "Thierry Carrez" wrote:
>If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin),
>Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the
>picture is:
>
>67% of commits come from a single person (John Wood)
>96% of commits come from a single com
The barbican meeting today will cover our progress on the incubation
issues brought up by the TC, test planning and any other issues.
If you are interested in barbican and have questions, stop on by
#openstack-meeting-alt in 20 minutes.
Thanks,
--
Jarret Raim
@jarretraim
smime.p7s
> I'd like to look at keeping things simple when they can be simple. I
>need to understand why there¹s
> already a key distribution service under keystone?
>
>
>https://review.openstack.org/#/c/40692/18/openstack-identity-api/v3/src/ma
>rkdown/identity-api-v3-os-kds-ext.md
I¹ve said before that I
Barbican is having our official IRC meeting in #openstack-meeting-alt today
at 2 central or 2000 UTC.
The main topic of conversation will be the tasks / comments that came up
from our incubation request. We welcome anyone with additional questions or
comments to come join us.
Thanks,
Jarret
> While I am all for adding a new program, I think we should only add one
>if we
> rule out all existing programs as a home. With that in mind why not add
>this
> to the keystone program? Perhaps that may require a tweak to keystones
>mission
> statement, but that is doable. I saw a partial an
>>
>> I think this conversation has gotten away from our incubation request
>>and
>> into an argument about what makes a good library and when and how
>>projects
>> should choose between oslo and other options. I¹m happy to have the
>>second
>> one in another thread, but that seems like a longer
> The API and developer documentation is at
>http://docs.openstack.org/developer/oslo.messaging/
This is great, thanks for the link. Would there be any objections to
adding this to the github repo and the openstack wiki pages? I spent a
bunch of time looking and wasn¹t able to turn this up.
Add
>I think there's something else you should take under consideration.
>Oslo messaging is not just an OpenStack library. It's the RPC library
>that all projects are relying on and one of the strong goals we have
>in OpenStack is to reduce code and efforts duplications. We'd love to
>have more people
>With the introduction of programs (think: official teams), all
>incubated/integrated projects must belong to an official program... So
>when a project applies for incubation but is not part of an official
>program yet, it de-facto also applies to be considered a program.
Ahh, understood. So I gu
> I've been anxious to try out Barbican, but haven't had quite enough time
to
> try it yet. But finding out it won't work with Qpid makes it unworkable
for us
> at the moment. I think a large swath of the OpenStack community won't be
> able to use it in this form too.
As mentioned in the other thr
> There are two big parts to this, I think. One is techincal - a significant
> portion
> of OpenStack deployments will not work with this because Celery does not
> work with their deployed messaging architecture.
> See another reply in this thread for an example of someone that sees the
> inabil
>>> Uses tox, but not pbr or global requirements
>>
>> I added a ŒTasks¹ section for stuff we need to do from this review and
>> I¹ve added these tasks. [4]
>>
>> [4] https://wiki.openstack.org/wiki/Barbican/Incubation
>
>Awesome. Also, if you don't mind - we should add "testr" to that list.
>We
>>> * Process
>>> ** Project must be hosted under stackforge (and therefore use git as
>>>its VCS)
>>
>> I see that barbican is now on stackforge, but python-barbicanclient is
>> still on github. Is that being moved soon?
>>
>>> ** Project must obey OpenStack coordinated project interface (
duplicate functionality present in
>>other
>> OpenStack projects. If they do, they should have a clear plan and
>>timeframe
>> to prevent long-term scope duplication.
>> ** Project should leverage existing functionality in other OpenStack
>>projects
&
-barbican and you can
contact us using the barbi...@lists.rackspace.com mailing list if desired.
Thanks,
Jarret Raim |Security Intrapreneur
-
5000 Walzem RoadOffice: 210.312.3121
San Antonio, TX 78218
> I also don't like that the discussions suggested that because it would be
hard
> to get Barbican incubated/integrated it should not be used. That is just
crazy
> talk. TripleO merged with Tuskar because Tuskar is part of deployment.
We are completing our incubation request for Barbican right now
not do that unless we have to though.
Jarret
>
>Jamie
>
>On Thu, 2013-11-21 at 20:08 +, Jarret Raim wrote:
>> The Barbican team has been taking a look at the KDS feature and the
>> proposed patch and I think this may be better placed in Barbican rather
>> than
The Barbican team has been taking a look at the KDS feature and the
proposed patch and I think this may be better placed in Barbican rather
than Keystone. The patch, from what I can tell, seems to require that a
service account create & use a key under its own tenant. In this use case,
Barbican can
A little more detail. We cut our feature complete release along with everyone
else for Havana M3. We are currently standing up the production environments
for the code. So, we believe that the codebase is pretty stable, but it has not
been run in production yet.
As John said, we're happy to hel
our 1.0 release for Havana and it should be
relatively easy to integrate the proposed patches with Barbican at that
time. Even so, the current version does offer some security and gives us
the ability to have the code tested before we introduce another moving
part.
Thanks,
Jarret Raim
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>Dolph Mathews wrote:
>> With regard
>> to:
>>https://blueprints.launchpad.net/keystone/+spec/key-distribution-server
>> [...]
>
>Dolph: you don't mention Barbican at all, does that mean that the issue
>is settled and the KDS should live in keystone ?
Dolph and I talked about having a design ses
I vote for including cffi. We are going to use a cffi lib as part of Barbican
(key management) anyway, so I'd like to see wider acceptance.
Jarret
From: Alex Gaynor mailto:alex.gay...@gmail.com>>
Reply-To: OpenStack List
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 14, 201
ts about the common features that barbican provides. I will
>take a look at the barbican architecture and join discussions there.
Thanks, we'd love the help.
Jarret
>
>
>Thanks,
>Bill
>
>
>From: Jarret Raim [mailto:jarret.r...@rackspace.com]
>
>Sen
e
hope that other projects will integrate with us. We will also provide key
management directly to customers to ensure that everyone can build strong
data protection into their applications.
Now if we can just get HSM vendors to install Barbican on their devices,
maybe we'd have something :)
I'm the product owner for Barbican at Rackspace. I'll take a shot an answering
your questions.
> 1. What is the state of the project, is it in the state where it can be
> utilized in production deployments?
We currently in active development and pushing for our 1.0 release for Havana.
As to pr
I'm not sure that I agree with this direction. In our investigation, KMIP is a
problematic protocol for several reasons:
* We haven't found an implementation of KMIP for Python. (Let us know if
there is one!)
* Support for KMIP by HSM vendors is limited.
* We haven't found software i
On 7/2/13 12:43 PM, "Simo Sorce" wrote:
>On Tue, 2013-07-02 at 16:55 +, Tiwari, Arvind wrote:
>> Hi Simo,
>>
>> I am lost.
>>
>> Does Barbican is product came out of
>>https://wiki.openstack.org/wiki/KeyManager BP?
>
>Yes Barbican is an implementation of this Blueprint afaik.
Barbican is
the keys yourself,
than that seems fine.
On 7/2/13 9:07 AM, "Jay Pipes" wrote:
>On 07/02/2013 09:49 AM, Jarret Raim wrote:
>> I've spent some time thinking about how Barbican (Key Management) can
>>help
>> in this workflow.
>>
>> We will have
I've spent some time thinking about how Barbican (Key Management) can help
in this workflow.
We will have the ability to generate SSH keys (and a host of other key &
certificate types). This is backed by cryptographically sound code and
we've spent some time figuring out the entropy problem and HS
58 matches
Mail list logo
