20:01:12 <redrobot> #startmeeting barbican
20:01:13 <openstack> Meeting started Mon Feb 15 20:01:12 2016 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:16 <openstack> The meeting name has been set to 'barbican'
20:01:21 <redrobot> #topic Roll Call
20:01:25 <jmckind> o/
20:01:33 <arunkant> o/
20:01:38 <rellerreller> o/
20:01:43 <diazjf> o/
20:01:45 <silos> \o/
20:02:32 <redrobot> guess people are out for the US holiday?
20:02:37 <jhfeng> o/
20:02:41 <jmckind> guess so...
20:02:44 <redrobot> in any case, we got lots to talk about today, so let's get started!
20:02:50 <redrobot> #topic Action Items
20:02:57 <rellerreller> Snowing on east coast, so may be missing for that.
20:02:57 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2016/barbican.2016-02-08-20.01.html
20:03:07 <redrobot> #note redrobot sucks at action items
20:03:16 <redrobot> hehe
20:03:25 <diazjf> rellerreller, I was in NYC this weekend 5 degrees!!
20:03:45 <dave-mccowan> o/
20:04:02 <redrobot> Trying to get something organized for the SA/Austin Barbican guild...  I was hoping to be able to do something this week, but I think I won't be able to do it until next week.  I'll keep y'all posted diazjf and silos
20:04:25 <diazjf> redrobot, thanks! yeah next week is perfect as well.
20:04:27 <redrobot> diazjf silos did you have a preference of whole day/ afternoon + evening / evening only ?
20:04:27 <silos> redrobot: kk. no worries.
20:04:49 <diazjf> redrobot, we can do an all day event
20:05:27 <redrobot> diazjf ok, I'll keep that in mind for tomorrow when we'll be sorting out the details.
20:05:45 <redrobot> as far as the security bugs / designate, I haven't made much progress there
20:05:51 <edtubill> o/
20:05:52 <redrobot> and by not much, I mean none at all
20:05:57 <diazjf> redrobot, sounds good!
20:06:00 * redrobot drops head down in shame
20:06:09 <mp1> o /
20:06:27 <redrobot> ok, moving on to today's agenda
20:06:36 <redrobot> which, as usua, can be found here:
20:06:38 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican#Agenda
20:06:57 <redrobot> #topic Go over keystone middleware in Credential Factory
20:06:58 <redrobot> diazjf your topic
20:07:18 <diazjf> hey everyone, checkout https://review.openstack.org/#/c/273863/11/castellan/common/utils.py
20:07:22 <diazjf> rellerreller ^
20:08:07 <diazjf> I was wondering if services which use keystonemiddleware auth should be able to pass the _TokenData directly from the context
20:08:22 <redrobot> diazjf I'd guess no since it's marked as private api
20:08:23 <rellerreller> diazjf I did not understand that bottom comment.
20:08:45 <diazjf> rellerreller, example: In swift you can do "context = env.get('keystone.token_auth').user"
20:09:06 <diazjf> And that contains all the items needed to a keystone token
20:10:04 <diazjf> Is it ok to only have auth_token and project_id
20:10:07 <diazjf> as seen in the patch
20:10:47 <rellerreller> I'm ok with it.
20:11:28 <diazjf> rellerreller, ok cool, in swift there would need to be a switch in the config or something that lets them switch between using context or config file
20:11:40 <diazjf> but I guess thats upto swift
20:12:05 * redrobot needs to look into the patch before having an opinion
20:12:06 <diazjf> I was just thinking in the swift keymaster they would want a way to switch between both
20:13:07 <diazjf> I'll see if I can get janie, and john to take a look at it this week
20:13:22 <rellerreller> diazjf could swift not always use token auth type?
20:14:23 <diazjf> so they could use token auth type, but there needs to be a way of switching between current usesr(context for env) and service user(config) values.
20:14:52 <diazjf> I may be just over thinking this :/
20:15:08 <rellerreller> I understand. I don't think the credential factory can help much there.
20:15:46 <diazjf> rellerreller, yeah I was thinking of whether to have another type for auth_type for that or if it was up to swift
20:15:58 <diazjf> either way iteration 1 should just allow for service users
20:16:25 <rellerreller> If they were ok with username and password then could choose that type. That would override any context passed in.
20:16:45 <rellerreller> The performance might suffer, but I'm not sure.
20:17:34 <panatl> o/
20:17:51 <rellerreller> It seems that if Swift will have two contexts (one for user and one for service) then code for which one to use should go in Swift.
20:18:05 <redrobot> rellerreller +1
20:18:26 <diazjf> rellerreller, understood. thanks :)
20:19:16 <redrobot> ok, moving on
20:19:20 <redrobot> #topic pycryptodome
20:19:23 <redrobot> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086509.html
20:19:57 <redrobot> In case you missed it, it appears that there's a new crypto library in town called cryptodome
20:20:05 <redrobot> it appears that it aims to be a drop-in replacement for pycrypto
20:20:51 <redrobot> however, they're not doing a very good job with compatibility, so even though they use the same namespaces, Barbican will break if you install pycryptodome
20:21:07 <redrobot> doesn't seem to be an issue if you install pycrypto after installing pycryptodome
20:21:57 <redrobot> The thread is ongoing in the ML
20:22:17 <rellerreller> What are our dependencies on pycrypto? How much of the space does pyca/cryptography cover?
20:23:03 <redrobot> rellerreller last time we checked pyca/cryptography was missing a few features... that was a long time ago though, and I think pyca/cryptography should have everything we need by now.
20:23:08 <jhfeng> redrobot: saw wail, first time to hear pycryptodome also
20:23:17 <jhfeng> s/wail/email
20:23:38 <redrobot> my $0.02 is that we should move to pyca/cryptography ... mostly because pure-python crypto gives me the heebie jeebies
20:24:15 <rellerreller> It would also be nice to be dependent on one crypto library instead of two
20:24:23 <jhfeng> some RSA call used in pkcs11  plugin code. should be supported by cryptography also
20:24:27 <redrobot> rellerreller +1
20:24:40 <diazjf> + 1 to that
20:25:06 <redrobot> I'll try to see if I can get some time to work on the code changes to drop pycrypto
20:25:22 <redrobot> #agreed Barbican should drop pycrypto in favor of pyca/cryptography
20:25:38 <jhfeng> +1, it's time to verify to move to py/ca cryptography
20:25:50 <redrobot> that's all I wanted to talk about for this topic.  I'll follow up with my findings.
20:26:12 <redrobot> feel free to join in on the ML discussion as well
20:26:15 <redrobot> #topic Fernando Diaz for Core
20:26:38 <redrobot> Just a heads up for the core reviewers that I've nominated diazjf for the Core team.
20:26:45 <redrobot> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086581.html
20:26:57 <redrobot> Cores, please reply to the ML thread with your vote
20:27:48 <diazjf> whoop whoop thanks redrobot, and thanks everyone for all your help!!!
20:28:21 <redrobot> we'll revisit this next week to tally the votes
20:28:27 <redrobot> moving on
20:28:30 <redrobot> #topic Volunteer meeting chair for next week
20:28:56 <redrobot> I'll be out next Monday afternoon and need someone to chair this meeting
20:28:58 <redrobot> any volunteers?
20:29:29 <diazjf> redrobot, I can help out with that
20:29:35 <redrobot> diazjf awesome!  thanks.
20:29:50 <redrobot> #info diazjf will be meeting chair on Feb 22
20:30:11 <redrobot> ok, moving on
20:30:11 <diazjf> no worries
20:30:17 <redrobot> #topic Barbican client cliff bug
20:30:29 <redrobot> silos your topic
20:30:45 <silos> k So I looked into that cliff bug from the mid-cycle.
20:31:17 <silos> Turns our when the barbican client uses the —table format. Cliff will always try to encode the returned secret in utf-8.
20:31:21 <redrobot> #link https://bugs.launchpad.net/python-barbicanclient/+bug/1504646
20:31:21 <openstack> Launchpad bug 1504646 in python-barbicanclient "Get secret for symmetric secrets returns decode error" [Undecided,In progress] - Assigned to Christopher Solis (cnsolis)
20:31:23 <silos> redrobot: thanks.
20:32:29 <silos> This is problematic because some things returned from Barbican can't be encoded into utf-8. SO what I was gonna do is just throw an error and tell the client to use a different format like 'value', or 'json'.
20:32:57 <silos> Basically I was wondering if the community is okay with not being able to 'see' the gibberish returned when retrieving things like symmetric keys through the client.
20:33:04 <redrobot> silos so I don't think the user actually sets --table?
20:33:13 <redrobot> I feel like the CLI needs some serious TLC
20:33:16 <silos> redrobot: Its default by cliff.
20:33:35 <silos> redrobot: unless the user sets it as something else.
20:33:46 <redrobot> from a user perspective, I want to be able to retrieve the payload for a secret, and redirect the stdout to an environment variable or file
20:34:00 <rellerreller> I ran into the utf-8 issue while doing the content types work.
20:34:12 * rellerreller is having nightmares of content types
20:34:22 <redrobot> lol
20:34:29 <silos> haha
20:34:32 <redrobot> I still like the idea of content-types for v2 ;)
20:34:54 <silos> redrobot: I also think this topic kind of leans towards a v2 client.
20:35:13 <redrobot> silos I think the unified python-openstackclient could be our v2 CLI
20:35:31 <silos> redrobot: +1
20:35:40 <rellerreller> I also like the content types for v2.
20:36:19 <rellerreller> silos could you return the value as base64 string? My guess is that will break lots of stuff because not backwards compatible.
20:36:57 <redrobot> silos want to collaborate on what the unified CLI should do?  ...  I want to approach it from the POV of someone using the CLI to store/retrieve keys, without tying ourselves to REST workflows
20:37:15 <redrobot> rellerreller yeah... that definitely sound like a breaking change
20:37:17 <silos> rellerreller: Hmmm I haven't tried that. It's not that it can't be returned in its normal encoding. It's just that cliff will try to make it utf-8 when presenting it to the user.
20:37:20 <redrobot> I want to be able to do stuff like:
20:37:40 <silos> redrobot: Yea! I definitely want to see the client get some TLC.
20:37:45 <redrobot> openstack key-manager store < cat $PWD/my-secret-file
20:37:58 <redrobot> and
20:38:17 <redrobot> openstack key-manager payload https:///someurl > my-retrieved-secret
20:38:39 <redrobot> but I have no idea if cliff would even be able to do that..
20:38:57 <redrobot> #action silos and redrobot to collaborate on an etherpad for what the unified CLI should look like
20:39:15 <redrobot> silos as far as this bug is concerned... is it possible to default to just raw output when you're fetching the payload?
20:39:28 <redrobot> silos and leave the payload out of the secret table when showing the metadata?
20:40:14 <silos> redrobot: I'm not sure. But I can definitely look into it.
20:40:47 <silos> redrobot: It would make it a lot easier if the default was something like value.
20:42:06 <redrobot> silos cool, we can revisit the bug next week after you've had a chance to dig into it some more
20:42:21 <silos> redrobot: sounds good. Looks like we have a good roadmap for the client.
20:43:11 <silos> I think that's all from me. thanks!
20:43:14 <redrobot> ok, that's all we had on the agenda for today
20:43:19 <redrobot> #topic Open Discussion
20:43:29 <redrobot> any patches that are in need of review?
20:43:35 <redrobot> or other topics we haven't covered?
20:43:56 <jhfeng> redrobot yes https://review.openstack.org/#/c/279371/
20:44:12 <silos> pending castellan spec if anyone has some free time: https://review.openstack.org/#/c/246546/
20:44:21 <rellerreller> silos reviewing now
20:44:32 <silos> rellerreller: thanks!
20:44:40 <diazjf> I have a couple baby patches https://review.openstack.org/#/c/263000/ https://review.openstack.org/#/c/277202/
20:44:54 <jhfeng> redrobot another affected cmd by p11 perf patch
20:45:10 <redrobot> jhfeng ok, I'll take a look at it.
20:45:16 <edtubill> If some people can take a look at the database cleanup: https://review.openstack.org/#/c/269903/
20:45:55 <jhfeng> redrobot: thx, let me know if I need open a bug report also
20:47:13 <redrobot> any other topics/patches?  If not we can have 10 min of our day back
20:48:40 <redrobot> alrighty then, sounds like this is a wrap!
20:48:43 <redrobot> thanks everyone for coming
20:48:47 <redrobot> #endmeeting