15:02:24 <d34dh0r53> #startmeeting keystone 15:02:24 <opendevmeet> Meeting started Wed Aug 9 15:02:24 2023 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:24 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:24 <opendevmeet> The meeting name has been set to 'keystone' 15:02:33 <d34dh0r53> #topic roll call 15:02:37 <hiromu> o/ 15:02:53 <d34dh0r53> admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, knikolla[m], lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek, gmann, zaitcev, reqa, dmendiza[m] 15:02:55 <d34dh0r53> o/ 15:03:05 <xek> o/ 15:03:05 <zaitcev> Sorry, I'll have to be in and out. 15:03:23 <d34dh0r53> no problem zaitcev 15:03:27 <knikolla> o/ 15:03:31 <dmendiza[m]> 🙋 15:06:10 <d34dh0r53> #topic review past meeting work items 15:06:37 <noonedeadpunk> o/ 15:06:55 <d34dh0r53> I didn't get to the docs last week 15:07:08 <d34dh0r53> d34dh0r53 Look into adding/restoring a known issues section to our documentation 15:07:42 <d34dh0r53> #action d34dh0r53 Look into adding/restoring a known issues section to our documentation 15:07:50 <d34dh0r53> #action d34dh0r53 add https://bugs.launchpad.net/keystone/+bug/1305950 to the known issues section of our documentation 15:07:57 <d34dh0r53> #topic liaison updates 15:08:03 <d34dh0r53> nothing from VMT 15:10:08 <d34dh0r53> moving on 15:10:15 <d34dh0r53> #topic specification OAuth 2.0 (hiromu) 15:10:24 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext 15:10:26 <d34dh0r53> External OAuth 2.0 Specification 15:10:28 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 15:10:30 <d34dh0r53> OAuth 2.0 Implementation 15:10:32 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls 15:10:34 <d34dh0r53> OAuth 2.0 Documentation 15:10:36 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/838108 15:10:38 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 15:11:16 <hiromu> We're looking for the appropriate place for the user guide of the ext authz server support in the keystonemiddleware user document 15:11:49 <hiromu> Do you have any recommandation? 15:12:22 <hiromu> https://docs.openstack.org/keystonemiddleware/latest/index.html 15:13:18 <hiromu> i) placing under Middleware Architecture; ii) creating a new page on the root 15:14:58 <d34dh0r53> I think option 1, under the middleware architecture, after the delegated mode authentication component 15:15:59 <hiromu> ok, thanks 15:16:24 <hiromu> We'll submit a patch later 15:16:57 <hiromu> Also, is it possible to review this patch? within this cycle?https://review.opendev.org/c/openstack/keystonemiddleware/+/888523 15:17:25 <noonedeadpunk> Talking about oauth, hiromu maybe you have an idea on how to workaround/fix this regression caused supposedly by oauth mutual-tls patch? 15:17:29 <noonedeadpunk> #link https://bugs.launchpad.net/keystone/+bug/2029134 15:19:58 <hiromu> Looks caused by mTLS OAuth support, but I need to see the details. I'll check the bug report 15:20:34 <noonedeadpunk> awesome, would be great to improve upgrade path :) 15:21:19 <d34dh0r53> indeed, thanks for raising that noonedeadpunk 15:21:42 <d34dh0r53> hiromu: we'll start reviewing the patch you mentioned 15:22:09 <noonedeadpunk> I'm not sure if that was discussed previous meeting or not, but I'm even more bothered by this bug to be frank, as I have no idea how to workaround it 15:22:14 <noonedeadpunk> #link https://bugs.launchpad.net/keystone/+bug/2028809 15:22:28 <hiromu> great thank you :d34dh0r53. noonedeadpunk: thank you for pointing it out 15:23:11 <noonedeadpunk> as seems that if user was unaware enough about password length, after upgrade their passwords will be just invalidated 15:23:19 <d34dh0r53> noonedeadpunk: that bug is on my radar but I haven't had a chance to dive into it yet 15:23:44 <noonedeadpunk> And this also kinda raises question, if bcrypt still should be default? 15:24:01 <d34dh0r53> we can discuss more in the open discussion, I'd like to get through the specs 15:24:15 <noonedeadpunk> sure, sry 15:24:29 <d34dh0r53> no worries :) 15:24:50 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m]) 15:24:54 <d34dh0r53> Secure RBAC (dmendiza[m]) 15:24:56 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ 15:24:58 <d34dh0r53> Service Role Implementation 15:25:00 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/863420 15:25:02 <d34dh0r53> Manager Role Implementation 15:25:04 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/822601 15:25:06 <d34dh0r53> Keystone Tempest Plugin Updates 15:25:08 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/885799 15:25:19 <dmendiza[m]> No updates this week 😅 15:25:20 <d34dh0r53> the Service Role patch merged, dmendiza[m] any updates on the manager role testing? 15:25:41 <d34dh0r53> ack, thanks dmendiza[m] 15:25:46 <dmendiza[m]> I've been busy with downstream things, but hope to do it this week 15:25:56 <d34dh0r53> yep, likewise 15:26:09 <d34dh0r53> #topic open discussion 15:26:21 <d34dh0r53> first off I think we'll discuss the password truncation bug 15:26:31 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2028809 15:27:21 <noonedeadpunk> Yeah, so I was thinking if there are good reasons not to use scrypt hashing by default? 15:28:03 <noonedeadpunk> as after some "poll" among operators, lik 95% of them were pretty much surprised that passwords are jsut got trimmed 15:28:43 <noonedeadpunk> and no matter what you place in your password after 54 symbols. 15:29:34 <noonedeadpunk> And if operators are not always aware of that, it becomes even more problematic to communicate this to end users I guess 15:30:14 <noonedeadpunk> but that's a bit "going forward" discussion, rather then "how to handle upgrades right now". 15:33:30 <d34dh0r53> yeah, I'm surprised that this is breaking existing passwords 15:35:31 <d34dh0r53> I wonder if settting BCRYPT_MAX_LENGTH to 72 would fix the fact that 55-72 are "not fully mixed" 15:35:53 <noonedeadpunk> We have upgrade jobs for antelope pretty much broken whenever we get password longer then 54... 15:36:46 <noonedeadpunk> But yeah, my guess was that when passowrd is just latin, it takes less "bytes" so it could be indeed up to 72 15:38:51 <noonedeadpunk> I will have time to play with that somewhere... friday-ish, so unless you fix it before then, I can take a look as well 15:38:55 <d34dh0r53> noonedeadpunk: do you have the ability to test setting #link https://opendev.org/openstack/keystone/src/branch/master/keystone/common/password_hashing.py#L71 to 72 and see if that fixes the problem? 15:39:41 <d34dh0r53> and as to your second point, based on my limited research thus far I don't see a reason why we can't switch to scrypt 15:39:45 <noonedeadpunk> I'd need to reproduce the env, but yeah, will do that 15:39:51 <d34dh0r53> thanks noonedeadpunk 15:41:19 <d34dh0r53> #action d34dh0r53 investigate switching the default hashing algo to scrypt in 2024.x 15:41:27 <noonedeadpunk> I did also pretty limited research, and the downside was increased memory consumption, but I don't think it matter for real deployments 15:41:49 <noonedeadpunk> And for devstack that can be switched back to bcrypt if this is a concern 15:42:10 <noonedeadpunk> but dunno... 15:42:14 <d34dh0r53> yeah, I'm curious to see just how much larger those memory requirements are 15:45:36 <d34dh0r53> next up 15:45:38 <d34dh0r53> (drencrom) Remove cache invalidation when using expired token 15:45:40 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystonemiddleware/+/889191 15:46:22 <d34dh0r53> I think everything has merged 15:46:29 <d34dh0r53> we can remove this from the doc 15:47:28 <d34dh0r53> next up 15:47:30 <d34dh0r53> (reqa) Add openstack cli support for OAuth 2.0 Device Authorization Grant with PKCE: 15:47:32 <d34dh0r53> review request 15:47:34 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/883852 15:47:36 <d34dh0r53> Reasoning: When switching wsgi-keystone.conf to use PKCE for WebSSO, this also applies to the CLI (e.g. ForgeRock implemented the same) 15:48:08 <d34dh0r53> reviews on this one please 15:48:26 <d34dh0r53> any thing else for open discussion before we move on to bug triage? 15:48:52 <d34dh0r53> #topic bug review 15:49:00 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 15:49:40 <d34dh0r53> of the three latest bugs for keystone we've discussed two already 15:50:00 <d34dh0r53> #action hiromu is going to look at https://bugs.launchpad.net/keystone/+bug/2029134 15:50:23 <d34dh0r53> #action noonedeadpunk and d34dh0r53 are looking for a workaround/fix for https://bugs.launchpad.net/keystone/+bug/2028809 15:50:59 <d34dh0r53> finally we have #link https://bugs.launchpad.net/keystone/+bug/2030061 15:52:30 <noonedeadpunk> yeah, that's actually also interesting one... 15:53:29 <noonedeadpunk> OSA was quite slow with dropping _member_ role and historically it worked. But it's also kinda "upgrade" issue I'd say 15:55:40 <d34dh0r53> hmm, yeah that is an interesting one 15:56:35 <d34dh0r53> maybe dmendiza[m] or knikolla can look at that one ;) 15:57:10 <d34dh0r53> moving on for time 15:57:18 <d34dh0r53> #link #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 15:57:27 <d34dh0r53> no new bugs for python-keystoneclient 15:57:42 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 15:57:53 <d34dh0r53> keystoneauth is good 15:57:59 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 15:58:15 <d34dh0r53> no new bugs for keystonemiddleware 15:58:22 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 15:58:37 <d34dh0r53> pycadf is clean 15:58:39 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 15:58:42 <d34dh0r53> as is ldappool 15:59:21 <d34dh0r53> #topic conclusion 15:59:46 <d34dh0r53> nothing from me, reviewathon will be Friday, let me know if you'd like a calendar invite or the link 16:00:23 <d34dh0r53> thanks all 16:00:26 <d34dh0r53> #endmeeting