| *** kgriffs|afk is now known as kgriffs | 00:03 | |
| *** SheenaG1 has joined #openstack-barbican | 00:04 | |
| *** stanzi has quit IRC | 00:07 | |
| *** zz_dimtruck is now known as dimtruck | 00:11 | |
| *** stanzi has joined #openstack-barbican | 00:12 | |
| *** kgriffs is now known as kgriffs|afk | 00:12 | |
| *** dimtruck is now known as zz_dimtruck | 00:16 | |
| *** ryanpetrello has quit IRC | 00:18 | |
| *** JeffF1 has quit IRC | 00:20 | |
| *** ryanpetrello has joined #openstack-barbican | 00:24 | |
| *** kebray has quit IRC | 00:26 | |
| *** david-lyle is now known as david-lyle_afk | 00:33 | |
| *** ryanpetrello_ has joined #openstack-barbican | 00:37 | |
| *** ryanpetrello has quit IRC | 00:38 | |
| *** ryanpetrello_ is now known as ryanpetrello | 00:38 | |
| *** stanzi has quit IRC | 00:40 | |
| *** ryanpetrello_ has joined #openstack-barbican | 00:44 | |
| *** bdpayne has quit IRC | 00:46 | |
| *** ryanpetrello has quit IRC | 00:47 | |
| *** ryanpetrello_ has quit IRC | 00:50 | |
| *** stanzi has joined #openstack-barbican | 01:29 | |
| *** stanzi has quit IRC | 01:38 | |
| *** kgriffs|afk is now known as kgriffs | 01:40 | |
| *** stanzi has joined #openstack-barbican | 01:44 | |
| *** SheenaG1 has quit IRC | 01:51 | |
| *** ryanpetrello has joined #openstack-barbican | 02:04 | |
| *** jorge_munoz has quit IRC | 02:09 | |
| *** kgriffs is now known as kgriffs|afk | 02:13 | |
| *** stanzi has quit IRC | 02:33 | |
| *** SheenaG1 has joined #openstack-barbican | 02:35 | |
| *** SheenaG1 has quit IRC | 02:52 | |
| *** ryanpetrello has quit IRC | 03:01 | |
| *** ryanpetrello has joined #openstack-barbican | 03:04 | |
| *** SheenaG1 has joined #openstack-barbican | 03:11 | |
| *** ryanpetrello has quit IRC | 03:16 | |
| *** ryanpetrello has joined #openstack-barbican | 03:17 | |
| *** ryanpetrello has quit IRC | 03:31 | |
| *** stanzi has joined #openstack-barbican | 03:43 | |
| *** stanzi has quit IRC | 03:48 | |
| *** stanzi has joined #openstack-barbican | 04:02 | |
| *** dave-mccowan has quit IRC | 04:02 | |
| *** stanzi has quit IRC | 04:08 | |
| *** kgriffs|afk is now known as kgriffs | 04:09 | |
| *** stanzi has joined #openstack-barbican | 04:15 | |
| *** kgriffs is now known as kgriffs|afk | 04:19 | |
| *** stanzi has quit IRC | 04:36 | |
| *** david-lyle_afk has quit IRC | 04:43 | |
| *** stanzi has joined #openstack-barbican | 04:51 | |
| *** ryanpetrello has joined #openstack-barbican | 04:54 | |
| *** stanzi has quit IRC | 05:47 | |
| *** bdpayne has joined #openstack-barbican | 06:56 | |
| *** bdpayne has quit IRC | 06:56 | |
| *** ryanpetrello has quit IRC | 07:05 | |
| *** jaosorior has joined #openstack-barbican | 07:58 | |
| *** woodster_ has quit IRC | 09:10 | |
| *** jaosorior has quit IRC | 10:43 | |
| *** dave-mccowan has joined #openstack-barbican | 12:46 | |
| *** woodster_ has joined #openstack-barbican | 13:01 | |
| *** rellerreller has joined #openstack-barbican | 13:18 | |
| *** jamielennox is now known as jamielennox|away | 13:20 | |
| *** SheenaG11 has joined #openstack-barbican | 13:20 | |
| *** SheenaG1 has quit IRC | 13:22 | |
| *** ryanpetrello has joined #openstack-barbican | 14:03 | |
| *** ryanpetrello_ has joined #openstack-barbican | 14:05 | |
| *** codekobe_ has quit IRC | 14:06 | |
| *** codekobe_ has joined #openstack-barbican | 14:07 | |
| *** ryanpetrello has quit IRC | 14:08 | |
| *** ryanpetrello_ is now known as ryanpetrello | 14:08 | |
| *** dave-mccowan has quit IRC | 14:12 | |
| *** insequent has quit IRC | 14:16 | |
| *** russell_h has quit IRC | 14:16 | |
| *** rm_work has quit IRC | 14:16 | |
| *** rm_work has joined #openstack-barbican | 14:17 | |
| *** rm_work has quit IRC | 14:17 | |
| *** rm_work has joined #openstack-barbican | 14:17 | |
| *** insequent has joined #openstack-barbican | 14:17 | |
| *** russell_h has joined #openstack-barbican | 14:17 | |
| *** paul_glass has joined #openstack-barbican | 14:24 | |
| openstackgerrit | Thomas Dinkjian proposed openstack/barbican: Add functional tests for order https://review.openstack.org/136155 | 14:26 |
|---|---|---|
| *** rellerreller has quit IRC | 14:42 | |
| *** rellerreller has joined #openstack-barbican | 14:42 | |
| *** stanzi has joined #openstack-barbican | 15:03 | |
| *** kgriffs|afk is now known as kgriffs | 15:03 | |
| *** kebray has joined #openstack-barbican | 15:05 | |
| *** kebray has quit IRC | 15:06 | |
| *** kebray has joined #openstack-barbican | 15:07 | |
| openstackgerrit | Thomas Dinkjian proposed openstack/barbican: Add functional tests for order https://review.openstack.org/136155 | 15:12 |
| *** kgriffs is now known as kgriffs|afk | 15:17 | |
| *** kebray has quit IRC | 15:27 | |
| *** ayoung is now known as ayoung-dentist | 15:28 | |
| *** ayoung-dentist has quit IRC | 15:28 | |
| *** kgriffs|afk is now known as kgriffs | 15:28 | |
| *** SheenaG11 has quit IRC | 15:30 | |
| *** JeffF has joined #openstack-barbican | 15:32 | |
| *** kebray has joined #openstack-barbican | 15:35 | |
| *** dave-mccowan has joined #openstack-barbican | 15:41 | |
| openstackgerrit | Steve Heyman proposed openstack/barbican-specs: Add spec to support running functional tests as different users https://review.openstack.org/135724 | 15:42 |
| *** zz_dimtruck is now known as dimtruck | 15:49 | |
| *** woodster_ has quit IRC | 16:00 | |
| *** rellerreller has quit IRC | 16:00 | |
| *** SheenaG1 has joined #openstack-barbican | 16:01 | |
| *** SheenaG11 has joined #openstack-barbican | 16:04 | |
| *** SheenaG1 has quit IRC | 16:06 | |
| alee_ | rm_work, ping | 16:36 |
| alee_ | redrobot, ping | 16:36 |
| rm_work | alee_: pong | 16:38 |
| alee_ | rm_work, I have a question about barbican_client | 16:38 |
| rm_work | alee_: i might have an answer about barbican_client | 16:38 |
| alee_ | rm_work, specifically the code that gets a secret | 16:39 |
| rm_work | ok | 16:39 |
| alee_ | rm_work, so in secrets.py , there is a function .. | 16:39 |
| rm_work | probably, yes | 16:39 |
| * rm_work is feeling salty this morning for some reason :P | 16:39 | |
| alee_ | :/ | 16:39 |
| alee_ | get() in SecretManager | 16:40 |
| rm_work | ok | 16:40 |
| alee_ | this ultimately calls .. | 16:40 |
| alee_ | self._api._get() | 16:40 |
| rm_work | yes | 16:41 |
| alee_ | which is defined in client.py | 16:41 |
| rm_work | yes | 16:41 |
| rm_work | that sounds right | 16:41 |
| alee_ | now -- as far as I can see -- we are setting Accept to "application/json" | 16:41 |
| rm_work | yes | 16:41 |
| alee_ | but isn't that what we would set to get the secret metadata only? | 16:41 |
| rm_work | _get_raw is for payload | 16:42 |
| rm_work | yes | 16:42 |
| alee_ | ah .. | 16:42 |
| rm_work | that call doesn't get payload | 16:42 |
| rm_work | the secret.payload attribute is a lazy-load that will call _get_raw() when you try to access it | 16:42 |
| rm_work | see Secret.payload -> Secret._fetch_payload() | 16:43 |
| alee_ | rm_work, ok cool - that makes more sense now :/ | 16:45 |
| rm_work | sorry, this is what I'm like when I am in especially good humor :P | 16:45 |
| alee_ | (and totally messes up my patch) | 16:45 |
| *** paul_glass has quit IRC | 16:45 | |
| alee_ | :) | 16:45 |
| rm_work | you have a patch? | 16:46 |
| rm_work | what mischief are you up to? :) | 16:46 |
| alee_ | working on one for transport key support in client | 16:46 |
| *** paul_glass has joined #openstack-barbican | 16:46 | |
| rm_work | ah, cool | 16:46 |
| rm_work | I was just asking about that yesterday | 16:46 |
| rm_work | out-of-channel | 16:47 |
| alee_ | yup -- I should start sending out patches for review next week or the week after | 16:47 |
| alee_ | of course now that I understand the code better, then patches might make more sense now. | 16:48 |
| rm_work | you'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 there | 16:48 |
| rm_work | doing it from Containers will be fun too | 16:48 |
| rm_work | :P | 16:48 |
| alee_ | rm_work, well its tricky --- you want to use a 2-step GET | 16:49 |
| rm_work | yeah but you can hide that in the _fetch_payload | 16:49 |
| rm_work | right? | 16:49 |
| rm_work | wait, what are the two steps? | 16:49 |
| rm_work | I thought you basically just passed a pub-key to the GET and it wrapped and returned | 16:49 |
| rm_work | maybe I don't understand transport key fully | 16: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 wrapping | 16:50 |
| alee_ | 2. server responds with metadata and the transport key ref if available | 16:51 |
| rm_work | woah, ok | 16:51 |
| rm_work | so 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 side | 16:51 |
| alee_ | this is not the pre-encryption on client side | 16:52 |
| rm_work | wait, is this for sending data TO barbican via transport key, or getting data FROM barbican via transport key? | 16:52 |
| rm_work | I think I was imagining getting existing secret data from Barbican with a transport key | 16:52 |
| alee_ | rm_work, getting data FROM barbican | 16:52 |
| rm_work | hmm | 16:52 |
| alee_ | rm_work, let me go through the steps .. | 16:52 |
| rm_work | sorry k | 16: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_work | k | 16:54 |
| alee_ | so you first need to get the secret metadata -specifically asking for transport key ref | 16:54 |
| alee_ | thats step 1 | 16: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 already | 16: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-barbican | 16:56 | |
| alee_ | step 4: server unwraps the wrapped symmetric key, uses it to wrap the secret and returns the wrapped secret | 16:56 |
| alee_ | step 5: client uses symmetric key to unwrap secret | 16:57 |
| rm_work | ok so | 16:57 |
| rm_work | what I imagine is | 16:57 |
| rm_work | barbican_client.secrets.get(secret_ref=my_secret_uuid, transport_key=True) | 16:58 |
| rm_work | err | 16:58 |
| rm_work | mysecret = ^^ | 16:58 |
| rm_work | data = mysecret.payload | 16:58 |
| redrobot | rm_work +1 | 16:58 |
| rm_work | cool | 16:58 |
| rm_work | so yeah, that shouldn't be too bad | 16:58 |
| rm_work | the client can handle all of that stuff internally | 16:59 |
| rm_work | the initial metadata GET will include the transport key now, which Secret will store internall | 16:59 |
| rm_work | *y | 16:59 |
| rm_work | and then the _fetch_payload will just have to do a couple of calls in a row and some other generation stuff | 16:59 |
| rm_work | I didn't realize the transport-key stuff required symmetric keys | 17:00 |
| rm_work | I am still not sure WHY, but that's fine :P | 17: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 CR | 17:01 |
| alee_ | so you can see if I'm totally off base. | 17:02 |
| rm_work | I 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_work | what does the symmetric key stuff buy you? | 17:03 |
| * rm_work is not a security expert | 17:03 | |
| rm_work | redrobot: ? | 17:04 |
| tiger_toes | rm_work: anyone who proclaims should be treated with skepticism, the experts don't need to flash alleged bona fides | 17:04 |
| rm_work | heh, true | 17:05 |
| reaperhulk | in fact the experts shy away from ever saying anything definitive | 17:06 |
| alee_ | rm_work, that requires the client to have a pub/priv key. Not all clients have that necessarily. | 17:06 |
| redrobot | rm_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_work | O_o | 17:06 |
| reaperhulk | rm_work: transport keys require symmetric because asymmetric encryption is limited to the length of the key (minus some padding) | 17:06 |
| rm_work | AH | 17:06 |
| rm_work | so to prevent the client from having to generate like a 16384 sized key | 17:07 |
| rm_work | got it :P | 17:07 |
| reaperhulk | Yup | 17:07 |
| rm_work | did not realize that | 17:07 |
| rm_work | so messages signed with PGP/GPG need to be pretty small | 17:07 |
| reaperhulk | With the symmetric wrap you end up with no real size limitations | 17:07 |
| rm_work | IE, I wouldn't sign a novel with my default pubkey | 17:08 |
| reaperhulk | GPG has symmetric options | 17:08 |
| rm_work | err, ok | 17:08 |
| rm_work | I guess I mean standard RSA pub/priv | 17:08 |
| rm_work | which is how I use GPG 99% of the time | 17:08 |
| rm_work | anywho, that makes sense now, thanks | 17:10 |
| *** paul_glass has quit IRC | 17:33 | |
| *** stanzi has quit IRC | 17:35 | |
| *** paul_glass has joined #openstack-barbican | 17:36 | |
| *** paul_glass1 has joined #openstack-barbican | 17:36 | |
| *** paul_glass has quit IRC | 17:40 | |
| SheenaG11 | redrobot: ping?! | 17:42 |
| SheenaG11 | rm_work: ping ping ping | 17:43 |
| SheenaG11 | SOMEBODY | 17:43 |
| rm_work | SheenaG11: pong pong pong | 17:43 |
| redrobot | SheenaG11 pong pong pong | 17:43 |
| SheenaG11 | ...I have weird packages downstairs and no patience | 17:43 |
| SheenaG11 | Who wants to go see what they are?! | 17:43 |
| SheenaG11 | Caveat: you will probably have to bring them back upstairs | 17:43 |
| rm_work | heh, if I were in the office :P | 17:43 |
| SheenaG11 | DAMNIT | 17:43 |
| redrobot | in receiving? | 17:43 |
| SheenaG11 | I NEED TO KNOW | 17:43 |
| SheenaG11 | Yep | 17:43 |
| SheenaG11 | I can e-mail them and tell them you're coming | 17:43 |
| redrobot | Sure, I'll head down there in just a sec. | 17:43 |
| rm_work | SheenaG11: they are probably anthrax >_> | 17:43 |
| SheenaG11 | But you'll have to take them - I doubt they'll just let you inspect and report back | 17:43 |
| SheenaG11 | redrobot: you are my hero | 17:44 |
| redrobot | wooooot! | 17:44 |
| redrobot | just another day in the life of a PTL :-P | 17:44 |
| SheenaG11 | I sent them an e-mail saying you could take them | 17:44 |
| SheenaG11 | I hope they're something crazy | 17:44 |
| rm_work | SheenaG11: I hope they're something non-deadly :P | 17:44 |
| SheenaG11 | rm_work: me too... | 17:44 |
| SheenaG11 | rm_work: hell of a way to kill Doug | 17:45 |
| rm_work | right? | 17:45 |
| * redrobot is starting to regret this decision | 17:45 | |
| rm_work | "Oh hey, want to go pick up a box for me? Ignore the ticking noise" | 17:45 |
| SheenaG11 | redrobot: it might be food!! | 17:45 |
| redrobot | ... poisoned food. O_o | 17:45 |
| rm_work | :P | 17:46 |
| *** dave-mccowan has quit IRC | 17:48 | |
| *** dave-mccowan has joined #openstack-barbican | 17:48 | |
| rm_work | currently trying to figure out why the water at my house appears to be off... | 17:48 |
| *** stanzi has joined #openstack-barbican | 17:50 | |
| *** stanzi has quit IRC | 17:56 | |
| *** ayoung has joined #openstack-barbican | 17:59 | |
| *** stanzi has joined #openstack-barbican | 17:59 | |
| *** paul_glass1 has quit IRC | 18:09 | |
| *** kebray has quit IRC | 18:24 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements https://review.openstack.org/136445 | 18:25 |
| *** kebray has joined #openstack-barbican | 18:39 | |
| *** trey has joined #openstack-barbican | 18:45 | |
| openstackgerrit | Ade Lee proposed openstack/python-barbicanclient: Implement transport key wrapping for barbican-client https://review.openstack.org/136454 | 18: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 |
| redrobot | alee_ sounds good, will try to take a look as soon as I get a chance | 18:53 |
| alee_ | redrobot, thanks | 18:54 |
| *** kebray has quit IRC | 19:02 | |
| *** kebray has joined #openstack-barbican | 19:02 | |
| *** SheenaG11 has quit IRC | 19:22 | |
| *** stanzi has quit IRC | 19:46 | |
| rm_work | alee_: comments posted | 19:57 |
| alee_ | rm_work, thanks | 19:57 |
| rm_work | included a -1 even though it's still WIP, just because I so rarely get to -1 things :P | 19:57 |
| *** darrenmoffat has quit IRC | 19:57 | |
| alee_ | :) | 19:57 |
| *** darrenmoffat has joined #openstack-barbican | 19:57 | |
| alee_ | rm_work, does the client always do a get() ofr the metadata before getting the payload? | 20:01 |
| rm_work | yes | 20:01 |
| rm_work | always | 20:01 |
| rm_work | 100% not possible to do it any other way with the client currently | 20:01 |
| rm_work | which actually came up in a discussion | 20:01 |
| rm_work | because technically it is inefficient if you LITERALLY just want the payload | 20:01 |
| reaperhulk | Wait, really? You can't get a secret without getting its metadata first in our client? | 20:01 |
| rm_work | reaperhulk: correct | 20:01 |
| reaperhulk | That's totally unacceptable | 20:02 |
| *** bdpayne has joined #openstack-barbican | 20:02 | |
| rm_work | well, there was some discussion of that, but | 20:02 |
| rm_work | it 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 metadata | 20:02 |
| rm_work | reaperhulk: did you read the reviews for the client code? T_T | 20:03 |
| reaperhulk | python-barbicanclient? | 20:03 |
| rm_work | yes | 20:03 |
| reaperhulk | I did not, which would explain how I'm surprised | 20:04 |
| rm_work | hmm looks like you weren't on the email chain where this was explicitly discussed recently | 20:04 |
| reaperhulk | "Just gimme some bytes" is not an unusual requirement though | 20:04 |
| reaperhulk | And two round trips for something where you already know what it is (probably the vast majority of cases!) is total crap | 20:04 |
| rm_work | I mean, I wrote it, but I'm also the one that brought it up as an issue :P | 20:04 |
| *** bdpayne_ has joined #openstack-barbican | 20:05 | |
| rm_work | so, I could see writing a method for it | 20:05 |
| rm_work | and that was discussed | 20:05 |
| rm_work | but it would change a bit about how alee_ is doing the transport key implementation | 20:05 |
| rm_work | I could work with him to do that patch and then rebase his on top of it | 20:05 |
| rm_work | I think it's pretty trivial to patch | 20:06 |
| reaperhulk | I'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 nicely | 20:07 |
| rm_work | reaperhulk: dunno what to tell you though, lots of people reviewed the client changes pretty extensively :P | 20: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 IRC | 20:07 | |
| rm_work | alee_: yeah, that would probably need to be changed to work in that way for the Secret object | 20:08 |
| rm_work | and then we'd need a little bit different set of code for the get_just_payload() function that we're discussing adding now | 20:08 |
| alee_ | rm_work, but I agree with reaperhulk -- it makes sense to have a function where just the payload is returned | 20:08 |
| reaperhulk | rm_work: not blaming anybody. Complex changes can frequently hide issues like this | 20:08 |
| rm_work | yeah, it was on my todo list anyway, because of another use-case | 20:09 |
| *** JeffF has quit IRC | 20:09 | |
| rm_work | we had been discussing making it possible for the *entire secret object* to be loaded up lazily | 20:09 |
| rm_work | so that might be the actual approach to take | 20:10 |
| rm_work | I actually have time to take a crack at that now, I think | 20:12 |
| rm_work | alee_: 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_work | k | 20:12 |
| alee_ | and doing the actual crypto | 20:13 |
| rm_work | it might change your stuff minorly but actually not too bad | 20:13 |
| rm_work | yeah, work on the actual crypto util functions for now :P | 20: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 |
| reaperhulk | I do :/ dragged into some horrible internal stuff today | 20:19 |
| *** dave-mccowan has quit IRC | 20:24 | |
| alee_ | reaperhulk, how do a wrap a symmetric key with a public key using cryptography? | 20:26 |
| reaperhulk | RSA key? | 20:26 |
| alee_ | yup | 20:26 |
| reaperhulk | basically like this: https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#encryption | 20:26 |
| reaperhulk | Preferably using OAEP like in the example, but PKCS1 v1.5 is also available | 20:27 |
| reaperhulk | (https://cryptography.io/en/latest/hazmat/primitives/asymmetric/padding/) | 20:27 |
| alee_ | cool | 20:27 |
| reaperhulk | PKCS1 takes no args if you do need to use it. Just pass an instance instead of OAEP | 20:28 |
| *** SheenaG1 has joined #openstack-barbican | 20:37 | |
| *** SheenaG11 has joined #openstack-barbican | 20: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 |
| reaperhulk | In cryptography? You wait for the next release :D | 20:40 |
| reaperhulk | Or you bind yourself tightly to the OpenSSL backend for the moment and I can give you some code that does it | 20:41 |
| alee_ | whens the next release? | 20:41 |
| *** dave-mccowan has joined #openstack-barbican | 20:41 | |
| rm_work | reaperhulk: 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 IRC | 20:42 | |
| reaperhulk | alee_: ideally sometime in December | 20:42 |
| reaperhulk | rm_work: :/ no, need to followup on some of the back channel avenues I'm pursuing there | 20:42 |
| reaperhulk | alee_: https://github.com/pyca/cryptography/issues/1385 | 20:42 |
| reaperhulk | Specifically this: https://github.com/pyca/cryptography/issues/1385#issuecomment-59613012 | 20:42 |
| reaperhulk | That will get the public key from a cert :) | 20:42 |
| alee_ | reaperhulk, yeah I was looking at that -- thats just yucky | 20:44 |
| reaperhulk | yup, it's pure C :) | 20:44 |
| alee_ | december, eh? | 20:45 |
| rm_work | you wouldn't use pyOpenSSL to do that? You can get a pubkey out of a cert using their X509 objects I thought | 20:46 |
| reaperhulk | That'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) first | 20:46 |
| rm_work | or are you specifically saying you are trying to avoid pyOpenSSL because it is just using C? | 20:46 |
| reaperhulk | rm_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_work | well, you can always use pyOpenSSL to get the key out, then export it to PEM and go from there with crypto, right? :P | 20:46 |
| rm_work | yeah it's not a spectacular workflow right now :( | 20:47 |
| reaperhulk | not yet | 20:48 |
| reaperhulk | Maybe 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 key | 20:50 |
| alee_ | so I guess I only need (1) then .. | 20:51 |
| reaperhulk | Yeah #1 is what we don't provide without that ugly function in the issue I linked right now | 20:51 |
| reaperhulk | But if the next version of cryptography added an X509 loader where you could | 20:52 |
| reaperhulk | cert = load_x509_from_pem(data) | 20:52 |
| reaperhulk | pubkey = cert.public_key() | 20:52 |
| reaperhulk | that would resolve your issue | 20:52 |
| reaperhulk | even if cert had no other methods available on it for now, hehe | 20:52 |
| alee_ | reaperhulk, yup | 20:59 |
| alee_ | anyways - just putting in my request :) I may test out some patches with the ugly function till then | 21:00 |
| rm_work | wtf is going on with these mocks… this test passes if I run it, but fails if I debug through it T_T | 21:15 |
| rm_work | reaperhulk: if we don't fetch the metadata, how do we know what type of data to request as the payload? | 21:17 |
| rm_work | the metadata includes the content_type <_< | 21:17 |
| reaperhulk | Can you not always request application/octet-stream? | 21:22 |
| rm_work | hmm | 21:22 |
| rm_work | wouldn't that net a different result? | 21:22 |
| rm_work | i mean… if it doesn't, then what is the purpose of requesting with a specific content-type at all? | 21:22 |
| reaperhulk | Hmm, put another way: if you presumably know what you're fetching wouldn't you also presumably know the content-type you want | 21:23 |
| rm_work | i guess possibly | 21:23 |
| rm_work | k | 21:24 |
| *** JeffF has joined #openstack-barbican | 21:24 | |
| rm_work | I think I know how to deal with it | 21:24 |
| rm_work | WTF | 21:28 |
| rm_work | ok, so... | 21:28 |
| rm_work | now THIS test fails when I run it, but not when I debug it | 21:28 |
| rm_work | I don't know which is worse | 21:28 |
| *** SheenaG11 has quit IRC | 21:29 | |
| rm_work | ok this got a little confusing with some interdependent attributes and trying to keep everything lazy, but I think it's good | 21:42 |
| rm_work | kinda wanted to call the method that force-loads everything `self._kick_in_the_rear( )` | 21:43 |
| rm_work | but alas :( | 21:43 |
| -openstackstatus- NOTICE: gating is going offline while we deal with a broken block device, eta unknown | 21:43 | |
| *** ChanServ changes topic to "gating is going offline while we deal with a broken block device, eta unknown" | 21:43 | |
| rm_work | gah | 21:43 |
| rm_work | so, I am somewhat worried about this logic possibly being difficult to follow :( | 21:45 |
| rm_work | reaperhulk: would appreciate if you read through the client code (for secrets, at least) when I submit this | 21:46 |
| rm_work | I can't help but wonder if this interdependency logic could be simplified if I were able to step back and reset my brain a bit | 21:46 |
| redrobot | rm_work can't hurt | 21:54 |
| redrobot | rm_work plus it's friday | 21:54 |
| redrobot | rm_work so chill for the weekend... i'm sure everything will be clear on monday | 21:54 |
| rm_work | redrobot: well, I mean, I don't think I'm able to do it, i'm in too deep | 21:55 |
| rm_work | this 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 :P | 21:55 |
| openstackgerrit | Adam Harwell proposed openstack/python-barbicanclient: Defer loading Secret meta-data until requested https://review.openstack.org/136498 | 21:57 |
| rm_work | alee_: ^^ that is the review | 21:57 |
| *** kgriffs is now known as kgriffs|afk | 21:58 | |
| rm_work | redrobot: 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 |
| redrobot | rm_work kk, but I'm fading fast, and I'm on vacation next week. :-P | 21:59 |
| rm_work | redrobot: heh, k | 22:00 |
| rm_work | well, maybe reaperhulk will have some time to wrap his head around it | 22:00 |
| rm_work | redrobot / 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 there | 22: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_work | redrobot: anywho, enjoy your vacation :P | 22:05 |
| *** ryanpetrello has quit IRC | 22:17 | |
| *** kgriffs|afk is now known as kgriffs | 22:19 | |
| *** stanzi has joined #openstack-barbican | 22:26 | |
| *** dave-mccowan has quit IRC | 22:27 | |
| *** kebray has quit IRC | 22:36 | |
| *** stanzi has quit IRC | 22:40 | |
| *** kebray has joined #openstack-barbican | 22:42 | |
| *** kgriffs is now known as kgriffs|afk | 22:53 | |
| *** dave-mccowan has joined #openstack-barbican | 23:00 | |
| *** dave-mccowan_ has joined #openstack-barbican | 23:01 | |
| *** dave-mccowan has quit IRC | 23:04 | |
| *** dave-mccowan_ is now known as dave-mccowan | 23:04 | |
| *** stanzi has joined #openstack-barbican | 23:12 | |
| *** dimtruck is now known as zz_dimtruck | 23:16 | |
| *** stanzi has quit IRC | 23:22 | |
| *** SheenaG1 has joined #openstack-barbican | 23:52 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!