)]}'
{".pre-commit-config.yaml":[{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"9ac3702316fa46ebb27ed1f6101e44977dcbaf67","unresolved":true,"context_lines":[{"line_number":38,"context_line":"    hooks:"},{"line_number":39,"context_line":"      - id: hacking"},{"line_number":40,"context_line":"        additional_dependencies:"},{"line_number":41,"context_line":"          - setuptools\u003c81"},{"line_number":42,"context_line":"          - flake8-import-order~\u003d0.18.2"},{"line_number":43,"context_line":"        exclude: \u0027^(doc|releasenotes|tools|devstack)/.*$\u0027"},{"line_number":44,"context_line":"  - repo: https://github.com/openstack/bashate"}],"source_content_type":"text/x-yaml","patch_set":8,"id":"0d84eb3a_c4d0764d","line":41,"range":{"start_line":41,"start_character":12,"end_line":41,"end_character":25},"updated":"2026-02-17 14:30:09.000000000","message":"This likely conflicts with global requirements. We should bump flake8-import-order instead.","commit_id":"8da61709886e9b0c553969582652e422f6e2204b"}],"/COMMIT_MSG":[{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"c44cb821a8ae6f0ffbcc10a1ca2f82e0134bf649","unresolved":true,"context_lines":[{"line_number":4,"context_line":"Commit:     Bram Kranendonk \u003cbram.kranendonk@nl.team.blue\u003e"},{"line_number":5,"context_line":"CommitDate: 2026-02-16 17:20:26 +0100"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Moved the validation ensuring the authenticated user matches the trustor during trust creation from the API layer to the Trust SQL driver."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Change-Id: I0f5f001c9ecf1aeb32523027da5906d9efb7a26b"},{"line_number":10,"context_line":"Signed-off-by: Bram Kranendonk \u003cbram.kranendonk@nl.team.blue\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"b915b755_e3af39f9","line":7,"range":{"start_line":7,"start_character":0,"end_line":7,"end_character":138},"updated":"2026-02-16 17:33:29.000000000","message":"Please take a moment to read https://wiki.openstack.org/wiki/GitCommitMessages to find commit message guideline.\n\nAlso the message describes the change itself and does not explain why we need it. What\u0027s the actual problem resolved by this ?","commit_id":"5d1590783f596b6e0a20addd0ed29706ea1dbc46"},{"author":{"_account_id":34391,"name":"Bram Kranendonk","display_name":"bkranendonk","email":"bram.kranendonk@team.blue","username":"bkranendonk"},"change_message_id":"17df8881bc694746acec5f6f61755e0ed579374e","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     Bram Kranendonk \u003cbram.kranendonk@nl.team.blue\u003e"},{"line_number":5,"context_line":"CommitDate: 2026-02-16 17:20:26 +0100"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Moved the validation ensuring the authenticated user matches the trustor during trust creation from the API layer to the Trust SQL driver."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Change-Id: I0f5f001c9ecf1aeb32523027da5906d9efb7a26b"},{"line_number":10,"context_line":"Signed-off-by: Bram Kranendonk \u003cbram.kranendonk@nl.team.blue\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"e9916746_5fc73ff5","line":7,"range":{"start_line":7,"start_character":0,"end_line":7,"end_character":138},"in_reply_to":"b915b755_e3af39f9","updated":"2026-02-16 18:38:14.000000000","message":"Done","commit_id":"5d1590783f596b6e0a20addd0ed29706ea1dbc46"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"d3842efdfadd9194026050113437ac84efe98f6b","unresolved":true,"context_lines":[{"line_number":15,"context_line":"a duplicate pre-check."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Keeping this check in the backend is required for backend substitutability:"},{"line_number":18,"context_line":"operators can override the Trust backend through Stevedore and still get the"},{"line_number":19,"context_line":"same trustor validation behavior. With the earlier API-layer logic, that"},{"line_number":20,"context_line":"validation path was tied to one entrypoint and was not cleanly portable across"},{"line_number":21,"context_line":"backend implementations."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Behavior is unchanged for API callers: trust creation still fails with"},{"line_number":24,"context_line":"ForbiddenAction when the authenticated user differs from"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"9e4b4745_faf795ce","line":21,"range":{"start_line":18,"start_character":0,"end_line":21,"end_character":24},"updated":"2026-02-17 12:01:59.000000000","message":"I\u0027m still confused by this. In the earlier implementation the validation was done at api layer which is irrelevant to trust backends. Moving it to Trust allows users to \"disable\" that validation, not inheriting it.\n\nI think you are breaking the expected behavior you describe here ?","commit_id":"49818b202cc34b1ec6d919cd048cfdd2790913c9"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"be05d8dff267cc4e0c01bc3d89744965df6dde4a","unresolved":true,"context_lines":[{"line_number":15,"context_line":"a duplicate pre-check."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Keeping this check in the backend is required for backend substitutability:"},{"line_number":18,"context_line":"operators can override the Trust backend through Stevedore and still get the"},{"line_number":19,"context_line":"same trustor validation behavior. With the earlier API-layer logic, that"},{"line_number":20,"context_line":"validation path was tied to one entrypoint and was not cleanly portable across"},{"line_number":21,"context_line":"backend implementations."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Behavior is unchanged for API callers: trust creation still fails with"},{"line_number":24,"context_line":"ForbiddenAction when the authenticated user differs from"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"9cafc8cf_72ad76ea","line":21,"range":{"start_line":18,"start_character":0,"end_line":21,"end_character":24},"in_reply_to":"3aec7dae_2a937a93","updated":"2026-02-17 15:42:12.000000000","message":"I\u0027ve not tested this actually but I think you are correct and trust.trustor_user_id !\u003d user_id is checked both at policy later and code logic and we can remove the latter. Can you try customizing the rule and see if works (I expect not), and then removing the rule fixes it ? Once that is confirmed we can create a bug to track this work, I think.\n\nNote that the fix has theoretically upgrade impact in deployments overriding create_trust policy, in cse that trustor_user_id part is removed, so we should document that impact properly in a release note.","commit_id":"49818b202cc34b1ec6d919cd048cfdd2790913c9"},{"author":{"_account_id":34391,"name":"Bram Kranendonk","display_name":"bkranendonk","email":"bram.kranendonk@team.blue","username":"bkranendonk"},"change_message_id":"a0677820b76913e022a8163ce0a28fafd8a6c86a","unresolved":true,"context_lines":[{"line_number":15,"context_line":"a duplicate pre-check."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Keeping this check in the backend is required for backend substitutability:"},{"line_number":18,"context_line":"operators can override the Trust backend through Stevedore and still get the"},{"line_number":19,"context_line":"same trustor validation behavior. With the earlier API-layer logic, that"},{"line_number":20,"context_line":"validation path was tied to one entrypoint and was not cleanly portable across"},{"line_number":21,"context_line":"backend implementations."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Behavior is unchanged for API callers: trust creation still fails with"},{"line_number":24,"context_line":"ForbiddenAction when the authenticated user differs from"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"a610c2f0_d4c17cc8","line":21,"range":{"start_line":18,"start_character":0,"end_line":21,"end_character":24},"in_reply_to":"44cfd835_20583290","updated":"2026-02-17 14:45:23.000000000","message":"Thanks for the questions, and we absolutely understand the risks here.\n\nWe have some operational workflows that require admin controlled impersonation, similar to what systems like Keycloak support, where administrators can act in a user’s context for automation or support scenarios. Because of these needs, we would like the flexibility to handle the validation in the backend instead of having a non overridable check in the API.\n\nThe intention is not to weaken the default behavior or open this to regular users. The default backend continues to enforce the check, and any change would be an explicit operator decision with proper controls.\n\nMoving the validation into the backend (or being able to disable the API layer validation) is simply the first step to make this possible in a clean and consistent way.","commit_id":"49818b202cc34b1ec6d919cd048cfdd2790913c9"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"a6ee4bd47fed537ed008549b78d71a66b43ffd01","unresolved":true,"context_lines":[{"line_number":15,"context_line":"a duplicate pre-check."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Keeping this check in the backend is required for backend substitutability:"},{"line_number":18,"context_line":"operators can override the Trust backend through Stevedore and still get the"},{"line_number":19,"context_line":"same trustor validation behavior. With the earlier API-layer logic, that"},{"line_number":20,"context_line":"validation path was tied to one entrypoint and was not cleanly portable across"},{"line_number":21,"context_line":"backend implementations."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Behavior is unchanged for API callers: trust creation still fails with"},{"line_number":24,"context_line":"ForbiddenAction when the authenticated user differs from"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"44cfd835_20583290","line":21,"range":{"start_line":18,"start_character":0,"end_line":21,"end_character":24},"in_reply_to":"791fde3b_d7e7d60b","updated":"2026-02-17 14:26:56.000000000","message":"So you want to \"disable\" the check for your backend, not enforcing it, right ? I still don\u0027t understand why that is required specifically for your backend. Maybe reporting a bug with more details can help.\n\nAlso, note that removing the check exposes a huge risk becasue any user can create a trust to access resources of a different user, and that shouldn\u0027t be open for any users. I think the right approach is to create a separate policy rule, but I\u0027m unsure if that\u0027s an acceptable approach without understanding the actual use case where this is specifically needed.","commit_id":"49818b202cc34b1ec6d919cd048cfdd2790913c9"},{"author":{"_account_id":34391,"name":"Bram Kranendonk","display_name":"bkranendonk","email":"bram.kranendonk@team.blue","username":"bkranendonk"},"change_message_id":"eaab52047b5c7a9e85e40a6d86dd18d81beb3eb0","unresolved":false,"context_lines":[{"line_number":15,"context_line":"a duplicate pre-check."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Keeping this check in the backend is required for backend substitutability:"},{"line_number":18,"context_line":"operators can override the Trust backend through Stevedore and still get the"},{"line_number":19,"context_line":"same trustor validation behavior. With the earlier API-layer logic, that"},{"line_number":20,"context_line":"validation path was tied to one entrypoint and was not cleanly portable across"},{"line_number":21,"context_line":"backend implementations."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Behavior is unchanged for API callers: trust creation still fails with"},{"line_number":24,"context_line":"ForbiddenAction when the authenticated user differs from"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"7fca1ce3_61cef562","line":21,"range":{"start_line":18,"start_character":0,"end_line":21,"end_character":24},"in_reply_to":"9cafc8cf_72ad76ea","updated":"2026-02-17 22:00:23.000000000","message":"Hey Takashi, verified and it indeed works as expected (Oslo policy still restricts by default).\n\n- Updated the Change description\n\n- Added a reno file\n\nPlease let me know if there\u0027s anything left to do. Thanks.","commit_id":"49818b202cc34b1ec6d919cd048cfdd2790913c9"},{"author":{"_account_id":34391,"name":"Bram Kranendonk","display_name":"bkranendonk","email":"bram.kranendonk@team.blue","username":"bkranendonk"},"change_message_id":"8628d109a95875dc6a1512017a9b20c35d9a2e7e","unresolved":true,"context_lines":[{"line_number":15,"context_line":"a duplicate pre-check."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Keeping this check in the backend is required for backend substitutability:"},{"line_number":18,"context_line":"operators can override the Trust backend through Stevedore and still get the"},{"line_number":19,"context_line":"same trustor validation behavior. With the earlier API-layer logic, that"},{"line_number":20,"context_line":"validation path was tied to one entrypoint and was not cleanly portable across"},{"line_number":21,"context_line":"backend implementations."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Behavior is unchanged for API callers: trust creation still fails with"},{"line_number":24,"context_line":"ForbiddenAction when the authenticated user differs from"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"791fde3b_d7e7d60b","line":21,"range":{"start_line":18,"start_character":0,"end_line":21,"end_character":24},"in_reply_to":"9e4b4745_faf795ce","updated":"2026-02-17 14:02:15.000000000","message":"Hi Takashi, thanks for the swift feedback.\n\nI agree that removing it from the API layer would possibly expose a security risk when a Keystone admin already overrides the Trust SQL backend, and I agree that it is not a purely SQL-backend change.\n\nAnother solution would be to make the validation in the API layer optional using an oslo config opt (defaults to validation enabled). What are your thoughts on this?\n\n\n```\n[trust]\nvalidate_trustor \u003d True\n```","commit_id":"49818b202cc34b1ec6d919cd048cfdd2790913c9"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"c3a53418ea941e8e9621cb98c0b3ace97578a0b7","unresolved":true,"context_lines":[{"line_number":15,"context_line":"a duplicate pre-check."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Keeping this check in the backend is required for backend substitutability:"},{"line_number":18,"context_line":"operators can override the Trust backend through Stevedore and still get the"},{"line_number":19,"context_line":"same trustor validation behavior. With the earlier API-layer logic, that"},{"line_number":20,"context_line":"validation path was tied to one entrypoint and was not cleanly portable across"},{"line_number":21,"context_line":"backend implementations."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Behavior is unchanged for API callers: trust creation still fails with"},{"line_number":24,"context_line":"ForbiddenAction when the authenticated user differs from"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"e57ce946_d938a203","line":21,"range":{"start_line":18,"start_character":0,"end_line":21,"end_character":24},"in_reply_to":"a610c2f0_d4c17cc8","updated":"2026-02-17 14:50:52.000000000","message":"I\u0027m still unsure if the check should be done within backend for the described use case. It sounds like more general requirement which is independent from backend mechanism.\n\nThen IMO this check shouldn\u0027t be implemented within backend and should be implemented at api layer, and we should allow customization for policy rules. That\u0027s how in general we apply access control for resources.","commit_id":"49818b202cc34b1ec6d919cd048cfdd2790913c9"},{"author":{"_account_id":34391,"name":"Bram Kranendonk","display_name":"bkranendonk","email":"bram.kranendonk@team.blue","username":"bkranendonk"},"change_message_id":"f5a17254d4e230cee57780bd3fae389e586a7709","unresolved":true,"context_lines":[{"line_number":15,"context_line":"a duplicate pre-check."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Keeping this check in the backend is required for backend substitutability:"},{"line_number":18,"context_line":"operators can override the Trust backend through Stevedore and still get the"},{"line_number":19,"context_line":"same trustor validation behavior. With the earlier API-layer logic, that"},{"line_number":20,"context_line":"validation path was tied to one entrypoint and was not cleanly portable across"},{"line_number":21,"context_line":"backend implementations."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Behavior is unchanged for API callers: trust creation still fails with"},{"line_number":24,"context_line":"ForbiddenAction when the authenticated user differs from"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"3aec7dae_2a937a93","line":21,"range":{"start_line":18,"start_character":0,"end_line":21,"end_character":24},"in_reply_to":"e57ce946_d938a203","updated":"2026-02-17 15:06:57.000000000","message":"That sounds reasonable and flexible.\n\nI currently see this policy being enforced in create_trust(). So removing the static validation statement would still enforce the authenticated user being the trustor AFAICS.\n\n```\nRULE_TRUST_OWNER \u003d \u0027user_id:%(trust.trustor_user_id)s\u0027\n...\n    policy.DocumentedRuleDefault(\n        name\u003dbase.IDENTITY % \u0027create_trust\u0027,\n        check_str\u003dbase.RULE_TRUST_OWNER,\n        # FIXME(lbragstad): Trusts have the ability to optionally include a\n        # project, but until trusts deal with system scope it\u0027s not really\n        # useful. For now, this should be a project only operation.\n        scope_types\u003d[\u0027project\u0027],\n        description\u003d\u0027Create trust.\u0027,\n        operations\u003d[{\u0027path\u0027: \u0027/v3/OS-TRUST/trusts\u0027, \u0027method\u0027: \u0027POST\u0027}],\n    ),\n```\n\nWould simply removing the redundant static validation if-condition be acceptable? Thanks.","commit_id":"49818b202cc34b1ec6d919cd048cfdd2790913c9"}],"releasenotes/notes/move-trust-validation-to-sql-driver-92b7caca995aeaad.yaml":[{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"c44cb821a8ae6f0ffbcc10a1ca2f82e0134bf649","unresolved":true,"context_lines":[{"line_number":1,"context_line":"---"},{"line_number":2,"context_line":"other:"},{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    Moved the validation ensuring the authenticated user matches the trustor"},{"line_number":5,"context_line":"    during trust creation from the API layer to the Trust SQL driver. No"},{"line_number":6,"context_line":"    functional or API behavior changes are introduced; this is an internal"},{"line_number":7,"context_line":"    refactor to improve layering."}],"source_content_type":"text/x-yaml","patch_set":1,"id":"f7311e4a_ce8879e2","line":7,"range":{"start_line":2,"start_character":0,"end_line":7,"end_character":33},"updated":"2026-02-16 17:33:29.000000000","message":"If this is an internal change then we don\u0027t need a release note, IMHO. This is for users.","commit_id":"5d1590783f596b6e0a20addd0ed29706ea1dbc46"},{"author":{"_account_id":34391,"name":"Bram Kranendonk","display_name":"bkranendonk","email":"bram.kranendonk@team.blue","username":"bkranendonk"},"change_message_id":"17df8881bc694746acec5f6f61755e0ed579374e","unresolved":false,"context_lines":[{"line_number":1,"context_line":"---"},{"line_number":2,"context_line":"other:"},{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    Moved the validation ensuring the authenticated user matches the trustor"},{"line_number":5,"context_line":"    during trust creation from the API layer to the Trust SQL driver. No"},{"line_number":6,"context_line":"    functional or API behavior changes are introduced; this is an internal"},{"line_number":7,"context_line":"    refactor to improve layering."}],"source_content_type":"text/x-yaml","patch_set":1,"id":"36387b95_27abc5bf","line":7,"range":{"start_line":2,"start_character":0,"end_line":7,"end_character":33},"in_reply_to":"f7311e4a_ce8879e2","updated":"2026-02-16 18:38:14.000000000","message":"Done","commit_id":"5d1590783f596b6e0a20addd0ed29706ea1dbc46"}]}