)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"26b08b42fa47cbfa72ce76a3fc383f1eab655462","unresolved":false,"context_lines":[{"line_number":9,"context_line":"The keystone trusts API currently makes some flawed choices about access"},{"line_number":10,"context_line":"control. First, there is a security issue whereby trust existence is"},{"line_number":11,"context_line":"leaked to unauthorized users (see related bug). Second, it explicitly"},{"line_number":12,"context_line":"prevents the admin user from retrieving a trust. In order to correct the"},{"line_number":13,"context_line":"first issue, we need to change the keystone API to correctly return an"},{"line_number":14,"context_line":"HTTP 403 Forbidden in the case that a trust does not exist. This impacts"},{"line_number":15,"context_line":"tempest, which runs as the admin user, and is expecting to be able to"},{"line_number":16,"context_line":"validate a trust deletion by checking for an HTTP 404 Not Found. We will"},{"line_number":17,"context_line":"be able to correct the bad assumptions about the admin user by updating"},{"line_number":18,"context_line":"the default trust policies to be aware of system scope[1] and default"},{"line_number":19,"context_line":"roles[2]. But in all cases, the list_trusts request works properly for"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"7faddb67_150f772e","line":16,"range":{"start_line":12,"start_character":49,"end_line":16,"end_character":64},"updated":"2019-08-16 17:51:29.000000000","message":"Usually I don\u0027t want to make backwards incompatible change on APIs. But this case is error case, and the corresponding Keystone patch(https://review.opendev.org/#/c/676528/) already has 3 +2s. So LGTM now.","commit_id":"f986c85c79a2df9b0435cb94b41c39fbebbfbab5"}]}