| *** fungi is now known as Guest9249 | 01:33 | |
| *** kinrui is now known as fungi | 01:41 | |
| *** mhen_ is now known as mhen | 02:35 | |
| opendevreview | Stanislav Zaprudskiy proposed openstack/keystone master: Support emitting partial hash of invalid password https://review.opendev.org/c/openstack/keystone/+/932423 | 15:01 |
|---|---|---|
| d34dh0r53 | #startmeeting keystone | 15:02 |
| opendevmeet | Meeting started Wed Nov 13 15:02:26 2024 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 | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:02 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:03 |
| d34dh0r53 | #topic roll call | 15:03 |
| d34dh0r53 | admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek, gmann, zaitcev, reqa, dmendiza[m], dmendiza, mharley, jph, gtema, cardoe | 15:03 |
| cardoe | o/ | 15:04 |
| gtema | o/ | 15:04 |
| d34dh0r53 | o/ | 15:04 |
| d34dh0r53 | #topic review past meeting work items | 15:06 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-10-30-15.05.html | 15:06 |
| d34dh0r53 | no action items from our last meeting | 15:06 |
| d34dh0r53 | #topic liaison updates | 15:07 |
| d34dh0r53 | nothing from VMT or releases | 15:07 |
| d34dh0r53 | #topic specification OAuth 2.0 (hiromu) | 15:09 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | 15:09 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability | 15:09 |
| d34dh0r53 | External OAuth 2.0 Specification | 15:09 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged) | 15:09 |
| d34dh0r53 | OAuth 2.0 Implementation | 15:09 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls | 15:09 |
| d34dh0r53 | OAuth 2.0 Documentation | 15:09 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged) | 15:09 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged) | 15:09 |
| d34dh0r53 | no updates from me unfortunately, stuck in federation land | 15:10 |
| d34dh0r53 | next up | 15:10 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza[m]) | 15:10 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:10 |
| d34dh0r53 | 2024.1 Release Timeline | 15:10 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:10 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:10 |
| d34dh0r53 | not sure if dmendiza is around or not | 15:10 |
| d34dh0r53 | guess not, next up | 15:12 |
| d34dh0r53 | #topic specification OpenAPI support (gtema) | 15:12 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone | 15:12 |
| d34dh0r53 | https://review.opendev.org/c/openstack/keystone/+/925020 could now also land to ease api-ref work | 15:12 |
| gtema | not so many changes from my pov except that statement above | 15:12 |
| gtema | revieving changes | 15:12 |
| gtema | * reviewing changes students produce | 15:13 |
| d34dh0r53 | ack, I'll look over your changes in that one | 15:13 |
| d34dh0r53 | thanks gtema (Artem Goncharov) | 15:14 |
| d34dh0r53 | next up | 15:14 |
| d34dh0r53 | #topic specification domain manager (mhen) | 15:14 |
| d34dh0r53 | still unmerged are: | 15:14 |
| d34dh0r53 | documentation: https://review.opendev.org/c/openstack/keystone/+/928135 | 15:14 |
| d34dh0r53 | tempest tests: https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/924222 | 15:14 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: Add new keystone.wsgi module https://review.opendev.org/c/openstack/keystone/+/932060 | 15:14 |
| d34dh0r53 | cores, please look at the domain manager things dmendiza , | 15:15 |
| d34dh0r53 | Grzegorz Grasza: ^^ | 15:16 |
| d34dh0r53 | next up | 15:16 |
| d34dh0r53 | #topic specification Type annotations (stephenfin) | 15:16 |
| d34dh0r53 | #link https://review.opendev.org/q/project:openstack/keystoneauth+topic:typing | 15:16 |
| d34dh0r53 | This is just pending reviews now. I will push the remaining patches as soon as a sufficient quantity of the current ones land. | 15:16 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/931959 - ruffing the keystone misses +W | 15:16 |
| gtema | Dave Wilde (d34dh0r53): you missed to approve few changes | 15:16 |
| gtema | I mean from the keystoneauth series | 15:16 |
| gtema | therefore 4 changes are still open | 15:17 |
| gtema | and release patch was proposed last week which I "-1"-ed | 15:17 |
| d34dh0r53 | oh snap, my bad, I'll get to those today | 15:17 |
| gtema | great | 15:17 |
| gtema | and ruff for keystone - you +2ed, but another one with +W is still missing | 15:18 |
| gtema | and that one is with huge merge-conflicts potential | 15:18 |
| gtema | so we need to get it quickly | 15:19 |
| d34dh0r53 | I'm the only reviewer on the ruff patch, I'd like another core to take a look if possible, dmendiza or Grzegorz Grasza | 15:19 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/931959 | 15:19 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: Enable projects pagination https://review.opendev.org/c/openstack/keystone/+/933598 | 15:21 |
| d34dh0r53 | next up | 15:21 |
| d34dh0r53 | #topic specification Include bad password details in audit messages (stanislav-z) | 15:21 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/915482 | 15:21 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/932423 | 15:21 |
| d34dh0r53 | 30-Oct update: significant spec update including feedback during PTG. WIP implementation test are WIP. | 15:22 |
| d34dh0r53 | 06-Nov update: some implementation tests are added, more tests TBD (WIP). Spec is looking for reviews. | 15:22 |
| d34dh0r53 | 13-Nov update: spec needs reviews, implementation now includes tests. | 15:22 |
| stanislav-z | Yeap, the spec is ready and is looking for reviews. The implementation is linked too - it's ready in accordance with what's currently written in the spec. | 15:22 |
| gtema | Stanislav Zaprudskiy: have you talked internally about the sha512_crypt? | 15:23 |
| gtema | or was it sha256 we talked about during PTG? | 15:24 |
| stanislav-z | it was sha256 during the PTG. but I decided to go with scrypt + PBDKF2 - as these are very tunable (with option to control the parameters via conf) - it's mentioned in the spec | 15:25 |
| stanislav-z | and also I went on with hashlib - it turned out to be faster than cryptography | 15:26 |
| stanislav-z | (I also referenced benchmark results in the spec) | 15:26 |
| gtema | ok | 15:27 |
| d34dh0r53 | thank you Stanislav Zaprudskiy | 15:30 |
| gtema | ah, we talked about sha256_hmac | 15:30 |
| gtema | I can't find any records of what we have discussed | 15:30 |
| stanislav-z | it's doing pbkdf2_hmac(sha512) + scrypt on top by default | 15:32 |
| gtema | as I mentioned during PTG I am still "uncomfortable" with partial hash | 15:33 |
| stanislav-z | why so? it's a hash of an invalid password. it's partial. it's hashed with functions used to hash passwords in DB. I had another review of the spec by our security expert, and from his perspective just sha-256 would have been enough as long as it's partial (5 chars or so) | 15:35 |
| gtema | I explained during PTG quite detailed about so. Of course it is "safe" if you just expose part of info, but other tools like vault simply output hmac-sha256 and do not care about any slicing what avoids any possible collision by definition | 15:37 |
| stanislav-z | config allows to not slice the hash, but return it in full | 15:38 |
| gtema | anyway - lets move discussion back to the spec | 15:39 |
| stanislav-z | good, thanks | 15:39 |
| d34dh0r53 | cool | 15:40 |
| d34dh0r53 | please review the spec | 15:41 |
| d34dh0r53 | next up | 15:41 |
| d34dh0r53 | #topic open discussion | 15:41 |
| d34dh0r53 | pagination (gtema) | 15:41 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22pagination%22+project:openstack/keystone | 15:41 |
| d34dh0r53 | it is bit more complex than I thought since all DB queries need to be executed with pagination while some internal calls right now expect to get ALL entries (i.e. list_domains/list_projects) | 15:41 |
| gtema | this appears to be quite a beast. But my push some minutes ago hopefully addresses all cornercases | 15:42 |
| gtema | biggest issue is that pagination in DB must be applied unconditionally. I mean there is no way to re-apply pagination after fetching results | 15:42 |
| gtema | and some parts of the code assume that when they invoke internal methods (like list_domains) bypassing the API will get all results | 15:43 |
| gtema | there are explicit tests on that | 15:43 |
| gtema | it is not trivial to deal with that but hopefully I have found a way | 15:44 |
| gtema | on the other hand - I have not much clue how to deal with pagination for the ldap | 15:44 |
| d34dh0r53 | yeah, not sure about that either | 15:47 |
| gtema | the only solution to that I see is to forcibly fetch all data (respecting all other filters) and simulate pagination | 15:48 |
| gtema | so it will not save keystone<->ldap traffic, but user<->keystone | 15:48 |
| gtema | well - that is very close to what happens now since keystone will truncate entries at configured limit | 15:49 |
| d34dh0r53 | yeah, that's what I was thinking, huge LDAP databases might present a performance problem though | 15:51 |
| gtema | I mean that it will not be more then what we have right now (I mean we still get all entries and truncate results) | 15:51 |
| gtema | but maybe the more funny question is how to paginate when some results come from DB while others from ldap? | 15:52 |
| gtema | I was not looking in detail over there yet, this is just speculative thought | 15:52 |
| d34dh0r53 | I guess that's true | 15:52 |
| d34dh0r53 | Need to move on for time | 15:53 |
| d34dh0r53 | #topic bug review | 15:53 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:53 |
| d34dh0r53 | no new bugs in keystone | 15:53 |
| d34dh0r53 | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 15:53 |
| d34dh0r53 | nor python-keystoneclient | 15:53 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 15:53 |
| d34dh0r53 | keystoneauth is good | 15:53 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 15:53 |
| d34dh0r53 | nothing new in keystonemiddleware | 15:53 |
| d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 15:54 |
| d34dh0r53 | pycadf is good | 15:54 |
| d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?ordterby=-id&start=0 | 15:54 |
| d34dh0r53 | so is ldappool | 15:54 |
| d34dh0r53 | #topic conclusion | 15:54 |
| d34dh0r53 | Thanks everyone! Nothing else from me today | 15:54 |
| d34dh0r53 | #endmeeting | 15:54 |
| opendevmeet | Meeting ended Wed Nov 13 15:54:41 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:54 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-11-13-15.02.html | 15:54 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-11-13-15.02.txt | 15:54 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-11-13-15.02.log.html | 15:54 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON Schema to `endpoints` and validation decorators to endpoints resource. https://review.opendev.org/c/openstack/keystone/+/927856 | 18:48 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON schema to `trust` and validation decorators to trust resource. https://review.opendev.org/c/openstack/keystone/+/930361 | 19:10 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON Schema to `endpoint groups` and validation decorators to endpoint groups resource. https://review.opendev.org/c/openstack/keystone/+/929686 | 19:18 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON schema to `trust` and validation decorators to trust resource. https://review.opendev.org/c/openstack/keystone/+/930361 | 19:47 |
| *** tkajinam is now known as Guest9338 | 22:33 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!