20:00:47 #startmeeting barbican 20:00:47 Meeting started Mon Jul 28 20:00:47 2014 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:50 The meeting name has been set to 'barbican' 20:01:19 The agenda for todays meeting is available at: 20:01:21 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:01:24 #topic Roll Call 20:01:36 \o/ 20:01:37 _o/ 20:01:37 o/ 20:01:46 o/ 20:01:47 o/ 20:01:50 o/ 20:01:53 o/ 20:01:53 o/ 20:01:57 o/ 20:01:57 o/ 20:02:25 woohoo! lots of barbicaneers here today 20:02:34 ~o/ 20:03:08 o/ 20:03:18 alrighty then, let's get started 20:03:39 #topic CR: Add more types to Containers Order 20:03:49 #link https://review.openstack.org/#/c/87405/ 20:03:58 atiwari did you want to talk about this? 20:04:38 yes, it is waiting for review, just wanted to raise that 20:05:05 atiwari ok 20:05:19 +995 lines. Should be a fun review :) 20:05:26 there are more depended on this one. 20:05:27 yes 20:05:32 :) 20:05:33 is there a bp or spec? 20:06:04 hockeynu_, #link https://review.openstack.org/#/c/98174/ 20:06:18 awesome - thx! 20:06:53 and it looks like the BP just needs a +1 to Workflow. Hopefully we can get the BP merged today. 20:07:07 redrobot, there are more depending on this, so if we can make some progress on this, that will be awesome 20:07:19 redrobot, ok 20:08:03 everyone please try to get some eyes on both of those CRs so we can unblock atiwari and friends. 20:08:38 redrobot, this impl has backward compatibility on Orders resource. I will clean those duplicates in later CR 20:08:45 just for fyi.. 20:09:19 atiwari ok, sounds good. I'll try to get to the review today. Didn't get to do much reviewing over the weekend. 20:09:29 ok, moving on to the next topic 20:09:30 np 20:09:52 #topic Kilo Conference Presentation Proposals 20:10:00 Kilo = Paris? 20:10:18 Ya, I thought that was the next name 20:10:18 was this woodster__ or alee that added this? 20:10:25 I added this 20:10:26 Kilo = Japan 20:11:01 Icehouse was HK, Juno was Atlanta I thought??? 20:11:10 ^ +1 ^ 20:11:12 I think rellerreller is right. 20:11:22 + oo 20:11:25 woodster__, the next one after Paris is in Japan? 20:11:39 Anyways, I was wondering who all submitted proposals to the next conference. I was going to keep an eye out for them in case we get to vote again this time 20:11:42 alee rumor has it that the next one will be Tokyo... not official yet 20:11:56 rellerreller yes, actually, we've submitted a few 20:12:24 redrobot: did you actually do an abstract for the one we talked about on Friday? :P 20:12:33 We have submitted two: "Secure Key Management via Barbican's Plugin Architecture" and "Securing Data at Rest" 20:12:34 woodster__ submitted (or is about to submit) a proposal for a talk about the new Plugin Architecture 20:12:52 rellerreller, i submitted a hands-on barbican workshop with woodster__, hockeynu_ , and jvrbanac 20:13:08 +1 20:13:17 sounds like rellerreller and woodster__ are on the same page :) ... woodster__ were you going to ask rellerreller and alee about that submission? 20:13:41 Ya, I think our submissions are similar, if not the same 20:13:59 I sent an email to them a bit a ago about it...seeing if they'd like to co-present due to their strong hand in the design of it all 20:14:10 We can work together to get one in there. They should not be competing against each other. 20:14:13 rm_work nope... though I may submit one to talk about how to use the Client. 20:14:30 woodster__, must have missed that email -- maybe I was in transit - but sure :) 20:14:31 redrobot: hmm k, I'll try to get my bit sqeezed in on the neutron track 20:14:59 rm_work you didn't seem too enthused about it so I canned the idea. :-P 20:15:03 heh 20:15:26 +1 to unifying rellerreller and woodster__ talks 20:15:27 I am enthused about it, but it's only like 10 minutes so I just needed a tiny bite of someone else's block :P 20:16:37 I know jraim is submitting a few as well 20:16:50 Crypto, Python 3 and PyPy - A Path Forward for OpenStackCryptography and 20:16:50 the oslo.crypto Takeover 20:17:00 2) Key Wrapping in Barbican - A Path to Federation 20:17:10 3) Transparent Encryption Using Barbican 20:17:36 4) Cryptography in OpenStack: Uses and Opportunities 20:17:45 5) Cryptographic Performance in Python 20:17:55 4) +1 20:18:30 redrobot, I was thinking of submitting a presentation session on master key encryption management. 20:18:39 thoughts ? 20:19:03 master key encryption key 20:19:27 atiwari sounds interesting... would this cover HP's implementation of a Crypto plugin? 20:19:59 I am thinking for generic plugin approach to manage MKEK 20:20:57 Crypto plugin can choose a MKEK plugin if required 20:21:36 atiwari I see... that maybe an interesting talk. I'd go see it. :) 20:21:55 ok, I will submit it today 20:22:05 I would go as long as I had a barbican shirt/hat/beard 20:22:30 I'm trying to dig up a list of the other things we submitted 20:23:01 I know jvrbanac is talking about Stockade 20:23:16 :D 20:23:16 it's a Django-based password-sharing app that uses Barbican as a back end 20:23:38 and its awesome... 20:24:00 possibly doing a Barbican: where we're at and where we're going talk... I'll have to check with jraim about that one 20:25:27 rellerreller sound like enough talks? :) 20:26:14 Sounds awesome! 20:26:37 I hope we get several accepted. 20:28:20 we do too! Rackspace is sending anyone who gets a talk approved, so we're definitely wanting to see you guys in Paris. 20:28:39 redrobot: those all sound interesting. wish I could be there! 20:29:47 ok, that's all I have on the agenda for today 20:30:07 is there anything else we want to talk about while we're all here? 20:30:17 I have a question 20:30:26 kaitlin-farr go ahead 20:30:46 jvrbanac hockeynu_ and I were just discussing an issue that popped up with a patch I submitted today: https://review.openstack.org/#/c/101582/ 20:31:02 I added arg checks to the classes in secret_store 20:31:32 so I wanted to see if other people had opinions 20:31:49 because the arg checks sort of break some of the existing tests 20:32:01 the stack trace was here: http://logs.openstack.org/82/101582/3/check/gate-barbican-devstack-dsvm/db90e79/logs/screen-barbican.txt.gz 20:32:14 #topic Broken devstack tests due to arg checking 20:32:53 so I guess there's two issues: 20:33:34 1 - the server returned 500 code (jvrbanac and hockeynu_, was that unexpected behavior?) 20:33:44 yes - should never get 500 20:33:45 I think the issue is that secret store needs to be able to accommodate different secrets flows...one step secret stores, two step secret stores (neither of which require any meta data to be provided), and secret generates (which require most or all to be provided) 20:34:10 and 2 - should we keep arg checks and change the existing tests to not break or remove arg checks? 20:34:15 You'll get a 500 if (say) a ValueError is raised...that gets treated as a 500 20:34:50 The validators module is where we've been putting validation logic. 20:34:54 but controller should catch that and turn it into something reasonable (4xx) right? 20:35:30 raising a ValueError is a programmer logic problem...that should return a 500...essentially forcing the botched logic to be fixed 20:35:39 it is not a client data input error for example 20:36:23 validation should determine if, based on the flow involved if field-a is optional or required for example 20:36:32 yes, that is true 20:37:51 rellerreller do you have thoughts on the arg checks? 20:38:08 woodster__, I think though that there are some cases where ValueError is being raised for client errors .. and those need to be fixed to throw the correct exceptions. 20:38:10 so we have talked about adding a validate() method onto the secret store plugin at some point. So the supports() method would just say if that plugin could even consider the input data or not, and the validate() would do a 'deep dive' on that data to validate it. 20:38:33 alee: I'd agree with that 20:38:58 kaitlin-farr I'm not sure at the moment. This sounds different than what the issue was this morning. 20:39:22 I need to look at the error log 20:40:10 woodster__ the validation would occur at the time of the post request? 20:40:44 kaitlin-farr: yes 20:41:06 kaitlin-farr, just so I understand - why were the arg tests failing? was it because of invalid client data? 20:41:12 ...so synchronously, not waiting until the workers pick up the task 20:43:13 alee, the arg checks were checking if the input was valid, i.e. was defined in the list of valid constants and making sure the input wasn't none 20:43:25 alee its failing in the devstack gate - tempest test doing a simple create secret. The POST goes thru and eventually plugin gets called for store_secret and fails because None is passed in for the type parameter in SecretDTO c'tor and that fails the new test - thus raisingthe value error 20:44:08 yep, on secret POSTs/stores, those fields are optional 20:44:35 just optional meta data about a secret that the client could choose to provide if they wish 20:45:49 Soooo....should we consider adding a validate method to the plugin contract for Juno, or defer until Kilo? 20:45:59 If it's optional then which component determines the value for it? Should it be Barbican core or SecretStore? 20:46:05 hockeynu_, kaitlin-farr - and the type is populated from the original request? if that data is optional, then it sounds like we need to add some defaults 20:46:22 hockeynu_, kaitlin-farr - what you've uncovered is a bug. 20:46:43 alee I don't think defaults make sense in this case... some of that metadata is "sometimes-required" 20:46:52 I propose Barbican core provide default value. That way it is consistent across plugins. 20:47:09 its hardcoded None 20:47:11 either that or if there is no default, then the check must be changed 20:47:20 https://github.com/openstack/barbican/blob/master/barbican/plugin/resources.py line 60 20:47:29 ie, if I'm storing a password and POST it to /secrets, then I don't want that to default to "algortim": "AES" for example. 20:48:14 yep - that would bad...mmmkay 20:49:21 a client can store any data they wish as a secret...and don't have to tell Barbican what type it is either...so it's their little 'secret' (pun alert, sorry) 20:50:03 kaitlin-farr, hockeynu_ sounds to me like we need to rethink whether the arg checks are valid, given the many types of secrets that can be stored. and only check those args that are really required. 20:50:21 alee +1 20:50:25 Ok, that makes sense 20:50:41 yes - find the places and add a "validate_me" flag (default false)...set to true when we want validation... 20:50:55 like SecretDTO c'tor for example 20:51:21 If error is on line 60 then does not seem like arg error 20:51:55 It looks like Barbican core is always setting None for secret type. It needs to determine which type to set for it. 20:52:07 line 60 passes None as parm 1...then in the c'tor it checks the value of parm 1 (type) and throws ValueError since its None 20:52:09 According to https://github.com/openstack/barbican/blob/master/barbican/plugin/resources.py line 60 20:53:10 Now I see 20:53:10 well, the algorithm in line 60 is not required, as that info is saved (if provided) on the Secret entity in line 30. 20:54:07 now, if a plugin were to require a field to be set, that is where the plugin.validate() method could be useful. So the validate() method would be called as part of the up-front validation processing. 20:54:32 If you are going to store a secret then that information needs to be provided to the secretstore 20:54:33 yep! 20:54:53 So for secret store and the DTO, algorithm should probably be ignored for storage operations. It is only needed for generate operations. 20:55:09 rellerreller: why is this info needed to *store* a secret? 20:55:14 we're running dangerously close to the end of the meeting... this is a good discussion though... do we want to continue on #openstack-barbican? 20:55:47 works 4 me 20:55:48 The backend SecretStore may need this information. KMIP will need it. 20:55:49 rellerreller I think the metadata is only required to *generate* a secret 20:56:16 I definitely need it for storage. 20:56:21 rellerreller I see... hmm... 20:56:33 I need the crypto alg and crypto length 20:56:54 rellerreller, what happens if whats being stored is not a symmetric key? 20:57:11 I was about to say, does the K in KMIP imply that it's always a key? 20:57:11 alee, what do you mean? 20:57:13 rellerreller: if KMIP can only store specific types of secrets, then we really will need a validate() approach 20:57:51 rellerreller in Barbican, a Key is a Secret, but a Secret is not necessarily a Key 20:57:51 rellerreller: So I can't just store a db password in KMIP then? 20:58:08 KMIP can store any type of secret it just needs certain parameters. For keys it requires knowing the alg and length 20:58:17 rellerreller, we're talking about the store_secret() method, right? So, someone could choose to store a password for example. 20:58:22 we have 2 minutes until we get kicked out of this room 20:58:29 You can store a blob as a secret or a password 20:58:31 rellerreller: so what algo would I used to store a db password in KMIP? 20:58:38 let's continue this conversation on #openstack-barbican? ^_^ 20:58:43 will do... 20:58:44 ok 20:58:51 * jvrbanac moving to #openstack-barbican 20:59:48 thanks guys! Good meeting! First time we have to keep talking past the cutoff 20:59:54 #endmeeting