Friday, 2014-11-21

*** kgriffs|afk is now known as kgriffs00:03
*** SheenaG1 has joined #openstack-barbican00:04
*** stanzi has quit IRC00:07
*** zz_dimtruck is now known as dimtruck00:11
*** stanzi has joined #openstack-barbican00:12
*** kgriffs is now known as kgriffs|afk00:12
*** dimtruck is now known as zz_dimtruck00:16
*** ryanpetrello has quit IRC00:18
*** JeffF1 has quit IRC00:20
*** ryanpetrello has joined #openstack-barbican00:24
*** kebray has quit IRC00:26
*** david-lyle is now known as david-lyle_afk00:33
*** ryanpetrello_ has joined #openstack-barbican00:37
*** ryanpetrello has quit IRC00:38
*** ryanpetrello_ is now known as ryanpetrello00:38
*** stanzi has quit IRC00:40
*** ryanpetrello_ has joined #openstack-barbican00:44
*** bdpayne has quit IRC00:46
*** ryanpetrello has quit IRC00:47
*** ryanpetrello_ has quit IRC00:50
*** stanzi has joined #openstack-barbican01:29
*** stanzi has quit IRC01:38
*** kgriffs|afk is now known as kgriffs01:40
*** stanzi has joined #openstack-barbican01:44
*** SheenaG1 has quit IRC01:51
*** ryanpetrello has joined #openstack-barbican02:04
*** jorge_munoz has quit IRC02:09
*** kgriffs is now known as kgriffs|afk02:13
*** stanzi has quit IRC02:33
*** SheenaG1 has joined #openstack-barbican02:35
*** SheenaG1 has quit IRC02:52
*** ryanpetrello has quit IRC03:01
*** ryanpetrello has joined #openstack-barbican03:04
*** SheenaG1 has joined #openstack-barbican03:11
*** ryanpetrello has quit IRC03:16
*** ryanpetrello has joined #openstack-barbican03:17
*** ryanpetrello has quit IRC03:31
*** stanzi has joined #openstack-barbican03:43
*** stanzi has quit IRC03:48
*** stanzi has joined #openstack-barbican04:02
*** dave-mccowan has quit IRC04:02
*** stanzi has quit IRC04:08
*** kgriffs|afk is now known as kgriffs04:09
*** stanzi has joined #openstack-barbican04:15
*** kgriffs is now known as kgriffs|afk04:19
*** stanzi has quit IRC04:36
*** david-lyle_afk has quit IRC04:43
*** stanzi has joined #openstack-barbican04:51
*** ryanpetrello has joined #openstack-barbican04:54
*** stanzi has quit IRC05:47
*** bdpayne has joined #openstack-barbican06:56
*** bdpayne has quit IRC06:56
*** ryanpetrello has quit IRC07:05
*** jaosorior has joined #openstack-barbican07:58
*** woodster_ has quit IRC09:10
*** jaosorior has quit IRC10:43
*** dave-mccowan has joined #openstack-barbican12:46
*** woodster_ has joined #openstack-barbican13:01
*** rellerreller has joined #openstack-barbican13:18
*** jamielennox is now known as jamielennox|away13:20
*** SheenaG11 has joined #openstack-barbican13:20
*** SheenaG1 has quit IRC13:22
*** ryanpetrello has joined #openstack-barbican14:03
*** ryanpetrello_ has joined #openstack-barbican14:05
*** codekobe_ has quit IRC14:06
*** codekobe_ has joined #openstack-barbican14:07
*** ryanpetrello has quit IRC14:08
*** ryanpetrello_ is now known as ryanpetrello14:08
*** dave-mccowan has quit IRC14:12
*** insequent has quit IRC14:16
*** russell_h has quit IRC14:16
*** rm_work has quit IRC14:16
*** rm_work has joined #openstack-barbican14:17
*** rm_work has quit IRC14:17
*** rm_work has joined #openstack-barbican14:17
*** insequent has joined #openstack-barbican14:17
*** russell_h has joined #openstack-barbican14:17
*** paul_glass has joined #openstack-barbican14:24
openstackgerritThomas Dinkjian proposed openstack/barbican: Add functional tests for order  https://review.openstack.org/13615514:26
*** rellerreller has quit IRC14:42
*** rellerreller has joined #openstack-barbican14:42
*** stanzi has joined #openstack-barbican15:03
*** kgriffs|afk is now known as kgriffs15:03
*** kebray has joined #openstack-barbican15:05
*** kebray has quit IRC15:06
*** kebray has joined #openstack-barbican15:07
openstackgerritThomas Dinkjian proposed openstack/barbican: Add functional tests for order  https://review.openstack.org/13615515:12
*** kgriffs is now known as kgriffs|afk15:17
*** kebray has quit IRC15:27
*** ayoung is now known as ayoung-dentist15:28
*** ayoung-dentist has quit IRC15:28
*** kgriffs|afk is now known as kgriffs15:28
*** SheenaG11 has quit IRC15:30
*** JeffF has joined #openstack-barbican15:32
*** kebray has joined #openstack-barbican15:35
*** dave-mccowan has joined #openstack-barbican15:41
openstackgerritSteve Heyman proposed openstack/barbican-specs: Add spec to support running functional tests as different users  https://review.openstack.org/13572415:42
*** zz_dimtruck is now known as dimtruck15:49
*** woodster_ has quit IRC16:00
*** rellerreller has quit IRC16:00
*** SheenaG1 has joined #openstack-barbican16:01
*** SheenaG11 has joined #openstack-barbican16:04
*** SheenaG1 has quit IRC16:06
alee_rm_work, ping16:36
alee_redrobot, ping16:36
rm_workalee_: pong16:38
alee_rm_work, I have a question about barbican_client16:38
rm_workalee_: i might have an answer about barbican_client16:38
alee_rm_work, specifically the code that gets a secret16:39
rm_workok16:39
alee_rm_work, so in secrets.py , there is a function ..16:39
rm_workprobably, yes16:39
* rm_work is feeling salty this morning for some reason :P16:39
alee_:/16:39
alee_get() in SecretManager16:40
rm_workok16:40
alee_this ultimately calls ..16:40
alee_self._api._get()16:40
rm_workyes16:41
alee_which is defined in client.py16:41
rm_workyes16:41
rm_workthat sounds right16:41
alee_now -- as far as I can see -- we are setting Accept to "application/json"16:41
rm_workyes16:41
alee_but isn't that what we would set to get the secret metadata only?16:41
rm_work_get_raw is for payload16:42
rm_workyes16:42
alee_ah ..16:42
rm_workthat call doesn't get payload16:42
rm_workthe secret.payload attribute is a lazy-load that will call _get_raw() when you try to access it16:42
rm_worksee Secret.payload -> Secret._fetch_payload()16:43
alee_rm_work, ok cool - that makes more sense now :/16:45
rm_worksorry, this is what I'm like when I am in especially good humor :P16:45
alee_(and totally messes up my patch)16:45
*** paul_glass has quit IRC16:45
alee_:)16:45
rm_workyou have a patch?16:46
rm_workwhat mischief are you up to? :)16:46
alee_working on one for transport key support in client16:46
*** paul_glass has joined #openstack-barbican16:46
rm_workah, cool16:46
rm_workI was just asking about that yesterday16:46
rm_workout-of-channel16:47
alee_yup -- I should start sending out patches for review next week or the week after16:47
alee_of course now that I understand the code better, then patches might make more sense now.16:48
rm_workyou'd probably just have to pass whatever extra info you need into the get() function and store it in the Secret object, and let the _fetch_payload method utilize it if it's there16:48
rm_workdoing it from Containers will be fun too16:48
rm_work:P16:48
alee_rm_work, well its tricky --- you want to use a 2-step GET16:49
rm_workyeah but you can hide that in the _fetch_payload16:49
rm_workright?16:49
rm_workwait, what are the two steps?16:49
rm_workI thought you basically just passed a pub-key to the GET and it wrapped and returned16:49
rm_workmaybe I don't understand transport key fully16:49
alee_ok -- so when you do a GET you have to ..16:50
alee_1. send a GET for the secret metadata specifying that you want transport key wrapping16:50
alee_2. server responds with metadata and the transport key ref if available16:51
rm_workwoah, ok16:51
rm_workso the transport key is generated barbican-side?16:51
alee_3. you go and get the transport key (public key) if its available.16:51
alee_transport key is barbican side16:51
alee_this is not the pre-encryption on client side16:52
rm_workwait, is this for sending data TO barbican via transport key, or getting data FROM barbican via transport key?16:52
rm_workI think I was imagining getting existing secret data from Barbican with a transport key16:52
alee_rm_work, getting data FROM barbican16:52
rm_workhmm16:52
alee_rm_work, let me go through the steps ..16:52
rm_worksorry k16:53
alee_note that you have a secret in barbican you want to retrieve.  it has been stored by a secret store plugin that may or may not support transport key wrapping.16:53
rm_workk16:54
alee_so you first need to get the secret metadata -specifically asking for transport key ref16:54
alee_thats step 116:54
alee_server responds with tkey_ref if available.16:54
alee_step 2 : client gets the transport key -- if it has not gotten it already16:55
alee_(most likely it alredy has and its cached client side)16:55
alee_step 3: client generates a symmetric key -- wraps it with the transport key and sends it to the server with a GET request for the secret.16:56
*** woodster_ has joined #openstack-barbican16:56
alee_step 4: server unwraps the wrapped symmetric key, uses it to wrap the secret and returns the wrapped secret16:56
alee_step 5: client uses symmetric key to unwrap secret16:57
rm_workok so16:57
rm_workwhat I imagine is16:57
rm_workbarbican_client.secrets.get(secret_ref=my_secret_uuid, transport_key=True)16:58
rm_workerr16:58
rm_workmysecret = ^^16:58
rm_workdata = mysecret.payload16:58
redrobotrm_work +116:58
rm_workcool16:58
rm_workso yeah, that shouldn't be too bad16:58
rm_workthe client can handle all of that stuff internally16:59
rm_workthe initial metadata GET will include the transport key now, which Secret will store internall16:59
rm_work*y16:59
rm_workand then the _fetch_payload will just have to do a couple of calls in a row and some other generation stuff16:59
rm_workI didn't realize the transport-key stuff required symmetric keys17:00
rm_workI am still not sure WHY, but that's fine :P17:00
alee_just the way the encryption works ..17:01
alee_yeah - let me play a little bit with it and I'll put up a WIP CR17:01
alee_so you can see if I'm totally off base.17:02
rm_workI always thought you could just give the server your pub-key and it could encrypt with it and pass it back to you <_<17:02
rm_workwhat does the symmetric key stuff buy you?17:03
* rm_work is not a security expert17:03
rm_workredrobot: ?17:04
tiger_toesrm_work: anyone who proclaims should be treated with skepticism, the experts don't need to flash alleged bona fides17:04
rm_workheh, true17:05
reaperhulkin fact the experts shy away from ever saying anything definitive17:06
alee_rm_work, that requires the client to have a pub/priv key. Not all clients have that necessarily.17:06
redrobotrm_work it's using both asymmetric and symmetric encryption.  Client encrypts the secret with a symm key, then encrypts the symm key with the server's public key.17:06
rm_workO_o17:06
reaperhulkrm_work: transport keys require symmetric because asymmetric encryption is limited to the length of the  key (minus some padding)17:06
rm_workAH17:06
rm_workso to prevent the client from having to generate like a 16384 sized key17:07
rm_workgot it :P17:07
reaperhulkYup17:07
rm_workdid not realize that17:07
rm_workso messages signed with PGP/GPG need to be pretty small17:07
reaperhulkWith the symmetric wrap you end up with no real size limitations17:07
rm_workIE, I wouldn't sign a novel with my default pubkey17:08
reaperhulkGPG has symmetric options17:08
rm_workerr, ok17:08
rm_workI guess I mean standard RSA pub/priv17:08
rm_workwhich is how I use GPG 99% of the time17:08
rm_workanywho, that makes sense now, thanks17:10
*** paul_glass has quit IRC17:33
*** stanzi has quit IRC17:35
*** paul_glass has joined #openstack-barbican17:36
*** paul_glass1 has joined #openstack-barbican17:36
*** paul_glass has quit IRC17:40
SheenaG11redrobot: ping?!17:42
SheenaG11rm_work: ping ping ping17:43
SheenaG11SOMEBODY17:43
rm_workSheenaG11: pong pong pong17:43
redrobotSheenaG11 pong pong pong17:43
SheenaG11...I have weird packages downstairs and no patience17:43
SheenaG11Who wants to go see what they are?!17:43
SheenaG11Caveat: you will probably have to bring them back upstairs17:43
rm_workheh, if I were in the office :P17:43
SheenaG11DAMNIT17:43
redrobotin receiving?17:43
SheenaG11I NEED TO KNOW17:43
SheenaG11Yep17:43
SheenaG11I can e-mail them and tell them you're coming17:43
redrobotSure, I'll head down there in just a sec.17:43
rm_workSheenaG11: they are probably anthrax >_>17:43
SheenaG11But you'll have to take them - I doubt they'll just let you inspect and report back17:43
SheenaG11redrobot: you are my hero17:44
redrobotwooooot!17:44
redrobotjust another day in the life of a PTL :-P17:44
SheenaG11I sent them an e-mail saying you could take them17:44
SheenaG11I hope they're something crazy17:44
rm_workSheenaG11: I hope they're something non-deadly :P17:44
SheenaG11rm_work: me too...17:44
SheenaG11rm_work: hell of a way to kill Doug17:45
rm_workright?17:45
* redrobot is starting to regret this decision17:45
rm_work"Oh hey, want to go pick up a box for me? Ignore the ticking noise"17:45
SheenaG11redrobot: it might be food!!17:45
redrobot... poisoned food. O_o17:45
rm_work:P17:46
*** dave-mccowan has quit IRC17:48
*** dave-mccowan has joined #openstack-barbican17:48
rm_workcurrently trying to figure out why the water at my house appears to be off...17:48
*** stanzi has joined #openstack-barbican17:50
*** stanzi has quit IRC17:56
*** ayoung has joined #openstack-barbican17:59
*** stanzi has joined #openstack-barbican17:59
*** paul_glass1 has quit IRC18:09
*** kebray has quit IRC18:24
openstackgerritOpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements  https://review.openstack.org/13644518:25
*** kebray has joined #openstack-barbican18:39
*** trey has joined #openstack-barbican18:45
openstackgerritAde Lee proposed openstack/python-barbicanclient: Implement transport key wrapping for barbican-client  https://review.openstack.org/13645418:47
alee_rm_work, redrobot ^^18:49
alee_rm_work, redrobot please take a look - its still wip but you should be able to tell me if I got something totally borked.18:50
redrobotalee_ sounds good, will try to take a look as soon as I get a chance18:53
alee_redrobot, thanks18:54
*** kebray has quit IRC19:02
*** kebray has joined #openstack-barbican19:02
*** SheenaG11 has quit IRC19:22
*** stanzi has quit IRC19:46
rm_workalee_: comments posted19:57
alee_rm_work, thanks19:57
rm_workincluded a -1 even though it's still WIP, just because I so rarely get to -1 things :P19:57
*** darrenmoffat has quit IRC19:57
alee_:)19:57
*** darrenmoffat has joined #openstack-barbican19:57
alee_rm_work, does the client always do a get() ofr the metadata before getting the payload?20:01
rm_workyes20:01
rm_workalways20:01
rm_work100% not possible to do it any other way with the client currently20:01
rm_workwhich actually came up in a discussion20:01
rm_workbecause technically it is inefficient if you LITERALLY just want the payload20:01
reaperhulkWait, really? You can't get a secret without getting its metadata first in our client?20:01
rm_workreaperhulk: correct20:01
reaperhulkThat's totally unacceptable20:02
*** bdpayne has joined #openstack-barbican20:02
rm_workwell, there was some discussion of that, but20:02
rm_workit works out that it's kind of impossible to spin up an appropriate object to represent a secret, if you don't have any of the metadata20:02
rm_workreaperhulk: did you read the reviews for the client code? T_T20:03
reaperhulkpython-barbicanclient?20:03
rm_workyes20:03
reaperhulkI did not, which would explain how I'm surprised20:04
rm_workhmm looks like you weren't on the email chain where this was explicitly discussed recently20:04
reaperhulk"Just gimme some bytes" is not an unusual requirement though20:04
reaperhulkAnd two round trips for something where you already know what it is (probably the vast majority of cases!) is total crap20:04
rm_workI mean, I wrote it, but I'm also the one that brought it up as an issue :P20:04
*** bdpayne_ has joined #openstack-barbican20:05
rm_workso, I could see writing a method for it20:05
rm_workand that was discussed20:05
rm_workbut it would change a bit about how alee_ is doing the transport key implementation20:05
rm_workI could work with him to do that patch and then rebase his on top of it20:05
rm_workI think it's pretty trivial to patch20:06
reaperhulkI'd definitely like to see that. Just having a method where it returns bytes and doesn't try to understand the type probably covers it quite nicely20:07
rm_workreaperhulk: dunno what to tell you though, lots of people reviewed the client changes pretty extensively :P20:07
alee_rm_work, yeah - as it is right now - it completely makes sense to keep a reference to the transport key and just get it in the initial get() to avoid the extra operation.20:07
*** bdpayne has quit IRC20:07
rm_workalee_: yeah, that would probably need to be changed to work in that way for the Secret object20:08
rm_workand then we'd need a little bit different set of code for the get_just_payload() function that we're discussing adding now20:08
alee_rm_work, but I agree with reaperhulk -- it makes sense to have a function where just the payload is returned20:08
reaperhulkrm_work: not blaming anybody. Complex changes can frequently hide issues like this20:08
rm_workyeah, it was on my todo list anyway, because of another use-case20:09
*** JeffF has quit IRC20:09
rm_workwe had been discussing making it possible for the *entire secret object* to be loaded up lazily20:09
rm_workso that might be the actual approach to take20:10
rm_workI actually have time to take a crack at that now, I think20:12
rm_workalee_: would you mind rebasing on top of that change, if I can get it in soon?20:12
alee_rm_work, sure -- I need to work on adding tests etc.20:12
rm_workk20:12
alee_and doing the actual crypto20:13
rm_workit might change your stuff minorly but actually not too bad20:13
rm_workyeah, work on the actual crypto util functions for now :P20:13
alee_rm_work, I think your patch will be much simpler and easier to get in.20:13
alee_rm_work, sounds good.20:13
alee_reaperhulk, you owe me some spec reviews :)20:14
reaperhulkI do :/ dragged into some horrible internal stuff today20:19
*** dave-mccowan has quit IRC20:24
alee_reaperhulk, how do a wrap a symmetric key with a public key using cryptography?20:26
reaperhulkRSA key?20:26
alee_yup20:26
reaperhulkbasically like this: https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#encryption20:26
reaperhulkPreferably using OAEP like in the example, but PKCS1 v1.5 is also available20:27
reaperhulk(https://cryptography.io/en/latest/hazmat/primitives/asymmetric/padding/)20:27
alee_cool20:27
reaperhulkPKCS1 takes no args if you do need to use it. Just pass an instance instead of OAEP20:28
*** SheenaG1 has joined #openstack-barbican20:37
*** SheenaG11 has joined #openstack-barbican20:39
alee_reaperhulk, so if I have a base64 encoded DER cert - with header and footer -- and I want to extract the public key as a RSAPublicKey ..20:40
reaperhulkIn cryptography? You wait for the next release :D20:40
reaperhulkOr you bind yourself tightly to the OpenSSL backend for the moment and I can give you some code that does it20:41
alee_whens the next release?20:41
*** dave-mccowan has joined #openstack-barbican20:41
rm_workreaperhulk: any word on a pyOpenSSL release that includes to stuff we added months ago? or did it actually happen finally and I missed it?20:42
*** SheenaG1 has quit IRC20:42
reaperhulkalee_: ideally sometime in December20:42
reaperhulkrm_work: :/ no, need to followup on some of the back channel avenues I'm pursuing there20:42
reaperhulkalee_: https://github.com/pyca/cryptography/issues/138520:42
reaperhulkSpecifically this: https://github.com/pyca/cryptography/issues/1385#issuecomment-5961301220:42
reaperhulkThat will get the public key from a cert :)20:42
alee_reaperhulk, yeah I was looking at that -- thats just yucky20:44
reaperhulkyup, it's pure C :)20:44
alee_december, eh?20:45
rm_workyou wouldn't use pyOpenSSL to do that? You can get a pubkey out of a cert using their X509 objects I thought20:46
reaperhulkThat's the goal, but X509 has a big set of challenges. It's possible to scope it down, so I may implement an opaque x509 object that has a limited set of things (like getting the public key) first20:46
rm_workor are you specifically saying you are trying to avoid pyOpenSSL because it is just using C?20:46
reaperhulkrm_work: You can, and that's not necessarily the worst idea, although if you then want to use that public key to encrypt it becomes much trickier since pyopenssl doesn't make that easy :)20:46
rm_workwell, you can always use pyOpenSSL to get the key out, then export it to PEM and go from there with crypto, right? :P20:46
rm_workyeah it's not a spectacular workflow right now :(20:47
reaperhulknot yet20:48
reaperhulkMaybe I should look at that opaque X509 idea to unstick progress on that front...20:48
alee_reaperhulk, this is for the transport key stuff -- I'd like to 1) extract a public key from a cert 2) use that public key to encrypt a symmetric key20:50
alee_so I guess I only need (1) then ..20:51
reaperhulkYeah #1 is what we don't provide without that ugly function in the issue I linked right now20:51
reaperhulkBut if the next version of cryptography added an X509 loader where you could20:52
reaperhulkcert = load_x509_from_pem(data)20:52
reaperhulkpubkey = cert.public_key()20:52
reaperhulkthat would resolve your issue20:52
reaperhulkeven if cert had no other methods available on it for now, hehe20:52
alee_reaperhulk, yup20:59
alee_anyways - just putting in my request :)  I may test out some patches with the ugly function till then21:00
rm_workwtf is going on with these mocks… this test passes if I run it, but fails if I debug through it T_T21:15
rm_workreaperhulk: if we don't fetch the metadata, how do we know what type of data to request as the payload?21:17
rm_workthe metadata includes the content_type <_<21:17
reaperhulkCan you not always request application/octet-stream?21:22
rm_workhmm21:22
rm_workwouldn't that net a different result?21:22
rm_worki mean… if it doesn't, then what is the purpose of requesting with a specific content-type at all?21:22
reaperhulkHmm, put another way: if you presumably know what you're fetching wouldn't you also presumably know the content-type you want21:23
rm_worki guess possibly21:23
rm_workk21:24
*** JeffF has joined #openstack-barbican21:24
rm_workI think I know how to deal with it21:24
rm_workWTF21:28
rm_workok, so...21:28
rm_worknow THIS test fails when I run it, but not when I debug it21:28
rm_workI don't know which is worse21:28
*** SheenaG11 has quit IRC21:29
rm_workok this got a little confusing with some interdependent attributes and trying to keep everything lazy, but I think it's good21:42
rm_workkinda wanted to call the method that force-loads everything `self._kick_in_the_rear( )`21:43
rm_workbut alas :(21:43
-openstackstatus- NOTICE: gating is going offline while we deal with a broken block device, eta unknown21:43
*** ChanServ changes topic to "gating is going offline while we deal with a broken block device, eta unknown"21:43
rm_workgah21:43
rm_workso, I am somewhat worried about this logic possibly being difficult to follow :(21:45
rm_workreaperhulk: would appreciate if you read through the client code (for secrets, at least) when I submit this21:46
rm_workI can't help but wonder if this interdependency logic could be simplified if I were able to step back and reset my brain a bit21:46
redrobotrm_work can't hurt21:54
redrobotrm_work plus it's friday21:54
redrobotrm_work so chill for the weekend... i'm sure everything will be clear on monday21:54
rm_workredrobot: well, I mean, I don't think I'm able to do it, i'm in too deep21:55
rm_workthis is the same code that was here when 3.0 was released, if I haven't been able to reset since then, I don't know if it's going to happen :P21:55
openstackgerritAdam Harwell proposed openstack/python-barbicanclient: Defer loading Secret meta-data until requested  https://review.openstack.org/13649821:57
rm_workalee_: ^^ that is the review21:57
*** kgriffs is now known as kgriffs|afk21:58
rm_workredrobot: if you have time to give it a look-see, would be appreciated. the specific interaction I'm referring to is the "payload_content_type" which can come either from the Secret's meta-data (content_types['default']) or user specifying it (which takes priority over the meta-data, even if it exists)21:59
redrobotrm_work kk, but I'm fading fast, and I'm on vacation next week. :-P21:59
rm_workredrobot: heh, k22:00
rm_workwell, maybe reaperhulk will have some time to wrap his head around it22:00
rm_workredrobot / reaperhulk: the tricky bit is if the user tries to get the payload without loading the Secret meta-data, we have to figure out: did the user provide a payload_content_type? if so, we use that to pull the payload, avoiding pulling the metadata. if not, I guess we go ahead and pull the meta-data and see if that specified a default content_type, and if so, pull the payload with it, otherwise either complain that there22:04
rm_work is no default content_type to use and that the user needs to specify one (if the user didn't already specify one, and some content_types EXIST but there is no "default") or else we know (?) that the Secret doesn't have a payload at all (no user specified content type, and no meta-data spefified content-types *AT ALL*)22:04
rm_work<_<22:04
rm_workredrobot: anywho, enjoy your vacation :P22:05
*** ryanpetrello has quit IRC22:17
*** kgriffs|afk is now known as kgriffs22:19
*** stanzi has joined #openstack-barbican22:26
*** dave-mccowan has quit IRC22:27
*** kebray has quit IRC22:36
*** stanzi has quit IRC22:40
*** kebray has joined #openstack-barbican22:42
*** kgriffs is now known as kgriffs|afk22:53
*** dave-mccowan has joined #openstack-barbican23:00
*** dave-mccowan_ has joined #openstack-barbican23:01
*** dave-mccowan has quit IRC23:04
*** dave-mccowan_ is now known as dave-mccowan23:04
*** stanzi has joined #openstack-barbican23:12
*** dimtruck is now known as zz_dimtruck23:16
*** stanzi has quit IRC23:22
*** SheenaG1 has joined #openstack-barbican23:52

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!