barbican — Change history

Change history — barbican — branch stable/2026.2

Branch stable/2026.2 @ de32745a7a4f — repository https://opendev.org/openstack/barbican — analysed on 2026-10-29

• Range: 22.0.0..stable/2026.2 (f8a331a40eb2..de32745a7a4f), i.e. the whole 2026.2 (Hibiscus) development cycle since the 2026.1 release, 47 non-merge commits. The automatic range (since the branch left master, 1efe16cd73b6..de32745a7a4f) holds only the two release-bot commits (.gitreview, tox.ini); there are no backports on the branch yet.
• Target: none given, so presence in a target is not computed. The carry-over plan below orders the commits for a fork of 2026.1 (stable/2026.1); for OpenKeel the column "Impact on the Go rewrite" is the useful one.
• Raw facts: _inventory/history_stable-2026.2.md / .json (trailers, files, release notes, earlier commits on the same files).
• Categories (heuristic, corrected after reading the diffs): security 1, upgrade 4, feature 3, fix 10, deprecation 1, dependencies/packaging 4, refactor 4, maintenance 20.

Summary

Change specifications

42. Enforce Secure RBAC by default — security, upgrade

• Before: barbican/common/policy.py forced [oslo_policy] enforce_scope = False and enforce_new_defaults = False, so only the legacy roles (admin, creator, observer, audit, key-manager:service-admin) mattered. After: the override is removed (barbican/common/policy.py:25 is now the first function), oslo.policy's defaults apply: project-scoped tokens with reader / member / admin; system- and domain-scoped tokens are refused. The new rules are guarded by True:%(enforce_new_defaults)s (barbican/common/policies/secrets.py:66), the flag being injected in the policy target (barbican/api/controllers/__init__.py:61).
• Why: the community "consistent and secure RBAC" goal; oslo.policy is removing enforce_scope.
• Impact on the spec: 07 § 6. The functional suite of the repository still uses legacy roles; this reverse-spec ran it with enforce_new_defaults = False (07 § 8.1).
• Upgrade: operators who relied on creator/observer/audit must grant member/reader or set both options to False (release note releasenotes/notes/enable-srbac-new-defaults-e22cd5c5f1b3a29c.yaml). This is the biggest behaviour change of the release: users with only creator get 403 after the upgrade.
• Carrying it over: one-file change plus test updates; depends on #30 (ACL target) to avoid spurious 403s for non-owner members. Easy.

19. Microversion 1.2: no deletion of a secret that has consumers — feature

• Before: DELETE /v1/secrets/{id} always deleted the secret and silently removed its consumers. After (microversion ≥ 1.2): 400 Secret cannot be deleted as it has consumers. unless force is a true boolean string (barbican/api/controllers/secrets.py:264); invalid force → 400 URI provided invalid query string parameters.. _MAX_MICROVERSION goes from 1 to 2 and _LAST_UPDATED to 2025-09-18T00:00:00Z (barbican/api/controllers/versions.py:30); new exception SecretHasConsumers (barbican/common/exception.py:171).
• Why: users deleting keys that Nova/Cinder volumes depend on; the safety net belongs in the API, not in each client.
• Impact on the spec: 01 (DELETE secret, microversions), 02, 04 § 3. Clients: python-barbicanclient sends force=1 only at ≥ 1.2 (python-barbicanclient:barbicanclient/v1/secrets.py:600); castellan exposes delete(force).
• Upgrade: none for 1.0/1.1 clients (behaviour unchanged); clients negotiating 1.2 must handle the new 400.
• Carrying it over: self-contained; tests in barbican/tests/api/controllers/test_secrets.py. Easy.

30. ACL endpoints build the full policy target — fix

• Before: SecretACLsController and ContainerACLsController overrode get_acl_tuple with only project_id and creator_id, so secret_is_not_private (True:%(target.secret.read_project_access)s) was always false on …/acl calls: with the new defaults, a project member who was not the owner got 403 on GET /v1/secrets/{id}/acl. After: the overrides are removed; the inherited ACLMixin.get_acl_tuple adds the user's ACL operations and read_project_access (barbican/api/controllers/__init__.py:185).
• Impact: 01 § ACLs, 07 § 6 (policy target). Carrying it over: deletion of 10 lines; must come with or before #42.

34. host_href unset by default — upgrade

• Before: host_href defaulted to http://localhost:9311, so every reference returned by a deployment that did not set it pointed to localhost. After: the option has no default; when unset, the base URL is derived from the request (Host, X-Forwarded-Proto, path prefix) (barbican/common/config.py:72, barbican/common/utils.py:79); an empty string is still accepted but deprecated (barbican/common/config.py:61); outside a request context and without the option, ValueError('host_href cannot be determined').
• Impact: all *_ref values and Location headers; container creation, whose secret_refs must start with that base URL (barbican/common/validators.py:713). Behind a TLS proxy, [oslo_middleware] enable_proxy_headers_parsing becomes necessary (devstack sets it).
• Upgrade: deployments that relied on the default keep working only if clients reach Barbican with the same host they want in references; set host_href explicitly otherwise (releasenotes/notes/update-default-host_ref-26c6fa050dc847e3.yaml).

2. Secret list pagination keeps the filters — fix

• Before: next/previous of GET /v1/secrets?secret_type=passphrase were …/v1/secrets?limit=10&offset=10, dropping the filters. After: every query parameter except limit/offset is URL-encoded and appended (barbican/api/controllers/secrets.py:436, barbican/common/hrefs.py:88). Only the secrets list does this; containers, orders, consumers and transport keys still drop extra parameters.
• Carrying it over: two files; easy.

5. Non-base64 binary payloads — fix

• Before: GET …/payload with a binary Accept failed with 500 when the store returned raw (not base64) data, as legacy castellan/Vault rows do. After: if base64 decoding fails, the data is returned as-is (barbican/plugin/util/translations.py:107). Ambiguous by nature: raw data that happens to be valid base64 is still decoded.
• Impact: 07 § 3.7 (Vault legacy rows).

38. EC key sizes in orders — fix

• TypeOrderValidator accepted only multiples of 8, rejecting P-521. Now algorithm: ec requires 256, 384 or 521 and any other value is 400 Provided field value is not supported (barbican/common/validators.py:531, barbican/common/validators.py:543). Note that no bundled store can generate EC keys (simple_crypto supports RSA/DSA only), so such orders still end in ERROR unless a KMIP/Vault store generates them [inferred].

9. KMIP object names — fix

• PyKMIP does not enforce unique Name attributes and some KMIP servers reject duplicates or unnamed objects; every registered object now gets name = uuid4 (barbican/plugin/kmip_secret_store.py:471). Barbican still identifies objects by key_uuid.

24–26. Vault options — feature, deprecation

• New [vault_plugin] kv_path (sub-path inside the KV mount) and kv_version (1 or 2, default 2) passed to castellan (barbican/plugin/vault_secret_store.py:44); castellan requirement raised to ≥ 4.2.0. vault_url is now a URIOpt limited to http/https (barbican/plugin/vault_secret_store.py:50): an invalid URL fails at start-up. use_ssl deprecated for removal because it never had any effect (barbican/plugin/vault_secret_store.py:58).
• Impact on data: changing kv_path or kv_version moves where new secrets are written and where existing ones are looked up (castellan builds the URL from them): existing secrets become unreadable unless they are moved (07 § 3.7) [inferred from castellan:castellan/key_manager/vault_key_manager.py:202].

37. Batched database clean-up — fix

• cleanup_softdeletes, cleanup_parent_with_no_child, cleanup_unassociated_projects and the expired-secret soft delete now select ids and delete/update in batches of DEFAULT_CLEANUP_BATCH_SIZE = 10,000 rows, committing each batch (barbican/model/clean.py:31, barbican/model/clean.py:458). barbican-db-manage clean --batch-size/-b sets it (barbican/cmd/db_manage.py:131); barbican-manage db clean has no such option and always uses 10,000 (barbican/cmd/barbican_manage.py:83).
• Operational impact: a failure mid-run leaves the earlier batches committed (the run is no longer all-or-nothing).

4, 22. Missing master KEK — fix

• [simple_crypto_plugin] kek gets default=[] and the constructor tests truthiness (barbican/plugin/crypto/simple_crypto.py:37, barbican/plugin/crypto/simple_crypto.py:59), so an unconfigured KEK raises ValueError("SimpleCrypto KEK is undefined"), logged when plugins load; requests then fail with 500 … failure seen (CryptoPluginNotFound) as observed during this analysis (02 § 2.3).

Other changes

Maintenance-only changes

Carry-over plan (onto stable/2026.1, oldest first)

Apply with git cherry-pick -x. Order matters for the policy pair: #30 before #42.

1. efe7040bca08 pagination filters (#2)
2. aeec1611f602 binary payload fallback (#5)
3. de534b60d7f9 KMIP names (#9)
4. fa35b14f9931 then a9f7478e3629 simple_crypto KEK checks (#4, #22)
5. 9f28ddb9248c microversion 1.2 (#19) — API change; carry only if clients may negotiate 1.2
6. 7eeb9a0f3560, 7371127192e5, f846df774d1b Vault options (#24–26) — needs castellan ≥ 4.2.0
7. 96b3e462f7c1 PKCS#11 migration script (#20)
8. 65a1dc983400 EC bit lengths (#38)
9. 70b20d3f9616 host_href default (#34) — upgrade note required
10. c370f7991a35 ACL policy target (#30)
11. be7d8103db9f Secure RBAC by default (#42) — upgrade note required; usually not backported to a stable branch because it changes authorisation
12. 27e3961bf1fa threading backend order (#36) — only if the target already uses the oslo.service threading backend
13. a28ddb94c353 batched clean-up (#37)

Packaging changes (#27–29) and GMR (#6) are release-level and not worth backporting.

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