[openstack-dev] [barbican] Adjust weekly meeting time for US DST

[Douglas Mendizabal]

Hi openstack-dev@,

During the weekly meeting today the topic of moving the weekly meeting
forward by an hour to adjust for US Daylight Savings Time ending was
brought up.  All contributors in attendance unanimously voted for the
move. [1]

If you would like to participate in the meetings and didn't have a
chance to attend to day, or are unable to make the new proposed time of
Tuesdays at 1300 UTC, please respond to this thread and we can try to
find a time that works for everyone.  Otherwise we'll be meeting at the
new proposed time next week.

Thanks,
- Douglas Mendizábal

[1] 
http://eavesdrop.openstack.org/meetings/barbican/2018/barbican.2018-10-30-12.01.txt


__
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][heat] Identifying secrets in Barbican

[Douglas Mendizabal]

Replying inline.

On Wed, 2018-06-27 at 16:39 -0400, Zane Bitter wrote:
> We're looking at using Barbican to implement a feature in Heat[1]
> and 
> ran into some questions about how secrets are identified in the
> client.
> 
> With most openstack clients, resources are identified by a UUID. You 
> pass the UUID on the command line (or via the Python API or
> whatever) 
> and the client combines that with the endpoint of the service
> obtained 
> from the service catalog and a path to the resource type to generate
> the 
> URL used to access the resource.
> 
> While there appears to be no technical reason that barbicanclient 
> couldn't also do this, instead of just the UUID it uses the full URL
> as 
> the identifier for the resource. This is extremely cumbersome for
> the 
> user, and invites confused-deputy attacks where if the attacker can 
> control the URL, they can get barbicanclient to send a token to an 
> arbitrary URL. What is the rationale for doing it this way?
> 

IIRC, using URIs instead of UUIDs was a federation pre-optimization
done many years ago when Barbican was brand new and we knew we wanted
federation but had no idea how it would work.  The rationale was that
the URI would contain both the ID of the secret as well as the location
of where it was stored.

In retrospect, that was a terrible idea, and using UUIDs for
consistency with the rest of OpenStack would have been a better choice.
 I've added a story to the python-barbicanclient storyboard to enable
usage of UUIDs instead of URLs:

https://storyboard.openstack.org/#!/story/2002754

I'm sure you've noticed, but the URI that identifies the secret
includes the UUID that Barbican uses to identify the secret internally:

http://{barbican-host}:9311/v1/secrets/{UUID}

So you don't actually need to store the URI, since it can be
reconstructed by just saving the UUID and then using whatever URL
Barbican has in the service catalog.

> 
> In a tangentially related question, since secrets are immutable once 
> they've been uploaded, what's the best way to handle a case where
> you 
> need to rotate a secret without causing a temporary condition where 
> there is no version of the secret available? (The fact that there's
> no 
> way to do this for Nova keypairs is a perpetual problem for people,
> and 
> I'd anticipate similar use cases for Barbican.) I'm going to guess
> it's:
> 
> * Create a new secret with the same name
> * GET /v1/secrets/?name==created:desc=1 to find out
> the 
> URL for the newest secret with that name
> * Use that URL when accessing the secret
> * Once the new secret is created, delete the old one
> 
> Should this, or whatever the actual recommended way of doing it is,
> be 
> baked in to the client somehow so that not every user needs to 
> reimplement it?
> 

When you store a secret (e.g. using POST /v1/secrets), the response
includes the URI both in the JSON body and in the Location: header. 
 
There is no need for you to mess around with searching by name, since
Barbican does not use the name to identify a secret.  You should just
save the URI (or UUID) from the response, and then update the resource
using the old secret to point to the new secret instead.

> 
> Bottom line: how should Heat expect/require a user to refer to a 
> Barbican secret in a property of a Heat resource, given that:
> - We don't want Heat to become the deputy in "confused deputy
> attack".
> - We shouldn't do things radically differently to the way Barbican
> does 
> them, because users will need to interact with Barbican first to
> store 
> the secret.
> - Many services will likely end up implementing integration with 
> Barbican and we'd like them all to have similar user interfaces.
> - Users will need to rotate credentials without downtime.
> 
> cheers,
> Zane.
> 
> BTW the user documentation for Barbican is really hard to find.
> Y'all 
> might want to look in to cross-linking all of the docs you have 
> together. e.g. there is no link from the Barbican docs to the 
> python-barbicanclient docs or vice-versa.
> 
> [1] https://storyboard.openstack.org/#!/story/2002126
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] [barbican] NEW weekly meeting time

[Douglas Mendizabal]

+1

The new time slot would definitely make it much easier for me to attend
than the current one.

- Douglas Mendizábal

On Thu, 2018-06-14 at 16:30 -0400, Ade Lee wrote:
> The new time slot has been pretty difficult for folks to attend.
> I'd like to propose a new time slot, which will hopefully be more
> amenable to everyone.
> 
> Tuesday 12:00 UTC
> 
> https://www.timeanddate.com/worldclock/fixedtime.html?hour=12=00;
> se
> c=0
> 
> This works out to 8 am EST, around 1pm in Europe, and 8 pm in China.
> Please vote by responding to this email.
> 
> Thanks,
> Ade
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] pycrypto is dead, long live pycryptodome... or cryptography...

[Douglas Mendizabal]

One of my goals for Barbican for this cycle is to migrate our code to use 
pyca/cryptography exclusively.  We currently depend on both because at one 
point we needed things that were not available in early releases of 
cryptography.

- Douglas Mendizábal (redrobot)

> On Mar 8, 2017, at 1:11 PM, Davanum Srinivas  wrote:
> 
> Matthew,
> 
> Please see the last time i took inventory:
> https://review.openstack.org/#/q/pycryptodome+owner:dims-v
> 
> Thanks,
> Dims
> 
> On Wed, Mar 8, 2017 at 2:03 PM, Matthew Thode  
> wrote:
>> So, pycrypto upstream is dead and has been for a while, we should look
>> at moving off of it for both bugfix and security reasons.
>> 
>> Currently it's used by the following.
>> 
>> barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,
>> kolla, openstack-ansible, and a couple of other smaller places.
>> 
>> Development of it was forked into pycryptodome, which is supposed to be
>> a drop in replacement.  The problem is that due to co-installability
>> requirements we can't have half of packages out there using pycrypto and
>> the other half using pycryptodome.  We'd need to hard switch everyone as
>> both packages install into the same namespace.
>> 
>> Another alternative would be to use something like cryptography instead,
>> though it is not a drop in replacement, the migration would be able to
>> be done piecemeal.
>> 
>> I'd be interested in hearing about migration plans, especially from the
>> affected projects.
>> 
>> --
>> Matthew Thode (prometheanfire)
>> 
>> 
>> __
>> 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
>> 
> 
> 
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> 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] OpenStack Speaker Support

[Douglas Mendizabal]

Does anyone monitor speakersupp...@openstack.org 
mailto:speakersupp...@openstack.org?  I’ve been waiting for a reply for a few 
days now.

Thanks,
- Doug Mendizábal


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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 : Dependency of pyenv configuration in Barbican.sh script

[Douglas Mendizabal]

Hi Asha,

I hope I can clear up some of your confusion about the Barbican server.  
Barbican is a standard WSGI application. [1]  The WSGI application object is 
created by the create_main_app function in barbican.api.app [2].  WSGI should 
not be confused with uWSGI [3], which is a web server that can serve WSGI 
applications.

There are many ways to deploy a WSGI application.  You could use apache with 
mod_wsgi [4],  or you could use gunicorn [5], or you could use paste.httpserver 
[6] as the barbican-api script does, or you could use uWSGI as the barbican.sh 
script does.  Whatever your choice of web server will not affect how Barbican 
works.

The barbican-api script that runs Barbican using paste.httpserver is a very 
lightweight script to get Barbican running quickly in development environments 
without any additional requirements.  The barbican.sh script is a very 
opinionated script for setting up a development environment.  Note that uwsgi 
and pyenv are not required by Barbican itself, only for the barbican.sh script. 
 Neither script is intended to be used for production deployments.

The Barbican team currently defers all deployment decisions to the operator, so 
you will have to figure out which WSGI host is right for your deployment, and 
create your own deployment scripts.

The reason you’re seeing 406 errors with your curl commands is because you’re 
not specifying an “Accept” header with your requests.  You should retry the 
curl commands with –H “Accept: application/json” and you should see the correct 
responses.

Thanks,
- Douglas Mendizabal

[1] https://www.python.org/dev/peps/pep-/
[2] 
http://git.openstack.org/cgit/openstack/barbican/tree/barbican/api/app.py#n74
[3] http://uwsgi-docs.readthedocs.org/en/latest/
[4] https://code.google.com/p/modwsgi/
[5] http://gunicorn.org/
[6] http://pythonpaste.org/modules/httpserver.html

From: Asha Seshagiri asha.seshag...@gmail.commailto:asha.seshag...@gmail.com
Date: Thursday, April 23, 2015 at 4:17 PM
To: Adam Harwell adam.harw...@rackspace.commailto:adam.harw...@rackspace.com
Cc: neetu jain nut...@gmail.commailto:nut...@gmail.com, John Wood 
john.w...@rackspace.commailto:john.w...@rackspace.com, openstack-dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Reller, Nathan S. 
nathan.rel...@jhuapl.edumailto:nathan.rel...@jhuapl.edu, Douglas Mendizábal 
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com, 
Paul Kehrer paul.keh...@rackspace.commailto:paul.keh...@rackspace.com, 
Alexis Lee alex...@hp.commailto:alex...@hp.com
Subject: Re: Barbican : Dependency of pyenv configuration in Barbican.sh script

Hi All ,

Would need help!

I tried executing the script present in the link 
https://github.com/openstack/barbican/blob/master/bin/barbican-api  to  start 
the barbican instance but  the use cases of barbican are failing.
Please find the details of the investigations :

Usecase for posting and retrieving the secret.

[root@barbican-keystone2 ~]# curl -X POST -H 'content-type:application/json' -H 
'X-Project-Id:12345' -d '{payload: my-secret-here, payload_content_type: 
text/plain}' http://localhost:9311/v1/secrets
{code: 406, description: null, title: Not 
Acceptable}[root@barbican-keystone2 ~]#

[root@barbican-keystone2 ~]# curl -H 'Accept: application/json' -H 
'X-Project-Id:12345' http://localhost:9311/v1/secrets
{code: 406, description: null, title: Not 
Acceptable}[root@barbican-keystone2 ~]#
[root@barbican-keystone2 ~]#

[root@barbican-keystone2 ~]#  curl -X POST -H 'content-type:application/json' 
-H 'X-Project-Id:12345' -d '{payload: my-secret-here, 
payload_content_type: text/plain}' http://127.0.0.1:9311/v1/secrets
{code: 406, description: null, title: Not 
Acceptable}[root@barbican-keystone2 ~]#

The output of the ps command when the barbican instance is stood up using the 
python script as pointed in the above link
We do not see the instance of uwsgi in the response:

[root@barbican-keystone2 ~]# ps -ef | grep barbican
avahi 2920 1  0 Apr22 ?00:00:00 avahi-daemon: running 
[barbican-keystone2.local]
root 14743 14554  2 14:54 pts/100:00:01 python bin/barbican-api
root 14781 13975  0 14:55 pts/000:00:00 grep --color=auto barbican

The output of the ps command when the barbican instance is stood up using the 
barbican.sh script
[root@barbican-keystone2 ~]# ps -ef | grep barbican
avahi 2920 1  0 Apr22 ?00:00:00 avahi-daemon: running 
[barbican- keystone2.local]
root 14577 14554  0 14:50 pts/100:00:00 /bin/bash bin/barbican.sh start
root 14582 14577  0 14:50 pts/100:00:00 uwsgi --master --emperor 
/etc/barbican/vassals
root 14583 14582  0 14:50 pts/100:00:00 uwsgi --master --emperor 
/etc/barbican/vassals
root 14584 14583  0 14:50 pts/100:00:00 /usr/bin/uwsgi --ini 
barbican-admin.ini
root 14585 14583  0 14:50 pts/100:00:00 /usr/bin/uwsgi --ini 
barbican-api.ini
root 14586 14584

[openstack-dev] [api] Minor changes to API

[Douglas Mendizabal]

Hi openstack-dev@

I was wondering if the API Working Group had an opinion on how to deal with 
minor changes to the api?  For example, what if you wanted to add a new 
attribute to a JSON response?  I would think that a minor change like that 
could be done without having to create a new versioned endpoint.  So a newer 
release would just add the new attribute without having to create a new /v1.1/ 
endpoint.

However, minor changes like that could still possibly break clients that are 
not expecting them.  For example, a client that uses the json response as 
arguments to a method via **kwargs would start seeing TypeErrors for unexpected 
arguments.

Thanks,
Douglas Mendizabal


__
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] Liberty Design Summit - Proposed slot allocation

[Douglas Mendizabal]

The Barbican will probably only need 2 fishbowls, so we wouldn’t mind
donating the third one to OSSG.

-Doug Mendizabal

On 4/10/15, 4:46 AM, Clark, Robert Graham robert.cl...@hp.com wrote:

On 10/04/2015 10:37, Thierry Carrez thie...@openstack.org wrote:

Hi PTLs,

Here is the proposed slot allocation for every project team at the
Liberty Design Summit in Vancouver. This is based on the requests the
kilo PTLs have made, space availability and project activity 
collaboration needs.

Since newly-elected PTLs might want to make some changes based on their
perceived needs now, I'll let a week pass before I present the *final*
slot allocation and proposed room layout. Please send comments to me
directly so I can take everything into account.

We have some extra availability but it comes with constraints.
- *1* extra fishbowl slot which I kept as wiggle room to solve hard
dilemmas next week.
- Extra work room space, but that would happen on the Tuesday (same day
as cross-project and ops sessions which you should not want to miss)
- For those who haven't any Friday contributors meetups, we have 4
slots left for a half-day meetup, but it would be on Friday *afternoon*.

If you're interested in those, let me know.
If you don't need that many slots after all, let me also know.

Here is the allocation (Fishbowl/Work rooms/Meetup*):

Nova  18  0   2
Neutron   8   9   1
Horizon   3   8   2
Cinder5   8   2
Keystone  4   8   2
Heat  5   10  1
Rally 1   2   0
Ironic2   6   2
Glance4   8   1
Sahara2   5   2
Ceilometer2   8   1
Manila3   4   0
Magnum**  4   6   0
Swift 6   10  2
Designate 1   8   1
Congress  1   2   0
Trove 3   5   2
Barbican  3   10  1
Murano1   2   2
OpenStackClient   1   1   1
Zaqar 2   4   0
Mistral   2   4   0
GBP   0   5   0

Oslo  9   8   0
QA5   4   2
Infra 4   4   0***
TripleO   2   2   2
Docs  4   2   1
Release Mgmt  1   1   0***
Security**1   1   0

* For meetup: 1 means half-day, 2 means full day
** Haven't received requests in time for those projects, so I made an
educated guess
*** Shares the meetup with QA

Thanks for organising this Thierry,

The security team discussed this last night, we could use one more
fishbowl and one meetup if anything else is available, if not then we¹ll
just squeeze everything in where we can.

We can try for the Friday afternoon meetup slots but I¹m guessing
attendance will be down for those pretty much across the board.

Regards
-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 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] Kilo stable branches for other libraries

[Douglas Mendizabal]

The Barbican Team also has a plan to release a new version of barbican client 
for Kilo.  The planned version is 3.1.0. [1] and it will include features 
landed during FFE.

Thanks,
-Douglas Mendizabal

[1] https://launchpad.net/python-barbicanclient/+milestone/3.1.0 
https://launchpad.net/python-barbicanclient/+milestone/3.1.0

 On Apr 9, 2015, at 11:23 AM, Akihiro Motoki amot...@gmail.com wrote:
 
 Neutron team has a plan to release a new version of neutornclient for Kilo.
 We waited the new release until all granted FFE patches land,
 and now we are almost ready to go. (waiting one patch in the gate)
 
 The planned new version is 2.4.0. It is because neutronclient uses 2.3.x 
 version
 for a long time (including Kilo) and we would like to have a room for
 bug fixing for Juno release.
 So we would like to propose the following for Kilo:
 
  python-neutronclient =2.4.0 2.5.0
 
 I am in the same page with Kyle.
 I hope this plan is acceptable.
 
 Thanks,
 Akihiro
 
 
 2015-04-10 0:09 GMT+09:00 Thierry Carrez thie...@openstack.org 
 mailto:thie...@openstack.org:
 Doug Hellmann wrote:
 Excerpts from Dean Troyer's message of 2015-04-08 09:42:31 -0500:
 On Wed, Apr 8, 2015 at 8:55 AM, Thierry Carrez thie...@openstack.org
 wrote:
 
 The question is, how should we proceed there ? This is new procedure, so
 I'm a bit unclear on the best way forward and would like to pick our
 collective brain. Should we just push requirements cap for all OpenStack
 libs and create stable branches from the last tagged release everywhere
 ? What about other libraries ? Should we push a cap there too ? Should
 we just ignore the whole thing for the Kilo release for all non-Oslo stuff
 ?
 
 Provided that represents the code being used for testing at this point, and
 I believe it does, this seems like a sensible default action.  Next cycle
 we can make a bit more noise about when this default action will occur,
 probably pick one of the other existing dates late in the cycle such as RC
 or string freeze or whatever. (Maybe that already happened and I can't
 remember?)
 
 I had hoped to have the spec approved in time to cut releases around
 the time Oslo did (1 week before feature freeze for applications,
 to allow us to merge the requirements cap before applications
 generate their RC1). At this point, I agree that we should go with
 the most recently tagged versions where possible. It sounds like
 we have a couple of libs that need releases, and we should evaluate
 those on a case-by-case basis, defaulting to not updating the stable
 requirements unless absolutely necessary.
 
 OK, here is a plan, let me know if it makes sense.
 
 If necessary:
 Cinder releases python-cinderclient 1.1.2
 Designate releases python-designateclient 1.1.2
 Horizon releases django_openstack_auth 1.2.0
 Ironic releases python-ironicclient 0.5.1
 
 Then we cap in requirements stable/kilo branch (once it's cut, when all
 RC1s are done):
 
 python-barbicanclient =3.0.1 3.1.0
 python-ceilometerclient =1.0.13 1.1.0
 python-cinderclient =1.1.0 1.2.0
 python-designateclient =1.0.0 1.2.0
 python-heatclient =0.3.0 0.5.0
 python-glanceclient =0.15.0 0.18.0
 python-ironicclient =0.2.1 0.6.0
 python-keystoneclient =1.1.0 1.4.0
 python-neutronclient =2.3.11 2.4.0
 python-novaclient =2.22.0 2.24.0
 python-saharaclient =0.8.0 0.9.0
 python-swiftclient =2.2.0 2.5.0
 python-troveclient =1.0.7 1.1.0
 glance_store =0.3.0 0.5.0
 keystonemiddleware =1.5.0 1.6.0
 pycadf =0.8.0 0.9.0
 django_openstack_auth=1.1.7,!=1.1.8 1.3.0
 
 As discussed we'll add openstackclient while we are at it:
 
 python-openstackclient=1.0.0,1.1.0
 
 That should trickle down to multiple syncs in multiple projects, which
 we'd merge in a RC2. Next time we'll do it all the same time Oslo did
 it, to avoid creating unnecessary respins (live and learn).
 
 Anything I missed ?
 
 Bonus question: will the openstack proposal bot actually propose
 stable/kilo g-r changes to proposed/kilo branches ?
 
 --
 Thierry Carrez (ttx)
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org 
 mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 --
 Akihiro Motoki amot...@gmail.com mailto:amot...@gmail.com
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org 
 mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


signature.asc
Description: Message signed with OpenPGP using GPGMail

[openstack-dev] [barbican] PTL Candidacy

[Douglas Mendizabal]

I would like to announce my candidacy for Barbican PTL for the Liberty cycle.

I’ve been working on the Barbican project for almost two years now, and I’ve 
had the honor of serving as the PTL for the current cycle.  I’m proud of all 
the work our team has put into the Kilo release.  We managed to add a lot of 
new functionality while also improving the quality of the existing code base by 
dramatically increasing our testing coverage.

For the Liberty cycle, I would like to see our team continue to grow, as well 
as help out other projects who are planning to integrate with Barbican.

Thanks,
-Douglas Mendizabal


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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 : Usage of mode attribute in storing and order the secret

[Douglas Mendizabal]

Hi Asha,

Barbican Orders of type “key” are intended to generate keys suitable for 
encryption.  The metadata associated with the key order defines the encryption 
scheme in which the key will be used.  In the example you provided, the order 
is requesting a key that is suitable for use in a block cipher.  Specifically 
you’re requesting a key that will be used with the “AES” block cipher, so the 
“mode describes the mode of operation to be used, which in this case is Cipher 
Block Chaining or “CBC”.

Acceptable values for “mode” are dependent on the value of the “algorithm” 
attribute.  When requesting orders for keys to be used in AES encryption, the 
values for “mode” correspond to the other possible modes of operation for AES, 
such as “ECB”, “CTR”, etc.

-Doug


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

On Mar 30, 2015, at 12:46 PM, Asha Seshagiri 
asha.seshag...@gmail.commailto:asha.seshag...@gmail.com wrote:

Any help would be appreciated ?
Thanks in advance !

Thanks and Regards,
Asha Seshagiri

On Mon, Mar 30, 2015 at 12:45 PM, Asha Seshagiri 
asha.seshag...@gmail.commailto:asha.seshag...@gmail.com wrote:
Hi All ,

What is the use of the mode attribute ? what does the value of this attribute 
signify and what are the possible values of this attribute?
For ex :Consider the order request to create the secret :


POST v1/orders

Header: content-type=application/json
X-Project-Id: {project_id}
{
  type: key,
  meta: {
name: secretname,
algorithm: AES,
bit_length: 256,
mode: cbc,
payload_content_type: application/octet-stream
  }
}

What does the mode  value cbc  indicate ?
--
Thanks and Regards,
Asha Seshagiri



--
Thanks and Regards,
Asha Seshagiri

__
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] [barbican] python-barbicanclient 3.0.3 released

[Douglas Mendizabal]

The Barbican Project Team would like to announce the release of 
python-barbicanclient 3.0.3.

The release is available via PyPI

* https://pypi.python.org/pypi/python-barbicanclient 
https://pypi.python.org/pypi/python-barbicanclient

For detailed release notes, please visit the milestone page in Launchpad

* https://launchpad.net/python-barbicanclient/+milestone/3.0.3 
https://launchpad.net/python-barbicanclient/+milestone/3.0.3

Many thanks to all the contributors who made this release possible!

- Doug Mendizábal


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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 : Unable to create the container with the POST request using the CURL command

[Douglas Mendizabal]

HI Asha,

It looks like your curl command is malformed, which is why you’re getting all 
the curl errors.  You need to quote the entirety of the payload, like so:

curl -X POST -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d '{ 
name: container1 ,type: rsa,secret_refs: [ { name: private_key, 
secret_ref:http://localhost:9311/v1/secrets/b9e474a4-aed9-4d5b-98a7-5f2127aad81f;
 }, { name: public_key, 
secret_ref:http://localhost:9311/v1/secrets/c49e4b6a-7ec1-4a81-9ee5-58647102e5b6;
 } , { name: private_key_passphrase, 
secret_ref:http://localhost:9311/v1/secrets/3cd2fdc8-e30d-4f33-a1d8-81aa0bc2c47e;
 } ] }' http://localhost:9311/v1/containers

Or else your shell splits the payload and you get all the errors you listed.

-Doug


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

On Mar 16, 2015, at 5:24 PM, Asha Seshagiri 
asha.seshag...@gmail.commailto:asha.seshag...@gmail.com wrote:

Hi All,

Could any one help me out with the execution of the command for creating the 
container .
Please find the command and the response below :

root@barbican:~# curl -X POST -H 'content-type:application/json' -H 
'X-Project-Id: 12345' -d { name: container1 ,type: rsa,secret_refs: [ 
{ name: private_key, 
secret_ref:http://localhost:9311/v1/secrets/b9e474a4-aed9-4d5b-98a7-5f2127aad81f;
 }, { name: public_key, 
secret_ref:http://localhost:9311/v1/secrets/c49e4b6a-7ec1-4a81-9ee5-58647102e5b6;
 } , { name: private_key_passphrase, 
secret_ref:http://localhost:9311/v1/secrets/3cd2fdc8-e30d-4f33-a1d8-81aa0bc2c47e;
 } ] } http://localhost:9311/v1/containers
curl: (6) Could not resolve host: name
curl: (6) Could not resolve host: container1
curl: (6) Could not resolve host: ,type
curl: (6) Could not resolve host: rsa,secret_refs
curl: (3) [globbing] bad range specification in column 2
curl: (3) [globbing] unmatched brace in column 1
curl: (6) Could not resolve host: name
curl: (6) Could not resolve host: private_key,
curl: (6) Could not resolve host: secret_ref:http
curl: (3) [globbing] unmatched close brace/bracket in column 1
curl: (3) [globbing] unmatched brace in column 1
curl: (6) Could not resolve host: name
curl: (6) Could not resolve host: public_key,
curl: (6) Could not resolve host: secret_ref:http
curl: (3) [globbing] unmatched close brace/bracket in column 1
curl: (6) Could not resolve host: ,
curl: (3) [globbing] unmatched brace in column 1
curl: (6) Could not resolve host: name
curl: (6) Could not resolve host: private_key_passphrase,
curl: (6) Could not resolve host: secret_ref:http
curl: (3) [globbing] unmatched close brace/bracket in column 1
curl: (3) [globbing] unmatched close brace/bracket in column 1
curl: (3) [globbing] unmatched close brace/bracket in column 1
{code: 400, description: Malformed JSON, title: Bad 
Request}root@barbican:~#

Also I got the secret references by using the following command and selected 
the highlighted secret from the list  :

url -H 'Accept: application/json' -H 'X-Project-Id:12345' 
http://localhost:9311/v1/secrets
{secrets: [{status: ACTIVE, secret_type: opaque, 
updated: 2015-03-10T21:23:52.843606, name: null, algorithm: null, 
created: 2015-03-10T21:23:52.838400, secret_ref: 
http://localhost:9311/v1/secrets/de9502e5-42b2-4b17-8d8b-932dbc40604e;, 
content_types: {default: text/plain}, expiration: null, bit_length: 
null, mode: null}, {status: ACTIVE, secret_type: opaque, updated: 
2015-03-10T21:40:10.476840, name: null, algorithm: null, created: 
2015-03-10T21:40:10.473810, secret_ref: 
http://localhost:9311/v1/secrets/a7af62f1-b763-4643-813f-e268326967e3;, 
content_types: {default: text/plain}, expiration: null, bit_length: 
null, mode: null}, {status: ACTIVE, secret_type: opaque, updated: 
2015-03-11T19:02:03.381427, name: null, algorithm: null, created: 
2015-03-11T19:02:03.381427, secret_ref: 
http://localhost:9311/v1/secrets/b9e474a4-aed9-4d5b-98a7-5f2127aad81f;, 
expiration: null, bit_length: null, mode: null}, {status: ACTIVE, 
secret_type: opaque, updated: 2015-03-11T21:36:11.555639, name: null, 
algorithm: null, created: 2015-03-11T21:36:11.555639, secret_ref: 
http://localhost:9311/v1/secrets/c49e4b6a-7ec1-4a81-9ee5-58647102e5b6;, 
expiration: null, bit_length: null, mode: null}, {status: ACTIVE, 
secret_type: opaque, updated: 2015-03-11T22:22:49.473581, name: null, 
algorithm: null, created: 2015-03-11T22:22:49.473581, secret_ref: 
http://localhost:9311/v1/secrets/5ebc1454-785f-4001-bc22-dd25957e8de3;, 
expiration: null, bit_length: null, mode: null}, {status: ACTIVE, 
secret_type: opaque, updated: 2015-03-13T15:25:35.989442, name: null, 
algorithm: null, created: 2015-03-13T15:25:35.989442, secret_ref: 
http://localhost:9311/v1/secrets/13c7c239-0571-4471-820c-7f782855ee67;, 
expiration: null, bit_length: null, mode: null}, {status: ACTIVE, 
secret_type: opaque, updated: 2015-03-13T15:38:14.930289, name: null, 
algorithm: null, 

Re: [openstack-dev] Barbican : Usage of public_key, private_key and private_key_passphrase under RSA type Container

[Douglas Mendizabal]

Hello again Asha,

Yes, the predefined secret names in an RSA container should match up with 
secret refs for those actual things.  “private_key” should point to the private 
key of the RSA pair, “public_key” should point to the matching public key.

private_key_passphrase is optional, and it is only used for 
passphrase-protected keys.  It should point to a secret that has the plain text 
passphrase used to unlock the private key.

-Doug


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

 On Mar 16, 2015, at 5:29 PM, Asha Seshagiri asha.seshag...@gmail.com wrote:
 
 Hi All,
 
 Lastly , I would like to know whether the predefined secret names 
 private_key”, “public_key”, and “private_key_passphrase” in RSA containers  
 has any logical relation with the secret reference.
 
 For ex : If the name of the secret is private_key , should the secret_ref be 
 necessarily a private_key .Does the  same thing holds good  with the public 
 key as well.
 
 What is private_key_passpharse and what is the difference between private_key 
 and private_key_passpharse ?
 
 It would be great if anyone could help me on this .
 Thanks in advance !
 --
 Thanks and Regards,
 Asha Seshagiri
 __
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] new failures running Barbican functional tests

[Douglas Mendizabal]

Thanks for the insight, other Doug. :)  It appears that this is in part due to 
the fact that Tempest has not yet updated to oslo_log and is still using 
incubator oslo.log.  Can someone from the Tempest team chime in on what the 
status of migrating to oslo_log is?

It’s imperative for us to fix our gate, since we’re blocked from landing any 
code, which just over a week away from a milestone release is a major 
hinderance.

Thanks,
-Doug Mendizábal


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

 On Mar 9, 2015, at 8:58 PM, Doug Hellmann d...@doughellmann.com wrote:
 
 
 
 On Mon, Mar 9, 2015, at 05:39 PM, Steve Heyman wrote:
 We are getting issues running barbican functional tests - seems to have
 started sometime between Thursday last week (3/5) and today (3/9)
 
 Seems that oslo config giving us DuplicateOptErrors now.  Our functional
 tests use oslo config (via tempest) as well as barbican server code.
 Looking into it...seems that oslo_config is 1.9.1 and oslo_log is 1.0.0
 and a system I have working has oslo_config 1.9 and oslo_log at 0.4 (both
 with same barbican code).
 
 We released oslo.log today with an updated setting for the default log
 levels for third-party libraries. The new option in the library
 conflicts with the old definition of the option in the incubated code,
 so if you have some dependencies using oslo.log and some using the
 incubated library you'll see this error.
 
 Updating from the incubated version to the library is not complex, but
 it's not just a matter of changing a few imports. There are some
 migration notes in this review: https://review.openstack.org/#/c/147312/
 
 Let me know if you run into issues or need a hand with a review.
 
 Also getting Failure: ArgsAlreadyParsedError (arguments already parsed:
 cannot register CLI option)which seems to be related.
 
 This is probably an import order issue. After a ConfigOpts object has
 been called to parse the command line you cannot register new command
 line options. It's possible the problem is actually caused by the same
 module conflict, since both log modules register command line options. I
 would need a full traceback to know for sure.
 
 Doug
 
 Is this a known issue? Is there a launchpad bug yet?
 
 Thanks!
 
 [cid:5076AFB4-808D-4676-8F1C-A6E468E2CD73]
 __
 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
 Email had 1 attachment:
 + signature-with-mafia[2].png
  19k (image/png)
 
 __
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] python-barbicanclient 3.0.2 released

[Douglas Mendizabal]

 On Jan 29, 2015, at 1:19 PM, Doug Hellmann d...@doughellmann.com wrote:
 
 
 
 On Thu, Jan 29, 2015, at 01:31 PM, Joe Gordon wrote:
 On Thu, Jan 29, 2015 at 9:52 AM, Sean Dague s...@dague.net wrote:
 
 So, honestly, yes.
 
 For a library to release safely it must:
 
 * have stable-compat jobs running (this was the issue with barbican client)
 * if it has a stable/juno branch it must be pinned in stable/juno (this
 was the issue on most of the oslo libs)
 
 

[snip]

 Thanks to both of you for working on this!
 
 Doug
 

[snip]

+1  I definitely appreciate all the help sorting this out.  I think it’s good 
that we’ll have a stable-compat job in our gate now, but it’s still not clear 
to me how this would have prevented the problem?   Sure, we could have noticed 
that the global-requirements-sync CR was a breaking change in cinder/juno, but 
by that point the offending oslo library was already in global-requirements.

I’m still not sure what the barbican team needs to do going forward.  It seems 
that pinning an oslo lib pretty much forces every client using it to fork a 
stable branch?  If so, should we plan on supporting a stable/juno branch in 
python-barbicanclient which forks at 3.0.1 (the last juno compatible release?) 
and then back port fixes as 3.0.1.x?

Thanks,
-Doug Mendizabal


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [barbican] python-barbicanclient 3.0.2 released

[Douglas Mendizabal]

Hi openstack-dev,

The barbican team would like to announce the release of python-barbicanclient 
3.0.2.  This is a minor release that fixes a bug in the pbr versioning that was 
preventing the client from working correctly.

The release is available on PyPI

https://pypi.python.org/pypi/python-barbicanclient/3.0.2 
https://pypi.python.org/pypi/python-barbicanclient/3.0.2

Thanks,
- Doug Mendizábal


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] python-barbicanclient 3.0.2 released

[Douglas Mendizabal]

Hi Sean,

Thanks for the heads up, and for adding the stable-compat-jobs to the client. 
[1]  This is an interesting problem, since the proposal bot keeps the 
python-barbicanclient requirements in sync with global-requirements.  I’m not 
sure what the correct fix for this is?

- Doug

[1] https://review.openstack.org/#/c/150645/


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

 On Jan 27, 2015, at 7:22 PM, Sean Dague s...@dague.net wrote:
 
 On 01/27/2015 05:21 PM, Sean Dague wrote:
 On 01/27/2015 03:55 PM, Douglas Mendizabal wrote:
 Hi openstack-dev,
 
 The barbican team would like to announce the release of
 python-barbicanclient 3.0.2.  This is a minor release that fixes a bug
 in the pbr versioning that was preventing the client from working correctly.
 
 The release is available on PyPI
 
 https://pypi.python.org/pypi/python-barbicanclient/3.0.2
 
 Which just broke everything, because it creates incompatible
 requirements in stable/juno with cinder. :(
 
 Here is the footnote -
 http://logs.openstack.org/18/150618/1/check/check-grenade-dsvm/c727602/logs/grenade.sh.txt.gz#_2015-01-28_00_04_54_429
 
   -Sean
 
 --
 Sean Dague
 http://dague.net
 
 __
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [api] Optional Properties in an Entity

[Douglas Mendizabal]

Hi API WG,

I’m curious about something that came up during a bug discussion in one of the 
Barbican weekly meetings.  The question is about optional properties in an 
entity.  e.g. We have a Secret entity that has some properties that are 
optional, such as the Secret’s name.  We were split on what the best approach 
for returning the secret representation would be when an optional property is 
not set.

In one camp, some developers would like to see the properties returned no 
matter what.  That is to say, the Secret dictionary would include a key for 
“name” set to null every single time.  i.e.

{
  …
  “secret”: {
“name”: null,
…
  }
  ...
}

On the other camp, some developers would like to see optional properties 
omitted if they were not set by the user.

The advantage of always returning the property is that the response is easier 
to parse, since you don’t have to check for the existence of the optional keys. 
 The argument against it is that it makes the API more rigid, and clients more 
fragile.

I was wondering what the API Working Group’s thoughts are on this?

Thanks,
Douglas Mendizábal


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

__
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] [barbican] Retiring python-barbicanclient 2.x

[Douglas Mendizabal]

Hi openstack-dev@,

The barbican team would like to retire the 2.x branch of python-barbicanclient 
in favor of the 3.x branch:

https://review.openstack.org/#/c/146231/

The 3.x branch of python-barbicanclient represents a major improvement of the 
Barbican client.  The main breaking change between the 2.x and 3.x clients is 
the adoption of Keystone Sessions exclusively for authentication, so all 
python-barbicanclient specific authentication mechanisms from 2.x were removed.

The 3.x branch also includes a few changes to the Secret and Order models to 
make them more usable.  Specifically, both Orders and Secrets hold a handle to 
their respective EntityManager, so you don’t have to juggle two different 
objects to work with a single entity.  e.g. Storing a secret can now be done by 
calling Secret.store() on the secret instance.

Thanks,
-Douglas Mendizábal


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

__
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] [barbican] Kilo Mid-Cycle Sprint

[Douglas Mendizabal]

Hi openstack-dev!

I just wanted to send a reminder that the Barbican mid-cycle Sprint will be 
taking place on February 16-18 in Austin, TX, which is just five weeks away.  
There’ll be an overlap of a couple of days with the OSSG Mid-Cycle Sprint, 
which will hopefully give us a chance to collaborate remotely with the OSSG 
folks.  For more information and RSVP follow the link:

https://wiki.openstack.org/wiki/Sprints/BarbicanKiloSprint

Thanks,
-Douglas Mendizábal


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C
__
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] [barbican] Mid-Cycle Sprint

[Douglas Mendizabal]

Hi openstack-dev,

The Barbican team is planning to have a mid-cycle sprint in Austin, TX on 
February 16-18, 2015.  We’ll be meeting at Capital Factory, a co-working space 
in downtown Austin.

For more details and RSVP, please see:

https://wiki.openstack.org/wiki/Sprints/BarbicanKiloSprint

Thanks,
-Doug Mendizábal


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] Failing to create external stevedore plugin in Barbican

[Douglas Mendizabal]

Hi Divya,

I’m sorry to hear you’re having trouble developing a plugin.  Unfortunately,
I have not seen that error before, so I don’t have any specific advice to
give you.

From your description, I think you’re taking a few steps that are not
necessary.  You should not need to change anything in Barbican other than
the barbican-api.conf file to load a custom plugin.  The high level overview
of the steps you need to take is this:
1. Develop your own plugin as a separate python library.
2. Configure your own setup.cfg in your library to export your plugin as an
entry_point under some namespace.  E.g.
3. [entry_points]
4. mynamespace.secretstore.plugin =
5. my_plugin = mynamespace.secretstore.MySecretStorePlugin
6. Install your library so that the entry_point is added to your python path
7. Confugire barbican-api.conf to use the namespace and plugin name defined
in your own setup.cfg in step 2
There’s more detail on how to develop plugins in the official Barbican
documentation [1], although I don’t think it covers the specific steps
needed to configure your custom plugin once you’ve written it, so I’m making
a note to update those in the near future.

As a side note, I think this question would get more responses in the
openstack-dev mailing list, instead of the general purpose one you sent it
to.

I hope that helps!

-Doug Mendizábal

[1] http://docs.openstack.org/developer/barbican/plugin/index.html


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

From:  Divya Chandrasekar divya.chandrasekar...@gmail.com
Date:  Friday, November 21, 2014 at 1:50 PM
To:  openstack@lists.openstack.org openstack@lists.openstack.org
Subject:  [Openstack] Failing to create external stevedore plugin in
Barbican

Hi all,

I'm trying to create an external plugin for my barbican setup using
Stevedore. I've made changes to barbican-api.conf and setup.cfg files. Is
there anything else I should be fixing? I keep getting this broken pipe
error on install [please find below the error].

My plugin is pretty much just a placeholder now, and I've created the
namespace similar to crypto. The plugin gets added to entry_points.txt in
barbican.egg-info/ folder.

I'd appreciate any help or documentation support on how to create an
external plugin for barbican.

Thanks  regards,
Divya

== error =

Fri Nov 21 11:25:31 2014 - [emperor] vassal barbican-admin.ini has been
spawned
spawned uWSGI worker 1 (pid: 19721, cores: 1)
Loading paste environment: config:/etc/barbican/barbican-api-paste.ini
Loading paste environment: config:/etc/barbican/barbican-admin-paste.ini
WSGI app 0 (mountpoint='') ready in 9 seconds on interpreter 0x9b500e0 pid:
19721
Fri Nov 21 11:25:40 2014 - [emperor] vassal barbican-admin.ini is ready to
accept requests
2014-11-21 11:25:40.393 19720 DEBUG stevedore.extension [-] found extension
EntryPoint.parse('qpid = oslo.messaging._drivers.impl_qpid:QpidDriver')
_load_plugins 
/home/dc/.pyenv/versions/barbican27/lib/python2.7/site-packages/stevedore/ex
tension.py:156
2014-11-21 11:25:40.402 19720 DEBUG stevedore.extension [-] found extension
EntryPoint.parse('amqp =
oslo.messaging._drivers.protocols.amqp:ProtonDriver') _load_plugins
/home/dc/.pyenv/versions/barbican27/lib/python2.7/site-packages/stevedore/ex
tension.py:156
2014-11-21 11:25:40.403 19720 DEBUG stevedore.extension [-] found extension
EntryPoint.parse('kombu = oslo.messaging._drivers.impl_rabbit:RabbitDriver')
_load_plugins 
/home/dc/.pyenv/versions/barbican27/lib/python2.7/site-packages/stevedore/ex
tension.py:156
2014-11-21 11:25:40.405 19720 DEBUG stevedore.extension [-] found extension
EntryPoint.parse('rabbit =
oslo.messaging._drivers.impl_rabbit:RabbitDriver') _load_plugins
/home/dc/.pyenv/versions/barbican27/lib/python2.7/site-packages/stevedore/ex
tension.py:156
Traceback (most recent call last):
  File /home/dc/.pyenv/versions/2.7.5/lib/python2.7/runpy.py, line 162, in
_run_module_as_main
__main__, fname, loader, pkg_name)
  File /home/dc/.pyenv/versions/2.7.5/lib/python2.7/runpy.py, line 72, in
_run_code
exec code in run_globals
  File 
/home/dc/.pyenv/versions/barbican27/lib/python2.7/site-packages/subunit/run
.py, line 145, in module
main()
  File 
/home/dc/.pyenv/versions/barbican27/lib/python2.7/site-packages/subunit/run
.py, line 141, in main
stdout=stdout, exit=False)
  File 
/home/dc/.pyenv/versions/barbican27/lib/python2.7/site-packages/testtools/r
un.py, line 232, in __init__
self.runTests()
  File 
/home/dc/.pyenv/versions/barbican27/lib/python2.7/site-packages/testtools/r
un.py, line 384, in runTests
self.result = testRunner.run(self.test)
  File 
/home/dc/.pyenv/versions/barbican27/lib/python2.7/site-packages/subunit/run
.py, line 61, in run
result, _ = self._list(test)
  File 
/home/dc/.pyenv/versions/barbican27/lib/python2.7/site-packages/subunit/run
.py, line 94, in _list
result.status(test_id=test_id, 

Re: [openstack-dev] [Openstack-security] [Barbican][OSSG] Mid Cycle Attendance / Crossover.

[Douglas Mendizabal]

I think it would also be interesting to hear for the Keystone folks that
are interested in attending OSSG and/or Barbican.  A few people have told
me they found the Keystone/Barbican overlap for the last mid-cycle to be
helpful, so it might be worthwhile doing again.

-Doug M.


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




On 11/7/14, 8: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


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

Re: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for barbican-core

[Douglas Mendizabal]

Hi all,

As discussed during the Barbican Weekly Meeting today [1], after 5 days of
lazy consensus the nomination for Juan Antonio Osorio Robles has been
approved with six +1 votes, so we would like to welcome Juan to the
barbican-core team.

Thanks,
Doug Mendizábal

[1] 
http://eavesdrop.openstack.org/meetings/barbican/2014/barbican.2014-11-10-2
0.00.log.html




Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




On 11/7/14, 1:03 PM, Ade Lee a...@redhat.com wrote:

+1 for me.

On Wed, 2014-11-05 at 15:53 +, Douglas Mendizabal wrote:
 Hi All,
 
 
 I would like to nominate Juan Antonio Osorio Robles to the
 barbican-core team.
 
 
 Juan has been consistently giving us very well thought out and
 constructive reviews for Barbican, python-barbicanclient and
 barbican-specs.  It’s obvious from his reviews that he cares deeply
 for the quality of the Barbican project, and I think he will be a
 great addition to the core team.
 
 
 As a reminder to barbican-core members, we use the voting process
 outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
 members to our team.
 
 
 References:
 
 
 http://stackalytics.com/report/contribution/barbican-group/90
 
 
 Thanks,
 Douglas
 
 
 
 Douglas Mendizábal
 IRC: redrobot
 PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C
 ___
 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


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

Re: [openstack-dev] [Barbican] Nominating Steve Heyman for barbican-core

[Douglas Mendizabal]

Hi all,

As discussed during the Barbican Weekly Meeting today [1], after 5 days of
lazy consensus the nomination for Steve Heyman has been approved with six
+1 votes, so we would like to welcome Steve to the barbican-core team.

Thanks,
Doug Mendizábal

[1] 
http://eavesdrop.openstack.org/meetings/barbican/2014/barbican.2014-11-10-2
0.00.log.html


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




On 11/7/14, 1:03 PM, Ade Lee a...@redhat.com wrote:

+1 for me.

On Thu, 2014-11-06 at 11:21 +, John Wood wrote:
 +1
 
 Thanks,
 John
 
 
 From: Nathan Reller [rellerrel...@yahoo.com]
 Sent: Thursday, November 06, 2014 3:35 AM
 To: Openstack-Dev
 Subject: Re: [openstack-dev] [Barbican] Nominating Steve Heyman for
barbican-core
 
 +1 for me
 
 -Nate
 
 ___
 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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Barbican] Nominating Steve Heyman for barbican-core

[Douglas Mendizabal]

+1

Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

From:  Chad Lung chad.l...@gmail.com
Reply-To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:  Wednesday, November 5, 2014 at 4:17 PM
To:  openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org
Subject:  [openstack-dev] [Barbican] Nominating Steve Heyman for
barbican-core

Greetings ,

I would like to nominate Steve Heyman for the barbican-core team.

Steve is very active in Barbican code reviews and has been a regular
contributor of test related change requests as well as documentation.

As a reminder to barbican-core members, we use the voting process outlined
in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our
team.

Thanks,

Chad Lung





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

[openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for barbican-core

[Douglas Mendizabal]

Hi All,

I would like to nominate Juan Antonio Osorio Robles to the barbican-core
team.

Juan has been consistently giving us very well thought out and constructive
reviews for Barbican, python-barbicanclient and barbican-specs.  It’s
obvious from his reviews that he cares deeply for the quality of the
Barbican project, and I think he will be a great addition to the core team.

As a reminder to barbican-core members, we use the voting process outlined
in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our
team.

References:

http://stackalytics.com/report/contribution/barbican-group/90

Thanks,
Douglas


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




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

[openstack-dev] [barbican] Barbican Juno Release

[Douglas Mendizabal]

Hi All,

The Barbican team is proud to announce the final release of the Barbican Key
Management Service for Juno:

https://launchpad.net/barbican/juno/2014.2

This release includes 9 Blueprints and 47 bug fixes.  Check the link above
for the full details.  Many thanks to all the contributors who made this
release possible!

-Doug


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




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

[openstack-dev] [barbican] PTL Candidacy

[Douglas Mendizabal]

Hi OpenStack-dev,

I would like to put my name in the hat for PTL of the Key Management Service
Program, which includes Barbican, python-barbicanclient, Kite, and
python-kiteclient.

I’ve had the pleasure of being a part of the Barbican team since the very
beginning of the project.  During the last year and half I’ve helped
Barbican grow from a project that only a couple of Rackers were hacking on,
to an Incubated OpenStack project that continues to gain adoption in the
community, and I would like to see that momentum continue through the Kilo
cycle.

I’ve been a big fan and supporter of Jarret Raim’s vision for Barbican, and
it would be an honor for me to continue his work as the new PTL for the Key
Management Program.  One of my goals for the Kilo cycle is to move Barbican
through the Integration process by working with other OpenStack projects to
enable the security minded use-cases that are now possible with Barbican.
Additionally, I would like to continue to focus on the quality of Barbican
code by leveraging the knowledge and lessons learned from deploying Barbican
at Rackspace.

Thank you,
Douglas Mendizábal


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




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

[openstack-dev] python-barbicanclient 2.2.1 released

[Douglas Mendizabal]

The Barbican development team would like to announce the release of
python-barbicanclient version 2.2.1

python-barbicanclient is a client library for the Barbican Key Management
Service.  It provides a Python API (barbicanclient module) and a
command-line tool (barbican).

This release can be installed from PyPI:

https://pypi.python.org/pypi/python-barbicanclient

Thanks,
Doug


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




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

[openstack-dev] [barbican] Meeting Monday July 14 at 20:00 UTC

[Douglas Mendizabal]

Hi Everyone,

The Barbican team is hosting our weekly meeting today, Monday June 14, at
20:00 UTC in #openstack-meeting-alt

Meeting agenda is available here
https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed
to add agenda items.

You can check this link
http://time.is/0800PM_14_Jul_2014_in_UTC/CDT/EDT/PDT?Barbican_Weekly_Meeting
if you need to figure out what 20:00 UTC means in your time.

-Doug


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




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

[openstack-dev] [barbican] Nominating Nathan Reller for barbican-core

[Douglas Mendizabal]

Hi Everyone,

I would also like to nominate Nathan Reller for the barbican-core team.

Nathan has been involved with the Key Management effort since early 2013.
Recently, Nate has been driving the development of a KMIP backend for
Barbican, which will enable Barbican to be used with KMIP devices.  Nate’s
input to the design of the plug-in mechanisms in Barbican has been extremely
helpful, as well as his feedback in CR reviews.

As a reminder to barbican-core members, we use the voting process outlined
in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our
team.

Thanks,
Doug


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




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

[openstack-dev] [barbican] Rebase pending CRs

[Douglas Mendizabal]

All,

As part of our ongoing mid-cycle meetup, the Barbican team was able to merge
the plugin restructuring CR [1].   This is a pretty big change that will
likely cause merge conflicts for most pending CRs.  So, if you’re waiting on
reviews for Barbican change requests, please take some time to rebase your
changes.

Many thanks to John Wood for all his work and everyone who was involved in
reviewing the change!

-Doug

[1] https://review.openstack.org/#/c/103431/


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




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

[openstack-dev] [barbican] Consumer Registration API

[Douglas Mendizabal]

I was looking through some Keystone docs and noticed that for version 3.0 of
their API [1] Keystone merged the Service and Admin API into a single core
API.  I haven’t gone digging through mail archives, but I imagine they had a
pretty good reason to do that.

Adam, I know you’ve already implemented quite a bit of this, and I hate to
ask this, but how do you feel about adding this to the regular API instead
of building out the Service API for Barbican?

[1] 
https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identi
ty-api-v3.md#whats-new-in-version-30


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




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

Re: [openstack-dev] [barbican] Juno Mid-cycle Meetup

[Douglas Mendizabal]

Hi Everyone,

Just a reminder that the Barbican mid-cycle meetup is just under two weeks
away.   I just wanted to send out a link to the etherpad we’re using to do
some pre-planning of things that need to be covered during the meetup

https://etherpad.openstack.org/p/barbican-juno-meetup

Also, please be sure to RSVP if you’re planning on coming, so that we can
plan accordingly.

RSVP [ 
https://docs.google.com/forms/d/1iao7mEN6HV3CRCRuCPhxOaF4_tJ-Kqq4_Lli1quft58
/viewform?usp=send_form ]

Thanks,
Doug Mendizábal
IRC: redrobot

From:  Douglas Mendizabal douglas.mendiza...@rackspace.com
Reply-To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:  Monday, June 16, 2014 at 9:29 PM
To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject:  [openstack-dev] [barbican] Juno Mid-cycle Meetup

Hi Everyone,

Just wanted to send a reminder that the Barbican Juno meetup is coming up in
a few weeks.  We’ll be meeting at the new Geekdom location in San Antonio,
TX on  July 7-9 (Monday-Wednesday).  This meetup will overlap with the
Keystone Juno Hackathon being held July 9-11 at the same location.

RSVP [ 
https://docs.google.com/forms/d/1iao7mEN6HV3CRCRuCPhxOaF4_tJ-Kqq4_Lli1quft58
/viewform?usp=send_form ]

LOCATION

Geekdom
110 E Houston St, 7th Floor
San Antonio TX, 78205
( https://goo.gl/maps/skMaI )

DATES

Mon, July 7 – Barbican
Tue, July 8 – Barbican
Wed, July 9 – Barbican/Keystone
Thu, July 10 – Keystone
Fri, July 11 – Keystone

For more information check out the wiki page. [
https://wiki.openstack.org/wiki/Barbican/JunoMeetup ]

Thanks,

Douglas Mendizábal
IRC: redrobot




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

[openstack-dev] [barbican] Meeting Monday June 16 at 20:00 UTC

[Douglas Mendizabal]

Hi Everyone,

The Barbican team is hosting our weekly meeting today, Monday June 16nd, at
20:00 UTC in #openstack-meeting-alt

Meeting agenda is available here
https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed
to add agenda items.

You can check this link
http://time.is/0800PM_16_Jun_2014_in_UTC/CDT/EDT/PDT?Barbican_Weekly_Meeting
if you need to figure out what 20:00 UTC means in your time.

-Douglas Mendizábal





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

[openstack-dev] [barbican] Juno Mid-cycle Meetup

[Douglas Mendizabal]

Hi Everyone,

Just wanted to send a reminder that the Barbican Juno meetup is coming up in
a few weeks.  We’ll be meeting at the new Geekdom location in San Antonio,
TX on  July 7-9 (Monday-Wednesday).  This meetup will overlap with the
Keystone Juno Hackathon being held July 9-11 at the same location.

RSVP [ 
https://docs.google.com/forms/d/1iao7mEN6HV3CRCRuCPhxOaF4_tJ-Kqq4_Lli1quft58
/viewform?usp=send_form ]

LOCATION

Geekdom
110 E Houston St, 7th Floor
San Antonio TX, 78205
( https://goo.gl/maps/skMaI )

DATES

Mon, July 7 – Barbican
Tue, July 8 – Barbican
Wed, July 9 – Barbican/Keystone
Thu, July 10 – Keystone
Fri, July 11 – Keystone

For more information check out the wiki page. [
https://wiki.openstack.org/wiki/Barbican/JunoMeetup ]

Thanks,

Douglas Mendizábal
IRC: redrobot




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

Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

[Douglas Mendizabal]

Hi Doug,


Barbican does guarantee the integrity and availability of the secret,
unless the owner of the secret deletes it from Barbican.  We’re not
encouraging that you store a shadow-copy of the secret either.  This was
proposed by the LBaaS team as a possible workaround for your use case.
Our recommendation was that there are two options for dealing with Secrets
being deleted from under you:

If you want to control the lifecycle of the secret so that you can prevent
the user from deleting the secret, then the secret should be owned by
LBaaS, not by the user.  You can achieve this by asking the user to upload
the secret via LBaaS api, and then use Barbican on the back end to store
the secret under the LBaaS tenant.

If you want the user to own and manage their secret in Barbican, then you
have to deal with the situation where the user deletes a secret and it is
no longer available to LBaaS.  This is a situation you would have to deal
with even with a reference-counting and force-deleting Barbican, so I
don’t think you really gain anything from all the complexity you’re
proposing to add to Barbican.

-Douglas M.



On 6/11/14, 12:57 PM, Doug Wiegley do...@a10networks.com wrote:

There are other fundamental things about secrets, like relying on their
presence, and not encouraging a proliferation of a dozen
mini-secret-stores everywhere to get around that fact, which makes it less
secret.  Have you considered a ³force² delete flag, required if some
service is using the secret, sort of ³rm² vs ³rm -f², to avoid the obvious
foot-shooting use cases, but still allowing the user to nuke it if
necessary?

Thanks,
Doug


On 6/11/14, 11:43 AM, Clark, Robert Graham robert.cl...@hp.com wrote:

Users have to be able to delete their secrets from Barbican, it's a
fundamental key-management requirement.

 -Original Message-
 From: Eichberger, German
 Sent: 11 June 2014 17:43
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document
 on Gerrit
 
 Sorry, I am late to the party. Holding the shadow copy in the backend
is a
 fine solution.
 
 Also, if containers are immutable can they be deleted at all? Can we
make a
 requirement that a user can't delete a container in Barbican?
 
 German
 
 -Original Message-
 From: Eichberger, German
 Sent: Wednesday, June 11, 2014 9:32 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document
 on Gerrit
 
 Hi,
 
 I think the previous solution is easier for a user to understand. The
 referenced container got tampered/deleted we throw an error - but keep
 existing load balancers intact.
 
 With the shadow container we get additional complexity and the user
might
 be confused where the values are coming from.
 
 German
 
 -Original Message-
 From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
 Sent: Tuesday, June 10, 2014 12:18 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document
 on Gerrit
 
 See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican
 Neutron LBaaS Integration Ideas.
 He's advocating keeping a shadow copy of the private key that is owned
by
 the LBaaS service so that incase a key is tampered with during an LB
update
 migration etc we can still check with the shadow backup and compare it
to
 the user owned TLS container in case its not their it can be used.
 
 On Jun 10, 2014, at 12:47 PM, Samuel Bercovici samu...@radware.com
  wrote:
 
  To elaborate on the case where containers get deleted while LBaaS
still
 references it.
  We think that the following approach will do:
  * The end user can delete a container and leave a dangling
 reference in LBaaS.
  * It would be nice to allow adding meta data on the
container so that
 the user will be aware which listeners use this container. This is
optional. It
 can also be optional for LBaaS to implement adding the listeners ID
 automatically into this metadata just for information.
  * In LBaaS, if an update happens which requires to pull the
container
 from Barbican and if the ID references a non-existing container, the
update
 will fail and will indicate that the reference certificate does not
exists any
 more. This validation could be implemented on the LBaaS API itself as
well
 as also by the driver who will actually need the container.
 
  Regards,
  -Sam.
 
 
  From: Evgeny Fedoruk
  Sent: Tuesday, June 10, 2014 2:13 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST
document
  on Gerrit
 
  Hi All,
 
  Carlos, Vivek, German, thanks for reviewing the RST doc.
  There are some issues I want to pinpoint final decision on them
here, in
 ML, before writing it down in the doc.
  Other issues will be commented on the document 

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

[Douglas Mendizabal]

I think that having Barbican decide whether the user is or isn’t allowed to
delete a secret that they own based on a reference count that is not
directly controlled by them is unacceptable.   This is indeed policy
enforcement, and we’d rather not go down that path.

I’m opposed to the idea of reference counting altogether, but a couple of
other Barbican-core members are open to it, as long as it does not affect
the delete behaviors.

-Doug M.

From:  Adam Harwell adam.harw...@rackspace.com
Reply-To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:  Tuesday, June 10, 2014 at 4:17 PM
To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject:  Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
Integration Ideas

Doug: Right, we actually have a blueprint draft for EXACTLY this, but the
Barbican team gave us a flat not happening, we reject this change on
causing a delete to fail. The shadow-copy solution I proposed only came
about because the option you are proposing is not possible. :(

I also realized that really, this whole thing is an issue for the backend,
not really for the API itself — the LBaaS API will be retrieving the
key/cert from Barbican and passing it to the backend, and the backend it
what's responsible for handling it from that point (F5, Stingray etc would
never actually call back to Barbican). So, really, the Service-VM solution
we're architecting is where the shadow-copy solution needs to live, at which
point it no longer is really an issue we'd need to discuss on this mailing
list, I think. Stephen, does that make sense to you?
--Adam

https://keybase.io/rm_you


From: Doug Wiegley do...@a10networks.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: Tuesday, June 10, 2014 4:10 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
Integration Ideas

 A third option, that is neither shadow copying nor policy enforcement:
 
 Ask the Barbican team to put in a small api that is effectively, “hey, I’m
 using this container” and “hey, I’m done with this container”, and the have
 their delete fail if someone is still using it.  This isn’t calling into other
 services, it’s simply getting informed of who’s using what, and not stomping
 it.  That seems pretty core to me, and the workarounds if we can’t trust the
 store to store things are pretty hacky.
 
 Doug
 
 
 From: Adam Harwell adam.harw...@rackspace.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Tuesday, June 10, 2014 at 3:04 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
 Integration Ideas
 
 Right, service VMs are the biggest case for this, because then we WILL need to
 be tracking the barbicanID even in the backend. I also agree that it would be
 more useful for OpenStack as a whole if it were managed by a central service
 (i.e., Barbican handles this issue) rather than having to duplicate all of
 this logic in every service that utilizes the containers (VPN/FW would have to
 use essentially the same strategy, or else fragment and do something entirely
 different — the first of which is a lot of duplicated effort, and the second
 is just generally bad, already way too much fragmentation going on). On the
 other hand, the Barbican team is very opposed to doing policy enforcement
 within Barbican, and I can't say I fault them for that opinion (Barbican was
 never designed to include a policy enforcement engine). The shadow-copy
 strategy is the best alternative I can think of given the current
 project/political landscape. :(
 
 --Adam
 
 https://keybase.io/rm_you
 
 
 From: Doug Wiegley do...@a10networks.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Tuesday, June 10, 2014 3:42 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
 Integration Ideas
 
  Doug: The reasons a LB might be reprovisioned are fairly important —
 mostly around HA, for fail overs or capacity — exactly the times we're
 trying avoid a failure.
 
 Certainly the ticking time bomb is a bad idea, but HA seems cleaner to do in
 the backend, rather than at the openstack API level (the dangling reference
 doesn’t kick in until the lbaas api is used to accomplish that failover.)
 And the lbaas api also doesn’t have any provisions for helping to shuffle for
 capacity, so that also becomes a backend issue.  And the backend won’t be
 natively dealing with a barbican reference.
 
 However, couple this with 

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

[Douglas Mendizabal]

Hi all,

I’m strongly in favor of having immutable TLS-typed containers, and very
much opposed to storing every revision of changes done to a container.  I
think that storing versioned containers would add too much complexity to
Barbican, where immutable containers would work well.


I’m still not sold on the idea of registering services with Barbican, even
though (or maybe especially because) Barbican would not be using this data
for anything.  I understand the problem that we’re trying to solve by
associating different resources across projects, but I don’t feel like
Barbican is the right place to do this.

It seems we’re leaning towards option #2, but I would argue that
orchestration of services is outside the scope of Barbican’s role as a
secret-store.  I think this is a problem that may need to be solved at a
higher level.  Maybe an openstack-wide registry of dependend entities
across services?

-Doug

On 6/9/14, 2:54 PM, Tiwari, Arvind arvind.tiw...@hp.com wrote:

As per current implementation, containers are immutable.
Do we have any use case to make it mutable? Can we live with new
container instead of updating an existing container?

Arvind 

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Monday, June 09, 2014 1:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
Integration Ideas

As far as I understand the Current Barbican implementation is immutable.
Can anyone from Barbican comment on this?

-Original Message-
From: Jain, Vivek [mailto:vivekj...@ebay.com]
Sent: Monday, June 09, 2014 8:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
Integration Ideas

+1 for the idea of making certificate immutable.
However, if Barbican allows updating certs/containers then versioning is
a must.

Thanks,
Vivek


On 6/8/14, 11:48 PM, Samuel Bercovici samu...@radware.com wrote:

Hi,

I think that option 2 should be preferred at this stage.
I also think that certificate should be immutable, if you want a new
one, create a new one and update the listener to use it.
This removes any chance of mistakes, need for versioning etc.

-Sam.

-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Friday, June 06, 2014 10:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
Integration Ideas

Hey everyone,

Per our IRC discussion yesterday I'd like to continue the discussion on
how Barbican and Neutron LBaaS will interact. There are currently two
ideas in play and both will work. If you have another idea please free
to add it so that we may evaluate all the options relative to each other.
Here are the two current ideas:

1. Create an eventing system for Barbican that Neutron LBaaS (and other
services) consumes to identify when to update/delete updated secrets
from Barbican. For those that aren't up to date with the Neutron LBaaS
API Revision, the project/tenant/user provides a secret (container?) id
when enabling SSL/TLS functionality.

* Example: If a user makes a change to a secret/container in Barbican
then Neutron LBaaS will see an event and take the appropriate action.

PROS:
 - Barbican is going to create an eventing system regardless so it will
be supported.
 - Decisions are made on behalf of the user which lessens the amount of
calls the user has to make.

CONS:
 - An eventing framework can become complex especially since we need to
ensure delivery of an event.
 - Implementing an eventing system will take more time than option #2ŠI
think.

2. Push orchestration decisions to API users. This idea comes with two
assumptions. The first assumption is that most providers' customers use
the cloud via a GUI, which in turn can handle any orchestration
decisions that need to be made. The second assumption is that power API
users are savvy and can handle their decisions as well. Using this
method requires services, such as LBaaS, to register in the form of
metadata to a barbican container.

* Example: If a user makes a change to a secret the GUI can see which
services are registered and opt to warn the user of consequences. Power
users can look at the registered services and make decisions how they
see fit.

PROS:
 - Very simple to implement. The only code needed to make this a
reality is at the control plane (API) level.
 - This option is more loosely coupled that option #1.

CONS:
 - Potential for services to not register/unregister. What happens in
this case?
 - Pushes complexity of decision making on to GUI engineers and power
API users.


I would like to get a consensus on which option to move forward with
ASAP since the hackathon is coming up and delivering Barbican to
Neutron LBaaS integration is essential to exposing SSL/TLS
functionality, which almost everyone has stated is 

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

[Douglas Mendizabal]

I understand how this could be helpful, but I still don’t understand why
this is Barbican’s problem to solve.

From Jorge’s original email:

 Using this method requires services, such as LBaaS, to register in
the form of metadata to a barbican container.

If our assumptions are that the GUI can handle information, and that power
users are savvy.  Then how does that require Barbican to store the
metadata?  I would argue that the GUI can store its own metadata, and that
Power Users should be savvy enough to update their LBs (via PUT or
whatever) after uploading a new certificate.


-Doug

On 6/9/14, 6:10 PM, John Wood john.w...@rackspace.com wrote:

The impression I have from this thread is that Containers should remain
immutable, but it would be helpful to allow services like LBaaS to
register as interested in a given Container. This could be the full URI
to the load balancer instance for example. This information would allow
clients to see what services (and load balancer instances in this
example) are using a Container, so they can update them if a new
Container replaces the old one. They could also see what services depend
on a Container before trying to remove the Container.

A blueprint submission to Barbican tomorrow should provide more details
on this, and let the Barbican and LBaaS communities weigh in on this
feature.

Thanks,
John



From: Tiwari, Arvind [arvind.tiw...@hp.com]
Sent: Monday, June 09, 2014 2:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
Integration Ideas

As per current implementation, containers are immutable.
Do we have any use case to make it mutable? Can we live with new
container instead of updating an existing container?

Arvind

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Monday, June 09, 2014 1:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
Integration Ideas

As far as I understand the Current Barbican implementation is immutable.
Can anyone from Barbican comment on this?

-Original Message-
From: Jain, Vivek [mailto:vivekj...@ebay.com]
Sent: Monday, June 09, 2014 8:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
Integration Ideas

+1 for the idea of making certificate immutable.
However, if Barbican allows updating certs/containers then versioning is
a must.

Thanks,
Vivek


On 6/8/14, 11:48 PM, Samuel Bercovici samu...@radware.com wrote:

Hi,

I think that option 2 should be preferred at this stage.
I also think that certificate should be immutable, if you want a new
one, create a new one and update the listener to use it.
This removes any chance of mistakes, need for versioning etc.

-Sam.

-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Friday, June 06, 2014 10:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
Integration Ideas

Hey everyone,

Per our IRC discussion yesterday I'd like to continue the discussion on
how Barbican and Neutron LBaaS will interact. There are currently two
ideas in play and both will work. If you have another idea please free
to add it so that we may evaluate all the options relative to each other.
Here are the two current ideas:

1. Create an eventing system for Barbican that Neutron LBaaS (and other
services) consumes to identify when to update/delete updated secrets
from Barbican. For those that aren't up to date with the Neutron LBaaS
API Revision, the project/tenant/user provides a secret (container?) id
when enabling SSL/TLS functionality.

* Example: If a user makes a change to a secret/container in Barbican
then Neutron LBaaS will see an event and take the appropriate action.

PROS:
 - Barbican is going to create an eventing system regardless so it will
be supported.
 - Decisions are made on behalf of the user which lessens the amount of
calls the user has to make.

CONS:
 - An eventing framework can become complex especially since we need to
ensure delivery of an event.
 - Implementing an eventing system will take more time than option #2ŠI
think.

2. Push orchestration decisions to API users. This idea comes with two
assumptions. The first assumption is that most providers' customers use
the cloud via a GUI, which in turn can handle any orchestration
decisions that need to be made. The second assumption is that power API
users are savvy and can handle their decisions as well. Using this
method requires services, such as LBaaS, to register in the form of
metadata to a barbican container.

* Example: If a user makes a change to a secret the GUI can see which
services are registered and opt to warn the user of consequences. Power
users can look 

[openstack-dev] [barbican] Meeting Monday June 2nd at 20:00 UTC

[Douglas Mendizabal]

Hi Everyone,

The Barbican team is hosting our weekly meeting today, Monday June 2nd, at
20:00 UTC in #openstack-meeting-alt

Meeting agenda is available here
https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed
to add agenda items.

You can check this link
http://time.is/0800PM_2_Jun_2014_in_UTC/CDT/EDT/PDT?Barbican_Weekly_Meeting
if you need to figure out what 20:00 UTC means in your time.

-Douglas Mendizábal





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

Re: [openstack-dev] [barbican] any barbican devs at summit?

[Douglas Mendizabal]

Hi Michael,

There’s quite a few Barbican devs here at the summit.  We’ll be hanging out
at the Barbican table in room B204 tomorrow if you want to drop in and chat.
You can also ping us on #openstack-barbican on freenode.

- Douglas Mendizábal
IRC: redrobot

From:  Michael Dorman mdor...@godaddy.com
Reply-To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:  Wednesday, May 14, 2014 at 8:54 PM
To:  openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org
Subject:  [openstack-dev] [barbican] any barbican devs at summit?

Would be interested in syncing up to hear about your experiences with this.
Anybody at the summit this week that’d be willing to chat for a few minutes?

Email works to reach out to me, or I’m on IRC (mdorman) sporadically this
week.

Thanks,
Mike





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

[openstack-dev] [barbican] Meeting Monday April 28th at 20:00 UTC

[Douglas Mendizabal]

Hi Everyone,

The Barbican team is hosting our weekly meeting today, Monday April 28, at
20:00 UTC  in #openstack-meeting-alt

Meeting agenda is avaialbe here
https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed
to add agenda items

You can check this link
http://time.is/0800PM_28_Apr_2014_in_UTC/CDT/EDT/PDT?Barbican_Weekly_Meeting
to help figure out what 20:00 UTC means in your local time.

-Douglas Mendizábal






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

[openstack-dev] [barbican] Meeting Monday April 21st at 20:00 UTC

[Douglas Mendizabal]

Hi Everyone,

The Barbican team is hosting our weekly meeting today, Monday April 21, at
20:00 UTC  in #openstack-meeting-alt

Meeting agenda is avaialbe here
https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed
to add agenda items

You can check this link
http://time.is/0800PM_21_Apr_2014_in_UTC/CDT/EDT/PDT?Barbican_Weekly_Meeting
if you need to figure out what 20:00 UTC means in your time.

-Douglas Mendizábal





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

[openstack-dev] [barbican] Barbican 2014.1 (Icehouse) is released

[Douglas Mendizabal]

Hi everybody!

It is my pleasure to announce the final release of Barbican for Icehouse
2014.1

Information on the milestone and its associated tar ball are available at:
https://launchpad.net/barbican/icehouse/icehouse

Many thanks to all the contributors who made this first incubated milestone
possible!

- Douglas Mendizábal




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

Re: [openstack-dev] [barbican] Barbican 2014.1 (Icehouse) is released

[Douglas Mendizabal]

Hi Eugene,

Currently, all of our documentation is in GitHub, which can be found at:
https://github.com/cloudkeep/barbican/wiki

We’re working on moving the docs to docbook format, so stay tuned for
updated docs in the future.

Regards,
Douglas Mendizábal

From:  Eugene Nikanorov enikano...@mirantis.com
Reply-To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:  Wednesday, April 16, 2014 at 4:51 PM
To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject:  Re: [openstack-dev] [barbican] Barbican 2014.1 (Icehouse) is
released

Hi Douglas,

could you please point to the project docs?

Thanks,
Eugene.



On Thu, Apr 17, 2014 at 1:48 AM, Douglas Mendizabal
douglas.mendiza...@rackspace.com wrote:
 Hi everybody!
 
 It is my pleasure to announce the final release of Barbican for Icehouse
 2014.1
 
 Information on the milestone and its associated tar ball are available at:
 https://launchpad.net/barbican/icehouse/icehouse
 
 Many thanks to all the contributors who made this first incubated milestone
 possible!
 
 - Douglas Mendizábal
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 





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

[openstack-dev] [barbican] Meeting Monday April 7th at 20:00 UTC

[Douglas Mendizabal]

Hi Everyone,

The Barbican team is hosting our weekly meeting today, Monday April 7, at
20:00 UTC  in #openstack-meeting-alt

Meeting agenda is avaialbe here
https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed
to add agenda items

You can check this link
http://time.is/0800PM_7_Apr_2014_in_UTC/CDT/EDT/PDT?Barbican_Weekly_Meeting
if you need to figure out what 20:00 UTC means in your time.

-Douglas Mendizabal




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

[openstack-dev] [barbican] Meeting Monday March 31st at 20:00 UTC

[Douglas Mendizabal]

Hi Everyone,

The Barbican team is hosting our weekly meeting today, Monday March 24, at
20:00 UTC  in #openstack-meeting-alt

Meeting agenda is avaialbe here
https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed
to add agenda items

You can check this link
http://time.is/0800PM_31_Mar_2014_in_UTC/CDT/EDT/PDT?Barbican_Weekly_Meeting
if you need to figure out what 20:00 UTC means in your time.

-Douglas Mendizabal




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

Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone

[Douglas Mendizabal]

Yes, this is exactly the use case we’re trying to address with Barbican. I
think this is something that definitely belongs in Barbican, especially
now that we are an incubated project.  We’d love to help out with any
integration questions you may have.

-Doug Mendizabal


On 3/25/14, 12:49 PM, Jay Pipes jaypi...@gmail.com wrote:

On Tue, 2014-03-25 at 17:39 +, Miller, Mark M (EB SW Cloud - RD -
Corvallis) wrote:
 Why not use Barbican? It stores credentials after encrypting them.

No reason not to add a Barbican driver as well.

Best,
-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [barbican] Meeting Monday March 24th at 20:00 UTC

[Douglas Mendizabal]

Hi Everyone,

The Barbican team is hosting our weekly meeting today, Monday March 24, at
20:00 UTC  in #openstack-meeting-alt

Meeting agenda is avaialbe here
https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed
to add agenda items

You can check this link
http://time.is/0800PM_24_Mar_2014_in_UTC/CDT/EDT/PDT?Barbican_Weekly_Meeting
if you need to figure out what 20:00 UTC means in your time.

-Douglas Mendizabal




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

Re: [Openstack] [Barbican] Key Recovery / Availability

[Douglas Mendizabal]

Our plan for deployment is exactly as Clark described:


* Several API nodes behind a load balancer
* PostgreSQL master/slave replication
* HSMs in HA paired mode
* Several Worker nodes

I’m also curios as to why this would be considered “clunky”?

-Doug

On 3/19/14, 1:21 PM, Clint Byrum cl...@fewbar.com wrote:

Excerpts from Clark, Robert Graham's message of 2014-03-19 07:41:35 -0700:
 Has there been much discussion on how to ensure that keys are
 recoverable in the event that Barbican has some sort of horrific
 failure? 
 
 I suppose a HA frontend, Redundant Keystore Databases and HA paired HSMs
 would be the most obvious non-code-writing path but this feels pretty
 clunky, I was wondering if it had been discussed yet? Possibly it should
 be something for a design session?
 

Sorry, what is clunky about backing up your data?

___
Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Barbican] HTTPS Connection Question

[Douglas Mendizabal]

Arvind,

I think you are confused about HTTPS support.

 Barbican does not support SSL , I have added BP for the same.
This is a false statement.  Barbican does not need to support SSL.  It’s up
to the container (aka the Web Server) being used to provide SSL for the
application, just as you’ve shown in the wiki entry to set up Nginx with
SSL.  There is nothing that we can do to “add SSL to Barbican”, so I’m not
sure what your blueprint is trying to accomplish.

Thanks,
-Doug

From:  Tiwari, Arvind arvind.tiw...@hp.com
Date:  Tuesday, March 4, 2014 at 7:08 PM
To:  Miller, Mark M (EB SW Cloud - RD - Corvallis)
mark.m.mil...@hp.com, Douglas Mendizabal
douglas.mendiza...@rackspace.com, Ferreira, Rafael r...@io.com, Remo
Mattei r...@italy1.com, Wyllys Ingersoll wyllys.ingers...@evault.com,
openstack@lists.openstack.org openstack@lists.openstack.org
Subject:  RE: [Openstack] [Barbican] HTTPS Connection Question

Hi Mark,
 
Barbican does not support SSL , I have added BP for the same.
https://blueprints.launchpad.net/barbican/+spec/transport-layer-security-is-
needed-in-barbican
 
I have added this page which uses NginX (I like better than APache) to
provide SSL support
https://github.com/cloudkeep/barbican/wiki/Deploy-OpenStack-Barbican-with-Ng
inx-web-server
 
Hope this will help.
 
Thanks,
Arvind
 
 

From: Miller, Mark M (EB SW Cloud - RD - Corvallis)
Sent: Tuesday, March 04, 2014 4:34 PM
To: Douglas Mendizabal; Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll;
openstack@lists.openstack.org
Subject: Re: [Openstack] [Barbican] HTTPS Connection Question
 
Hello Doug,
 
Thank you for the information. I will keep you informed if we decide to use
Apache2 as a front end.
 
Regards,
 
Mark
 

From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.com]
Sent: Tuesday, March 04, 2014 2:47 PM
To: Miller, Mark M (EB SW Cloud - RD - Corvallis); Ferreira, Rafael; Remo
Mattei; Wyllys Ingersoll; openstack@lists.openstack.org
Subject: Re: [Openstack] [Barbican] HTTPS Connection Question
 

Hi Mark,

 

I hope I can answer your questions:

 

1. HTTP support should be provided by the web server used to host barbican,
not by barbican itself.  The files where you noticed the “protocol = http”
settings are uwsgi configuration files the Barbican team uses to run
Barbican using uwsgi during development.  The settings are just default
development settings, and should be tuned to your particular situation.  You
can find more information about uwsgi config options on their official
documentation. [1]  In particular, you may be interested in enabling HTTPS
support documentation. [2]

 

2. As I mentioned above, the dev team uses uwsgi to run Barbican, however
there are no dependencies on uwsgi built into barbican.  This means that, in
theory, you should be able to run Barbican using Apache + mod_uwsgi, or
Nginx + gunicorn, or any other web server capable of hosting a WSGI app.
That said, we have not actually built environments with alternative web
servers, so we don’t currently have any documentation on how to set that up.
If you decide to deploy Barbican using Apache, we’d love to hear about your
experience and help out in any way we can (join us at #openstack-barbican on
Freenode).  I would encourage you to contribute to our documentation wiki if
you are successful.

 

Regards,

-Doug Mendizabal

 

[1] http://uwsgi-docs.readthedocs.org/en/latest/Options.html

[2] 
http://uwsgi-docs.readthedocs.org/en/latest/HTTPS.html?highlight=ssl#https-s
upport-from-1-3

 

 

From: Miller, Mark M (EB SW Cloud - RD - Corvallis)
mark.m.mil...@hp.com
Date: Tuesday, March 4, 2014 at 12:44 PM
To: Ferreira, Rafael r...@io.com, Remo Mattei r...@italy1.com, Wyllys
Ingersoll wyllys.ingers...@evault.com, openstack@lists.openstack.org
openstack@lists.openstack.org
Subject: Re: [Openstack] [Barbican] HTTPS Connection Question

 

Hello,
 
I’ve been digging and digging and I have not been able to locate the
following information:
 
1. Does Barbican provide support for HTTPS connections to it? I noticed
“protocol=http” in several .ini files and a .conf file, but no information
on how to configure Barbican to use it.

2. The quickstart wiki shows how to install Barbican behind the uwsgi
server. Is it possible to install Barbican behind Apache2? Is there any
documentation or example configuration guides?

 
Thanks,
 
Mark 
 
 




smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] Proposal to move from Freenode to OFTC

[Douglas Mendizabal]

I agree with Stefano.  Migrating the entire community to a new service
would be incredibly painful.  It seems the pain of moving is not justified
if we don’t know for a fact that OFTC would be more resilient to DDoS
attacks.


-1 to the switch as well.

-Doug Mendizabal


On 3/4/14, 2:48 PM, Stefano Maffulli stef...@openstack.org wrote:

-1 to the switch from me.

this question from Sean is of fundamental value:

On 03/03/2014 03:19 PM, Sean Dague wrote:
 #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.

until we can say that *fundamentally* OFTC is not going to suffer
disruptions in the future I wouldn't even remotely consider a painful
switch like this one.

/stef

-- 
Ask and answer questions on https://ask.openstack.org

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [Openstack] [Barbican] HTTPS Connection Question

[Douglas Mendizabal]

Hi Mark,

I hope I can answer your questions:

1. HTTP support should be provided by the web server used to host barbican,
not by barbican itself.  The files where you noticed the “protocol = http”
settings are uwsgi configuration files the Barbican team uses to run
Barbican using uwsgi during development.  The settings are just default
development settings, and should be tuned to your particular situation.  You
can find more information about uwsgi config options on their official
documentation. [1]  In particular, you may be interested in enabling HTTPS
support documentation. [2]

2. As I mentioned above, the dev team uses uwsgi to run Barbican, however
there are no dependencies on uwsgi built into barbican.  This means that, in
theory, you should be able to run Barbican using Apache + mod_uwsgi, or
Nginx + gunicorn, or any other web server capable of hosting a WSGI app.
That said, we have not actually built environments with alternative web
servers, so we don’t currently have any documentation on how to set that up.
If you decide to deploy Barbican using Apache, we’d love to hear about your
experience and help out in any way we can (join us at #openstack-barbican on
Freenode).  I would encourage you to contribute to our documentation wiki if
you are successful.

Regards,
-Doug Mendizabal

[1] http://uwsgi-docs.readthedocs.org/en/latest/Options.html
[2] 
http://uwsgi-docs.readthedocs.org/en/latest/HTTPS.html?highlight=ssl#https-s
upport-from-1-3


From:  Miller, Mark M   (EB SW Cloud - RD - Corvallis)
mark.m.mil...@hp.com
Date:  Tuesday, March 4, 2014 at 12:44 PM
To:  Ferreira, Rafael r...@io.com, Remo Mattei r...@italy1.com, Wyllys
Ingersoll wyllys.ingers...@evault.com, openstack@lists.openstack.org
openstack@lists.openstack.org
Subject:  Re: [Openstack] [Barbican] HTTPS Connection Question

Hello,
 
I’ve been digging and digging and I have not been able to locate the
following information:
 
1.  Does Barbican provide support for HTTPS connections to it? I noticed
“protocol=http” in several .ini files and a .conf file, but no information
on how to configure Barbican to use it.

2.  The quickstart wiki shows how to install Barbican behind the uwsgi
server. Is it possible to install Barbican behind Apache2? Is there any
documentation or example configuration guides?

 
Thanks,
 
Mark 
 
 




smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] a common client library

[Douglas Mendizabal]

+1 to a stand alone library for this.

 1) We would have to maintain rationale versioning and backwards compatibility
of this library. If we start library from scratch we'll have to add/change lots
of stuff before we'll reach some stability period.

I don’t think this is a hard problem to solve.  I think something like
semantic versioning fits the bill, and allows for backwards-incompatible
changes.  

 2)Another option would be to follow waterfall process and create a solid
library interface before including it to all client projects. However such
approach this period can take unknown amount of time and can be easily failed
during integration stage cause requirements change or some other reason.

Again, I think semver could address this.  Iterate over 0.x.x series, and
projects that don’t want to deal with constantly-changing code wouldn’t need
to jump on board until a 1.0.0 release.

-Doug M.

From:  Alexei Kornienko alexei.kornie...@gmail.com
Reply-To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:  Thursday, January 16, 2014 at 1:03 PM
To:  openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org
Subject:  Re: [openstack-dev] a common client library

Hello Joe,

 continuous refactoring and syncing across 22+ repositories sounds like a
 nightmare, one that I would like to avoid.
You are right this is not easy.

However I have several reasons to do that:
The hardest part is to bring basic stuff in sync across all projects (That's
what we are doing now). Later we'll work directly with oslo lib and just
sync changes from it.

We could introduce a standalone library to avoid the need to sync oslo code
across all projects but it brings additional problems:

1) We would have to maintain rationale versioning and backwards
compatibility of this library. If we start library from scratch we'll have
to add/change lots of stuff before we'll reach some stability period.

2)Another option would be to follow waterfall process and create a solid
library interface before including it to all client projects. However such
approach this period can take unknown amount of time and can be easily
failed during integration stage cause requirements change or some other
reason.

Please let me know what you think.

Best Regards,
Alexei

On 01/16/2014 08:16 PM, Joe Gordon wrote:
 
 
 
 On Thu, Jan 16, 2014 at 12:07 PM, Alexei Kornienko
 alexei.kornie...@gmail.com wrote:
 On 01/16/2014 06:15 PM, Jesse Noller wrote:
 
 On Jan 16, 2014, at 9:54 AM, Alexei Kornienko alexei.kornie...@gmail.com
 wrote:
 
 On 01/16/2014 05:25 PM, Jesse Noller wrote:
 
 On Jan 16, 2014, at 9:07 AM, Joe Gordon joe.gord...@gmail.com wrote:
 
 
 
 
 On Thu, Jan 16, 2014 at 9:45 AM, Jesse Noller
 jesse.nol...@rackspace.com wrote:
 
 On Jan 16, 2014, at 5:53 AM, Chmouel Boudjnah chmo...@enovance.com
 wrote:
 
 
 On Thu, Jan 16, 2014 at 12:38 PM, Chris Jones c...@tenshu.net wrote:
 Once a common library is in place, is there any intention to (or
 resistance against) collapsing the clients into a single project or even
 a single command (a la busybox)?
 
 
 that's what openstackclient is here for
 https://github.com/openstack/python-openstackclient
 
 After speaking with people working on OSC and looking at the code base
 in depth; I don’t think this addresses what Chris is implying: OSC wraps
 the individual CLIs built by each project today, instead of the inverse:
 a common backend that the individual CLIs can wrap - the latter is an
 important distinction as currently, building a single binary install of
 OSC for say, Windows is difficult given the dependency tree incurred by
 each of the wrapped CLIs, difference in dependencies, structure, etc.
 
 Also, wrapping a series of inconsistent back end Client classes /
 functions / methods means that the layer that presents a consistent user
 interface (OSC) to the user is made more complex juggling
 names/renames/commands/etc.
 
 In the inverted case of what we have today (single backend); as a
 developer of user interfaces (CLIs, Applications, Web apps (horizon))
 you would be able to:
 
 from openstack.common.api import Auth
 from openstack.common.api import Compute
 from openstack.common.util import cli_tools
 
 my_cli = cli_tools.build(…)
 
 def my_command(cli):
 compute = Compute(Auth(cli.tentant…, connect=True))
 compute.list_flavors()
 
 This would mean that *even if the individual clients needed or wanted to
 keep their specific CLIs, they would be able to use a not “least common
 denominator” back end (each service can have a rich
 common.api.compute.py http://common.api.compute.py/  or
 api.compute/client.py and extend where needed. However tools like
 horizon / openstackclient can choose not to leverage the “power
 user/operator/admin” components and present a simplified user interface.
 
 I’m working on a wiki page + blueprint to brainstorm how we could
 accomplish this based off of what work is in flight today (see doug’s
 linked 

Re: [openstack-dev] [openstack-tc] Incubation Request for Barbican

[Douglas Mendizabal]

I agree that this is concerning. And that what's concerning isn't so
much that the project did something different, but rather that choice
was apparently made because the project thought it was perfectly fine
for them to ignore what other OpenStack projects do and go off and do
its own thing.

We can't make this growth in the number of OpenStack projects work if
each project goes off randomly and does its own thing without any
concern for the difficulties that creates.

Mark.

Hi Mark,

You may have missed it, but barbican has added a blueprint to change our
queue to use oslo.messaging [1]

I just wanted to clarify that we didn’t choose Celery because we thought
that “it was perfectly fine to ignore what other OpenStack projects do”.
Incubation has been one of our goals since the project began.  If you’ve
taken the time to look at our code, you’ve seen that we have been using
oslo.config this whole time.  We chose Celery because it was

a) Properly packaged like any other python library, so we could just
pip-install it.
b) Well documented
c) Well tested in production environments

At the time none of those were true for oslo.messaging.  In fact,
oslo.messgaging still cannot be pip-installed as of today.  Obviously, had
we know that using oslo.messaging is hard requirement in advance, we would
have chosen it despite its poor distribution story.

- Doug Mendizabal

[1] 
https://blueprints.launchpad.net/barbican/+spec/queue-use-oslo-messaging

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev