13:00:10 <dmendiza[m]> #startmeeting barbican 13:00:10 <opendevmeet> Meeting started Tue Sep 20 13:00:10 2022 UTC and is due to finish in 60 minutes. The chair is dmendiza[m]. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:10 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:10 <opendevmeet> The meeting name has been set to 'barbican' 13:00:15 <dmendiza[m]> #topic Roll Call 13:00:20 <dmendiza[m]> Courtesy ping for ade_lee dave-mccowan d34dh0r53 hrybacki jamespage Luzi lxkong mhen rm_work tosky xek nearyo oleksandry 13:01:16 <tosky> hi 13:01:55 <dmendiza[m]> Hi tosky ! 13:02:01 <rajiv> hi 13:02:23 <ade_lee> o/ 13:03:28 <dmendiza[m]> Alright, let's get started 13:03:37 <dmendiza[m]> #topic Review Past Meeting Action Items 13:03:49 <dmendiza[m]> #link https://meetings.opendev.org/meetings/barbican/2022/barbican.2022-09-13-13.02.html 13:04:10 <dmendiza[m]> We didn't have any 13:04:21 <dmendiza[m]> #topic Liaison Updates 13:04:22 <dmendiza[m]> tosky: any updates this week? 13:06:27 <tosky> you mentioned an issue with grenade last week, but I didn't follow up, sorry: was it solved? 13:06:37 <tosky> apart from that, no updates 13:07:06 <dmendiza[m]> tosky: not yet. I did submit a patch to disable voting on grenade to unblock the gate 13:07:26 <dmendiza[m]> I looked into it briefly, and it looks like creating an encrypted volume is failing 13:07:36 <dmendiza[m]> because of a permissions issue 13:07:44 <dmendiza[m]> but I haven't had a chance to dig in to find the root cause 13:07:53 <dmendiza[m]> *barbican permission issue that is 13:08:04 <dmendiza[m]> seems we're rejecting an order request to generate the key 13:08:43 <dmendiza[m]> On the release side of things we still don't have an RC1 13:08:55 <dmendiza[m]> We'd like to include xek's patch: 13:10:18 <dmendiza[m]> #link https://review.opendev.org/c/openstack/barbican/+/857047 13:10:24 <dmendiza[m]> unfortunately it does not work for sqlite 13:10:29 <tosky> it's weird because it was working when the grenade pathc was merged 13:10:44 <dmendiza[m]> tosky: agreed ... real weird indeed. 13:10:59 <dmendiza[m]> tosky: now there's also apparently an issue with our .zuul.yaml file 13:11:12 <dmendiza[m]> looks like maybe zuul was updated and the yaml file is no longer valid 13:12:04 <dmendiza[m]> ... back to xek's patch ... I need to work on my SQLAlchemy chops to try to figure out a migration that will work for all DB backends 13:12:21 <dmendiza[m]> also, we don't test sqlite at the gate, even though we default to sqlite in the barbican conf 13:13:57 <ade_lee> dmendiza[m], yeah -we should consider defaulting to something else if we don't test it 13:14:06 <ade_lee> or test it 13:14:42 <dmendiza[m]> Well, it's easy to default to sqlite for dev 13:14:57 <dmendiza[m]> and it would not be an issue if we had not removed the auto-generate schema feature 13:15:05 <dmendiza[m]> so we're stuck having to apply migrations 13:15:19 <dmendiza[m]> which we apparently don't claim to support for sqlite: 13:15:25 <dmendiza[m]> #link https://opendev.org/openstack/barbican/src/branch/master/barbican/model/migration/commands.py#L47-L48 13:16:42 <ade_lee> dmendiza[m], :/ - so if I started with a brand new db, would the db migrations have worked? 13:16:50 <ade_lee> for sqlite? 13:17:05 <ade_lee> coz right now, they break with xek patch 13:17:18 <dmendiza[m]> ade_lee: no, the SQL generated by xek's patch does not work on sqlite period 13:17:26 <dmendiza[m]> there may be a way to rewrite the migration 13:17:46 <dmendiza[m]> using "batch" migrations: 13:17:47 <dmendiza[m]> #link https://alembic.sqlalchemy.org/en/latest/batch.html 13:17:54 <ade_lee> yeah - agreed , but we should test somewhere in the gate to make sure something doesn't slip through 13:18:18 <ade_lee> ifwe're going to support slqite at all 13:18:24 <tosky> dmendiza[m]: zuul issue - it may be that queue statement, there was an announced change in zuul 13:18:50 <dmendiza[m]> tosky: ack, I'll throw up a patch after this meeting 13:19:58 <dmendiza[m]> ade_lee: to answer your question RE: brand new db, there's two ways of applying the current schema to the db. One way is to generate schema from the current models (we used to do this automatically), the second way is to apply migrations. 13:20:07 <dmendiza[m]> presumaby, doing the former would work on SQLite 13:20:37 <ade_lee> ok - and we no longer do the former .. 13:20:57 <dmendiza[m]> correct 13:22:03 <dmendiza[m]> Anyway, I'll continue to work on this patch, but if we can't get sqlite working by the end of the week, then we may need to release RC1 without it 13:23:32 <dmendiza[m]> OK, moving on 13:23:40 <dmendiza[m]> #topic Secret Consumers 13:23:58 <dmendiza[m]> As I mentioned, we'll try to get xek's patch merged 13:24:19 <dmendiza[m]> ade_lee: any updates on the client side of things? 13:24:34 <ade_lee> yeah - lots of progress 13:25:05 <ade_lee> we have some barbicanclient patches up and also a castellan patch that uses the stuff in the barbicanclient 13:25:28 <ade_lee> in general stuff seems to be working and we're adding tests (unit/functional etc) 13:25:51 <ade_lee> waiting on reviews mostly now -- nudge nudge 13:26:23 <dmendiza[m]> ack, will review as soon as possible 13:26:29 <dmendiza[m]> OK, moving on 13:26:35 <dmendiza[m]> #topic Secure RBAC 13:26:38 <dmendiza[m]> I think we're good for now 13:27:02 <dmendiza[m]> #topic Open Discussion 13:27:11 <dmendiza[m]> Any topics y'all want to talk about? 13:27:56 <rajiv> hi, I have 3 queries to ask 13:28:11 <dmendiza[m]> rajiv: go ahead 13:28:35 <rajiv> 1. could i know why only generic container secrets can be updated ? why not certificate containers : https://github.com/openstack/barbican/blob/stable/yoga/barbican/api/controllers/containers.py#L246-L247 13:29:11 <rajiv> would there be any issues if we comment or remove these 2 code lines ? 13:29:50 <dmendiza[m]> rajiv: by design. Generic containers can be modified, but "certificate" containers are supposed to represent a cert + key + passphrase. For a typical x509, you would not "modify" they key, you would just issue a new cert, for example. 13:30:40 <rajiv> correct, but there is no option to update the new cert ? 13:31:09 <dmendiza[m]> The recommended workflow is to create a new container for the new cert + key + passphrase 13:31:51 <rajiv> okay, in general there is no harm to add certificate container to this list or remove the if condition ? 13:32:11 <dmendiza[m]> IIRC, the main concern was with having certificates changed under you. e.g. I expect a certain certificate, but someone updated it then the original certificate is lost 13:32:18 <dmendiza[m]> since "certificate" type containers only allow a single cert 13:33:36 <rajiv> okay, i have a custom role "keymanager_admin" who can only edit secrets not even admin, there are only 1-2 users per project with "keymanager_admin" role. hence i presume its safe to patch this code ? 13:34:20 <dmendiza[m]> rajiv: if your workflow requires you to modify the container, then why not use "generic" type? 13:34:52 <dmendiza[m]> I am not sure we would merge a change to the behavior of non-generic containers 13:34:59 <dmendiza[m]> ade_lee: what's your opinion? 13:35:01 <rajiv> the user wants only certificate type! i did try convince but had no luck 13:35:49 <rajiv> i see this bug also reports the same : https://storyboard.openstack.org/#!/story/2007629 13:37:17 * dmendiza[m] looks at bug report 13:37:35 <ade_lee> sorry .. reading up .. 13:38:10 <dmendiza[m]> Yeah, that's an interesting use case ... although not quite the same as you're proposing. The bug report mentions the ability for a secret to be created, and then the payload uploaded. 13:38:16 <dmendiza[m]> but secret still cannot be modified 13:38:24 <rajiv> yes 13:38:41 <dmendiza[m]> it's a design decision we made when we started barbican to disallow changing secrets and focing a user to create a new one. 13:39:33 <dmendiza[m]> from my point of view your user has two options 1) use "generic" container and add/remove secrets whenever they want or 2) use "certificate" type containers and create a new one when the certiricate or key changes. 13:40:00 <ade_lee> dmendiza[m], I'm not fundamentally opposed to this change. 13:40:35 <rajiv> okay, would there be any progress on that bug ? or would there be anything else i need to check if i disable the if condition ? 13:40:59 <dmendiza[m]> rajiv: I'll have to test a few things for that bug report 13:40:59 <ade_lee> dmendiza[m], I can imagine for instance that certificates expire and need to be replaced. Is it an undue burden to require folks to find all the clients and update with a new cert? 13:41:05 <rajiv> i can patch my internal repo and not create a PR upstream :) 13:41:35 <rajiv> @ade_lee this is another complain i received from the user as well. 13:41:44 <ade_lee> dmendiza[m], after all its not some random person updating the cert 13:42:19 <dmendiza[m]> rajiv: it may make sense to allow for creating an empty "certificate" type container and then allow the secrets to be added later, but still not allow delete/update after that. 13:42:48 <dmendiza[m]> ade_lee: I am ooposed to the change because it would override and lose the old cert 13:43:04 <dmendiza[m]> ade_lee: which, even when expired, may be needed to decrypt prior traffic for example 13:43:29 <ade_lee> dmendiza[m], good point 13:44:07 <ade_lee> dmendiza[m], feels like we need a better way to track old certs 13:44:59 <ade_lee> rajiv, maybe this is a good candidate for a spec to be written -- at least then we can discuss all the requirements and design decisions 13:45:17 <rajiv> ade_lee: sure 13:45:23 <rajiv> 2. few weeks back, i requested for sorting secrets by name, i created a patch but later found https://github.com/openstack/barbican/blob/stable/yoga/barbican/model/repositories.py#L669-L670 , 13:45:34 <ade_lee> rajiv, we may ultimately decided not to change anything but at least we can specify why 13:46:31 <rajiv> as sql "like" supports % and _ operators support regex, would i still need a patch or is this fine to proceed ? does the docu need mentioning of these operators ? 13:48:27 <ade_lee> rajiv, so you're saying you can get sorting by passing in a regex/operator in the query string? 13:48:30 <dmendiza[m]> sorry, I'm not sure I understand how % and _ are used. Would that be part of the user query? Does it work currently? 13:49:09 <rajiv> we cannot filter names but only sort them, right ? 13:50:14 <rajiv> by using % and _ operators in the curl command, i am able to perform regex operations. I would like to know, if this is an acceptable approach or would i need to go ahead testing the patch : https://github.com/sapcc/barbican/commit/f6f50c90ad89982dca9b7c34a52c70dede09c750 13:50:20 <dmendiza[m]> OH, I think the "like" operation will filter, not just sort 13:50:47 <rajiv> yes, 13:50:50 <rajiv> example : 13:51:25 <rajiv> curl -s 'https://keymanager-3.xxx.cloud.sap/v1/secrets?name=my%' -H "X-Auth-Token: ${OS_AUTH_TOKEN}" | jq -r | grep total "total": 3 13:51:42 <rajiv> curl -s 'https://keymanager-3.xxx.cloud.xxx/v1/secrets?name=raj%' -H "X-Auth-Token: ${OS_AUTH_TOKEN}" | jq -r | grep total "total": 1 13:53:00 <rajiv> all of the below options mentioned, 'a_%', 'a%o', here for example, worked : https://www.w3schools.com/sql/sql_like.asp 13:53:50 <dmendiza[m]> neat 13:54:40 <dmendiza[m]> rajiv: is your patch needed to get those curl commands to work? 13:55:39 <rajiv> dmendiza[m]: nope, while testing the patch i bumped into this "like" operation, later tested with % and _ operators 13:55:56 <rajiv> i guess i neednt go ahead developing a patch ? this also works for other parameters, alg, mode, etc 13:57:43 <dmendiza[m]> I see, yeah, it would be awesome if you could add that to the barbican docs 13:58:24 <rajiv> cool, 13:58:45 <dmendiza[m]> ... almost out of time ... 13:58:51 <rajiv> last q, i am starting my python dev skills, i need assistance pagination bug 13:58:51 <dmendiza[m]> rajiv: you had one more Q? 13:59:17 <rajiv> https://github.com/sapcc/barbican/pull/2/files this doesnt go as i thought, whom could i reach out to for help ? 14:00:15 <dmendiza[m]> You can definitely ask for help here 14:01:12 <rajiv> cool, its related to https://storyboard.openstack.org/#!/story/2009322 14:01:20 <rajiv> thats it from me 14:02:25 <dmendiza[m]> Fridays is usually when I have time to do things upstream, so that would be a good day to ping me and have a look 14:02:26 <dmendiza[m]> That's it for meeting time, I gotta run to another meeting. 14:02:26 <dmendiza[m]> See y'all online! 14:02:31 <dmendiza[m]> #endmeeting