Wednesday, 2023-08-09

*** halali- is now known as halali13:10
*** halali is now known as halali-13:22
*** halali- is now known as halali13:42
*** dviroel__ is now known as dviroel14:43
xeko/15:02
d34dh0r53#startmeeting keystone15:02
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:02
opendevmeetThe meeting name has been set to 'keystone'15:02
d34dh0r53#topic roll call15:02
hiromuo/15:02
d34dh0r53admiyo, 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
d34dh0r53o/15:02
xeko/15:03
zaitcevSorry, I'll have to be in and out.15:03
d34dh0r53no problem zaitcev 15:03
knikollao/15:03
dmendiza[m]🙋15:03
d34dh0r53#topic review past meeting work items15:06
noonedeadpunko/15:06
d34dh0r53I didn't get to the docs last week15:06
d34dh0r53d34dh0r53 Look into adding/restoring a known issues section to our documentation15:07
d34dh0r53#action d34dh0r53 Look into adding/restoring a known issues section to our documentation15:07
d34dh0r53#action d34dh0r53 add https://bugs.launchpad.net/keystone/+bug/1305950 to the known issues section of our documentation15:07
d34dh0r53#topic liaison updates15:07
d34dh0r53nothing from VMT15:08
d34dh0r53moving on15:10
d34dh0r53#topic specification OAuth 2.0 (hiromu)15:10
d34dh0r53#link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext15:10
d34dh0r53External OAuth 2.0 Specification15:10
d34dh0r53#link https://review.opendev.org/c/openstack/keystone-specs/+/86155415:10
d34dh0r53OAuth 2.0 Implementation15:10
d34dh0r53#link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls15:10
d34dh0r53OAuth 2.0 Documentation15:10
d34dh0r53#link https://review.opendev.org/c/openstack/keystone/+/83810815:10
d34dh0r53#link https://review.opendev.org/c/openstack/keystoneauth/+/83810415:10
hiromuWe're looking for the appropriate place for the user guide of the ext authz server support in the keystonemiddleware user document15:11
hiromuDo you have any recommandation? 15:11
hiromuhttps://docs.openstack.org/keystonemiddleware/latest/index.html15:12
hiromui) placing under Middleware Architecture; ii) creating a new page on the root 15:13
d34dh0r53I think option 1, under the middleware architecture, after the delegated mode authentication component15:14
hiromuok, thanks15:15
hiromuWe'll submit a patch later15:16
hiromuAlso, is it possible to review this patch? within this cycle?https://review.opendev.org/c/openstack/keystonemiddleware/+/88852315:16
noonedeadpunkTalking 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/202913415:17
hiromuLooks caused by mTLS OAuth support, but I need to see the details. I'll check the bug report15:19
noonedeadpunkawesome, would be great to improve upgrade path :)15:20
d34dh0r53indeed, thanks for raising that noonedeadpunk 15:21
d34dh0r53hiromu: we'll start reviewing the patch you mentioned15:21
noonedeadpunkI'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 it15:22
noonedeadpunk#link https://bugs.launchpad.net/keystone/+bug/202880915:22
hiromugreat thank you :d34dh0r53. noonedeadpunk: thank you for pointing it out15:22
noonedeadpunkas seems that if user was unaware enough about password length, after upgrade their passwords will be just invalidated15:23
d34dh0r53noonedeadpunk: that bug is on my radar but I haven't had a chance to dive into it yet15:23
noonedeadpunkAnd this also kinda raises question, if bcrypt still should be default?15:23
d34dh0r53we can discuss more in the open discussion, I'd like to get through the specs15:24
noonedeadpunksure, sry15:24
d34dh0r53no worries :)15:24
d34dh0r53#topic specification Secure RBAC (dmendiza[m]) 15:24
d34dh0r53Secure RBAC (dmendiza[m])15:24
d34dh0r53#link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_15:24
d34dh0r53Service Role Implementation15:24
d34dh0r53#link https://review.opendev.org/c/openstack/keystone/+/86342015:25
d34dh0r53Manager Role Implementation15:25
d34dh0r53#link https://review.opendev.org/c/openstack/keystone/+/82260115:25
d34dh0r53Keystone Tempest Plugin Updates15:25
d34dh0r53#link https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/88579915:25
dmendiza[m]No updates this week 😅15:25
d34dh0r53the Service Role patch merged, dmendiza[m] any updates on the manager role testing?15:25
d34dh0r53ack, thanks dmendiza[m] 15:25
dmendiza[m]I've been busy with downstream things, but hope to do it this week15:25
d34dh0r53yep, likewise15:25
d34dh0r53#topic open discussion15:26
d34dh0r53first off I think we'll discuss the password truncation bug15:26
d34dh0r53#link https://bugs.launchpad.net/keystone/+bug/202880915:26
noonedeadpunkYeah, so I was thinking if there are good reasons not to use scrypt hashing by default?15:27
noonedeadpunkas after some "poll" among operators, lik 95% of them were pretty much surprised that passwords are jsut got trimmed15:28
noonedeadpunkand no matter what you place in your password after 54 symbols.15:28
noonedeadpunkAnd if operators are not always aware of that, it becomes even more problematic to communicate this to end users I guess15:29
noonedeadpunkbut that's a bit "going forward" discussion, rather then "how to handle upgrades right now".15:30
d34dh0r53yeah, I'm surprised that this is breaking existing passwords15:33
d34dh0r53I wonder if settting BCRYPT_MAX_LENGTH to 72 would fix the fact that 55-72 are "not fully mixed"15:35
noonedeadpunkWe have upgrade jobs for antelope pretty much broken whenever we get password longer then 54...15:35
noonedeadpunkBut yeah, my guess was that when passowrd is just latin, it takes less "bytes" so it could be indeed up to 7215:36
noonedeadpunkI will have time to play with that somewhere... friday-ish, so unless you fix it before then, I can take a look as well15:38
d34dh0r53noonedeadpunk: 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
d34dh0r53and as to your second point, based on my limited research thus far I don't see a reason why we can't switch to scrypt15:39
noonedeadpunkI'd need to reproduce the env, but yeah, will do that15:39
d34dh0r53thanks noonedeadpunk 15:39
d34dh0r53#action d34dh0r53 investigate switching the default hashing algo to scrypt in 2024.x15:41
noonedeadpunkI did also pretty limited research, and the downside was increased memory consumption, but I don't think it matter for real deployments15:41
noonedeadpunkAnd for devstack that can be switched back to bcrypt if this is a concern15:41
noonedeadpunkbut dunno...15:42
d34dh0r53yeah, I'm curious to see just how much larger those memory requirements are15:42
d34dh0r53next up15:45
d34dh0r53(drencrom) Remove cache invalidation when using expired token15:45
d34dh0r53#link https://review.opendev.org/c/openstack/keystonemiddleware/+/88919115:45
d34dh0r53I think everything has merged15:46
d34dh0r53we can remove this from the doc15:46
d34dh0r53next up15:47
d34dh0r53(reqa) Add openstack cli support for OAuth 2.0 Device Authorization Grant with PKCE:15:47
d34dh0r53review request15:47
d34dh0r53#link https://review.opendev.org/c/openstack/keystoneauth/+/88385215:47
d34dh0r53Reasoning: When switching wsgi-keystone.conf to use PKCE for WebSSO, this also applies to the CLI (e.g. ForgeRock implemented the same)15:47
d34dh0r53reviews on this one please15:48
d34dh0r53any thing else for open discussion before we move on to bug triage?15:48
d34dh0r53#topic bug review15:48
d34dh0r53#link https://bugs.launchpad.net/keystone/?orderby=-id&start=015:49
d34dh0r53of the three latest bugs for keystone we've discussed two already15:49
d34dh0r53#action hiromu is going to look at https://bugs.launchpad.net/keystone/+bug/202913415:50
d34dh0r53#action noonedeadpunk and d34dh0r53 are looking for a workaround/fix for https://bugs.launchpad.net/keystone/+bug/202880915:50
d34dh0r53finally we have #link https://bugs.launchpad.net/keystone/+bug/203006115:50
noonedeadpunkyeah, that's actually also interesting one...15:52
noonedeadpunkOSA was quite slow with dropping _member_ role and historically it worked. But it's also kinda "upgrade" issue I'd say15:53
d34dh0r53hmm, yeah that is an interesting one15:55
d34dh0r53maybe dmendiza[m] or knikolla can look at that one ;)15:56
d34dh0r53moving on for time15:57
d34dh0r53#link #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=015:57
d34dh0r53no new bugs for python-keystoneclient15:57
d34dh0r53#link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=015:57
d34dh0r53keystoneauth is good15:57
d34dh0r53#link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=015:57
d34dh0r53no new bugs for keystonemiddleware15:58
d34dh0r53#link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=015:58
d34dh0r53pycadf is clean15:58
d34dh0r53#link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=015:58
d34dh0r53as is ldappool15:58
d34dh0r53#topic conclusion15:59
d34dh0r53nothing from me, reviewathon will be Friday, let me know if you'd like a calendar invite or the link15:59
d34dh0r53thanks all16:00
d34dh0r53#endmeeting16:00
opendevmeetMeeting ended Wed Aug  9 16:00:26 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:00
opendevmeetMinutes:        https://meetings.opendev.org/meetings/keystone/2023/keystone.2023-08-09-15.02.html16:00
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/keystone/2023/keystone.2023-08-09-15.02.txt16:00
opendevmeetLog:            https://meetings.opendev.org/meetings/keystone/2023/keystone.2023-08-09-15.02.log.html16:00
noonedeadpunkd34dh0r53: 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
noonedeadpunkhttps://passlib.readthedocs.io/en/stable/lib/passlib.hash.bcrypt_sha256.html16:20
d34dh0r53I was just wondering that :)16:21
d34dh0r53not that I know16:21
noonedeadpunkas this sounds actually more adequate then scrypt...16:24
noonedeadpunkand also - it's talking about bytes, while we in fact checking string length, which is not the same...16:24
noonedeadpunkquite trivial example https://paste.openstack.org/show/bTPmV5uOWQR7anMq3k53/16:26
noonedeadpunkbut trimming that is fun...16:27
opendevreviewDmitriy Rabotyagov proposed openstack/keystone master: Properly trimm bcrypt hashed passwords  https://review.opendev.org/c/openstack/keystone/+/89093618:41
noonedeadpunkd34dh0r53: yup, 72 bytes does restore access. Setting it even to 71 - does not18:42

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!