*** halali- is now known as halali | 13:10 | |
*** halali is now known as halali- | 13:22 | |
*** halali- is now known as halali | 13:42 | |
*** dviroel__ is now known as dviroel | 14:43 | |
xek | o/ | 15:02 |
---|---|---|
d34dh0r53 | #startmeeting keystone | 15:02 |
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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:02 |
opendevmeet | The meeting name has been set to 'keystone' | 15:02 |
d34dh0r53 | #topic roll call | 15:02 |
hiromu | o/ | 15:02 |
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 |
d34dh0r53 | o/ | 15:02 |
xek | o/ | 15:03 |
zaitcev | Sorry, I'll have to be in and out. | 15:03 |
d34dh0r53 | no problem zaitcev | 15:03 |
knikolla | o/ | 15:03 |
dmendiza[m] | 🙋 | 15:03 |
d34dh0r53 | #topic review past meeting work items | 15:06 |
noonedeadpunk | o/ | 15:06 |
d34dh0r53 | I didn't get to the docs last week | 15:06 |
d34dh0r53 | d34dh0r53 Look into adding/restoring a known issues section to our documentation | 15:07 |
d34dh0r53 | #action d34dh0r53 Look into adding/restoring a known issues section to our documentation | 15:07 |
d34dh0r53 | #action d34dh0r53 add https://bugs.launchpad.net/keystone/+bug/1305950 to the known issues section of our documentation | 15:07 |
d34dh0r53 | #topic liaison updates | 15:07 |
d34dh0r53 | nothing from VMT | 15:08 |
d34dh0r53 | moving on | 15:10 |
d34dh0r53 | #topic specification OAuth 2.0 (hiromu) | 15:10 |
d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | 15:10 |
d34dh0r53 | External OAuth 2.0 Specification | 15:10 |
d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 | 15:10 |
d34dh0r53 | OAuth 2.0 Implementation | 15:10 |
d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls | 15:10 |
d34dh0r53 | OAuth 2.0 Documentation | 15:10 |
d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/838108 | 15:10 |
d34dh0r53 | #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 | 15:10 |
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 |
hiromu | Do you have any recommandation? | 15:11 |
hiromu | https://docs.openstack.org/keystonemiddleware/latest/index.html | 15:12 |
hiromu | i) placing under Middleware Architecture; ii) creating a new page on the root | 15:13 |
d34dh0r53 | I think option 1, under the middleware architecture, after the delegated mode authentication component | 15:14 |
hiromu | ok, thanks | 15:15 |
hiromu | We'll submit a patch later | 15:16 |
hiromu | Also, is it possible to review this patch? within this cycle?https://review.opendev.org/c/openstack/keystonemiddleware/+/888523 | 15:16 |
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 |
noonedeadpunk | #link https://bugs.launchpad.net/keystone/+bug/2029134 | 15:17 |
hiromu | Looks caused by mTLS OAuth support, but I need to see the details. I'll check the bug report | 15:19 |
noonedeadpunk | awesome, would be great to improve upgrade path :) | 15:20 |
d34dh0r53 | indeed, thanks for raising that noonedeadpunk | 15:21 |
d34dh0r53 | hiromu: we'll start reviewing the patch you mentioned | 15:21 |
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 |
noonedeadpunk | #link https://bugs.launchpad.net/keystone/+bug/2028809 | 15:22 |
hiromu | great thank you :d34dh0r53. noonedeadpunk: thank you for pointing it out | 15:22 |
noonedeadpunk | as seems that if user was unaware enough about password length, after upgrade their passwords will be just invalidated | 15:23 |
d34dh0r53 | noonedeadpunk: that bug is on my radar but I haven't had a chance to dive into it yet | 15:23 |
noonedeadpunk | And this also kinda raises question, if bcrypt still should be default? | 15:23 |
d34dh0r53 | we can discuss more in the open discussion, I'd like to get through the specs | 15:24 |
noonedeadpunk | sure, sry | 15:24 |
d34dh0r53 | no worries :) | 15:24 |
d34dh0r53 | #topic specification Secure RBAC (dmendiza[m]) | 15:24 |
d34dh0r53 | Secure RBAC (dmendiza[m]) | 15:24 |
d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:24 |
d34dh0r53 | Service Role Implementation | 15:24 |
d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/863420 | 15:25 |
d34dh0r53 | Manager Role Implementation | 15:25 |
d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/822601 | 15:25 |
d34dh0r53 | Keystone Tempest Plugin Updates | 15:25 |
d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/885799 | 15:25 |
dmendiza[m] | No updates this week 😅 | 15:25 |
d34dh0r53 | the Service Role patch merged, dmendiza[m] any updates on the manager role testing? | 15:25 |
d34dh0r53 | ack, thanks dmendiza[m] | 15:25 |
dmendiza[m] | I've been busy with downstream things, but hope to do it this week | 15:25 |
d34dh0r53 | yep, likewise | 15:25 |
d34dh0r53 | #topic open discussion | 15:26 |
d34dh0r53 | first off I think we'll discuss the password truncation bug | 15:26 |
d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2028809 | 15:26 |
noonedeadpunk | Yeah, so I was thinking if there are good reasons not to use scrypt hashing by default? | 15:27 |
noonedeadpunk | as after some "poll" among operators, lik 95% of them were pretty much surprised that passwords are jsut got trimmed | 15:28 |
noonedeadpunk | and no matter what you place in your password after 54 symbols. | 15:28 |
noonedeadpunk | And if operators are not always aware of that, it becomes even more problematic to communicate this to end users I guess | 15:29 |
noonedeadpunk | but that's a bit "going forward" discussion, rather then "how to handle upgrades right now". | 15:30 |
d34dh0r53 | yeah, I'm surprised that this is breaking existing passwords | 15:33 |
d34dh0r53 | I wonder if settting BCRYPT_MAX_LENGTH to 72 would fix the fact that 55-72 are "not fully mixed" | 15:35 |
noonedeadpunk | We have upgrade jobs for antelope pretty much broken whenever we get password longer then 54... | 15:35 |
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:36 |
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 |
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:38 |
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 |
noonedeadpunk | I'd need to reproduce the env, but yeah, will do that | 15:39 |
d34dh0r53 | thanks noonedeadpunk | 15:39 |
d34dh0r53 | #action d34dh0r53 investigate switching the default hashing algo to scrypt in 2024.x | 15:41 |
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 |
noonedeadpunk | And for devstack that can be switched back to bcrypt if this is a concern | 15:41 |
noonedeadpunk | but dunno... | 15:42 |
d34dh0r53 | yeah, I'm curious to see just how much larger those memory requirements are | 15:42 |
d34dh0r53 | next up | 15:45 |
d34dh0r53 | (drencrom) Remove cache invalidation when using expired token | 15:45 |
d34dh0r53 | #link https://review.opendev.org/c/openstack/keystonemiddleware/+/889191 | 15:45 |
d34dh0r53 | I think everything has merged | 15:46 |
d34dh0r53 | we can remove this from the doc | 15:46 |
d34dh0r53 | next up | 15:47 |
d34dh0r53 | (reqa) Add openstack cli support for OAuth 2.0 Device Authorization Grant with PKCE: | 15:47 |
d34dh0r53 | review request | 15:47 |
d34dh0r53 | #link https://review.opendev.org/c/openstack/keystoneauth/+/883852 | 15:47 |
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:47 |
d34dh0r53 | reviews on this one please | 15:48 |
d34dh0r53 | any thing else for open discussion before we move on to bug triage? | 15:48 |
d34dh0r53 | #topic bug review | 15:48 |
d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:49 |
d34dh0r53 | of the three latest bugs for keystone we've discussed two already | 15:49 |
d34dh0r53 | #action hiromu is going to look at https://bugs.launchpad.net/keystone/+bug/2029134 | 15:50 |
d34dh0r53 | #action noonedeadpunk and d34dh0r53 are looking for a workaround/fix for https://bugs.launchpad.net/keystone/+bug/2028809 | 15:50 |
d34dh0r53 | finally we have #link https://bugs.launchpad.net/keystone/+bug/2030061 | 15:50 |
noonedeadpunk | yeah, that's actually also interesting one... | 15:52 |
noonedeadpunk | OSA was quite slow with dropping _member_ role and historically it worked. But it's also kinda "upgrade" issue I'd say | 15:53 |
d34dh0r53 | hmm, yeah that is an interesting one | 15:55 |
d34dh0r53 | maybe dmendiza[m] or knikolla can look at that one ;) | 15:56 |
d34dh0r53 | moving on for time | 15:57 |
d34dh0r53 | #link #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 15:57 |
d34dh0r53 | no new bugs for python-keystoneclient | 15:57 |
d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 15:57 |
d34dh0r53 | keystoneauth is good | 15:57 |
d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 15:57 |
d34dh0r53 | no new bugs for keystonemiddleware | 15:58 |
d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 15:58 |
d34dh0r53 | pycadf is clean | 15:58 |
d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 | 15:58 |
d34dh0r53 | as is ldappool | 15:58 |
d34dh0r53 | #topic conclusion | 15:59 |
d34dh0r53 | nothing from me, reviewathon will be Friday, let me know if you'd like a calendar invite or the link | 15:59 |
d34dh0r53 | thanks all | 16:00 |
d34dh0r53 | #endmeeting | 16:00 |
opendevmeet | Meeting ended Wed Aug 9 16:00:26 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:00 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2023/keystone.2023-08-09-15.02.html | 16:00 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2023/keystone.2023-08-09-15.02.txt | 16:00 |
opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2023/keystone.2023-08-09-15.02.log.html | 16:00 |
noonedeadpunk | d34dh0r53: from top of your head, is there any reason why passlib.hash.bcrypt_sha256 is not supported? As this is still bcrypt, but without limitation on 72 bytes.... | 16:20 |
noonedeadpunk | https://passlib.readthedocs.io/en/stable/lib/passlib.hash.bcrypt_sha256.html | 16:20 |
d34dh0r53 | I was just wondering that :) | 16:21 |
d34dh0r53 | not that I know | 16:21 |
noonedeadpunk | as this sounds actually more adequate then scrypt... | 16:24 |
noonedeadpunk | and also - it's talking about bytes, while we in fact checking string length, which is not the same... | 16:24 |
noonedeadpunk | quite trivial example https://paste.openstack.org/show/bTPmV5uOWQR7anMq3k53/ | 16:26 |
noonedeadpunk | but trimming that is fun... | 16:27 |
opendevreview | Dmitriy Rabotyagov proposed openstack/keystone master: Properly trimm bcrypt hashed passwords https://review.opendev.org/c/openstack/keystone/+/890936 | 18:41 |
noonedeadpunk | d34dh0r53: yup, 72 bytes does restore access. Setting it even to 71 - does not | 18:42 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!