*** kebray has quit IRC | 00:01 | |
*** kebray has joined #openstack-barbican | 00:03 | |
openstackgerrit | John Vrbanac proposed openstack/python-barbicanclient: Fixing the broken functional tests https://review.openstack.org/171465 | 00:03 |
---|---|---|
openstackgerrit | Dave McCowan proposed openstack/barbican: Add Bandit security static analysis checking via tox https://review.openstack.org/171893 | 00:24 |
*** chlong has joined #openstack-barbican | 00:25 | |
*** SheenaG has joined #openstack-barbican | 01:03 | |
*** crc32 has quit IRC | 01:14 | |
*** SheenaG has left #openstack-barbican | 01:16 | |
*** alee has quit IRC | 01:19 | |
*** kfarr has quit IRC | 01:29 | |
*** alee has joined #openstack-barbican | 01:31 | |
*** rm_you| has quit IRC | 03:11 | |
*** kebray has quit IRC | 03:21 | |
openstackgerrit | Douglas Mendizábal proposed openstack/barbican: Document public secret type https://review.openstack.org/171859 | 03:22 |
openstackgerrit | Kaitlin Farr proposed openstack/castellan: Add Barbican key manager https://review.openstack.org/171918 | 03:22 |
*** gyee has quit IRC | 03:27 | |
openstackgerrit | Douglas Mendizábal proposed openstack/barbican: Document public secret type https://review.openstack.org/171859 | 03:27 |
*** dave-mccowan has quit IRC | 03:40 | |
*** kebray has joined #openstack-barbican | 03:54 | |
woodster_ | alee, are you there? | 03:57 |
alee | woodster_, whats up? | 04:04 |
woodster_ | alee, the retry process is running right in devstack now, but my sample test fails because the dogtag plugin is installed, not the simple one. :\ | 04:08 |
woodster_ | alee, can I make a request that just runs the simple cert plugin for the order request? Via the ca_id feature now | 04:09 |
woodster_ | ? | 04:09 |
alee | woodster_, really? I'd be very surprised that the dogtag plugin was installed | 04:09 |
alee | didn't think redrobot got that working | 04:09 |
alee | are you sure the dogtag plugin is being called? | 04:10 |
woodster_ | This function (https://github.com/openstack/barbican/blob/master/contrib/devstack/lib/barbican#L70) is invoked from here (https://github.com/openstack/barbican/blob/master/contrib/devstack/extras.d/70-barbican.sh#L16) | 04:11 |
woodster_ | ...I think | 04:11 |
alee | woodster_, by the way, feel free to +2 https://review.openstack.org/#/c/169600/3 | 04:11 |
alee | woodster_, right -- is that parameter set? | 04:12 |
alee | woodster_, do you have logs indicating the failure? | 04:12 |
woodster_ | I see the test fail expecting ACTIVE, I see the retry service runs during the time but never sees a retry task, and I don't see a log indicating a task needs to be retried. | 04:15 |
alee | woodster_, what does the status indicate instead of ACTIVE? PENDING? | 04:16 |
alee | woodster_, do you see any of the dogtag tests runnning? | 04:16 |
alee | there are a whole slew of tests there that only run with dogtag | 04:17 |
woodster_ | so those are skipped then? | 04:17 |
alee | if dogtag is not there yes .. | 04:17 |
alee | so check to see what is run .. | 04:18 |
alee | that will tell you if dogtag is there | 04:18 |
alee | woodster_, regardless though, at some point dogtag will be there -- and so the test needs to work even in the presence of dogtag | 04:18 |
alee | woodster_, thats easy enough to do. | 04:19 |
woodster_ | yep, they appear to be skipped due to no dogtag import | 04:19 |
woodster_ | yeah, the ca_id still will need to be used for reals when we have both plugins there! | 04:19 |
alee | woodster_, ok - so no dogtag | 04:19 |
alee | woodster_, see get_dogtag_ca_id() in test_certificate_orders.py | 04:20 |
woodster_ | yeah, so has to be using the default plugin, not sure why it fails out in devstack and runs on my machine | 04:20 |
alee | is the order created and in pending state? | 04:21 |
alee | if so, then something went wrong with setting up the workers most likely | 04:21 |
alee | if the order is not created, you have bigger problems | 04:22 |
woodster_ | oh, in logs too: | 04:22 |
woodster_ | https://www.irccloud.com/pastebin/gOW0k77V | 04:22 |
alee | yup | 04:22 |
*** alee is now known as alee_zzz | 04:31 | |
*** chlong has quit IRC | 05:09 | |
openstackgerrit | John Wood proposed openstack/barbican: Add retry server and functional tests to DevStack https://review.openstack.org/170896 | 05:48 |
*** jamielennox is now known as jamielennox|away | 08:01 | |
*** kebray has quit IRC | 08:02 | |
*** woodster_ has quit IRC | 08:10 | |
*** gitorres1 has quit IRC | 08:46 | |
*** gitorres has joined #openstack-barbican | 08:48 | |
openstackgerrit | Thomas Herve proposed openstack/python-barbicanclient: Fix order listing on the command line. https://review.openstack.org/169481 | 09:42 |
*** darrenmoffat has quit IRC | 10:22 | |
*** darrenmoffat has joined #openstack-barbican | 10:23 | |
*** jaosorior has joined #openstack-barbican | 10:31 | |
*** jamielennox|away is now known as jamielennox | 10:42 | |
*** woodster_ has joined #openstack-barbican | 11:49 | |
*** jamielennox is now known as jamielennox|away | 11:53 | |
*** alee_zzz has quit IRC | 12:19 | |
*** dave-mccowan has joined #openstack-barbican | 12:56 | |
*** alee has joined #openstack-barbican | 13:32 | |
*** dave-mccowan has quit IRC | 13:33 | |
*** dave-mccowan has joined #openstack-barbican | 13:34 | |
*** openstackgerrit has quit IRC | 13:53 | |
*** openstackgerrit has joined #openstack-barbican | 13:53 | |
*** jorge_munoz has quit IRC | 13:54 | |
alee | woodster_, redrobot , jaosorior , any more comments on https://review.openstack.org/#/c/169600 ? I will create another version to address woodster_ comment, but want to make sure there is nothing else. | 14:09 |
alee | redrobot, deadline for rc1 is today? then we need to get this in .. | 14:10 |
jaosorior | alee: no comments from my side | 14:10 |
*** paul_glass has joined #openstack-barbican | 14:10 | |
jaosorior | alee: waiting for the next CR for a +2 | 14:10 |
alee | jaosorior, great - I'll put it up momentarily then .. | 14:11 |
openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Switch to oslo_policy https://review.openstack.org/172071 | 14:13 |
jaosorior | woodster_: ping | 14:16 |
jaosorior | alee, redrobot, woodster_: is it me or we are not using barbican.openstack.common.context at all? | 14:17 |
*** SheenaG has joined #openstack-barbican | 14:17 | |
openstackgerrit | Ade Lee proposed openstack/barbican: Changes to get remaining cert functional tests working https://review.openstack.org/169600 | 14:18 |
alee | jaosorior, woodster_ , redrobot ^^ updated with John's change. Get out those +2's and workflows! | 14:18 |
woodster_ | alee: +2-ed just now | 14:27 |
woodster_ | jaosorior: maybe not, would that be from the middleware? | 14:27 |
alee | woodster_, jaosorior thanks. | 14:27 |
alee | redrobot, can I have a whoop whoop please? | 14:27 |
*** zz_dimtruck is now known as dimtruck | 14:28 | |
jaosorior | woodster_: seems that barbican/context.py is being used instead of the barbican/openstack/common/context.py | 14:28 |
openstackgerrit | John Wood proposed openstack/barbican: Add retry server and functional tests to DevStack https://review.openstack.org/170896 | 14:28 |
jaosorior | woodster_: They seem to do fairly similar things, but the main difference is that barbican/context.py actually adds some roles to the context, while the one in openstack.common doesn't | 14:29 |
woodster_ | jaosorior: would not surprise me, that is ancient code in there I believe. Adds roles? | 14:29 |
jaosorior | woodster_: Adds roles? | 14:30 |
woodster_ | jaosorior: referring to what you mentioned was different between the two | 14:30 |
jaosorior | woodster_: that the 'roles' field in the context is not mentioned whatsoever in the openstack.common.context library | 14:31 |
jaosorior | woodster_: And it's also not used in oslo_context, which is what I actually aimed to switch to | 14:32 |
alee | jvrbanac, hockeynut , redrobot - https://review.openstack.org/#/c/169600/ just needs a workflow please. | 14:32 |
woodster_ | jaosorior: Oh I see. Yeah if the middleware is adding that stuff already, no need in the context | 14:32 |
woodster_ | jaosorior: that should be fine to do then | 14:32 |
alee | dave-mccowan needs that to be merged so he can get his CR rebased on top of that. | 14:32 |
woodster_ | jaosorior: we have a lot of unit testing around roles anyway | 14:32 |
jaosorior | woodster_: well, I'll upload two patches. One deleting the openstack.common.context and another one attempting to use oslo_context | 14:33 |
openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Delete openstack.common.context https://review.openstack.org/172088 | 14:34 |
*** SheenaG has quit IRC | 14:34 | |
*** kebray has joined #openstack-barbican | 14:36 | |
*** everjeje has joined #openstack-barbican | 14:37 | |
openstackgerrit | werner mendizabal proposed openstack/barbican: Create Barbican python scripts for development. https://review.openstack.org/170961 | 14:39 |
openstackgerrit | Thierry Carrez proposed openstack/barbican: Open Liberty development https://review.openstack.org/172106 | 15:01 |
igueths | redrobot: Hey saw you modified the status of bug #1430516 a bit ago, had you planned on taking a look at my CR for that as well? | 15:04 |
openstack | bug 1430516 in Barbican "Potential resource exhaustion when registering consumers to a container" [Medium,In progress] https://launchpad.net/bugs/1430516 - Assigned to Igor Gueths (igor-gueths) | 15:04 |
redrobot | igueths indeed | 15:04 |
igueths | redrobot: Awesome! | 15:05 |
redrobot | igueths I think it would be a good bug to include in the Kilo release | 15:05 |
igueths | redrobot: I agree...What's the current timeline for RC1? | 15:05 |
alee | redrobot, still waiting on that workflow .. | 15:05 |
igueths | Iirc it was coming up pretty fast. | 15:05 |
redrobot | igueths it was supposed to be today, but we still have some outstanding bugs | 15:05 |
igueths | Ah. | 15:05 |
redrobot | alee you're a really good CR pusher. :-P | 15:06 |
redrobot | alee I'll take a look right now | 15:06 |
alee | redrobot, great. I'm hoping we can get dave-mccowan CRs in too - but that means getting mine in first. | 15:07 |
alee | so he can rebase on top of that | 15:07 |
redrobot | alee cool. The release manager was ok with us deferring to next week. | 15:07 |
redrobot | alee but it's definitely better to land these sooner rather than later | 15:08 |
alee | redrobot, ideally today. so you have some basis for your docs/tests on content types | 15:08 |
openstackgerrit | werner mendizabal proposed openstack/barbican: Create Barbican python scripts for development. https://review.openstack.org/170961 | 15:25 |
openstackgerrit | John Vrbanac proposed openstack/barbican: Potential resource exhaustion when registering consumers to containers https://review.openstack.org/170693 | 15:25 |
*** SheenaG has joined #openstack-barbican | 15:26 | |
*** mecoide has joined #openstack-barbican | 15:26 | |
jvrbanac | igueths, I rebased your change as I was concerned that it wouldn't merge due to the existing validate_stored_key_rsa_container function. | 15:28 |
*** mecoide is now known as apodo | 15:29 | |
igueths | jvrbanac: Ah thanks! I've tried to rebase it several times in the past but Gertty was acting strangely so I never knew if the process actually worked. | 15:29 |
*** dave-mccowan has quit IRC | 15:38 | |
*** rellerreller has joined #openstack-barbican | 15:42 | |
jaosorior | what was the agreed format for public keys again? | 15:43 |
*** dimtruck is now known as zz_dimtruck | 15:44 | |
jaosorior | nevermind, found it | 15:45 |
redrobot | jaosorior yes, it's the default public key format that openssl uses | 15:47 |
redrobot | jaosorior note that the RSA format is not supported | 15:47 |
*** rm_mobile has joined #openstack-barbican | 15:52 | |
*** tkelsey has joined #openstack-barbican | 15:54 | |
*** dave-mccowan has joined #openstack-barbican | 15:56 | |
*** gyee has joined #openstack-barbican | 15:59 | |
*** darrenmoffat has quit IRC | 16:03 | |
*** zz_dimtruck is now known as dimtruck | 16:03 | |
*** darrenmoffat has joined #openstack-barbican | 16:09 | |
jaosorior | rellerreller: ping | 16:12 |
jaosorior | or redrobot | 16:13 |
redrobot | jaosorior pong | 16:13 |
jaosorior | in barbican/test/utils.py, there are the functions get_private_key() get_public_key() etc... a little bit irrelevant, but, wouldn't they usually have some newline after the header and before the footer? | 16:14 |
openstackgerrit | Merged openstack/barbican: Changes to get remaining cert functional tests working https://review.openstack.org/169600 | 16:15 |
jaosorior | aaah | 16:16 |
jaosorior | I had forgotten that those newlines were added by alee already in the commit that just merged | 16:16 |
jaosorior | :P | 16:16 |
redrobot | jaosorior yeah... we're having to do ghetto DER -> PEM conversions since cryptography.io doesn't support it yet. | 16:17 |
jaosorior | in tha hood | 16:18 |
alee | yeah! merged! | 16:19 |
jaosorior | alee: your commit is gonna make my life a lot easier (working on a fix for a bug) | 16:19 |
*** ccneill has joined #openstack-barbican | 16:20 | |
alee | jaosorior, excellent | 16:20 |
jaosorior | :D | 16:20 |
redrobot | jaosorior not that for the correct workflow, the entirety of the public.pem file needs to be base64 encoded | 16:20 |
alee | rellerreller, thanks for the workflow -- redrobot , rellerreller beat you to it .. | 16:20 |
redrobot | alee I saw :( | 16:21 |
jaosorior | redrobot: huh? | 16:21 |
rellerreller | redrobot ? | 16:21 |
alee | redrobot, but now at least we have something that is working -- even if its not doing what you suggest is the right thing to do. | 16:21 |
redrobot | jaosorior rellerreller so I think the bug stems from mixing up a detail of the PEM implementation, and what the 'base64' encoding means for a single POST request | 16:22 |
redrobot | the fact that a PEM file uses base64 under the hood does not mean that it is base64-encoded | 16:22 |
redrobot | ie, if you were to read the contents of the public.pem file, and feed that to base64 decode you would get an error | 16:23 |
rellerreller | redrobot You mean because it has header and footer that are not base64? | 16:23 |
redrobot | rellerreller in addition to the newlines, yes | 16:23 |
redrobot | if you look at the PEM as a whole, it is not a base64 string | 16:23 |
rellerreller | redrobot I agree. I also thought of this. | 16:23 |
rellerreller | I kept it that way for backwards compatability reasons. | 16:24 |
rellerreller | I think we need PEM, binary, and base64 types | 16:24 |
redrobot | rellerreller not necessarily. | 16:25 |
redrobot | rellerreller take a look at these workflows: http://docs-draft.openstack.org/59/171859/3/check/gate-barbican-docs/9671d40//doc/build/html/api/reference/secret_types.html#public | 16:25 |
redrobot | rellerreller the one POST workflow, and the POST+PUT workflow should result in the same thing: A DER stored in Barbican | 16:25 |
redrobot | rellerreller when a client makes a request (with application/octet-stream) they should get back the DER File they originally sent up | 16:26 |
rellerreller | redrobot It does not matter how the bytes are stored in the backend secret stores | 16:26 |
redrobot | rellerreller yep, I don't think a client should care how they're stored as long as they can retrieve the same thing they sent | 16:27 |
*** darrenmoffat has left #openstack-barbican | 16:27 | |
rellerreller | redrobot I agree about the request to retrieve back in DER format. Unfortunately we do not accept an enocding type for return. | 16:27 |
redrobot | rellerreller yea, I think we should stick to PEM only for Kilo. If we want to be able to request both PEM and DER, then that could be a Liberty feature | 16:28 |
rellerreller | I think the real bug is that the return type cannot be specified. I should be able to retrieve in DER or PEM or whatever. | 16:28 |
jaosorior | redrobot: well, the http://docs-draft.openstack.org/59/171859/3/check/gate-barbican-docs/9671d40//doc/build/html/api/reference/secret_types.html#example-2-2 would issue a DER with newlines...so I guess those should be stripped either by the user or us, not sure how that will end up working in the b64encode | 16:28 |
rellerreller | redrobot Every secret is returned in binary format. That is what the API specifies. | 16:28 |
redrobot | rellerreller actually, every secret has a list of "content_types" | 16:28 |
redrobot | rellerreller the client can make a choice of what they want | 16:29 |
redrobot | rellerreller DER can be considered binary | 16:29 |
rellerreller | redrobot Every secret has a list of content types but there is no code to return back in that format. | 16:29 |
redrobot | so, since we're limiting input to the DER format only, and calling that application/octet-stream, then on the retrieve application/octet-stream should return the same DER | 16:30 |
redrobot | if we want to be in the business of converting from DER to PEM we'll need to define our own content-types | 16:30 |
rellerreller | redrobot "Note that even if a binary secret is provided in the base64 format, it is converted to binary by Barbican prior to encryption and storage. Thereafter the secret will only be decrypted and returned as raw binary." | 16:31 |
redrobot | rellerreller yes... so that's a convenience feature provided by barbican. | 16:31 |
redrobot | I hope I can clear up confusion about this | 16:31 |
redrobot | if you look at example 2.1, the POST creates the metadata, and the PUT sends a binary request that includes the entire contents of the PEM | 16:31 |
rellerreller | redrobot We are not limiting on the input side. The secret can be input in several formats. | 16:32 |
*** arunkant_ has joined #openstack-barbican | 16:32 | |
jaosorior | redrobot, rellerreller: so, it seems that store_crypto was trying to fetch the contents of the PEM header twice, even though it was done already by the plugin.resources, this CR https://review.openstack.org/#/c/172144/ actually returns the correct key. Taking the steps to reproduce the bug that redrobot put in the bug report | 16:32 |
rellerreller | I tried adding tests for binary input but was unable to get those working. | 16:33 |
rm_mobile | Certificate orders return DER? I always assumed everyone operated with PEM :( | 16:33 |
redrobot | rellerreller I think we are limiting the "public" secrets to DER only. Let me explain | 16:33 |
redrobot | so, for Example 2.1, the PEM is sent as binary in the PUT. | 16:33 |
redrobot | some clients may have an issue with sending two requests | 16:33 |
redrobot | it would be more efficient to send only one request | 16:33 |
rellerreller | redrobot What do you mean by PEM is sent as binary? | 16:34 |
redrobot | rellerreller I mean, it takes the bytes of the content of the pem file and sends them as is, in their entirety | 16:34 |
redrobot | so, back to making only one request | 16:34 |
redrobot | in order to reduce the two request workflow into a single one, it is necessary to send a JSON request to specify the metadata | 16:35 |
redrobot | the contents of the PEM file do not fit in a JSON request | 16:35 |
redrobot | so in order to fit it inside the JSON request, we Base64 encode the contents of the PEM file | 16:35 |
redrobot | "payload_content_encoding"="base64 | 16:36 |
redrobot | means that the base64 conversion was done to fit it inside JSON | 16:36 |
rellerreller | redrobot How does that make it smaller? It sounded like you did base64(base64(pem)). | 16:36 |
redrobot | no | 16:36 |
redrobot | only base64(PEM) | 16:36 |
redrobot | rellerreller look at Example 2.2 | 16:36 |
rellerreller | But how can that be smaller than a PEM file? | 16:36 |
redrobot | rellerreller it's not smaller. It's just friendly to JSON | 16:37 |
redrobot | base64 by definition expands the input | 16:37 |
rellerreller | So by fit you meant encoding issue and not size issue. | 16:37 |
alee | redrobot, when you say "friendlier", what do you mean? | 16:37 |
rellerreller | I heard fit and think it's a size issue. My mistake. | 16:37 |
redrobot | alee if you look at the contents of the PEM as a whole, there are certain bytes that are not allowed inside a json string | 16:38 |
rellerreller | JSON does not sound like it will accept some of the bytes of the PEM file. Perhaps the newlines? | 16:38 |
redrobot | alee namely the newlines | 16:38 |
redrobot | yes, in JSON format, newlines must be escaped | 16:38 |
redrobot | so, because the PEM has newline characters, we cannot place it as-is in a JSON string | 16:39 |
redrobot | thus, we HAVE to encode it somehow | 16:39 |
redrobot | since we're already using base64 for symmetric secrets, it makes sense to use base64 again for a PEM | 16:39 |
alee | redrobot, so we need to use base64.encodestring()? or base64.b64encode()? | 16:39 |
redrobot | if you're doing it in python it would be something like: | 16:40 |
rellerreller | redrobot why not base64 of DER? | 16:40 |
alee | redrobot, there is a difference -- base64.b64encode() strips out the newlines. | 16:40 |
redrobot | rellerreller because the PEM is what openssl produces by default. | 16:40 |
redrobot | rellerreller as per your spec, we only support the DER | 16:40 |
redrobot | *derp, I mean, per your spec, we only support the PEM | 16:40 |
rellerreller | redrobot My spec does not limit that | 16:41 |
alee | redrobot, this is important because without the newlines, it isn't valid PEM, and so things like load_privatekey() will fail. | 16:41 |
rellerreller | redrobot You can pass in a base64 encoded DER and it will work | 16:41 |
rellerreller | redrobot Now the API and code says it will only return in binary. That was not my doing. | 16:41 |
redrobot | rellerreller http://specs.openstack.org/openstack/barbican-specs/specs/kilo/content-type.html#content-encoding-for-each-secret-type defines only the PEM type | 16:42 |
redrobot | rellerreller for public key that is | 16:42 |
rellerreller | redrobot That spec defines the relationship between Barbican Core and the SecretStore. That is not with the API. | 16:43 |
redrobot | alee http://paste.openstack.org/show/201398/ note that encode/decode of the entire PEM preserves newlines | 16:43 |
alee | redrobot, actually it doesn;t -- that was precisely the point of my CR | 16:45 |
redrobot | alee try running that paste. | 16:45 |
jaosorior | alee: it seems it did preserve them | 16:45 |
alee | redrobot, let me rephrase -- if you do this with a private key and you try to load that private key, it fails. | 16:45 |
alee | thats why I ended up putting in base64.encodestring() and decodestring() | 16:46 |
redrobot | alee I still haven't worked through the private key workflows | 16:47 |
alee | redrobot, well - I don't see the point of doing private keys different from public keys | 16:47 |
alee | redrobot, the public key is derivable from the private key | 16:48 |
redrobot | rellerreller my mistake. I assumed that the types you spelled out were going to be the types that were acceptable throughout barbican. I don't think the spec is clear on what is expected from a user point of view | 16:48 |
rellerreller | redrobot The problem you are really having is that you want to give Barbican a PEM file and have it return a PEM file? | 16:48 |
redrobot | alee I suspect that private keys are also not being base64 encoded in their entirety | 16:48 |
redrobot | rellerreller yes. I thought that format conversions were outside the scope of this BP | 16:49 |
rellerreller | If you want to store a PEM and retrieve a PEM then do a POST with secret type opaque where payload is base64(pem). | 16:50 |
rellerreller | redrobot Until we can specify the return type as something other than binary then this is all that you can do. | 16:50 |
redrobot | rellerreller "binary" does not necessarily mean that it has to be a DER | 16:51 |
rellerreller | redrobot For public and private keys what else would it mean? | 16:51 |
redrobot | if we want to say that retrieving a key by using "application/octet-stream" means that you are getting a DER, then we should require a DER on input as well | 16:51 |
rellerreller | redrobot I disagree. I think you should be able to store a key using any format and return in any format. | 16:52 |
redrobot | rellerreller I think that it is a good goal to have, but I don't think we can do that in Kilo... not if we want to release next week anyway. | 16:53 |
rellerreller | Just like with openssl. It can write keys out in DER or PEM format. Underneath the hood the bytes of the key are the only thing that matter. | 16:53 |
rellerreller | redrobot Likely not unless someone does not feel like sleeping. | 16:53 |
redrobot | rellerreller I think so to, but to make that work, we would need to define new content-types for each possible format | 16:54 |
*** xaeth_afk is now known as xaeth | 16:54 | |
rellerreller | redrobot I don't understand that last comment. | 16:54 |
redrobot | since the spec did not mention many different formats, I assumed that we would start with only one format and add new formats down the line | 16:54 |
redrobot | ok, so when I retrieve a secret from barbican, I send a content-type, right? | 16:55 |
redrobot | I can choose one from all the ones that are listed in the secret metadata | 16:55 |
rellerreller | redrobot yes | 16:55 |
*** kebray_ has joined #openstack-barbican | 16:55 | |
alee | rellerreller, I agree with you, but thats not going to happen for K. what does need to happen is that we need to define all the possible inputs for public and private keys, and then we need to make sure we can access them and use them in the stored key cert request case | 16:55 |
*** kebray_ has quit IRC | 16:55 | |
alee | (and return them as binary) | 16:55 |
rellerreller | redrobot You can also choose foo and bar. It does not matter. | 16:55 |
*** kebray_ has joined #openstack-barbican | 16:56 | |
redrobot | rellerreller so, the content_types property was always supposed to be used to limit the content-types that you can use to request a secret | 16:56 |
redrobot | rellerreller so you can't use foo and bar | 16:56 |
redrobot | rellerreller if you use a content-type that is not listed in the content_types metadata, then barbican responds witn "Not Acceptable" | 16:56 |
rellerreller | redrobot Unless that is happening in a validator then I don't know where that check happens. | 16:56 |
rellerreller | redrobot If it is then that is ok. We limited it, but it does not affect the way the result is returned. | 16:57 |
alee | crowds with pitchforks calling me for lunch --- redrobot - I'm looking forward to seeing that spec .. | 16:57 |
redrobot | crap, I need to run too | 16:57 |
*** alee is now known as alee_lunch | 16:57 | |
redrobot | let's continue this discussion after lunch? | 16:57 |
*** kebray has quit IRC | 16:57 | |
rellerreller | alee redrobot Google hangout? | 16:57 |
alee_lunch | yes please | 16:57 |
redrobot | rellerreller sure thing, mind scheduling one at about 3:30pm CST? I have a dentist appoint ment at 2pm | 16:58 |
rellerreller | Today might be a little tough for me, but I am open all day tomorrow. | 16:58 |
redrobot | ok, let's aim for tomorrow then | 16:58 |
rellerreller | redrobot thanks. | 16:58 |
rellerreller | I only have one free hour this afternnon. | 16:58 |
alee_lunch | fien for me tomorrow. that gives redrobot time to write something down .. | 16:58 |
alee_lunch | (it will go a lot faster if we have actual expected use cases) | 16:59 |
openstackgerrit | John Wood proposed openstack/barbican: Expose root cause plugin exceptions https://review.openstack.org/171868 | 17:00 |
*** openstack has quit IRC | 17:13 | |
*** openstack has joined #openstack-barbican | 17:13 | |
-sendak.freenode.net- [freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup | 17:13 | |
*** apodo has quit IRC | 17:22 | |
*** ccneill has quit IRC | 17:27 | |
*** rellerreller has quit IRC | 17:32 | |
*** kebray_ has quit IRC | 17:35 | |
*** gyee has quit IRC | 17:40 | |
*** kebray has joined #openstack-barbican | 17:52 | |
*** kfarr has joined #openstack-barbican | 18:00 | |
*** kebray has quit IRC | 18:07 | |
*** kebray has joined #openstack-barbican | 18:11 | |
*** everjeje has quit IRC | 18:16 | |
*** jkf has joined #openstack-barbican | 18:21 | |
*** alee_lunch is now known as alee | 18:21 | |
igueths | redrobot: Just saw your comment...I hadn't written a negative test specifically targetting the schema change, given that there was already a test to evaluate all the fields within the Consumer request payload. | 18:25 |
igueths | However, if we don't think that putting in a specific test is going to duplicate what is already there, then np I'll drop it in. | 18:26 |
*** tkelsey has quit IRC | 18:26 | |
*** ccneill has joined #openstack-barbican | 18:48 | |
*** nickrmc83 has joined #openstack-barbican | 18:53 | |
*** nickrmc84 has quit IRC | 18:54 | |
*** ccneill has quit IRC | 19:09 | |
*** mdarby has joined #openstack-barbican | 19:12 | |
*** mdarby has quit IRC | 19:13 | |
*** mdarby has joined #openstack-barbican | 19:14 | |
openstackgerrit | Kaitlin Farr proposed openstack/barbican: Makes all alembic version scripts pep8-compliant https://review.openstack.org/172181 | 19:15 |
*** everjeje has joined #openstack-barbican | 19:39 | |
*** kfarr has quit IRC | 19:51 | |
*** rm_mobile has quit IRC | 20:11 | |
*** jaosorior has quit IRC | 20:22 | |
woodster_ | core devs out there, please workflow this CR: https://review.openstack.org/#/c/170961 | 20:55 |
*** crc32 has joined #openstack-barbican | 21:01 | |
*** rm_you has joined #openstack-barbican | 21:16 | |
*** rm_you has quit IRC | 21:16 | |
*** rm_you has joined #openstack-barbican | 21:16 | |
*** alee has quit IRC | 21:22 | |
*** mdarby has quit IRC | 21:27 | |
*** kebray has quit IRC | 21:31 | |
openstackgerrit | Merged openstack/barbican: Delete openstack.common.context https://review.openstack.org/172088 | 21:34 |
openstackgerrit | Merged openstack/barbican: Create Barbican python scripts for development. https://review.openstack.org/170961 | 21:37 |
*** kebray has joined #openstack-barbican | 21:49 | |
*** kebray has quit IRC | 21:55 | |
*** paul_glass has quit IRC | 22:07 | |
*** xaeth is now known as xaeth_afk | 22:08 | |
openstackgerrit | Merged openstack/python-barbicanclient: Fixing the broken functional tests https://review.openstack.org/171465 | 22:11 |
*** igueths has quit IRC | 22:21 | |
*** dave-mccowan has quit IRC | 22:22 | |
*** dimtruck is now known as zz_dimtruck | 22:37 | |
*** alee has joined #openstack-barbican | 22:41 | |
*** dave-mccowan has joined #openstack-barbican | 22:41 | |
*** paul_glass has joined #openstack-barbican | 22:59 | |
*** arunkant_ has quit IRC | 23:16 | |
*** gyee has joined #openstack-barbican | 23:16 | |
*** SheenaG has quit IRC | 23:31 | |
*** everjeje has quit IRC | 23:36 | |
*** crc32 has quit IRC | 23:38 | |
*** jkf has quit IRC | 23:44 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!