Debian Patches

Status for keystone/2:27.0.0-3+deb13u4

Patch Description Author Forwarded Bugs Origin Last update
CVE-2026-40683-OSSA-2026-007-fix_ldap_enabled_setting_not_interpreted_as_boolean.patch OSSA-2026-007: fix ldap 'enabled' setting not interpreted as boolean interpretation of the ldap enabled attribute as boolean
is only done if enabled_invert setting is set to true.

diff --git a/keystone/identity/backends/ldap/core.py b/keystone/identity/backends/ldap/core.py
index 5ddf14d..fd09c7c 100644		 Benedikt Trefzer <benedikt.trefzer@cirrax.com> yes debian upstream upstream, https://review.opendev.org/c/openstack/keystone/+/982408 2026-04-15
0001-Add-tests-for-restricted-app-cred-guard.patch [PATCH 1/5] Add tests for restricted app cred guard
Verify that the _check_unrestricted_application_credential guard on
the OS-EC2 credential create endpoint blocks restricted application
credentials from creating EC2 credentials, while still allowing
unrestricted application credentials to do so.

(cherry picked from commit c87ce6ed435f01431343d6b2bb6697a640514d27)		 Boris Bobrov <b.bobrov@sap.com> no 2026-04-07
0002-Block-restricted-app-creds-from-creating-EC2-credent.patch [PATCH 2/5] Block restricted app creds from creating EC2 credentials via /credentials

The POST /v3/credentials endpoint accepted EC2 credential creation
from restricted application credential tokens, bypassing the guard
on the dedicated OS-EC2 endpoint. Add the same unrestricted
application credential check to the generic credentials API for
EC2-type credentials, and update the existing test to use an
unrestricted application credential.

(cherry picked from commit d6a3dc511057d6ac25bd2d75776a4233c5608684)		 Boris Bobrov <b.bobrov@sap.com> no 2026-04-07
install-missing-files.patch install missing files Thomas Goirand <zigo@debian.org> not-needed 2019-08-18
do-not-set-chartset-in-flask-responce.patch Do not set charset in flask responce
===================================================================		 Thomas Goirand <zigo@debian.org> no 2024-01-22
set-deprecation-warnings-to-ignore.patch Set deprecation warnings to ignore Otherwise, Keystone FTBFS in Unstable. Thomas Goirand <zigo@debian.org> no 2025-03-13
api_Remove_constraints_on_user_IDs.patch api: Remove constraints on user IDs Per the comment added inline, this is not valid when LDAP is in use.

===================================================================		 Stephen Finucane <stephenfin@redhat.com> yes upstream upstream, https://review.opendev.org/c/openstack/keystone/+/951282 2025-05-20
keystone-bug-2119646-stable-2025.1.patch Add service user authentication to ec2 and s3 endpoints Add a policy to enforce authentication with a user in the service
group. This maintains AWS compatibility with the added security
layer.

===================================================================		 Grzegorz Grasza <xek@redhat.com> yes upstream https://bugs.launchpad.net/keystone/+bug/2119646 2025-10-30
CVE-2026-33551~OSSA-2026-005_Prevent_unauthorized_EC2_credential_creation_and_deletion.patch Prevent unauthorized EC2 credential creation and deletion A restricted application credential could be used to create EC2
credentials granting full user access to S3, bypassing the role
restriction. Add the same _check_unrestricted_application_credential
guard that already protects application credential create/delete
endpoints.
.
Additionally, tighten the ec2_create_credential and ec2_delete_credential
policies to require at least member role, as these are write operations
that should not be accessible to reader-role users regardless of whether
they are using an application credential.

diff --git a/keystone/api/users.py b/keystone/api/users.py
index b3ec13f..f614f1c 100644		 Grzegorz Grasza <xek@redhat.com> yes debian upstream upstream, https://review.opendev.org/c/openstack/keystone/+/983589 2026-04-10
0003-Block-app-cred-tokens-from-authorizing-OAuth1-reques.patch [PATCH 3/5] Block app cred tokens from authorizing OAuth1 requests
The OAuth1 authorize endpoint checked is_delegated_auth to block
trust-scoped and OAuth-scoped tokens from authorizing request
tokens, but application credential tokens were not covered by
this check. A restricted application credential could authorize
a request token with any role the user actually holds, producing
an access token that yields an unrestricted Keystone token with
roles beyond the application credential's restricted set.

Add an explicit check for application credential tokens on the
OAuth1 authorize endpoint, consistent with how trust-scoped and
OAuth-scoped tokens are already blocked.

(cherry picked from commit 29246c5fd8d1dafbe6cc8cec4c57faf5590cd44e)		 Boris Bobrov <b.bobrov@sap.com> no 2026-04-07
0004-Enforce-app-cred-project-boundary-on-EC2-credential-.patch [PATCH 4/5] Enforce app cred project boundary on EC2 credential paths
POST /v3/credentials did not validate that the caller-supplied
project_id for an EC2-type credential matched the project of the
authenticating application credential. This allowed an attacker
holding an unrestricted application credential for project A to
create an EC2 credential targeting project B; a subsequent
/v3/ec2tokens exchange would then issue a Keystone token scoped to
project B while still carrying the original app_cred_id, enabling
cross-project lateral movement within the credential owner's role
footprint.

Two fixes:

1. credentials.py: after extracting app_cred_id from the token,
check that credential['project_id'] == app_cred['project_id']
for EC2-type credentials and raise ForbiddenAction otherwise.

2. EC2_S3_Resource.py: in handle_authenticate(), assert that the
stored EC2 credential project_id matches the application
credential's project before issuing the token.

This issue is orthogonal to CVE-2026-33551 (LP#2142138 / Gerrit
983655), which blocks restricted application credentials from
creating EC2 credentials at all. The project-boundary check is
absent regardless of the restricted flag and requires separate
treatment.

(cherry picked from commit b6fd80996b882890a51f3e2aab41d952d7ff68ae)
(cherry picked from commit d9e18a37888cabdea919c58b24f630fd722aa8b0)		 Grzegorz Grasza <xek@redhat.com> no 2026-04-22
0005-Use-branch-constraints-for-tempest-venv-on-stable-20.patch [PATCH 5/5] Use branch constraints for tempest venv on stable/2025.1
The stable/2025.1 gate is completely broken for all Keystone changes.
The grenade, grenade-skip-level, k2k federation, and other devstack-
based jobs fail during configure_tempest because tox creates a 'venv'
environment using master's upper-constraints.txt, which pins
Sphinx===9.0.4. This conflicts with tempest's doc/requirements.txt
(sphinx>=2.0.0,!=2.1.0), producing a ResolutionImpossible error from
pip. No Keystone code executes before the failure.

Fix this by setting TEMPEST_VENV_UPPER_CONSTRAINTS to the branch-
specific constraints file from the locally cloned requirements repo.
DevStack already supports this: when the variable is set to a file
path (not "master"), set_tempest_venv_constraints in lib/tempest
reads the file and exports UPPER_CONSTRAINTS_FILE pointing to it.
The cloned requirements repo on each branch has a compatible Sphinx
pin, eliminating the resolution conflict.

For grenade jobs, the variable is set via grenade_devstack_localrc
(shared) so it applies to both old-side and new-side devstack. On
the old side (stable/2024.2), $DEST expands to /opt/stack/old and
the requirements repo is cloned from stable/2024.2. On the new side,
$DEST is /opt/stack/new with stable/2025.1 constraints. Both have
Sphinx pins compatible with their respective tempest versions.

This is a standalone CI configuration change, separate from change
988237 (the EC2 credential policy fix that was blocked by this gate
failure).		 "Dave Wilde (d34dh0r53)" <dwilde@redhat.com> no 2026-05-19
CVE-2026-43001-2025.1.v4.patch [PATCH 1/5] Enforce delegation project boundary for delegated tokens Delegated tokens (trusts, application credentials, OAuth1 access tokens)
are scoped to a single project at delegation time. This must be enforced
thoroughly while granting the API access to Keystone resources that
might be also bound to a single project. Without this it is possible to
gain different access (using trust to see application credentials for a
different project, reuse the MFA seed, etc).
.
* Credentials CRUD (/v3/credentials)
.
All five CRUD operations verified ownership via user_id but did not bind
credential.project_id to the delegating token's project scope.
.
Fix: _check_credential_project_scope() - no-op for non-delegated tokens,
raises ForbiddenAction on project mismatch. For list, out-of-scope
credentials are silently filtered.
.
Credentials with project_id=None (TOTP/MFA bindings) are treated as
out-of-scope for any delegated token: they are user-level secrets with no
project anchor, and a delegated token should never be able to enumerate,
read, or mutate them - doing so would allow a stolen delegation token to
exfiltrate or destroy a user's MFA binding.
.
* OS-EC2 credential CRUD (/v3/users/{id}/credentials/OS-EC2)
.
POST accepted any tenant_id from a delegated token. GET and DELETE had
no delegation check at all.
.
Fix: _check_delegation_for_ec2() enforces the project boundary;
list silently filters.
.
Additionally, pre-existing OAuth1 access-token-backed EC2 credentials
with a mismatched project_id could be used at auth-time (POST /v3/ec2tokens)
to obtain a cross-project token. Added a check in EC2_S3_Resource.py that
cred_data['project_id'] matches access_token['project_id'] before issuing
the token. The trust branch does not need this check - the token provider
uses the trust's project regardless of the credential's project_id.
.
* OS-OAUTH1 access token management (/v3/users/{id}/OS-OAUTH1/access_tokens)
.
GET and DELETE had no delegation check. List blocked trust/OAuth but not
app-cred tokens.
.
Fix: _block_delegated_token() raises Forbidden for any delegation type
on list, get, and delete.
.
* Application credential management (/v3/users/{id}/application_credentials)
.
Trust-scoped and OAuth1 tokens had no guard on the application credential
and access rule management APIs. An impersonating trust could LIST, CREATE,
or DELETE application credentials, creating a persistent backdoor that
outlives the trust's own expiry. App credential tokens are intentionally
excluded - the unrestricted/restricted distinction is handled separately by
_check_unrestricted_application_credential.
.
Fix: _block_delegated_token_app_creds() raises Forbidden for trust-scoped
and OAuth1 tokens on all six app credential and access rule endpoints.

===================================================================		 Grzegorz Grasza <xek@redhat.com> yes debian upstream upstream, https://bugs.launchpad.net/keystone/+bug/2150089 2026-05-26

All known versions for source package 'keystone'

Links