April 2026 - openstack-discuss - lists.openstack.org

[OSSA-2026-007] OpenStack Keystone: LDAP identity backend does not convert enabled attribute to boolean (CVE PENDING)
by Goutham Pacha Ravi 05 Aug '26

05 Aug '26

================================================================================== OSSA-2026-007: LDAP identity backend does not convert enabled attribute to boolean ================================================================================== :Date: April 14, 2026 :CVE: CVE-2026-pending Affects ~~~~~~~ - Keystone: >=8.0.0 <25.0.1, >=26.0.0 <26.1.1, >=27.0.0 <27.0.1, >=28.0.0 <28.0.1 Description ~~~~~~~~~~~ Benedikt Trefzer and Andrew Bogott independently reported a vulnerability in the Keystone LDAP identity backend. When the user_enabled_invert configuration option was False (the default), Keystone did not correctly interpret the LDAP enabled attribute, causing users disabled in LDAP to be treated as enabled and allowed to authenticate. Deployments using the LDAP identity backend without user_enabled_invert=True or user_enabled_emulation are affected. Patches ~~~~~~~ -https://review.opendev.org/982409 (2024.2/dalmatian) -https://review.opendev.org/982408 (2025.1/epoxy) -https://review.opendev.org/982407 (2025.2/flamingo) -https://review.opendev.org/958205 (2026.1/gazpacho) Credits ~~~~~~~ - Benedikt Trefzer from Cirrax GmbH (CVE-2026-pending) - Andrew Bogott from Wikimedia Foundation (CVE-2026-pending) - Grzegorz Grasza from Red Hat (CVE-2026-pending) References ~~~~~~~~~~ -https://launchpad.net/bugs/2121152 -https://launchpad.net/bugs/2141713 Notes ~~~~~ - To work around this vulnerability, set user_enabled_invert=True and use an LDAP attribute with inverted semantics such as nsAccountLock, or use user_enabled_emulation with group-based enabled status. - A CVE request was filed with MITRE on 2026-04-10. - The fix was merged on the master branch before the stable/2026.1 branch was cut, so no specific stable/2026.1 patch exists. The fix is included in the gazpacho (29.0.0) release. -- Goutham Pacha Ravi (gouthamr) OpenStack Vulnerability Management Team

1 1

[policy] Removing the enforce_scope config option
by Ghanshyam Maan 17 Jul '26

17 Jul '26

Hello everyone, As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle to remove this flag. What does this mean: ----------------------------- Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project can catch this exception and raise the modified error message similar to PolicyNotRegistered. Action item on projects: ------------------------------- 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change to remove it and would like to request that the project maintainer look into the changes/failure. 2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For example nova unit tests[3]. How to test your project: I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in your project jobs in 'required_project' field and depends-on the oslo.policy change (986475) oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479 Tracking and deadline: ------------------------------ Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies. - https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(statu… I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing enforce_scope. [1] https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.en… [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a… -gmaan

3 13

[zun] Service is broken for 2026.1 with constrained oslo_db
by Dmitriy Rabotyagov 16 Jun '26

16 Jun '26

Hey there, I wanted to let the community know, that Zun service has been released in a broken state for the 2026.1 and is not passing CI tests with constrained version of oslo.db [1], due to reliance on the legacy engine facade, which has been removed from the oslo.db for 2026.1 With that, patch fixing Zun for 2026.1 was published around a month ago, with no reviews from the Zun Core Reviewers group. It would be really appreciated if somebody from the Zun team could have a look at the state of the gates, and merge/backport required patches to ensure working state of the service. Thanks in advance. [1] https://opendev.org/openstack/requirements/src/commit/7e07cb254ee7786723be7… [2] https://review.opendev.org/c/openstack/zun/+/982362

1 1

[barbican][oslo][nova][glance][cinder] cursive library status
by Brian Rosmaita 26 May '26

26 May '26

Hello Barbican team, Apologies for not including barbican in the previous thread on this topic: http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019430… The situation is that cursive is used by Nova, Glance, and Cinder and we'd like to move it out of the 'x' namespace into openstack governance. The question is then what team would oversee it. It seems like a good fit for Oslo, and the Oslo team seems OK with that, but since barbican-core is currently included in cursive-core, it make sense to give the Barbican team first dibs. From the consuming teams' side, I don't think we have a preference as long as it's clear who we need to bother about approvals if a bugfix is posted for review. Thus my ask is that the Barbican team indicate whether they'd like to move cursive to the 'openstack' namespace under their governance, or whether they'd prefer Oslo to oversee the library. Thank you! brian

6 6

[ops][nova] Performance problems in nova-api after Caracal → Epoxy update (and nova validators)
by federica fanzago 25 May '26

25 May '26

Dear all, summarizing the problem as much as possible, we have seen serious (blocking) performance problems after a Caracal → Epoxy update (on almalinux9 using RDO) that we were able to address only disabling the response_body_schema and query_schema nova validators. In more detail: to prepare the Caracal → Epoxy update of our production cloud, we have tried such update on a small testbed, composed by two controllers and four compute nodes.Please note that this testbed was initially installed using kilo, and then this cloud was regularly updated. There is a haproxy cluster in front of these 2 controllers, providing load balancing and also SSL terminations. The haproxy cluster uses OPTIONS nova webAPI for polling the service. As we already reported in this mailing list, after having updated the two controllers and one compute node everything seems ok, but the cpu usage of the node started increasing, as shown in the following Ganglia monitor dashboard: The processes consuming a lot of CPU are nova-api: after a couple of days they use 100% cpu of their thread (we are using 4 nova-api workers and the controller nodes have 8 cores), and everything becomes basically unusable. In particular we can see the problem trying to create a new VM: it takes a lot of time showing the list of available flavors (and often the operation fails). It looks like the checks done by the haproxy are enough to trigger the problem. This is the relevant section for nova-api in the haproxy conf file: frontend nova-api-public_infn bind <public-ip>:8774 ssl no-sslv3 crt /etc/cert/cloud-areapd_test_infn_chain_key.pem mode http option httpclose option forwardfor http-request set-header X-Forwarded-Proto https if { ssl_fc } default_backend nova-api-public frontend nova-api-public_unipd Bind <public-ip2>:8774 ssl no-sslv3 crt /etc/cert/cloud-areapd_test_unipd_chain_key.pem mode http option httpclose option forwardfor http-request set-header X-Forwarded-Proto https if { ssl_fc } default_backend nova-api-public backend nova-api-public mode http balance source option httpchk server controller-01.cloud.pd.infn.it 192.168.60.42:8774 check inter 2000 rise 2 fall 3 server controller-02.cloud.pd.infn.it 192.168.60.45:8774 check inter 2000 rise 2 fall 3 Attaching using strace to a nova-api process, we noticed that the calls to OPTIONS or GET (version) webAPIs trigger some “cryptographic calls” that we didn’t see in Caracal, e.g.: getrandom("\xdb\x08\x41\x11\x9b\x4a\x66\xc9\x14\x6d\x7d\xa2\xb3\xad\xf1\x79", 16, 0) = 16 getrandom("\xa2\x09\xbe\xcc\xa4\x60\x2a\xed\x21\xe1\x01\x1f\x21\xe8\x8c\x4c", 16, 0) = 16 getrandom("\x6f\xd0\x7b\xcf\x7c\xbb\x5f\x43\x78\xf8\xb8\xc6\x72\x45\xe8\x63", 16, 0) = 16 getrandom("\xc1\xc5\x58\x37\xaa\x0b\x85\x90\x61\xf9\x7e\xce\x42\x85\x1c\x9f", 16, 0) = 16 We presumed that the PRNG is somehow invoked by the schema validators. We then tried to disable the validation.response_body_schema(setting response_validation=ignore in nova.conf). This didn’t fix the problem (even if we noticed some improvement). We then disabled the *query_schema* (we had to patch the code) and this definitely helped: after some days we haven’t been seeing anymore the problem and the cpu usage doesn’t increase, as shown in the following picture: Please note that we are running AlmaLinux9 and we are using the latest rpm version from the RDO distribution. That means for nova we are using the version 31.0.0, which is not the latest version (since the packages in the RDO repo haven’t been updated after the initial epoxy release) but looking in the release note we don't find anything related to a problem with this symptom fixed in newer versions). We were told about a problem with similar symptoms (https://bugs.launchpad.net/nova/+bug/2121607) but we are not using those versions of python-jsonschema/python-attrs. Has anyone experienced similar problems ? Can you see/guess where the problem could be ? E.g. do you see problems in the haproxy configuration ? Are there known issues in these 2 nova validators ? How safe is disabling them ? Is it possible to disable the query_schema validator in a cleaner way than modifying the code ? Any help will be really appreciated ! Thanks a lot, cheers, Federica -- Federica Fanzago INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy Tel: +39 049.967.7367 --

2 2

[kolla] kolla-core and kolla-reviewers proposed changes
by Michał Nasiadka 12 May '26

12 May '26

Hello, Kolla cores had a discussion about the current state of the core team, and we propose following changes. 1. Move an existing and long time Kolla-core to emeritus status: * Christian Berendt (cberendt) Christian has been a core reviewer for a long time, but sadly now he’s not that active anymore (no activity for the past year) - so we propose to move him to Emeritus status. This just means that while he may be removed from the team, if at some future point he returns to the Kolla community we may expedite his return to the core group. 2. Move an existing, but with minimum activity kolla-core to kolla-reviewers group: * Michal Arbet (kevko) While we value his contributions and technical insight on the reviews - we want to ensure that the final merge step is handled by those with real-time visibility into the latest commits and dependencies. 3. Last, but not least - promote the inaugural member of kolla-reviewers group to kolla-core. He has used his +2 judiciously, has been very active and tracking development priorities and have earned the trust of the community to use that same judgement about which changes to approve: * Bertrand Lanson (blanson) Thanks everyone for your contributions to Kolla, current and future. I’ll wait a week for responses to that proposal and implement given no critical feedback. Michal

6 5

[policy][tc] RBAC global auditor (reader)
by Ghanshyam Maan 07 May '26

07 May '26

Hi All, We discussed the need for a global auditor (reader across all projects/system-level) back in the Vancouver 2023 session, and all agreed that this is a good idea. For ironic and keystone, the solution is a system-level reader; for all other services, we have a reader scoped to the project only, with no reader that can read across projects. Cardoe brought up this use case today in the TC IRC channel, which was a reminder to me that we agreed on the idea but had not progressed on it. I would like to call this out on ML and ask for a volunteer who can start the work, which includes the spec in Keystone (example manager role) and working items mentioned in 'Work Items' [1]. I will not be able to help in implementation, but happy to help in review. [1] https://review.opendev.org/c/openstack/keystone-specs/+/818603/5/specs/keys… -gmaan

9 14

Reviewing Oslo core group memberships.
by Daniel Mats Niklas Bengtsson 07 May '26

07 May '26

Hi, I was thinking it might be a good time to review the oslo core groups memberships. Over time, some members may have become inactive, and doing a periodic cleanup could help ensure that the groups accurately reflect the current active maintainers. Would you agree with doing a review of the current memberships across the oslo projects? If there is consensus, I can help prepare a proposal listing potentially inactive members for discussion before making any changes. Thanks!

3 2

[stackalytics] no "neutron" module for Commits
by Ihar Hrachyshka 07 May '26

07 May '26

Hi, I noticed that "neutron" is not an option in the Module list when Commits are selected, and no neutron commits are registered since ~Oct 2023. On the other hand, other Neutron program repos (e.g. neutron-lib and neutron-tempest-plugin) are available in the list and do register commits. Also, when Reviews are selected, neutron module is back as an option, and review stats are correctly updated. I checked governance yaml and it doesn't strike me as incorrect: https://opendev.org/openstack/governance/src/commit/5f93b99a3c90b452f6c7368… Any ideas what may have happened? Thanks, Ihar

5 10

[neutron] tap-as-a-service-core group updates
by Brian Haley 06 May '26

06 May '26

Hi Neutrinos, As discussed at our PTG meeting, I will be adding Miro Tomaska to the tap-as-a-service-core group - he as made a number of contributions to Neutron over the years and has agreed to take a more active role in Tap-as-a-service maintenance going forward. Welcome Miro and good luck! I have also taken this time to clean-up the group and remove some members who are no longer active - Anil Rao, Kazuhiro Suzuki, Soichi Shigeta, Yamamoto Takashi and Vinay Yadhav. Thank you for all your previous contributions! -Brian, Neutron PTL

2 1