| opendevreview | OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Imported Translations from Zanata https://review.opendev.org/c/openstack/keystonemiddleware/+/1007362 | 03:58 |
|---|---|---|
| opendevreview | OpenStack Proposal Bot proposed openstack/keystone master: Imported Translations from Zanata https://review.opendev.org/c/openstack/keystone/+/1007372 | 04:03 |
| opendevreview | Merged openstack/keystone master: Remove leading space from operation path user policy https://review.opendev.org/c/openstack/keystone/+/990574 | 07:48 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone-specs master: Propose write-only credentials and S3 signing-key exchange https://review.opendev.org/c/openstack/keystone-specs/+/1011634 | 11:07 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone-specs master: Propose write-only credentials and S3 signing-key exchange https://review.opendev.org/c/openstack/keystone-specs/+/1011634 | 11:25 |
| opendevreview | Stephen Finucane proposed openstack/keystoneauth master: typing: Accept Adapters in discover https://review.opendev.org/c/openstack/keystoneauth/+/1011642 | 12:25 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone master: OS-EC2: stamp app_cred_id like /v3/credentials https://review.opendev.org/c/openstack/keystone/+/1008795 | 12:25 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone master: EC2/S3 auth: honour delegation expires_at https://review.opendev.org/c/openstack/keystone/+/1008796 | 13:14 |
| opendevreview | Merged openstack/keystonemiddleware master: Enable ignored ruff rules https://review.opendev.org/c/openstack/keystonemiddleware/+/1006500 | 13:37 |
| opendevreview | Artem Goncharov proposed openstack/keystonemiddleware master: WIP: add SPIFFE mTLS transport option https://review.opendev.org/c/openstack/keystonemiddleware/+/1005601 | 14:30 |
| opendevreview | Artem Goncharov proposed openstack/keystonemiddleware master: Add SPIFFE based mTLS transport option https://review.opendev.org/c/openstack/keystonemiddleware/+/1005601 | 14:31 |
| gtema | #startmeeting keystone | 15:02 |
| opendevmeet | Meeting started Wed Oct 21 15:02:41 2026 UTC and is due to finish in 60 minutes. The chair is gtema. 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 |
| gtema | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:02 |
| d34dh0r53 | #startmeeting keystone | 15:02 |
| opendevmeet | d34dh0r53: Error: Can't start another meeting, one is in progress. Use #endmeeting first. | 15:02 |
| gtema | #link https://openinfra.dev/legal/code-of-conduct | 15:03 |
| d34dh0r53 | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:03 |
| gtema | #topic roll call | 15:03 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:03 |
| gtema | bbobrov, d34dh0r53, xek, dmendiza[m], dmendiza, mharley, jph, gtema, cardoe, deydra | 15:03 |
| d34dh0r53 | #topic roll call | 15:03 |
| gtema | lol | 15:03 |
| gtema | go on, Dave Wilde (d34dh0r53) | 15:03 |
| d34dh0r53 | oops, sorry @gte | 15:03 |
| gtema | no worries, go on | 15:04 |
| gtema | I will need to jump off shortly in 30 min, so would be nice if you just continue the meeting | 15:04 |
| d34dh0r53 | cool, will do | 15:05 |
| d34dh0r53 | I’ll wait a minute for roll call | 15:05 |
| gtema | seems we have again a forest without trees | 15:06 |
| d34dh0r53 | indeed | 15:07 |
| d34dh0r53 | #topic review past meeting work items | 15:07 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2026 | 15:07 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-10-07-15.04.html | 15:08 |
| d34dh0r53 | nothing from last meeting | 15:08 |
| d34dh0r53 | #topic liaison updates | 15:08 |
| d34dh0r53 | nothing from me | 15:08 |
| gtema | neither from me | 15:08 |
| d34dh0r53 | #topic specification Secuirty Compliance Testing (dmendiza) | 15:08 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/devstack/+/957969 | 15:08 |
| d34dh0r53 | [dmendiza](https://matrix.to/#/@dmendiza:matrix.org) around? | 15:10 |
| dmendiza[m] | 🙋♂️ | 15:11 |
| dmendiza[m] | Here, but no updates on Compliance Testing | 15:12 |
| d34dh0r53 | cool | 15:12 |
| d34dh0r53 | #topic specification User Specified Project/User UUIDs (dmendiza, alee) | 15:12 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/997320 | 15:12 |
| gtema | I still haven't posted another review to the projects/domains. There is a compiled list of findings (inconsistencies or corrupted samples, etc), but nothing conceptual | 15:14 |
| gtema | for others I posted conceptual reviews | 15:14 |
| gtema | and I still would like to see the detailed description of the real use case why it is required to verify it end2end | 15:15 |
| d34dh0r53 | ack | 15:17 |
| d34dh0r53 | thanks for those reviews | 15:17 |
| d34dh0r53 | #topic keystone-rs (gtema) | 15:17 |
| d34dh0r53 | #link https://github.com/openstack-experimental/keystone | 15:17 |
| gtema | working this week on DPoP implementation for oauth2 | 15:17 |
| gtema | half way through | 15:17 |
| gtema | I think this is something what would be relatively easy to adopt openstack-wide since it's only the keystoneauth and keystonemiddleware change | 15:18 |
| gtema | the other thing I work on is the service grants and on-behalf-exchange (as a replacement for trusts), but whether this will ever be adopted in openstack I unfortunately doubt | 15:19 |
| gtema | there is no light at the end of the tunnel | 15:19 |
| cardoe | o/ (o | 15:19 |
| gtema | I started thinking on the re-branding of the project | 15:19 |
| gtema | that's it for this week | 15:20 |
| cardoe | I've got some suggestions there gtema | 15:20 |
| gtema | really? shoot them | 15:20 |
| cardoe | So I think you propose some modules that can be used. Like move all of one piece as a rust library and package it into pypi so that keystone can consume it. | 15:21 |
| cardoe | and that can be a shared piece to both rust keystone and python keystone and that'll get folks to feel better about the migration | 15:22 |
| cardoe | I think they're stuck on a big switch | 15:22 |
| gtema | isn't it cheating? The point is to have a compiled binary doing tls termination and cryptographic validation | 15:22 |
| gtema | is there a way to package binary into python? I though it was only like a "lib" | 15:23 |
| cardoe | But a proposal along those lines would be easier to swallow by some folks | 15:23 |
| cardoe | They already depend on cryptography | 15:23 |
| gtema | folks showed they have no interest even discussing possibilities | 15:23 |
| gtema | if you remember we started as an "extension", and it can be still treated this way | 15:24 |
| cardoe | The fear is that keystone isn't going to get any support until a massive switch over. | 15:24 |
| cardoe | Rather than opening the door, let's open the window a little bit. | 15:25 |
| gtema | it doesn't get it even no, so there is no real difference to be honest. Our problem is that we cannot address some challenges without dramatically changing the deployment model | 15:25 |
| cardoe | Or put a different way | 15:25 |
| gtema | I get what you mean, but right now I do not really know how this can be really implemented | 15:25 |
| cardoe | How do you eat an elephant? One bite at a time. | 15:25 |
| gtema | first one need to align that one is going to eat an elephant, this is where we are now | 15:26 |
| cardoe | Don't tell the elephant you're eating it. | 15:26 |
| gtema | honestly speaking I ran out of ideas and arguments | 15:26 |
| cardoe | Tell it you're just nibbling on it. | 15:26 |
| gtema | maybe we can talk off-the meeting to align. I really do not have an idea so far how to proceed | 15:27 |
| gtema | feel free to ping me after the meeting if you have ideas on what I can change in the proposal | 15:28 |
| gtema | I think that's it on the topic for now | 15:30 |
| gtema | seems Dave Wilde (d34dh0r53) is afk now | 15:33 |
| gtema | #topic open discussion | 15:33 |
| cardoe | I've got a handful of patches I'd like to bring up. | 15:33 |
| cardoe | I'm gonna start doing like we've done in ironic where we set a hashtag on patches we want cores to look at | 15:33 |
| cardoe | I'll make something like cardoe-interest | 15:33 |
| cardoe | https://review.opendev.org/c/openstack/keystone/+/996105 | 15:33 |
| cardoe | https://review.opendev.org/c/openstack/keystone/+/1002333 (which is a backport, and I'm not gonna link the other stable branches) | 15:34 |
| cardoe | https://review.opendev.org/c/openstack/keystone/+/1011160 (for python 3.14 support) | 15:35 |
| cardoe | The first one was cleaning up an error around unsupported grant_type | 15:35 |
| cardoe | https://review.opendev.org/c/openstack/keystone/+/1011168 fixes a missing decoding that leads to a typeerror | 15:36 |
| gtema | for the first one I think we can define a time-box by end of the week since I reviewed it already | 15:36 |
| gtema | and Greg wrote, so if no other core reviews I will merge it by the end of the week | 15:36 |
| cardoe | https://review.opendev.org/c/openstack/keystone/+/981321 adds a test for something that can be done today | 15:36 |
| cardoe | https://review.opendev.org/c/openstack/keystone/+/1010040 is a fix for when we're syncing external keys in | 15:37 |
| gtema | oh yeah, I noticed this change and was wondering about it | 15:37 |
| cardoe | So that's in our public facing keystones (that Zuul uses for testing). They're syncing those keys from the internal to public keystone | 15:39 |
| cardoe | And during that sync it hits that | 15:39 |
| gtema | allright, good to know | 15:39 |
| cardoe | https://review.opendev.org/c/openstack/keystone/+/1007755 We're not using this yet but we've got interest in tracing with OTel in the future. | 15:40 |
| gtema | I am leaving all those as tabs to review | 15:40 |
| gtema | anything else? | 15:41 |
| gtema | #topic bug review | 15:42 |
| gtema | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:42 |
| gtema | this one is keystone itself. There are quite a few new bugs. I would not post all them here since some are security relevant and I don't want to accidentally put the wrong link | 15:43 |
| d34dh0r53 | sorry, had something come up | 15:43 |
| gtema | in anyway - quite some keystone bugs that cores should look at | 15:44 |
| cardoe | https://paste.opendev.org/show/bplFf1eyoRF5FfYTt5tH/ btw is the backtrace for the federated system scope | 15:44 |
| gtema | no problem Dave Wilde (d34dh0r53) | 15:44 |
| gtema | cardoe, thanks, but I want to see the full flow of the authentication. I am not keen to simply land the "fix", because I believe it addresses the consequence and not the root cause. I want to be sure we get the root cause covered | 15:45 |
| gtema | anyway I see some debugging info in the trace that already helps to some degree | 15:46 |
| gtema | but it doesn't show as a federated payload at all | 15:47 |
| gtema | anyway, will look deeper, but appreciate if you could have a full repro for it | 15:48 |
| gtema | going next | 15:48 |
| gtema | keystoneclient | 15:48 |
| gtema | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 15:48 |
| gtema | not sure we looked at 2w old https://bugs.launchpad.net/python-keystoneclient/+bug/2169595 | 15:48 |
| gtema | for the sake of the time there is one brand new bug in ksm | 15:50 |
| gtema | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 15:50 |
| gtema | #link https://bugs.launchpad.net/keystonemiddleware/+bug/2171551 | 15:50 |
| gtema | I briefly spotted there was some discussion in the channel during my late evening/night time | 15:51 |
| gtema | #topic conclusion | 15:54 |
| gtema | thanks a lot folks | 15:54 |
| d34dh0r53 | thanks Artem | 15:55 |
| gtema | whenever there are general question people should prefer pinging members directly rather than writing into the channel since we have this bloody time zone issue | 15:55 |
| gtema | so lot of questions land somehow when nobody is live | 15:55 |
| gtema | #endmeeting | 15:55 |
| opendevmeet | Meeting ended Wed Oct 21 15:55:58 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:55 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-10-21-15.02.html | 15:55 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-10-21-15.02.txt | 15:55 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-10-21-15.02.log.html | 15:55 |
| cardoe | So with that backtrace... fundamentally I don't want my keystone to crash when I'm using federation and someone requests a system scoped token. TBH we could consider this a possible denial of service. | 16:00 |
| cardoe | The issue is https://opendev.org/openstack/keystone/src/commit/f7c4c44a9220b16001cc5e9384647868c748bb16/keystone/token/providers/fernet/core.py#L50 MUST return one of those classes and there's a case that it can return None | 16:00 |
| cardoe | And that causes a crash today | 16:01 |
| cardoe | My original patch took the same behavior of the non-federated case... if the scope is unknown to the code... treat it as unscoped... https://review.opendev.org/c/openstack/keystone/+/975342 | 16:02 |
| cardoe | My original change didn't add FederatedSystemScope at all. | 16:03 |
| cardoe | It just made the code defensive. | 16:03 |
| gtema | this change is not making code defensive, it introduces the new payload which brings own issues with it. And as I said exactly the if and crash above shows that initial token comes corrupted and I want to figure out how come | 16:05 |
| cardoe | No I'm not adding a new payload | 16:08 |
| cardoe | Look at https://opendev.org/openstack/keystone/src/commit/f7c4c44a9220b16001cc5e9384647868c748bb16/keystone/token/providers/fernet/core.py#L50 | 16:08 |
| cardoe | If you're scope is unknown you go to line 73 | 16:09 |
| cardoe | But if you're federated, you go to line 55 first and then if you scope is unknown you don't return anything and so in Python that's None by default. | 16:09 |
| cardoe | I just want the line 55 block to return the same thing as line 73 | 16:10 |
| gtema | ah yes, this is absolutely fine for me, but as said it feels like it is addressing the consequence of the bug | 16:10 |
| cardoe | Boris is saying that I need to add a FederatedSystemScope class and return that. | 16:10 |
| cardoe | But we'd still have the "drop out and return None" potential issue | 16:11 |
| gtema | fallback at unscoped looks sane, but it eventually grants escapes from bounds, so yes, it need to be done carefully | 16:13 |
| gtema | that's the whole reason I want to move away from fernet - it masks a lot of useful data and we can't expand it reasonably | 16:13 |
| gtema | I mean e.g., when you have application_credential payload most of the checks to control scoping are done based exactly on the fact that it was an application_credential payload | 16:14 |
| gtema | so if you downsize it to simply unscoped token you loose bounds | 16:14 |
| gtema | federated tokens have different thing - you need to always keep the fact user authed through federation, casting to unscoped token means the info is lost | 16:15 |
| cardoe | I understand. | 16:19 |
| cardoe | The other option is that we raise instead of returning None and then all callers need to handle that raise | 16:19 |
| cardoe | I can do this against public providers that allow me to create a federation connection in keystone. | 16:20 |
| gtema | right, but I really want to understand with which state we end in this method that fails. For some reason the backtrace shows that it was considered as federated token, but with a weird scope - I want to understand what is this state and how it got here | 16:21 |
| gtema | would appreciate, I was never able to repro this since I never used skyline | 16:21 |
| cardoe | Well I can do it without skyline | 16:24 |
| cardoe | Any clouds.yaml entry to auth with a federated account and just set "system_scope: all" | 16:25 |
| cardoe | you can do it on devstack in the keycloak test | 16:26 |
| gtema | ah so, I wish you could have posted this to the bug. This is something I can try to reproduce myself and do a deeper debug | 16:28 |
| cardoe | tkajinam: wondering if there's something different then the suggested fix in https://bugs.launchpad.net/keystonemiddleware/+bug/2171551 we should do? | 19:19 |
| opendevreview | James Denton proposed openstack/keystone master: Skip non-numeric files before opening fernet keys https://review.opendev.org/c/openstack/keystone/+/1010040 | 22:13 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!