Debian Patches

Status for keystone/2:30.0.0-1

Patch Description Author Forwarded Bugs Origin Last update
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
OSSN-0109_lp-2157347_invalidate_MFA_auth_receipts_and_TOTP_passcodes_after_use.patch Invalidate MFA auth receipts and TOTP passcodes after use MFA auth receipts were never invalidated after use, so a captured
receipt (they appear in response headers) could be replayed within
its validity window to obtain repeated tokens. TOTP passcodes were
never tracked as used either, so the same 6-digit code could be
resubmitted within its validity window with the same effect.
.
Add keystone.common.cache.is_replay()/mark_used(), a small one-time-use
cache helper, and use it to track consumed receipts
(CONSUMED_RECEIPTS_REGION, checked in validate_receipt(), marked in
the new consume_receipt() once a token is actually issued) and used
TOTP passcodes (TOTP_REGION). Each caller passes an expiration_time
derived from the value's real validity window plus a margin, rather
than the shared [cache] expiration_time, and is_replay() clamps to
[cache] backend_expiration_time when that is set lower, logging a
warning either way caching may be degraded.

diff --git a/keystone/api/_shared/authentication.py b/keystone/api/_shared/authentication.py
index 7b13110..e4ffead 100644		 Grzegorz Grasza <xek@redhat.com> yes debian upstream upstream, https://review.opendev.org/c/openstack/keystone/+/1006480 2026-09-29
OSSN-0109_lp-2158970_identity_credentials_require_MFA_re-verification_for_sensitive_actions.patch identity, credentials: require MFA re-verification for sensitive actions Several actions that touch MFA-critical state never checked whether the
account had TOTP MFA configured, letting a stolen credential act on an
MFA-protected account without ever proving the second factor:
.
- POST /v3/users/{id}/password (self-service password change) checked
only the current password.
- PATCH /v3/users/{id} could flip options.multi_factor_auth_enabled to
false, or narrow options.multi_factor_auth_rules (a separate resource
option from _enabled, independently settable), with no re-verification.
- POST/PATCH/DELETE on /v3/credentials for a user's own TOTP credential
(create a new seed, overwrite an existing one's blob in place, or
delete it outright) had no MFA-aware guard at all.
- GET /v3/credentials and GET /v3/credentials/{id} returned a TOTP
credential's raw secret verbatim to any authorized reader, including
the account owner's own ordinary session.
.
A token whose methods happen to include 'totp' is not sufficient proof on
its own for the write-side gaps above: methods are fixed at issuance and
don't expire before the token does, so a stolen but still-valid session
would pass that check with no proof the current caller still has the
device. Add keystone.api._shared.mfa_reverification.require_fresh_mfa(),
requiring a current, valid TOTP passcode in the OpenStack-MFA-Passcode
request header, verified via a new keystone.auth.plugins.totp.
verify_totp_passcode() (extracted from the TOTP auth plugin, reusing its
existing anti-replay cache from LP#2157347 so a passcode can't be
replayed between login and this check, or vice versa). Password change
checks the target user's own rules; the PATCH /v3/users/{id} guard checks
the acting admin/domain-manager's own rules, not the target's, since the
target's MFA is what's being changed and can't gate itself.
.
TOTP credential reads are fixed unconditionally rather than gated: there
is no legitimate reason for any caller, however authorized, to read a
TOTP seed back after enrollment, so the blob field is dropped from both
GET/LIST /v3/credentials responses rather than requiring re-verification
to see it.
.
The whole re-verification requirement is controlled by a new
[security_compliance] require_mfa_for_sensitive_account_actions option,
enabled by default, since it changes existing documented API behavior for
accounts that have MFA configured.

diff --git a/keystone/api/_shared/mfa_reverification.py b/keystone/api/_shared/mfa_reverification.py
new file mode 100644
index 0000000..b4316ee		 Grzegorz Grasza <xek@redhat.com> yes debian upstream upstream, https://review.opendev.org/c/openstack/keystone/+/1006720 2026-09-29

All known versions for source package 'keystone'

Links