| *** lisaclark1 has quit IRC | 00:01 | |
| *** crc32 has quit IRC | 00:05 | |
| woodster_ | rm_work, you still there? | 00:05 |
|---|---|---|
| *** ayoung has joined #openstack-barbican | 00:09 | |
| *** jaosorior has quit IRC | 00:13 | |
| *** ayoung has quit IRC | 00:18 | |
| jamielennox | from a python 3 perspective in barbicanclient is the _get_raw which is used from things like payload supposed to return text or bytes? | 00:24 |
| jamielennox | things like secret payload | 00:24 |
| jamielennox | assume bytes? | 00:24 |
| reaperhulk | definitely should be bytes | 00:24 |
| reaperhulk | if it's not that's a total bug since we'd be applying an encoding :o | 00:25 |
| rm_you | woodster_: i am *here* | 00:25 |
| jamielennox | reaperhulk: assumed so, just something that popped up | 00:25 |
| rm_you | jamielennox: yeah, it's supposedly bytes, I think | 00:25 |
| rm_you | though that depends on the encoding we set | 00:26 |
| jamielennox | it's something that using a mock gets to completely ignore | 00:26 |
| rm_you | it's supposed to allow us to specify an encoding, really (the basic .get() doesn't, IIRC?) | 00:26 |
| rm_you | it was something like that | 00:26 |
| jamielennox | get assumes json and json needs an encoding | 00:26 |
| rm_you | yeah thats it | 00:26 |
| woodster_ | rm_you, I added a response to your question...I still think that LBaaS user should have the right roles to access secrets, but need to see what other folks think | 00:27 |
| rm_you | woodster_: but, access what secrets? its own? why would ability to access its own secrets have any relation to its ability to accessother people's? | 00:27 |
| *** ryanpetrello has quit IRC | 00:27 | |
| woodster_ | rm_you, I mean secrets that another user has created and then said lbaas user is allowed to decrypt that secret. Are you thinking roles shouldn't matter if you aren't the project that created a secret? Seems like a priv escalation to me? | 00:29 |
| rm_you | err | 00:30 |
| rm_you | so, keystone roles ARE specific to project | 00:30 |
| woodster_ | rm_you, how much does https://review.openstack.org/#/c/145073/ impact the client lib in your opinion? I'm thinking a significant change | 00:30 |
| rm_you | so effectively I have no roles for Barbican for the other user's secret | 00:30 |
| rm_you | it's just that they told barbican to let me see them anyway | 00:31 |
| woodster_ | rm_you, so I'm thinking that the lbaas user should be assigned the correct barbican roles to access secrets in barbican. | 00:31 |
| rm_you | woodster_: again, whose? roles are project specific | 00:31 |
| rm_you | you can't have a role that isn't tied to a project, AFAIK | 00:32 |
| woodster_ | rm_you, you would assign the correct barbican role to the lbaas user-to-lbaas-project association | 00:32 |
| woodster_ | rm_you, so in lbaas's policy definition in keystone | 00:32 |
| rm_you | so the logic would go "do you have access to your own secrets?" "yes" "did user A grant read-access to you for this secret?" "yes" "ok here is a secret" | 00:33 |
| rm_you | the first part seems redundant to me | 00:33 |
| rm_you | and i don't see how not having it would be escalation | 00:33 |
| rm_you | User A says "User B has access to my Secret" | 00:33 |
| rm_you | why do we care if User B has access to "secrets in general" (which again, isn't really what it'd be -- it'd be access to "their own secrets") | 00:34 |
| woodster_ | rm_you, well, something like 'does your role match the operation you are trying to do?' if yes, then access secret by its UUID...does it have a white list? If no, then project ids have to match (as now). If yes, then am I on that white list? If no, reject. | 00:34 |
| rm_you | hmm | 00:34 |
| rm_you | but again, that's not a sane reading of keystone's role system, IMO | 00:35 |
| rm_you | at least as far as I understand it | 00:35 |
| woodster_ | rm_you, I'm trying to resolve the current project-based approach with the white list approach, which is optional on secrets/containers. | 00:35 |
| *** SheenaG11 has quit IRC | 00:36 | |
| woodster_ | rm_you, yeah, it might be good to get some Keystone dev weigh in on that CR. | 00:36 |
| rm_you | trying to think of a good metaphor | 00:37 |
| rm_you | because i operate best with metaphors :P | 00:37 |
| rm_you | Ok so, imagine a bank with a safety deposit box area | 00:37 |
| rm_you | ... sec, i am still fleshing this out, should have waited a bit more on the first line <_< | 00:38 |
| *** kgriffs is now known as kgriffs|afk | 00:38 | |
| rm_you | so ignore what i said earlier. Barbican is a Bank. | 00:39 |
| rm_you | Your nephew Bill gives you access to his bank account via some method (Power of Attorney, possibly) | 00:40 |
| openstackgerrit | Venkat Sundaram proposed openstack/barbican-specs: Add Quota support for Barbican resources https://review.openstack.org/132091 | 00:40 |
| rm_you | You go to the bank and say "I would like to look at Bill's balance." | 00:40 |
| rm_you | The bank doesn't first ask you "do you have an account here?" nor if you did, "Can you put in the pin to your own account?" | 00:41 |
| rm_you | they check the operation at hand, which is "do you have access to Bill's account", which is "yes" | 00:41 |
| rm_you | whether you have your own account doesn't matter | 00:41 |
| rm_you | similar to this situation, there is no "I have access to *accounts in general*", because access to accounts is on a per account basis | 00:48 |
| woodster_ | rm_you, well in the case whether you have an account or not is not important either. What matters is the roles that were setup for your user on your account. An admin had to be told you can be granted this role to do xyz in this other service. So its an extra level of security, like going to a CA to verify a cert. | 00:48 |
| rm_you | ok, but keystone doesn't work that way | 00:48 |
| rm_you | it's all "can do xyz in this other service FOR THIS ACCOUNT" | 00:49 |
| rm_you | that's the only language keystone knows, if I understand correctly | 00:49 |
| rm_you | there is no such thing as a non-project associated role | 00:49 |
| rm_you | that's why there's a "service" project, so they can fake it, but that's exactly what we were trying to avoid | 00:49 |
| woodster_ | rm_you, I'm saying to barbican it doesn't matter what account you have for the policy.json RBAC check...it just looks at the roles right now any way | 00:49 |
| jamielennox | so i'm looking through the tests in python 3, the test secret data is a text object and the mocking happens such that it never tries to json serialize it | 00:49 |
| rm_you | yeah but what is the point of that | 00:50 |
| jamielennox | if i were to pass it as bytes it would attempt to put that into a json serialize structure and ti would fail | 00:50 |
| rm_you | jamielennox: that's... odd | 00:50 |
| *** ryanpetrello has joined #openstack-barbican | 00:50 | |
| woodster_ | jamielennox, well barbican supports a text and binary secret type...I wonder if that is a text-only secret? | 00:51 |
| jamielennox | and as it so happens if i use oslo.serialization or whatever then it does work - it just turns it into an array of integers (bytes representation) | 00:51 |
| woodster_ | rm_you, I think you are asking what is the point of roles in RBAC? | 00:51 |
| rm_you | woodster_: no, the point of roles in RBAC is to grant permanent access to specific things on a specific project :) | 00:51 |
| jamielennox | i'm looking at https://github.com/openstack/python-barbicanclient/blob/master/barbicanclient/test/test_client_secrets.py#L25 as used https://github.com/openstack/python-barbicanclient/blob/master/barbicanclient/test/test_client_secrets.py#L66 | 00:52 |
| rm_you | except we have to work outside of the RBAC system entirely, because it is not granular enough | 00:52 |
| woodster_ | rm_you, it is really so a 3rd party (system admin) can grant/revoke your ability to do thing in another system. If we don't respect that in barbican, then this 3rd pary check/balance breaks | 00:52 |
| rm_you | I mean, if it comes down to it, we can grant to our account whatever you are saying you want us to have | 00:52 |
| rm_you | but it's pretty meaningless in keystone terms | 00:52 |
| rm_you | woodster_: well, I could have 90 different "BARBICAN_READ" roles | 00:53 |
| rm_you | which one do you check? just one? | 00:53 |
| jamielennox | regardless of the 'payload_content_type' and 'payload_content_encoding' it's still sent to the server in a json structure which bytes don't support | 00:53 |
| jamielennox | (i can wait for you guys to finish) | 00:53 |
| rm_you | we're ignoring the project the roles are associated with in this example | 00:53 |
| rm_you | so really it's just "does the user have at least one"? | 00:54 |
| rm_you | roles are a mapping between projects and users | 00:54 |
| woodster_ | rm_you, if I'm user XYZ, I should stay XYZ forever (until I'm removed). However, my roles might change over time. Maybe I'm an observer in barbican starting out, but I change job assigments to admin latter. Maybe later still I leave to a different team that doesn't require any access, then all barbican roles are removed. My access to secrets, even | 00:54 |
| woodster_ | whitelisted for my user XYZ should not be a constant yeah decrypt away IMHO. However, if that is the expectation of folks, I can change, it just seems very odd to me. | 00:54 |
| rm_you | woodster_: but an observer/admin for what project? | 00:55 |
| woodster_ | rm_you, for barbican | 00:55 |
| rm_you | ... no | 00:55 |
| rm_you | it's like | 00:55 |
| rm_you | ProjectA:BARBICAN:Observer | 00:55 |
| rm_you | ProjectB:BARBICAN:Admin | 00:55 |
| woodster_ | jamielennox, that sounds like an issue you are finding there | 00:55 |
| rm_you | where "BARBICAN:Admin" is the role | 00:55 |
| rm_you | it's a linkage | 00:56 |
| woodster_ | jamielennox, if the secret is a binary (application/octet-stream) type it would have to be base64 encoded to before passing into json | 00:56 |
| jamielennox | woodster_: i've found a bunch of similar python 3 bugs when i remove all the mocks the clients have | 00:56 |
| *** lisaclark1 has joined #openstack-barbican | 00:56 | |
| rm_you | jamielennox: what is sent to the SERVER is always json, what *comes back* is bytes | 00:56 |
| *** lisaclark1 has quit IRC | 00:57 | |
| jamielennox | woodster_: what's the default there? how should you check? | 00:57 |
| *** lisaclark1 has joined #openstack-barbican | 00:57 | |
| rm_you | sounds like you're trying to send bytes to the server? | 00:57 |
| woodster_ | rm_you, so user XYZ has an assoc to project ABC, and can have barbican:admin, barbican:observer, etc. in that association...and that can change over time | 00:57 |
| jamielennox | rm_you: right, but in which case i would assume that my secret payload is bytes in my application as well | 00:57 |
| jamielennox | rm_you: if the secret_payload that is returned from the server is bytes then i would assume so | 00:58 |
| jamielennox | as a somewhat stupid example i expect | 00:58 |
| rm_you | jamielennox: the secret payload is base64 encoded and sent to the server in that form, but always stuck into the json message | 00:58 |
| woodster_ | jamielennox, take a look at these examples: https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface#one-step-utf-8ascii-secret-createretrieve | 00:58 |
| rm_you | well, possibly not base64 encoded if the type is "text"? | 00:58 |
| rm_you | so I am not sure | 00:58 |
| jamielennox | ack base64 barbicanclient/ gives no results | 00:59 |
| woodster_ | jamielennox, so there are modes where you pass binary streams to and from barbican, but most of the time it is a json exchange | 00:59 |
| jamielennox | so ignoring my wrong Syntax but i would want to be able to | 00:59 |
| jamielennox | s = Secret.get('id') | 00:59 |
| rm_you | https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface#post | 01:00 |
| rm_you | so | 01:00 |
| jamielennox | t = Secret.create(payload=s.payload, payload_content_type=s.payload_content-tpye) | 01:00 |
| rm_you | "payload": "gF6+lLoF3ohA9aPRpt+6bQ==" | 01:00 |
| rm_you | you're expected to have base64 encoded your own binary data | 01:00 |
| rm_you | it seems | 01:00 |
| rm_you | jamielennox: ^^ | 01:00 |
| jamielennox | yea | 01:01 |
| rm_you | when it comes back, it comes back in the same form | 01:01 |
| rm_you | _get_raw() doesn't return binary then, it returns a String, just not one that is valid json | 01:01 |
| jamielennox | from a user perspective it's weird that i have to encode something on the create, but i get it back as bytes on the fetch | 01:01 |
| rm_you | jamielennox: you'll get back the same base64 encoded string | 01:02 |
| rm_you | so if I said you actually get legit bytes back earlier, I was incorrect | 01:02 |
| rm_you | sorry for the confusion, i'm in the middle of another pretty draining debate here :P | 01:02 |
| woodster_ | jamielennox, yeah it might make more sense from the API perspective...that one-step secret store allows you to upload a binary secret via JSON because of the base64 encode, but barbican notes the secret is a binary one, so when it is retrieved, it wants to send it back as a binary secret (we don't support conversion back to base64 currently). | 01:03 |
| jamielennox | oh - it's fine from an API perspective | 01:04 |
| woodster_ | jamielennox. fwiw, this blueprint is attempting to address this issue: https://review.openstack.org/#/c/145073 | 01:04 |
| rm_you | woodster_: so sure, your relationship with Barbican for a specific project can change over time... but you might have a relationship with 5 projects all changing over time, and *none of it* should matter if User Bill says you can access his secret explicitly | 01:04 |
| jamielennox | i'm more thinking of a client user you could handle that for them | 01:04 |
| woodster_ | jamielennox, yeah it seems like this sort of confusion could be handled on the client side. The trick is that if the original secret is stamped as application/octet-stream, then it can only be retrieved that way, even if you originally had it as a base64 string. I.e. the get call would need to be able to take in a 'text/plain' sort of content to force the | 01:05 |
| woodster_ | conversion to occur | 01:05 |
| rm_you | woodster_: whatever happened to the OTHER CR that would make this less insane | 01:06 |
| rm_you | https://review.openstack.org/#/c/125798/ | 01:06 |
| rm_you | why hasn't that merged yet | 01:06 |
| woodster_ | rm_you, well, I think that is the fundamental question to answer. I think barbican role should always matter, but yourself and probably others would disagree. I think widening this conversation is essential though, otherwise this CR will never land :) | 01:07 |
| woodster_ | jamielennox, are you thinking along the lines of improving the client library, or some of the testing around it? | 01:07 |
| jamielennox | woodster_: well for the moment i guess it's a bug in testing | 01:08 |
| jamielennox | or maybe not, it's testing that you pass a string to the secret payload | 01:08 |
| jamielennox | s/string/text | 01:08 |
| woodster_ | rm_you, jamielennox, well that CR speaks to a unique URI to decrypt secrets, which makes the policy more explicit around that call. We'd still have the same issue of whether to convert to text or leave as binary though. I think blueprint https://review.openstack.org/#/c/145073 with its strong secret type to format concept is really the best way to go...less | 01:10 |
| woodster_ | ambiguity. If I counted up all the hours we've spent trying to describe the current approach, it would be several weeks I'm sure. :) | 01:10 |
| rm_you | IMO both would be best :P | 01:11 |
| woodster_ | rm_work, jamielennox, I'm heading out now, but will be on later this evening. rm_work, I added the big question to the RBAC comments just now. jamielennox, feel free to get on IRC tomorrow/later if you have other thoughts on the testing there. | 01:17 |
| jamielennox | woodster_: thanks, i'll see if i just maintain the string assumption if the tests will work | 01:18 |
| woodster_ | jamielennox, please let the list know if that isn't the case...means we probably need to address that soon | 01:19 |
| rm_you | jamielennox: i really think they should | 01:20 |
| rm_you | i went through another couple of your reviews today but i may have forgotten to submit my comments on the second one before i went home <_< | 01:20 |
| *** ryanpetrello_ has joined #openstack-barbican | 01:25 | |
| *** ryanpetrello has quit IRC | 01:25 | |
| *** ryanpetrello_ is now known as ryanpetrello | 01:25 | |
| *** alee has joined #openstack-barbican | 01:27 | |
| jamielennox | rm_you: so https://github.com/openstack/python-barbicanclient/blob/master/barbicanclient/test/test_client_secrets.py#L207 is a problem and makes a similar assumption i did | 01:40 |
| rm_you | makes the assumption the payload is of the default type (octet-stream, base64 encoded) | 01:41 |
| rm_you | I think | 01:41 |
| rm_you | IIRC I wrote that test | 01:42 |
| rm_you | yep, i wrote that test <_< | 01:42 |
| jamielennox | https://github.com/openstack/python-barbicanclient/blob/master/barbicanclient/test/test_client_secrets.py#L194 | 01:42 |
| jamielennox | so that is returning a text type | 01:42 |
| jamielennox | damnit what am i trying to say here, keep getting dragged between different conversations | 01:42 |
| rm_you | heh, been happening to me all day | 01:44 |
| rm_you | ALL DAY. | 01:44 |
| jamielennox | ok so that line 194 | 01:46 |
| jamielennox | in python 3 | 01:46 |
| jamielennox | that will return a string, where in reality you want it to return bytes | 01:47 |
| jamielennox | s/string/text | 01:47 |
| rm_you | err well no | 01:47 |
| rm_you | it'll return a string | 01:47 |
| rm_you | which will be a base64 encoded secret | 01:47 |
| rm_you | IIRC | 01:47 |
| rm_you | in -> barbican -> out | 01:47 |
| rm_you | should all be the same format at the moment | 01:47 |
| rm_you | it doesn't convert or anything | 01:47 |
| rm_you | string in -> string out | 01:47 |
| rm_you | telling it you're storing an octet-stream is really more of a hint to what's inside the string, not related to what it actually takes in or spits out :( | 01:48 |
| rm_you | which is a bit confusing probably | 01:48 |
| jamielennox | so https://github.com/openstack/python-barbicanclient/blob/master/barbicanclient/client.py#L153 is wrong? | 01:48 |
| rm_you | that's right | 01:49 |
| jamielennox | because .content implies the bytes and .text looks at the encoding and converts to a text string | 01:49 |
| rm_you | well, the content is a string | 01:49 |
| rm_you | >_> | 01:49 |
| rm_you | not actually byte format | 01:49 |
| rm_you | AFAIK | 01:49 |
| rm_you | it *works* | 01:49 |
| rm_you | which tells you something, at least | 01:49 |
| jamielennox | yea, this becomes a problem in python 3 where bytes != text string | 01:49 |
| rm_you | hmm | 01:49 |
| rm_you | what tries to make it one or the other? | 01:50 |
| jamielennox | for which part | 01:50 |
| jamielennox | resp.content == bytes, resp.text == text | 01:50 |
| rm_you | ahh | 01:51 |
| jamielennox | so maybe this was reaperhulk wrong earlier, that you do want to return a text string of base64 encoded data and not the raw bytes of the secret | 01:51 |
| rm_you | ok then maybe yes it could be wrong | 01:51 |
| rm_you | i am thinking of it as "they are the same thing" | 01:51 |
| rm_you | maybe it needs to be resp.text for py33 | 01:51 |
| reaperhulk | Never doubt my ability to be wrong | 01:52 |
| jamielennox | reaperhulk: never did | 01:52 |
| reaperhulk | :D | 01:52 |
| *** zz_dimtruck is now known as dimtruck | 01:52 | |
| rm_you | reaperhulk: so, barbican does just return strings, right? | 01:52 |
| rm_you | reaperhulk: even if it's octet-stream, it's returning a base64 STRING | 01:52 |
| rm_you | it's just a type-hint for the contents of the string | 01:52 |
| reaperhulk | We can return raw binary on a get | 01:53 |
| rm_you | hmm | 01:53 |
| rm_you | i would need to test this manually from py3 | 01:53 |
| jamielennox | so when does the secrets.payload return base64 text vs the raw secret bytes? | 01:53 |
| rm_you | at the moment, the barbican server won't make any changes to the data you send it | 01:54 |
| rm_you | so if you send it a base64 string and the content type "octet-stream", then it'll store the string with that content-type in its metadata (it doesn't actually parse the payload) | 01:55 |
| rm_you | then when you ask for it back, you ask for the payload by content-type, but it still just returns whatever you passed in, bit-for-bit | 01:55 |
| rm_you | (that is going to change with the content-types work being done now, re: the CR linked earlier) | 01:55 |
| rm_you | reaperhulk: correct me if i'm wrong here | 01:55 |
| jamielennox | ok, so currently on python 3 you would have to assume that this is all text | 01:55 |
| jamielennox | because if you were to pass bytes to the create function then the json serialization would fail | 01:56 |
| rm_you | i believe so | 01:56 |
| reaperhulk | rm_you: do a two step store (post/put) and you can store a binary payload. I believe you can also do it in one step by providing it base64 encoded with the right content types. | 01:56 |
| jamielennox | unfortunately that means we should string decode the raw data on response | 01:56 |
| reaperhulk | woodster_ would know better than me though | 01:56 |
| reaperhulk | I don't look at the Barbican api very often. Mostly just the crypto parts | 01:57 |
| rm_you | <_< | 01:57 |
| rm_you | I am not actually working *on Barbican*, I'm LBaaS :P | 01:57 |
| rm_you | so I keep leaving the Barbican world for a few weeks, coming back, and trying to remember all these specific interactions <_< | 01:58 |
| rm_you | it takes me a bit to recall everything | 01:58 |
| rm_you | redrobot would also probably be able to answer | 01:58 |
| jamielennox | it's not an easy answer - this migration problem is the primary reason py3 has struggled | 02:00 |
| jamielennox | IMO | 02:00 |
| rm_you | hmm | 02:01 |
| rm_you | where are you, BTW? is it still work hours in your timezone? :P | 02:01 |
| *** sigmavirus24 is now known as sigmavirus24_awa | 02:03 | |
| jamielennox | rm_you: brisbane, australia - so started up again - which means you should probably have finished by now | 02:08 |
| rm_you | heh | 02:08 |
| rm_you | yeah i've been eating dinner while typing :P | 02:08 |
| *** sigmavirus24_awa is now known as sigmavirus24 | 02:28 | |
| *** ryanpetrello has quit IRC | 02:29 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 02:44 | |
| *** woodster_ has quit IRC | 03:32 | |
| *** woodster_ has joined #openstack-barbican | 03:44 | |
| *** woodster_ has quit IRC | 03:52 | |
| *** ryanpetrello has joined #openstack-barbican | 03:59 | |
| *** woodster_ has joined #openstack-barbican | 04:11 | |
| *** ryanpetrello has quit IRC | 04:15 | |
| *** lisaclark1 has quit IRC | 04:54 | |
| *** dimtruck is now known as zz_dimtruck | 04:56 | |
| *** woodster_ has quit IRC | 05:20 | |
| *** jaosorior has joined #openstack-barbican | 06:05 | |
| jaosorior | jamielennox: ping | 06:06 |
| *** jamielennox is now known as jamielennox|away | 06:25 | |
| *** bdpayne has quit IRC | 06:54 | |
| *** chlong has quit IRC | 07:46 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Refactor order validation https://review.openstack.org/148900 | 11:59 |
| *** jamielennox|away is now known as jamielennox | 12:01 | |
| *** chlong has joined #openstack-barbican | 12:03 | |
| openstackgerrit | Merged openstack/python-barbicanclient: Replace httpretty with requests_mock https://review.openstack.org/148446 | 12:43 |
| *** ryanpetrello has joined #openstack-barbican | 13:10 | |
| *** zz_dimtruck is now known as dimtruck | 13:11 | |
| *** jamielennox is now known as jamielennox|away | 13:21 | |
| *** darrenmoffat has quit IRC | 13:35 | |
| *** darrenmoffat has joined #openstack-barbican | 13:36 | |
| *** elmiko has quit IRC | 13:41 | |
| *** elmiko has joined #openstack-barbican | 13:47 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 13:48 | |
| *** samueldmq-away has quit IRC | 13:55 | |
| *** lisaclark1 has joined #openstack-barbican | 14:03 | |
| *** samueldmq-away has joined #openstack-barbican | 14:06 | |
| *** lisaclark1 has quit IRC | 14:24 | |
| *** woodster_ has joined #openstack-barbican | 14:26 | |
| *** lisaclark1 has joined #openstack-barbican | 14:30 | |
| jaosorior | woodster_: ping | 14:39 |
| woodster_ | jaosorior: good morning | 14:41 |
| jaosorior | good morning sir | 14:42 |
| jaosorior | how's it going over there? | 14:42 |
| jaosorior | I replied to your comment in this CR https://review.openstack.org/#/c/125516/ and also made this CR https://review.openstack.org/#/c/148900/ since I thought refactoring would be worth being separate from the bug fix | 14:43 |
| jaosorior | what so you think? | 14:43 |
| jaosorior | *do | 14:43 |
| woodster_ | jaosorior: that looks good, thanks! | 14:48 |
| *** lisaclark1 has quit IRC | 14:49 | |
| openstackgerrit | Tim Kelsey proposed openstack/barbican-specs: Adding spec for Barbican MKEK Model. https://review.openstack.org/148948 | 14:51 |
| openstackgerrit | Tim Kelsey proposed openstack/barbican-specs: Adding spec for Barbican MKEK Model. https://review.openstack.org/148948 | 14:52 |
| *** lisaclark1 has joined #openstack-barbican | 14:55 | |
| *** paul_glass has joined #openstack-barbican | 15:12 | |
| *** lisaclark1 has quit IRC | 15:19 | |
| *** ayoung has joined #openstack-barbican | 15:21 | |
| *** rellerreller has joined #openstack-barbican | 15:27 | |
| *** tkelsey has joined #openstack-barbican | 15:28 | |
| *** lisaclark1 has joined #openstack-barbican | 15:29 | |
| alee | rm_work, ping | 15:30 |
| *** SheenaG1 has joined #openstack-barbican | 15:30 | |
| openstackgerrit | Steve Heyman proposed openstack/barbican: ** DO NOT MERGE ** https://review.openstack.org/146608 | 15:35 |
| *** atiwari has joined #openstack-barbican | 15:39 | |
| *** dave-mccowan has joined #openstack-barbican | 16:00 | |
| SheenaG1 | rellerreller: you around this AM? | 16:10 |
| dave-mccowan | alee, ping | 16:11 |
| rellerreller | SheenaG1 what's up? | 16:11 |
| alee | dave-mccowan, pong | 16:11 |
| SheenaG1 | rellerreller: I know I'm out of the loop for asking, but where is the Nova/Cinder patch? Did it land? | 16:11 |
| rellerreller | SheenaG1 Which patch are you talking about? | 16:12 |
| dave-mccowan | i working on the validators now. using some standard libraries would obviously be the best way to go. is there a process for choosing libraries to add, such as for ldap or ssl with methods for parsing the fields? | 16:13 |
| alee | dave-mccowan, I would make sure that whatever you use is in the global requirements | 16:15 |
| *** atiwari has quit IRC | 16:15 | |
| SheenaG1 | rellerreller: no idea on the number, did you guys have multiple outstanding? | 16:15 |
| *** atiwari has joined #openstack-barbican | 16:15 | |
| SheenaG1 | rellerreller: for whatever reason, I thought there was one patch that enabled Nova to talk to an encrypted Cinder block | 16:15 |
| rellerreller | SheenaG1 We have pushed several things to Cinder and Nova. | 16:15 |
| SheenaG1 | rellerreller: sweet - so if I wanted to have an encrypted Cinder block that transparently talked to Nova and stored the encryption keys in Barbican, is that possible? | 16:16 |
| rellerreller | One of the things we had accepted was the KeyManager interface | 16:16 |
| alee | dave-mccowan, it might make sense for you to propose a library and discuss it here. certainly reaperhulk will have some preferences no doubt | 16:16 |
| rellerreller | SheenaG1 Yes you can | 16:17 |
| alee | reaperhulk, ping | 16:17 |
| SheenaG1 | rellerreller: hot damn. That's excellent news. | 16:17 |
| SheenaG1 | alee: reaperhulk is in all day meetings today and tomorrow | 16:17 |
| rellerreller | SheenaG1 jcoffman had a presentation at the last couple of summits on that | 16:17 |
| alee | SheenaG1, ok thanks | 16:17 |
| SheenaG1 | rellerreller: would have been nice to be there.... grumble grumble. | 16:18 |
| rellerreller | SheenaG1 Here is a link to one of joel's talks -- https://www.youtube.com/watch?v=cYk0aoKzgmE | 16:18 |
| SheenaG1 | rellerreller: thanks sir | 16:19 |
| rellerreller | SheenaG1 I hear ya. It is not easy to get funding to attend those events :( | 16:19 |
| SheenaG1 | rellerreller: no, it's not - at least my devs got to attend! | 16:19 |
| rellerreller | There is another presentation he gave that is a demo. Let me try to find that real quick. | 16:19 |
| rm_work | alee: delayed pong | 16:21 |
| rellerreller | SheenaG1 check out this presentation as well, https://www.youtube.com/watch?v=9ccT_BFuzjE | 16:21 |
| alee | rm_work, hey - so you going to get some time to work on per-secret stuff? | 16:21 |
| rm_work | alee: i will find out tomorrow | 16:21 |
| rm_work | sprint planning meeting | 16:21 |
| dave-mccowan | alee, reaperhulk: For certificate orders, we need some methods to parse and validate parameters like asn1 and distinguished names. Crypto.Util and ldap.dn are two used by keystone. Any objections to pulling those into Barbican? | 16:21 |
| rellerreller | SheenaG1 That should give you the details on how it works, and a demo of it working. If you have any questions let us know. We can help with whatever. | 16:22 |
| alee | rm_work, ok - let me know if you need anything to bolster your case. | 16:22 |
| rm_work | it depends on what else comes down the pipe | 16:22 |
| alee | (as always) | 16:22 |
| SheenaG1 | rellerreller: thanks again sir! | 16:22 |
| rm_work | It is *required* to be working for our use-case, so I should have some decent ammo | 16:22 |
| alee | cool | 16:22 |
| SheenaG1 | rm_work: I think *required* is debatable, but I certainly don't mind you implementing it... | 16:23 |
| rm_work | SheenaG1: welllll | 16:23 |
| SheenaG1 | Hahahahaha | 16:23 |
| rm_work | if it isn't implemented, we'd need god-mode in Barbican | 16:23 |
| rm_work | if you think that's a legit option then it's "optional" | 16:24 |
| rm_work | i hope that doesn't happen :) | 16:25 |
| SheenaG1 | rm_work: agreed - certainly preferable not to | 16:26 |
| *** atiwari has quit IRC | 16:29 | |
| openstackgerrit | Venkat Sundaram proposed openstack/barbican-specs: Add Quota support for Barbican resources https://review.openstack.org/132091 | 16:36 |
| alee | dave-mccowan, I have no objections to those | 16:38 |
| woodster_ | rellerreller, I didn't think the cinder/nova patches had landed yet for some reason, but they did afterall? | 16:38 |
| alee | dave-mccowan, just confirm that its on the global requirements list | 16:38 |
| alee | woodster_, you in the same meeting with reaperhulk ? | 16:39 |
| rellerreller | woodster_ That stuff has been in there for a long time. | 16:39 |
| reaperhulk | Dave-mccowan: I'm in meetings today but why are you needing to directly validate asn.1? Also, the next release of cryptography will do DN parsing | 16:40 |
| alee | reaperhulk, I want to generate a csr -- what should I use? | 16:40 |
| alee | reaperhulk, or will that be in the next version of cryptography? | 16:41 |
| alee | reaperhulk, dave-mccowan wants to validate requests coming in to confirm that they are valid cmc requests -- | 16:42 |
| reaperhulk | It all sucks right now. I would love it to be in the next cryptography release but probably not. Maybe pyopenssl right now | 16:42 |
| reaperhulk | Pyasn1 may be a good option for that if you can define the shape of a request declaratively | 16:42 |
| alee | reaperhulk, that they include for instance subjectdn and key usage attributes | 16:43 |
| alee | dave-mccowan, ^^ | 16:43 |
| woodster_ | rellerreller, ha, sorry I'm trying to recall from Paris discussions and thought I heard that they hadn't landed yet for some reason | 16:44 |
| alee | dave-mccowan, pyopenssl and pyasn1 work for you? | 16:44 |
| openstackgerrit | Steve Heyman proposed openstack/barbican: ** DO NOT MERGE ** https://review.openstack.org/146608 | 16:46 |
| rellerreller | woodster_ We are always trying to add more features. Like we have been working on ephemeral encryption for a long time and that has been difficult to get in. We do have support for the LVM backend of ephemeral encryption but would like to support all types. | 16:46 |
| woodster_ | rellerreller, yeah I need to dig deeper on these integration efforts with barbican, not so much heads down in the coding :) | 16:57 |
| woodster_ | alee, is are you generating the csr for the stored-key order mode? | 16:58 |
| alee | woodster_, yes | 16:58 |
| woodster_ | alee, nice! | 16:58 |
| alee | woodster_, hoping to get to that patch this week. but the identifying ca patches are taking a little longer than I expected. | 16:59 |
| woodster_ | alee, rm_work, rellereller, reaperhulk, btw, after discussion with rm_work yesterday on the per-secret RBAC, I added a cover comment question that would be good to answer if folks have the time: https://review.openstack.org/#/c/127353/ | 17:00 |
| alee | woodster_, feel free to take a look at the ones out there though :) | 17:00 |
| rm_work | i'll look after loonch | 17:00 |
| woodster_ | alee, my union only allows me to look at 2 CRs per day, sorry! | 17:02 |
| *** rellerreller has quit IRC | 17:03 | |
| alee | woodster_, interesting question -- I'm not sure I have any strong feeling either way yet -- I'll wait to see what others indicate. | 17:03 |
| alee | jvrbanac and redrobot might have opinions on this. | 17:03 |
| redrobot | alee ohai! | 17:03 |
| alee | woodster_, just for you, I can squash all the CRs into one nice big one :) | 17:04 |
| alee | ohai -- figured you might have an opinion on woodster_ question above | 17:04 |
| woodster_ | alee, death by Uber CR!! | 17:07 |
| openstackgerrit | Brianna Poulos proposed openstack/castellan: Copy cinder.keymgr to castellan https://review.openstack.org/148742 | 17:08 |
| *** atiwari has joined #openstack-barbican | 17:14 | |
| *** samueldmq-away is now known as samueldmq | 17:19 | |
| openstackgerrit | Venkat Sundaram proposed openstack/barbican-specs: Add Quota support for Barbican resources https://review.openstack.org/132091 | 17:21 |
| *** jkf has joined #openstack-barbican | 17:25 | |
| alee | woodster_, ping | 17:26 |
| alee | woodster_, I have an implementation question. When we go issue a cert request, we will go through some logic to determine which ca we will send the request to. | 17:28 |
| woodster_ | alee, yep | 17:28 |
| alee | woodster_, and as a plugin might support multiple ca's, we need to communicate the selected ca to the plugin in the issue_certificate_request() call | 17:29 |
| alee | woodster_, now -- there are a couple ways of doing this .. | 17:29 |
| alee | 1. add an argument plugin_ca_id=None to the issue_cert_request() call | 17:29 |
| woodster_ | alee, I'd say that is needed for all the cert plugin calls btw | 17:29 |
| alee | yes | 17:30 |
| *** tkelsey has quit IRC | 17:30 | |
| alee | 2) add the plugin_ca_id to the order_metadata | 17:30 |
| alee | 2 has the advantage of not having to change the interface, but it means adding some metadata that was not in the original request | 17:30 |
| alee | 1 means an interface change | 17:31 |
| alee | (which is not so bad as its in the backend) | 17:31 |
| woodster_ | alee, doesn't the client have to specify which ca to use in their request? | 17:31 |
| alee | woodster_, they can - but they dont have to | 17:31 |
| woodster_ | alee, ah got it, so the project and so forth defaults can kick in | 17:32 |
| alee | and the ca_id they specify is not the same as the plugin_ca_id | 17:32 |
| *** lisaclark2 has joined #openstack-barbican | 17:32 | |
| *** lisaclark2 has quit IRC | 17:32 | |
| alee | yup | 17:32 |
| woodster_ | alee, yeah I'd say 1) is better as it is determined internal to barbican and should be segregated from client provided information | 17:32 |
| alee | woodster_, ok agreed | 17:33 |
| woodster_ | alee, I'd want to avoid any possiblity of that modified meta being mistaken for what the client provided | 17:33 |
| *** lisaclark2 has joined #openstack-barbican | 17:33 | |
| *** lisaclark2 has quit IRC | 17:33 | |
| alee | yup - we'll just have to make sure all ca plugin implementers fix their plugins | 17:33 |
| *** lisaclark2 has joined #openstack-barbican | 17:34 | |
| alee | which right now should be pretty easy :/ | 17:34 |
| *** SheenaG1 has quit IRC | 17:34 | |
| *** lisaclark1 has quit IRC | 17:34 | |
| woodster_ | alee, I think so | 17:34 |
| alee | woodster_, in the future though, this would be harder I think | 17:34 |
| alee | woodster_, what about adding another field like barbican_meta - which would be a dict of barbican added values? | 17:35 |
| woodster_ | alee, well, esp. if we have a plugin marketplace up and running like we proposed in Paris | 17:35 |
| alee | rather than just the plugin_ca_id .. that way if we need to make a change like this in future - then we can do so without breaking the interface | 17:36 |
| dave-mccowan | alee, pyopenssl and pyasn1 should work for me. i'll give them a try. | 17:37 |
| alee | woodster_, ? | 17:38 |
| alee | dave-mccowan, cool | 17:38 |
| woodster_ | alee, that could be a good thing to do though I could see some folks complaining about an overly generic interface. I think it makes sense though, like a context object that has system info available in it | 17:44 |
| alee | woodster_, ok cool - I'll add in the next CR then -- preference on variable name? | 17:45 |
| alee | barbican_meta? | 17:45 |
| woodster_ | alee that sounds good to me | 17:45 |
| alee | ok thanks | 17:46 |
| woodster_ | alee... _meta all the things! | 17:46 |
| alee | :) | 17:46 |
| alee | woodster_, in the case of the stored-key implementation, does it make sense to put the csr in the barbican_meta dict, rather than the order_meta -- as it was not part of the original request? | 17:51 |
| woodster_ | alee...hmmm...yeah, that makes sense actually. | 17:51 |
| alee | woodster_, cool - that was bugging me at the back of my mind | 17:52 |
| woodster_ | alee, yeah it's hard to think thru all of these details at BP time...the bp should really be pointing you in the right directly, but agile takes over to fill in the details | 17:53 |
| alee | yup | 17:54 |
| *** jkf has quit IRC | 17:56 | |
| *** jkf has joined #openstack-barbican | 17:59 | |
| *** atiwari has quit IRC | 17:59 | |
| *** SheenaG1 has joined #openstack-barbican | 18:00 | |
| *** ryanpetrello has quit IRC | 18:23 | |
| *** ryanpetrello_ has joined #openstack-barbican | 18:23 | |
| *** ryanpetrello_ is now known as ryanpetrello | 18:23 | |
| *** ryanpetrello_ has joined #openstack-barbican | 18:30 | |
| *** ryanpetrello has quit IRC | 18:31 | |
| *** ryanpetrello_ is now known as ryanpetrello | 18:31 | |
| *** rellerreller has joined #openstack-barbican | 18:31 | |
| *** ayoung has quit IRC | 18:40 | |
| *** lisaclark2 has quit IRC | 18:48 | |
| openstackgerrit | Steve Heyman proposed openstack/barbican: ** DO NOT MERGE ** https://review.openstack.org/146608 | 18:48 |
| *** lisaclark1 has joined #openstack-barbican | 18:52 | |
| *** lisaclark1 has quit IRC | 18:52 | |
| *** lisaclark1 has joined #openstack-barbican | 18:59 | |
| woodster_ | alee, I'm looking at a bp to add a reissue cert feature to barbican. Ive been thinking a new order type with a link to the generated certificate. The order processing would then use the original cert's info to cut the reissued cert (resulting in a new container/UUID). But we probably have the same choices as a normal cert order, such as providing a new CSR, | 19:01 |
| woodster_ | or having barbican generate it. So maybe better to just allow a normal 'certificate' order to take an optional link to a previous certificate to pull info from it if present? | 19:01 |
| woodster_ | SheenaG1, chellygel: ^^^ | 19:02 |
| SheenaG1 | woodster_: just to be clear, you aren't talking about reusing the original CSR, correct? Either the customer has to supply a new one or Barbican will generate one on their behalf? | 19:10 |
| *** jkf has quit IRC | 19:23 | |
| *** jkf has joined #openstack-barbican | 19:25 | |
| woodster_ | SheenaG1: I believe so. Would there be a use case for reusing the original csr though? | 19:26 |
| SheenaG1 | woodster_: not a good one | 19:26 |
| SheenaG1 | woodster_: I would rather not re-use the CSR ever, just wanted to make sure that wasn't implied somewhere | 19:27 |
| woodster_ | SheenaG1: I've been thinking it is more like a create order/cert process that uses info pulled from the original request | 19:27 |
| SheenaG1 | That would definitely be true in CA-land | 19:28 |
| woodster_ | SheenaG1: cool so I can detail that approach in the blueprint | 19:28 |
| SheenaG1 | woodster_: sounds good to me - in the case of our Symantec CA, the only things that they would really need are a new CSR with the same domain name and access to the e-mail address for the person who originally approved the certificate | 19:29 |
| SheenaG1 | Any other metadata used to create the new CSR/PK pair will be ignored | 19:30 |
| SheenaG1 | But it doesn't hurt to have it be accurate | 19:30 |
| chellygel | catching up woodster_ | 19:30 |
| chellygel | 2 secs | 19:30 |
| chellygel | i dont know why i bothered, since sheena responded :P | 19:31 |
| SheenaG1 | Oy! | 19:32 |
| chellygel | but that makes sense to me. | 19:32 |
| SheenaG1 | You look too. | 19:32 |
| SheenaG1 | I catch the dumb all the time. | 19:32 |
| chellygel | im too busy looking at the confetti on my desk! | 19:32 |
| jvrbanac | :P | 19:35 |
| woodster_ | chellygel: it is overwhelming! | 19:47 |
| woodster_ | chellygel: nice TV too | 19:47 |
| chellygel | right?? | 19:48 |
| chellygel | i should've made a ake | 19:48 |
| chellygel | i forgot my rack-versary was today] | 19:48 |
| chellygel | ake => cake | 19:48 |
| *** lisaclark1 has quit IRC | 19:57 | |
| woodster_ | SheenaG1: chellygel so ok to ignore info provided in the reissue that is provided in the previous order? | 19:58 |
| woodster_ | ...or maybe better to error out if doesn't match? | 19:59 |
| SheenaG1 | I would not allow for someone to provide information for a reissue | 20:00 |
| SheenaG1 | It has to be info from the old order only | 20:00 |
| *** crc32 has joined #openstack-barbican | 20:12 | |
| woodster_ | SheenaG1: alee so only the csr and stored key certificate order modes should be supported then | 20:16 |
| SheenaG1 | sorry, not sure what that mean? | 20:18 |
| SheenaG1 | meant* | 20:18 |
| SheenaG1 | Can you dumb it down a bit? | 20:18 |
| alee | woodster_, sounds reasonable to me. dogtag has a couple other modes to renew certs, but they are probably not standard for ca's | 20:19 |
| alee | SheenaG1, I think woodster_ means that we can reissue with the client providing a new csr or with barbican generating a new one. | 20:20 |
| *** lisaclark1 has joined #openstack-barbican | 20:21 | |
| openstackgerrit | Steve Heyman proposed openstack/barbican: ** DO NOT MERGE ** https://review.openstack.org/146608 | 20:21 |
| alee | woodster_, in the other modes supported by dogtag, a client can present the cert itself (doing client auth to verify possession of the public key) - the details are then taken from the original csr which is stored by dogtag | 20:22 |
| alee | this allows an automatically approved self-renewal | 20:22 |
| alee | that might actually be an option that the dogtag plugin could provide under the covers -- | 20:23 |
| alee | another mode it accepts is presenting the same csr | 20:24 |
| openstackgerrit | Venkat Sundaram proposed openstack/barbican-specs: Add Quota support for Barbican resources https://review.openstack.org/132091 | 20:25 |
| SheenaG1 | Ah, yes - thanks ale | 20:25 |
| SheenaG1 | alee | 20:25 |
| chellygel | alee, why would you accept the same CSR? maybe i misunderstand, but isn't the point to rotate out the private key | 20:26 |
| chellygel | to ensure its 'secure' | 20:26 |
| alee | chellygel, I understand reissuing a cert as being something like renewing a cert for instance. | 20:27 |
| alee | not in the sense of just providing a brand new request | 20:27 |
| chellygel | if a certificate expires, and you want a reissue -- lets say? | 20:28 |
| chellygel | right? | 20:28 |
| alee | renewing a cert using the same private/public key pair is what many people like to do. | 20:28 |
| alee | chellygel, if you change out the key pair, thats just like generating a brand new request | 20:29 |
| chellygel | hmmk | 20:30 |
| alee | chellygel, for example, you use a pki key pair to encrypt your email. | 20:31 |
| alee | if you change out the public/private key pair, you are no longer able to decrypt the email | 20:31 |
| alee | chellygel, https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Renewing_Certificates.html#about-renewal | 20:36 |
| *** bdpayne has joined #openstack-barbican | 20:37 | |
| *** rellerreller has quit IRC | 21:20 | |
| *** samueldmq is now known as samueldmq-away | 21:20 | |
| woodster_ | alee, so if one POSTed a certificate order as normal, but included a ref to an existing certificate container via UUID, then I would expect barbican to work with the CA to generate a new certificate, but using info from that original cert/order. | 21:23 |
| reaperhulk | Reuse of an existing private key is bad practice on renewal. Several CAs actually detect and reject that sort of behavior (provided you are a previous customer with them of course) | 21:24 |
| *** lisaclark1 has quit IRC | 21:28 | |
| rm_work | reaperhulk: interesting, did not know that | 21:31 |
| SheenaG1 | reaperhulk: are you ignoring the GLO or did they let you out to run amok? | 21:32 |
| reaperhulk | In it right now. Occasionally chatting on phone | 21:32 |
| *** david-lyle has joined #openstack-barbican | 21:46 | |
| alee | reaperhulk, I think thats debatable - sometimes people like to re-issue (as opposed to re-key) because of things like encrypted mail. | 21:49 |
| alee | reaperhulk, naturally, the longer a private key is out there, the more likely it is to be compromised | 21:49 |
| alee | woodster_, we'd have to figure out how we wanted to design it. as reaperhulk said, not all ca's may support key reuse. | 21:52 |
| alee | woodster_, I think having the option to request it is a good idea. | 21:52 |
| *** dave-mccowan has quit IRC | 21:53 | |
| *** sigmavirus24 has left #openstack-barbican | 21:55 | |
| rm_work | hey redrobot or woodster_ or anyone really, do you have a good gerrit dashboard trick to show reviews that are ready for you to look at (not WIP, not V-1) but that you haven't yet commented on? | 21:59 |
| rm_work | or anything else you have found to be useful for that kind of dashboard | 21:59 |
| *** chlong has quit IRC | 22:05 | |
| *** david-lyle has quit IRC | 22:11 | |
| *** david-lyle has joined #openstack-barbican | 22:11 | |
| *** david-lyle has quit IRC | 22:15 | |
| *** lisaclark1 has joined #openstack-barbican | 22:16 | |
| *** lisaclark1 has quit IRC | 22:20 | |
| *** SheenaG1 has quit IRC | 22:26 | |
| *** lisaclark1 has joined #openstack-barbican | 22:26 | |
| *** lisaclark1 has quit IRC | 22:29 | |
| *** lisaclark1 has joined #openstack-barbican | 22:29 | |
| woodster_ | rm_work, this view kindof sort of does this: https://review.openstack.org/#/ | 22:31 |
| rm_work | hmm | 22:34 |
| rm_work | project:stackforge/octavia is:open NOT label:Workflow-1 NOT label:Review>0,user=flux.adam@gmail.com | 22:34 |
| rm_work | ^^ that is what I am currently trying to use | 22:34 |
| *** jaosorior has quit IRC | 22:34 | |
| rm_work | but the last part doesn't actually work | 22:34 |
| woodster_ | alee: I see this as well for renewals/reissues: https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System_Common_Criteria_Certification/8.1/html/Deploy_and_Install_Guide/renewing-ca-certs.html | 22:34 |
| rm_work | it's supposed to cut out reviews I've put at least a +1/+2 on | 22:35 |
| woodster_ | rm_work: sounds...verbose. jvrbanac is working with the API to generate that daily list we see...maybe making your own query would be easier? :) | 22:36 |
| jvrbanac | woodster_, ? | 22:37 |
| jvrbanac | woodster_, rm_work, are y'all talking about: https://github.com/jmvrbanac/jmv-random-scripts/blob/master/send_gerrit_summary.py | 22:38 |
| woodster_ | jvrbanac, ^^^ regarding your API work with gerrit to produce the daily list of CRs you email out. | 22:38 |
| alee | woodster_, that has to do with CA signing certs -- thats a whole different box of wax | 22:38 |
| alee | ball of wax | 22:38 |
| woodster_ | alee, oh correct, sorry. | 22:38 |
| rm_work | jvrbanac: interesting | 22:40 |
| jvrbanac | rm_work, so that script is a quick and dirty cli script that pulls the data off of gerrit and sends it to people via mailgun | 22:41 |
| rm_work | cool | 22:41 |
| *** ryanpetrello has quit IRC | 22:51 | |
| alee | woodster_, ping | 22:53 |
| woodster_ | alee, hey | 22:53 |
| alee | woodster_, question about validators .. | 22:53 |
| alee | so one thing I was thinking about doing was adding a test to confirm that a client passed in ca_id actually corresponds to a valid ca | 22:54 |
| alee | and that -- if a project has project_ca's defined, that the ca is one of them | 22:54 |
| alee | I thought I would do that in the validator | 22:55 |
| alee | but this means that I need to pass in repos for ca_repo and project_ca_repo | 22:55 |
| alee | which is fine in itself I guess , I also need to pass in the project_id for the request | 22:56 |
| woodster_ | alee, looking at the red hat docs and projecting to Barbican, it seems that a renewal might be expected to overwrite the cert that is renewed...i.e. the UUID of the cert container wouldn't change, but the expiration date would move out. So it seems a reissue workflow (with new pk/csr) is a better fit for the barbican immutable way of doing things. | 22:57 |
| alee | woodster_, before I head down the dark tunnel of figuring out how to pass all that stuff in -- does it make sense to do all this in validators? | 22:57 |
| *** david-lyle has joined #openstack-barbican | 22:58 | |
| woodster_ | alee, yeah, validators have been static so far | 22:58 |
| alee | I can do all this outside of validators if it makes sense to do that .. | 22:58 |
| alee | woodster_, maybe I should do that so that I'm not changing absolutely everything | 23:00 |
| woodster_ | alee, I think it does for the time being, though that adds biz logic to the controllers. That isn't a bad place for that to be, but we are talking about a lot of lines of logic, that is still probably better to do in the common.validators.py module, just not associated with a ValidatorBase sub-class, but maybe a first class function that the controller calls | 23:01 |
| woodster_ | off to? | 23:01 |
| woodster_ | alee, my personal pref is for the controllers to be as brief as possible...just doing synchronous-side orchestration | 23:02 |
| alee | woodster_, well the advantage of doing the validation then is that the user immediately gets feedback that the parameter they have specified is bad | 23:03 |
| woodster_ | alee, putting validation logic in the validators.py...even if you are just passing in models to a function...still seems better and easier to test. | 23:03 |
| alee | rather than checking once the request is in the request queue. | 23:03 |
| woodster_ | alee, you are still doing the validation, but just not in the static/type validators (that extend ValidatorBase), but rather validation functions that the controller calls | 23:03 |
| woodster_ | alee, and if all of that is in the validators.py module, we can revisit that later to see if it makes sense to have the static validators do that instead | 23:04 |
| alee | woodster_, take a look at validators.py right now .. | 23:05 |
| woodster_ | so controllers would call the load-body validator thing first, and then call the validators.do_model_validation_thingster(my_model) | 23:05 |
| alee | ok | 23:06 |
| woodster_ | alee, it mainly has class definitions, but is also (at the top) has some first class functions carved out | 23:06 |
| alee | woodster_, so just to be clear -- there are some functions that I carved out before in validators() | 23:06 |
| alee | _validate_pkcs10_data() <- should stay in static validator? | 23:07 |
| alee | _validate_full_cmc_data() ? | 23:07 |
| alee | _validate_subject_dn_data() > | 23:08 |
| alee | ? | 23:08 |
| woodster_ | alee, that makes sense to me...but if _validate_xxxx is called from outside validators.py, you'd just remove that '_' | 23:08 |
| alee | _validate_extensions_data() | 23:08 |
| alee | but what about _validate_certificate_container() ? | 23:08 |
| alee | seems to me that this one needs to be outside of the static validator then? | 23:09 |
| woodster_ | alee, if this module gets too unruly, then you could create a 'validators' sub-package | 23:09 |
| *** david-lyle has quit IRC | 23:09 | |
| woodster_ | alee, yeah, I'd say if you need validation that doesn't 'fit' within the no-arg load_body() approach now, you'd want to make a standalone function def for it, but still in the validators.py module | 23:10 |
| alee | woodster_, this module is already pretty unruly and needs to be refactored -- but I'm trying avoid that in this CR. | 23:10 |
| alee | woodster_, ok - thats what I'll do then | 23:10 |
| alee | and we can revisit how the validators should look after that. | 23:10 |
| alee | back to your question then .. | 23:11 |
| alee | a renewal always results in a new cert being created | 23:11 |
| alee | with a new serial number | 23:11 |
| alee | so you'd need a new container .. | 23:12 |
| woodster_ | alee, that sounds good. Just noting also that we did start an effort to make singleton accessors for the repositories, but that was not completed I believe. | 23:12 |
| alee | but that does not translate into new keys per se | 23:12 |
| alee | it may be valuable to have the option of reusing the old keys | 23:13 |
| alee | and just create a new container with references to the old keys and a new cert | 23:13 |
| *** paul_glass has quit IRC | 23:14 | |
| woodster_ | alee, chellygel, hmmm. So some choices are to send POST a 'certificate' order with a container_ref attached implying a renewal/reissue. If by itself with no other info, then we have a renewal situation (reuse all of the original cert's info, including it's private key if it was originally a stored key order, etc.) | 23:16 |
| *** lisaclark1 has quit IRC | 23:17 | |
| woodster_ | alee, chellygel ...or we could introduce a new order type, like 'certificate_renewal'. | 23:17 |
| alee | woodster_, thats probably what we's need to do -- a new order type | 23:19 |
| alee | woodster_, being called to dinner | 23:19 |
| *** alee is now known as alee_dinner | 23:19 | |
| *** jkf has quit IRC | 23:22 | |
| *** lisaclark1 has joined #openstack-barbican | 23:23 | |
| *** jamielennox|away is now known as jamielennox | 23:27 | |
| *** chlong has joined #openstack-barbican | 23:34 | |
| *** SheenaG1 has joined #openstack-barbican | 23:40 | |
| *** lisaclark1 has quit IRC | 23:51 | |
| *** lisaclark1 has joined #openstack-barbican | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!