15:01:30 #startmeeting keystone 15:01:30 Meeting started Wed Jan 31 15:01:30 2024 UTC and is due to finish in 60 minutes. The chair is d34dh0r5|. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:30 The meeting name has been set to 'keystone' 15:02:03 🙋‍♂️ 15:02:09 #topic roll call 15:02:17 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], mharley, jph 15:07:01 o/ 15:08:28 #topic review past meeting work items 15:08:55 #link https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-01-17-15.00.html 15:09:09 no updates on my stuff 15:09:16 #action d34dh0r53 Look into adding/restoring a known issues section to our documentation 15:09:27 #action d34dh0r53 add https://bugs.launchpad.net/keystone/+bug/1305950 to the known issues section of our documentation 15:09:48 #topic liaison updates 15:10:02 nothing from release management or VMT 15:12:45 #topic specification OAuth 2.0 (hiromu) 15:12:56 #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext 15:12:58 #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability 15:13:00 External OAuth 2.0 Specification 15:13:02 #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 15:13:04 OAuth 2.0 Implementation 15:13:06 #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls 15:13:08 OAuth 2.0 Documentation 15:13:10 #link https://review.opendev.org/c/openstack/keystone/+/838108 15:13:12 #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 15:13:51 o/ 15:15:28 doesn't look like hiromu is around 15:15:54 #topic specification Secure RBAC (dmendiza[m]) 15:16:08 #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ 15:16:10 2024.1 Release Timeline 15:16:12 Update oslo.policy in keystone to enforce_new_defaults=True 15:16:14 Update oslo.policy in keystone to enforce_scope=True 15:16:16 #link https://review.opendev.org/c/openstack/keystone/+/902730 (Merged) 15:16:18 #link https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/903713 15:18:15 Yeah, still working on the tempest tests 15:19:16 but the policy changes have already merged all the way back to antelope 15:20:46 awesome, thanks for the work on that 15:21:03 let me know when the tempest tests are ready for review 15:23:08 #topic specification Improve federated users management (previously: Add schema version and support to "domain" attribute in mapping rules) (gtema) 15:23:19 #link https://review.opendev.org/c/openstack/keystone-specs/+/748042 (merged) 15:23:21 #link https://review.opendev.org/c/openstack/keystone/+/739966 (Merged) 15:23:23 #link https://review.opendev.org/c/openstack/keystone-specs/+/748748 15:23:43 I have added link to the next spec here 15:23:49 thanks for finally merging the change 15:24:12 yep, I'll take a look at the next one 15:24:15 so now we should do next step and allow also management of the user roles in the federated identity 15:24:49 otherwise it is required to have additional software that manages roles for ephemeral users 15:24:53 and that really sucks 15:25:41 I know the spec is currently tied to 2024.1 and it is no chance it can be made in this cycle 15:25:59 but I really appreciate we do not wait with review so that implementation is not blocked 15:26:01 thanks 15:27:20 np, thank you 15:28:15 #topic open discussion 15:28:21 i have topics 15:28:29 go ahead bbobrov 15:28:33 a topic about unified limits. The page in the docs says that they are experimental - https://docs.openstack.org/keystone/latest/admin/unified-limits.html . Since the Nova 28.0.0 (2023.2 Bobcat) release, it is recommended to use Keystone unified limits for Nova quota limits - https://docs.openstack.org/nova/latest/admin/unified-limits.html 15:28:45 Are the limits experimental or are they already stable? 15:34:44 I do not know, that is before my time and I'm surprised that it's still marked as experimental 15:37:27 an idea just came to me to search in gerrit: https://review.opendev.org/c/openstack/keystone/+/893120 15:37:56 ok, good, then i will consider them to be stable 15:38:16 yeah, I think that's safe at this point 15:39:02 then the next topic, about password truncation 15:39:07 After upgrade to Zed, we got flooded with messages "Truncating password to algorithm specific maximum length 72 characters." and "Truncating user password". They happen even though there is no config about password length. They happen even when somebody is authenticating with application credentials, because it seems that the code path leads to the method that prints the warning. 15:39:24 I will file a bugreport about this soon-ish; my question is: what is this all about? Or, more specific, can i just upgrade from Zed to Antilope, or do i need to care about the length of the secrets of application credentials and passwords? 15:42:36 I think this has to do with the intrinsic limitation in bcrypt 15:43:02 there were some bugs that I fixed in zed time frame that probably need some adjustment 15:44:38 #link https://review.opendev.org/c/openstack/keystone/+/828595 15:44:44 is that what you're seeing? 15:45:22 yes 15:46:18 i found that the limit got raised in https://review.opendev.org/c/openstack/keystone/+/890936 15:46:24 #link https://review.opendev.org/c/openstack/keystone/+/890936 15:46:50 but i still don't fully understand whether the issue with the upgrade has been fixed or not 15:50:24 I don't think upgrading will eliminate the messages, the truncation means that only the first 72 characters of a password are validated (https://passlib.readthedocs.io/en/stable/lib/passlib.hash.bcrypt.html#security-issues) and in the case of application credentials this probably happens more often 15:51:03 but will upgrading break the application credentials? 15:51:12 with long secrets 15:51:34 I don't think so, just the whole secret won't be used 15:55:13 ok then, thanks. 15:55:31 I would test that though :) 15:55:45 #topic bug review 15:55:51 #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 15:56:03 no new bugs for keystone 15:56:14 #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 15:56:19 python-keystoneclient is good 15:56:23 #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 15:56:36 nothing new for keystoneauth 15:56:42 #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 15:56:51 nor keystonemiddleware 15:56:59 #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 15:57:07 just a short question (other topic): did anyone of the Keystone team got time to review the domain manager role spec?: https://review.opendev.org/c/openstack/keystone-specs/+/903172 15:57:11 pycadf is GTG 15:57:47 dmendiza[m] and I can take a look 15:57:52 Luzi: ^ 15:58:11 thank you :) 15:58:14 #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 15:58:20 no new bugs for ldappool either 15:58:24 #undo 15:58:41 #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 15:58:48 Luzi: np 15:58:52 #topic conclusion 15:59:33 sign up for the vPTG, April 8-12 15:59:37 #link https://openinfra.dev/ptg/ 15:59:50 I'll shoot out the agenda in next weeks meeting 15:59:58 Thanks everyone! 16:00:01 #endmeeting 16:00:37 thank you 16:01:06 #endmeeting