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