etc/default_catalog.templates | 64 32 + 32 - 0 !
1 file changed, 32 insertions(+), 32 deletions(-)

 fix default keystone catalog
 Fix default catalog so that it matches the region name which is set by
 default by debconf in all of the Openstack Debian packages.

requirements.txt | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 allow babel 2.4.0
 There's no real need to blacklist 2.4.0, it's only an issue that we can
 patch in Debian if needed:
  https://github.com/python-babel/babel/pull/490/commits/33b4728d340e2910cfaf689d937527c1cfe5cdf2

MANIFEST.in | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 install missing files

keystone/api/credentials.py | 6 4 + 2 - 0 !
keystone/credential/core.py | 17 16 + 1 - 0 !
releasenotes/notes/bug-1831918-c70cf87ef086d871.yaml | 6 6 + 0 - 0 !
3 files changed, 26 insertions(+), 3 deletions(-)

 add cadf auditing to credentials
 added audit logging to credentials.
 .

keystone/conf/credential.py | 11 10 + 1 - 0 !
keystone/contrib/ec2/controllers.py | 27 27 + 0 - 0 !
keystone/tests/unit/test_contrib_ec2_core.py | 125 123 + 2 - 0 !
releasenotes/notes/bug-1872737-f8e1ad3b6705b766.yaml | 28 28 + 0 - 0 !
4 files changed, 188 insertions(+), 3 deletions(-)

 check timestamp of signed ec2 token request
 EC2 token requests contain a signature that signs the entire request,
 including the access timestamp. While the signature is checked, the
 timestamp is not, and so these signed requests remain valid
 indefinitely, leaving the token API vulnerable to replay attacks. This
 change introduces a configurable TTL for signed token requests and
 ensures that the timestamp is actually validated against it.
 .
 The check will work for either an AWS Signature v1/v2 'Timestamp'
 parameter[1] or the AWS Signature v4 'X-Aws-Date' header or
 parameter[2].
 .
 Although this technically adds a new feature and the default value of
 the feature changes behavior, this change is required to protect
 credential holders and therefore must be backported to all supported
 branches.
 .
 [1] https://docs.aws.amazon.com/general/latest/gr/signature-version-2.html
 [2] https://docs.aws.amazon.com/general/latest/gr/sigv4-date-handling.html
 .
 Conflicts due to six removal in e2d83ae9:
	keystone/api/_shared/EC2_S3_Resource.py
	keystone/tests/unit/test_contrib_ec2_core.py
 .
 Conflicts due to flask reorg:
	keystone/api/_shared/EC2_S3_Resource.py

keystone/models/token_model.py | 18 18 + 0 - 0 !
keystone/tests/unit/test_v3_oauth1.py | 13 13 + 0 - 0 !
releasenotes/notes/bug-1873290-ff7f8e4cee15b75a.yaml | 19 19 + 0 - 0 !
3 files changed, 50 insertions(+)

 ensure oauth1 authorized roles are respected
 Without this patch, when an OAuth1 request token is authorized with a
 limited set of roles, the roles for the access token are ignored when
 the user uses it to request a keystone token. This means that user of an
 access token can use it to escallate their role assignments beyond what
 was authorized by the creator. This patch fixes the issue by ensuring
 the token model accounts for an OAuth1-scoped token and correctly
 populating the roles for it.
 .
 Modified to work with older test helper function:
 .
  keystone/tests/unit/test_v3_oauth1.py
 .

keystone/api/credentials.py | 72 55 + 17 - 0 !
keystone/application_credential/controllers.py | 22 20 + 2 - 0 !
keystone/contrib/ec2/controllers.py | 54 44 + 10 - 0 !
keystone/tests/unit/test_v3_application_credential.py | 31 31 + 0 - 0 !
keystone/tests/unit/test_v3_credential.py | 430 395 + 35 - 0 !
releasenotes/notes/bug-1872733-2377f456a57ad32c.yaml | 16 16 + 0 - 0 !
releasenotes/notes/bug-1872735-0989e51d2248ce1e.yaml | 31 31 + 0 - 0 !
releasenotes/notes/bug-1872755-2c81d3267b89f124.yaml | 19 19 + 0 - 0 !
8 files changed, 611 insertions(+), 64 deletions(-)

 cve: fix security issues with ec2 credentials
 This change addresses several issues in the creation and use of EC2/S3
 credentials with keystone tokens.
 .
 1. Disable altering credential owner attributes or metadata
 .
 Without this patch, an authenticated user can create an EC2 credential
 for themself for a project they have a role on, then update the
 credential to target a user and project completely unrelated to them. In
 the worst case, this could be the admin user and a project the admin
 user has a role assignment on. A token granted for an altered credential
 like this would allow the user to masquerade as the victim user. This
 patch ensures that when updating a credential, the new form of the
 credential is one the acting user has access to: if the system admin
 user is changing the credential, the new user ID or project ID could be
 anything, but regular users may only change the credential to be one
 that they still own.
 .
 Relatedly, when a user uses an application credential or a trust to
 create an EC2 credential, keystone automatically adds the trust ID or
 application credential ID as metadata in the EC2 access blob so that it
 knows how the token can be scoped when it is used. Without this patch, a
 user who has created a credential in this way can update the access blob
 to remove or alter this metadata and escalate their privileges to be
 fully authorized for the trustor's, application credential creator's, or
 OAuth1 access token authorizor's privileges on the project. This patch
 fixes the issue by simply disallowing updates to keystone-controlled
 metadata in the credential.
 .
 2. Respect token roles when creating EC2 credentials
 .
 Without this patch, a trustee, an application credential user, or an
 OAuth1 access token holder could create an EC2 credential or an
 application credential using any roles the trustor, application
 credential creator, or access token authorizor had on the project,
 regardless of whether the creator had delegated only a limited subset of
 roles. This was because the trust_id attribute of the EC2 access blob
 was ignored, and no metadata for the application credential or access
 token was recorded either. This change ensures that the access
 delegation resource is recorded in the metadata of the EC2 credential
 when created and passed to the token provider when used for
 authentication so that the token provider can look up the correct roles
 for the request.