keystone — Change history

Change history — keystone — branch stable/2026.2

Branch stable/2026.2 @ e6dc5ae079e6 (30.0.0-5-ge6dc5ae07) — range 8755458dc539..e6dc5ae079e6 (automatic: where stable/2026.2 left master), 4 non-merge commits — target: none — analysed on 2026-10-28

Raw facts: _inventory/history_stable-2026.2.md and _inventory/history_stable-2026.2.json. The branch is young: it carries the 30.0.0 release plus 2 backports (1 security, 1 fix). Changes made in master before the branch point belong to release 30.0.0 and are not in this range. To cover them, rerun history.py --since 29.0.0.

3. EC2 credentials: stop impersonation through a forged trust_id (security)

• Commit: 7b9e0558fd080985a63396e6da75f40c7fd2dad2, a backport of 2427ef6a71a6 (master). Review https://review.opendev.org/q/I5d8530c8ebdb955026cb2d9b6c0033c769a979b4, bug 2165281.
• Before: POST /v3/credentials with type=ec2 stored the blob as sent, including any trust_id. Anyone who learned the ID of an impersonation trust could put it in their own EC2 credential, then exchange it through POST /v3/ec2tokens or /v3/s3tokens for a token in the trustor's name. This even worked through Swift's s3token middleware with only the service account.
• After:
  1. On creation, trust_id, app_cred_id and access_token_id are stripped from the blob, then written back only from the token used for the call (keystone/api/credentials.py:144-170).
  2. On EC2 or S3 authentication (keystone/api/_shared/EC2_S3_Resource.py:166-220), these give 401:
     • "EC2 credential user is not a party to the trust", when the credential's user_id is neither the trustor nor the trustee;
     • "EC2 credential user does not match the application credential user";
     • "EC2 credential user does not match the OAuth1 access token authorizing user". Point 2 also neutralises forged credentials already stored.
• Impact on the specification: REST API § 2.6 (already describes the new behaviour); errors, 401 row.
• Upgrade and operations: no migration and no option. EC2 credentials that held a foreign trust_id stop working, which is intended. Users who legitimately relied on them must recreate them with a token scoped to the trust.
• Carrying it over: a self-contained commit (2 source files, plus tests and release note). It is a priority for any fork that exposes /v3/ec2tokens or /v3/s3tokens (Swift S3, RadosGW). No prerequisite in this range.

4. IdP remote_ids capped at 64 characters by mistake (fix)

• Commit: be42a720420907ff73da26571123e9a6f86a6027, a backport of 4921da5a1538. Review https://review.opendev.org/q/Ia3e144033731733c4db6cda5cf80175a866aa447. Depends-On https://review.opendev.org/c/openstack/keystone/+/1009453.
• Before: an earlier change reused a 64-character string type for the identity providers' remote_ids, while the idp_remote_ids.remote_id column is String(255). Long OIDC issuer URLs were refused with 400.
• After: two types, idp_remote_id (255) and remote_id_attribute (64, the width of federation_protocol.remote_id_attribute) (keystone/federation/schema.py:26-30).
• Impact: REST API § 2.9; _rewrite/request-schemas_stable-2026.2.json (identity provider schemas).
• Carrying it over: trivial (keystone/federation/schema.py), plus its tests. Check that the Depends-On change, which introduced the schema validation, is present in the target; otherwise this commit is pointless there.

Maintenance-only changes

Carry-over plan

git cherry-pick -x 7b9e0558fd08   # security: EC2 credentials, bug 2165281
git cherry-pick -x be42a7204209   # fix: IdP remote_ids 255 characters

Source: reverse-spec-keystone/06-change-history_stable-2026.2.md. The _rewrite/ and _inventory/ files are not published on the site.