20:00:49 <chellygel> #startmeeting barbican
20:00:49 <openstack> Meeting started Mon Jul 20 20:00:49 2015 UTC and is due to finish in 60 minutes.  The chair is chellygel. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:54 <openstack> The meeting name has been set to 'barbican'
20:00:55 <chellygel> #topic Roll Call
20:01:00 <alee> o/
20:01:01 <hockeynut> o/
20:01:02 <redrobot> o/
20:01:02 <rellerreller> o/
20:01:04 <kfarr> o/
20:01:07 <mmdurrant> o /
20:01:07 <dave-mccowan> o/
20:01:16 <silos> o/
20:01:21 <jkf> o/
20:01:38 <chellygel> \(*❛‿❛)/˚°◦
20:01:38 <woodster_> o/
20:01:59 <elmiko> o/
20:02:03 <chellygel> redrobot is at a conference today, however i'll be running the meeting while he attends via phone!
20:02:14 <elmiko> i really need to get more creative my wave ascii
20:02:22 <chellygel> As redrobot would say, "wow! looks like a lot of barbicaneers here today!"
20:02:38 <chellygel> #topic Action Items from last meeting
20:02:39 <redrobot> chellygel hehe
20:02:48 <chellygel> does anyone have any action items from last meeting that they need to discuss with the class?
20:02:55 <rellerreller> chellygel what charater is the lips on your smiley face? I cannot find it.
20:03:24 <chellygel> i honestly steal them from japaneseemoticons.net :) rellerreller so ahlf the time i don't know what im copy-pasta-ing
20:03:43 <elmiko> ah-ha, so the secret is out ;)
20:03:52 <chellygel> okay, no action items from last meeting so we will move forward!
20:04:00 <chellygel> #topic Magnum integration
20:04:09 <chellygel> I'm not sure who wishes to discuss this, please feel free to speak up :)
20:04:35 <redrobot> not sure who added it this week
20:04:44 <redrobot> last week I added it to the agenda
20:04:51 <elmiko> i'm guessing this is to create a barbican container for magnum?
20:05:02 <dave-mccowan> i added it, but i nominate alee for the update.  some folks from the Magnum team have been trying to get Barbican to work and have run into various issues.
20:05:22 <dave-mccowan> unfortunately, they are in APAC timezime, so it's been tough syncing with them.
20:05:38 <redrobot> Yeah, my understanding is that out of the box they were unable to issue new x.509 certificates
20:05:51 <elmiko> interesting
20:05:56 <redrobot> I promised to look into it, and then was swamped with work
20:06:02 <redrobot> so they were understandably upset
20:06:10 <redrobot> and asked other folks for guidance
20:06:13 <elmiko> does issuing x.509 involve some sort of kernel calls or something?
20:06:22 <redrobot> so I think alee is looking into this
20:06:37 <redrobot> although I have some free-ish time, seeing how I'm at a conference all week.
20:07:03 <redrobot> elmiko nope, should be doable with openssl
20:07:18 <redrobot> which means some combination of pyca/cryptography and/or pyopenssl
20:07:31 <elmiko> huh, curious then. usually i run into issues in the containers when i try to run privileged type commands
20:07:56 <alee> redrobot, elmiko I'm trying to co-ordinate a debugging session with them
20:08:10 <elmiko> alee: cool, good luck to you sir =)
20:08:22 <alee> they are in APAC so that means a late  night session for me -- probably on Tuesday night
20:08:37 <redrobot> alee let me know when you schedule it, and I'll join as well.
20:08:47 <woodster_> alee: maybe you would work from Australia?
20:08:55 <alee> but they are unable to get certs working with the snake oil plugin ..
20:09:00 <alee> woodster_, tempting ..
20:09:01 <woodster_> alee: would --> could
20:09:30 <chellygel> so are there any other action items we need for this magnum discussion?
20:09:32 <redrobot> alee I'll be looking into the snakeoil issue this week.
20:09:34 <alee> the idea will be to try and get it working with snake oil first, and then figure out whats going on with their dogtag install
20:09:54 <alee> redrobot, I proposed 9:30 pm EST tommorow night
20:10:20 <alee> to see what they are doing --
20:10:25 <alee> there is this spec ..
20:10:37 <alee> https://review.openstack.org/194905
20:11:01 <alee> which I commented on -- please feel free to comment too.
20:11:19 <alee> they really want to get this working in liberty
20:13:01 <chellygel> anything further to discuss on this topic guys? alee  redrobot ?
20:13:14 <redrobot> chellygel I think we can move on
20:13:17 <alee> chellygel, nothing till next week
20:13:30 <chellygel> alright, moving on
20:13:36 <chellygel> #topic Resource Quotas
20:13:42 <chellygel> posted beneath this topic is:
20:13:48 <chellygel> Design Discussion
20:13:54 <chellygel> #link https://review.openstack.org/203678
20:14:53 <chellygel> someone wanted to discuss this today?
20:15:03 <dave-mccowan> i've been working on the resource quotas blueprint.  https://review.openstack.org/198764 is my first commit for config, controller, and validator.  i'm hoping this can merge soon.
20:15:35 <dave-mccowan> i'm currently working on the second patch set which will implement the repository code.
20:16:08 <dave-mccowan> as i've been coding, i've run into some things in the spec that are either wrong, inconsistent, or vague.
20:16:38 <dave-mccowan> i've called them out in the the review that chellygel linked to.  i'm looking for discussion there... or we can have it here, or schedule a hang out.
20:17:16 <dave-mccowan> i'm hoping to sort out some of those questions ASAP, so i'll code it right the first time.
20:18:06 * redrobot makes note to look at blueprint
20:18:10 <rellerreller> dave-mccowan I added some comments.
20:18:33 <rellerreller> elmiko there was a question on PUT vs PATCH that you might be able to help with.
20:18:44 <elmiko> cool
20:18:53 <elmiko> don't use PATCH, simple =)
20:19:21 <rellerreller> Alright, that was simple enough :)
20:19:23 <woodster_> elmiko: what he said
20:19:35 <dave-mccowan> shall we take the action item for interested parties to review and comment early this week?  i'd like to finish coding the repository code by the end of the week.
20:19:45 <rellerreller> We might need to clear up the language on the section then.
20:19:54 <elmiko> PATCH is difficult because you are supposed to send some sort of diff style patch, that will tell the server how to update the resource
20:20:12 <elmiko> there is an rfc about a json format for doing that type of update, let me dig it up
20:20:46 <woodster_> yeah, patch is not worth the complexity IMHO...much better to figure out how to use PUTs/POSTs on sub-resources
20:20:54 <dave-mccowan> there is no PATCH in the design. only PUT.  is that OK for both Set and Update?   (or does POST come in?)
20:21:49 <woodster_> dave-mccowan: I'll need to refresh on that spec
20:21:51 <elmiko> POST is for create when the URI returned is different than the one POST'ed to, where PUT is more appropriate when the URI is the same
20:22:00 <elmiko> and yea, i agree with woodster_
20:22:21 <dave-mccowan> With the current design PATCH would be near impossible... since not-specified means use-the-default.  so, there no way to know if not-specified means "don't change"  or  "use-the-default".
20:23:11 <dave-mccowan> elmiko excellent.  So PUT is perfect for this use case.  (and that's the way I coded it.) :-)
20:23:17 <elmiko> \o/
20:23:29 <elmiko> awesome, and i'll make sure to take a look at the spec this afternoon
20:23:46 <dave-mccowan> elmiko.. what's a good response for PUT?  200 OK, or 204 with some content about what was PUT?
20:24:09 <hockeynut> isn't 204 ok with no content?
20:24:16 <elmiko> yea 204 is no content
20:24:44 <elmiko> dave-mccowan: it depends, is this a synchronous or asynch operation?
20:24:50 <hockeynut> secret PUT returns 204 no content I believe, so we should be consistent
20:25:10 <dave-mccowan> elmiko.. what's a good response for PUT?  204 OK  or  200 with some content about what was PUT.  :-)      it just hits a database, so synchronous.
20:25:34 <elmiko> dave-mccowan: if its sync, i think 200 with the updated resource back
20:26:16 <elmiko> but if you don't want to return the content then 204 is fine
20:26:26 <elmiko> like, if its not needed back
20:26:52 <hockeynut> I like 204...the content was provided as input to the PUT so no need (IMHO) to return it
20:27:23 <dave-mccowan> i don't have a strong preference.  the spec contradicts itself.  it says 204, then gives an example with 200.   polling now is 1 to 1.  any other votes?
20:27:56 <hockeynut> my cats both vote for 204.  That makes it 3-1 :-)
20:28:13 <alee> elmiko, are all these REST guidelines being collated by the api wg being documented somewhere ?
20:28:39 <elmiko> alee: yea, we are working through the guidelines
20:29:16 <elmiko> dave-mccowan, hockeynut, if don't need the resource back then i htink 204 is acceptable
20:29:25 <alee> elmiko, so nothing available yet ?
20:29:36 <elmiko> alee: some, i'm searching for the ref
20:30:28 <chellygel> alright guys...
20:30:36 <chellygel> how are we doing here
20:31:12 <dave-mccowan> i'm happy to move on.  folks can look at the spec and add comments there.  thanks!
20:31:28 <chellygel> thanks dave-mccowan, we only have one topic left -- then review discussion... moving on
20:31:36 <chellygel> #topic Brief discussion regarding default policy settings and ability of secret creators to manage their secrets
20:31:42 <chellygel> #link https://bugs.launchpad.net/barbican/+bug/1475962
20:31:43 <openstack> Launchpad bug 1475962 in Barbican "Default policy does not allow secrets to be deleted by non-admin creator" [Undecided,New]
20:31:43 <uvirtbot> Launchpad bug 1475962 in barbican "Default policy does not allow secrets to be deleted by non-admin creator" [Undecided,New]
20:32:00 <chellygel> i believe mmdurrant had this one, is that correct?
20:32:05 <mmdurrant> That is correct
20:32:11 <elmiko> alee: http://specs.openstack.org/openstack/api-wg/index.html
20:32:25 <alee> elmiko, thanks
20:33:12 <mmdurrant> As a creator of secrets, what is the reasoning for not allowing a creator to delete secrets aside from protecting the user from shooting themselves in the foot?
20:33:57 <redrobot> mmdurrant It's not really to prevent footgun
20:34:17 <redrobot> Creator was added for some use cases where you want to allow someone in your project to add keys, but not delete them.
20:34:47 <redrobot> mmdurrant we have a total of 4 roles, and the permissions break down like this
20:34:49 <redrobot> #link https://github.com/cloudkeep/barbican/wiki/Role-Based-Access-Control#roles
20:35:13 <redrobot> mmdurrant if you want to give a user permission to both upload and delete secrets, then you should grant the "Admin" role, not the "Creator" role.
20:35:47 <redrobot> mmdurrant another way to think of this is
20:35:54 <mmdurrant> Does that not grant them admin over the entire project?
20:36:13 <redrobot> if you add delete to the "creator" role, then there is no difference between the "admin" and "creator" roles
20:36:20 <redrobot> mmdurrant not in the context of Barbican
20:36:45 <redrobot> mmdurrant we expect that live deployments will probably use namespaced roles
20:37:12 <mmdurrant> OK that would make more sense to me.  Thank you for addressing my concern.
20:37:41 <mmdurrant> that topic is ended as far as I’m concerned unless anyone has anything to add
20:38:21 <chellygel> that is the end of our list of topics... so the only thing left to do is...
20:38:45 <chellygel> #topic outstanding reviews needing attention
20:38:56 <chellygel> anything anyone wants to bring to everyone's attention for reviews or what have you
20:38:59 <chellygel> we have 20 minutes remaining.
20:39:11 <dave-mccowan> this one needs a +workflow: https://review.openstack.org/#/c/200696/
20:39:37 <silos> I have a pending spec. Don't need to talk about it now but looking for some review love: https://review.openstack.org/#/c/194298/
20:39:42 <hockeynut> dave-mccowan I can jump on yours
20:40:19 <woodster_> chellygel: I'll need to refresh on the TLS blueprints lingering out there :)
20:40:36 <Asha> Hi Chellygel ..I had one concern regarding HSM integration with Barbican..
20:40:39 <alee> dave-mccowan, I remember loking at this -- done
20:40:59 <dave-mccowan> hockeynut also https://review.openstack.org/#/c/198764/  (you reviewed patch set #2)  unless their is something really bad, I'd like to merge this one as is and address technical debt in next commit for this blueprint.
20:41:18 <hockeynut> ok
20:41:48 <chellygel> woodster_, what do you mean?
20:41:54 <chellygel> Asha, -- sure what are your concerns?
20:42:32 <woodster_> chellygel: I'm talking about the various TLS lifecycle blueprints out there for review. I need to get after some of the comments out there I think....
20:42:55 <chellygel> woodster_,  would you like a fancy action item tag for it?
20:43:05 <Asha> Thanks Cehllygel ... I am unable to run the script  python pkcs11-key-generation secript to generate MEK : root@HSM-Client bin]# python pkcs11-key-generation --library-path '/usr/lib/libCryptoki2_64.so' --passphrase 'test123' --slot-id 1 mkek --length 32 --label 'an_mkek' HSM returned response code: 0x13L CKR_ATTRIBUTE_VALUE_INVALID
20:43:26 <woodster_> chellygel: nah. More if folks have 'free time' to review those and add comments, that'd be appreciated
20:44:12 <woodster_> Asha: you are working with a safenet HSM?
20:44:23 <dave-mccowan> Asha are you part of the Magnum team?
20:44:26 <chellygel> Asha, i think that is a bug w/ the script not accepting the slot id or length as an integer -- the items you are passing through are defaulted though, and not necessary
20:44:36 <alee> +1 on more review comments on tls specs please
20:45:30 <Asha> [root@HSM-Client bin]# python pkcs11-key-generation --library-path '/usr/lib/libCryptoki2_64.so'  --passphrase 'test123' --slot-id  1 mkek --label 'an_mkek' Verified label ! MKEK successfully generated!
20:45:55 <Asha> Thanks chellyegel and for jvbranc as well for replying me to the email
20:46:01 <chellygel> woo hoo!
20:46:28 <woodster_> Asha: please add a bug if you can
20:46:38 <Asha> I  was able to generate .. MKEK
20:46:42 <Asha> sure woodster
20:47:22 <woodster_> Asha: we've only tested that with safenet btw...I don't think it would work with another pkcs11 hsm, but could be wrong
20:48:05 <Asha> yeah may be ..we are alos testing Safenet HSM
20:48:37 <Asha> Woodster : You mean to say that the length of MKEK may be diffent for other HSMs
20:49:47 <Asha> In that case dis would fail and hence the length of MKEK needs to be accepted as variable parameter
20:49:56 <woodster_> Asha: well, there are other vendor-specific constants in there I recall, but I've been out of the loop on that for a while now so may not be the case anymore
20:51:42 <Asha> Woodster : It means that the script would only run for Safenet based HSMs currently
20:54:02 <arunkant> looks like no one is talking so quick question.
20:54:26 <woodster_> Asha: I believe so
20:54:34 <arunkant> I am working on adding acl support in barbican client. I was on vacation for last 2 weeks and noticed in weekly meeting notes that there was a blueprint added for it.
20:54:38 <arunkant> So just want to find out if all details are captured in meeting notes + blueprint  or not?
20:55:15 <chellygel> hey arunkant i'm actually currently working on this -- are you actively working on this as well?
20:55:19 <Asha> Thanks Woodster
20:56:38 <arunkant> chellygel: yes, I have been working on it (as discussed in summit) and will have something soon for review. Just want to confirm if all the needed details are there or not?
20:57:14 <chellygel> im not sure specifically wh at details you might mean, but that blueprint and the meeting from last week should explain what the group expects for the items (add, delete, and get)
20:58:04 <chellygel> arunkant, lets talk about it in the openstack-barbican channel as the meeting is going to have to end here
20:58:11 <arunkant> okay. I was just confirming if there is anything else discussed.
20:58:19 <arunkant> okay
20:58:35 <chellygel> so, to wrap it up -- Please review TLS / SSL specs / blue prints in general! and other items listed in the meeting
20:58:38 <chellygel> thanks for attending guys
20:58:39 <chellygel> meeting over!
20:58:42 <chellygel> #endmeeting