Barbican Release Notes - en to en_GB translation catalogue (17 entries)

en: Added new options to the PKCS#11 Cryptographic Plugin configuration to enable the use of different encryption and hmac mechanisms. Added support for `CKM_AES_CBC` encryption in the PKCS#11 Cryptographic Plugin.
en_GB: Added new options to the PKCS#11 Cryptographic Plugin configuration to enable the use of different encryption and HMAC mechanisms. Added support for `CKM_AES_CBC` encryption in the PKCS#11 Cryptographic Plugin.

en: Added two options for the PKCS#11 Crypto Plugin: `[p11_crypto_plugin]/token_serial_number` and `[p11_crypto_plugin]/token_label`.  Both are optional and can be used instead of `[p11_crypto_plugin]/slot_id` to identify the Token to be used by the PKCS#11 plugin.  When either one of the new options is defined the plugin will search all slots on the PKCS#11 device for a token that matches the given value.  `token_serial_number` has the highest precendence and other values will be ignored when this value is set.  If `token_serial_number` is not set, then `token_label` has the next highest precedence and `slot_id` will be ignored. `slot_id` will be used when neither one of the new options is set.
en_GB: Added two options for the PKCS#11 Crypto Plugin: `[p11_crypto_plugin]/token_serial_number` and `[p11_crypto_plugin]/token_label`.  Both are optional and can be used instead of `[p11_crypto_plugin]/slot_id` to identify the Token to be used by the PKCS#11 plugin.  When either one of the new options is defined the plugin will search all slots on the PKCS#11 device for a token that matches the given value.  `token_serial_number` has the highest precedence and other values will be ignored when this value is set.  If `token_serial_number` is not set, then `token_label` has the next highest precedence and `slot_id` will be ignored. `slot_id` will be used when neither one of the new options is set.

en: By default barbican checks only the algorithm and the bit_length when creating a new secret. The xts-mode cuts the key in half for aes, so for using aes-256 with xts, you have to use a 512 bit key, but barbican allows only a maximum of 256 bit. A check for the mode within the _is_algorithm_supported method of the class SimpleCryptoPlugin was added to allow 512 bit keys for aes-xts in this plugin.
en_GB: By default Barbican checks only the algorithm and the bit_length when creating a new secret. The xts-mode cuts the key in half for AES, so for using AES-256 with xts, you have to use a 512 bit key, but barbican allows only a maximum of 256 bit. A check for the mode within the _is_algorithm_supported method of the class SimpleCryptoPlugin was added to allow 512 bit keys for AES-XTS in this plugin.

en: Default for auto_db_create has been changed to False (was True). This is a change compared to the previous behavior, but required to protect production deployments from performing upgrades without control. If you wish to keep the auto db creation/upgrade behavior, change this to True in your configuration.
en_GB: Default for auto_db_create has been changed to False (was True). This is a change compared to the previous behaviour, but required to protect production deployments from performing upgrades without control. If you wish to keep the auto db creation/upgrade behaviour, change this to True in your configuration.

en: Fixed Story #2008649: Correctly reinitialize PKCS11 object after secondary failures.
en_GB: Fixed Story #2008649: Correctly reinitialise PKCS11 object after secondary failures.

en: Fixed Story #2009247 - Fixed the response for POST /v1/secrets/{secret-id}/metadata so it matches the documented behavior.
en_GB: Fixed Story #2009247 - Fixed the response for POST /v1/secrets/{secret-id}/metadata so it matches the documented behaviour.

en: Fixed Story #2009791: Users with the "creator" role on a project can now delete secrets owned by the project even if the user is different than the user that originally created the secret.  Previous to this fix a user with the "creator" role was only allowed to delete a secret owned by the project if they were also the same user that originally created, which was inconsistent with the way that deletes are handled by other OpenStack projects that integrate with Barbican.  This change does not affect private secrets (i.e. secrets with the "project-access" flag set to "false").
en_GB: Fixed Story #2009791: Users with the "creator" role on a project can now delete secrets owned by the project even if the user is different than the user that originally created the secret.  Previous to this fix a user with the "creator" role was only allowed to delete a secret owned by the project if they were also the same user that originally created it, which was inconsistent with the way that deletes are handled by other OpenStack projects that integrate with Barbican.  This change does not affect private secrets (i.e. secrets with the "project-access" flag set to "false").

en: It is now possible for barbican-keystone-listener to listen on the same standard notification topic without interfering with other services by using the notification listener pools feature of oslo.messaging. To use it, set the new ``[keystone_notifications]pool_name`` option to some unique value (but the same for all instances of barbican-keystone-listener service). This feature is available only for those messaging transports of oslo.messaging that support it. At the moment those are rabbitmq and kafka. For more details see `oslo.messagind docs <https://docs.openstack.org/oslo.messaging/latest/reference/notification_listener.html>`_
en_GB: It is now possible for barbican-keystone-listener to listen on the same standard notification topic without interfering with other services by using the notification listener pools feature of oslo.messaging. To use it, set the new ``[keystone_notifications]pool_name`` option to some unique value (but the same for all instances of barbican-keystone-listener service). This feature is available only for those messaging transports of oslo.messaging that support it. At the moment those are RabbitMQ and Kafka. For more details see `oslo.messagind docs <https://docs.openstack.org/oslo.messaging/latest/reference/notification_listener.html>`_

en: New feature to support multiple secret store plugin backends. This feature is not enabled by default. To use this feature, the relevant feature flag needs to be enabled and supporting configuration needs to be added in the service configuration. Once enabled, a project adminstrator will be able to specify one of the available secret store backends as a preferred secret store for their project secrets. This secret store preference applies only to new secrets (key material) created or stored within that project. Existing secrets are not impacted. See http://docs.openstack.org/developer/barbican/setup/plugin_backends.html for instructions on how to setup Barbican multiple backends, and the API documentation for further details.
en_GB: New feature to support multiple secret store plugin backends. This feature is not enabled by default. To use this feature, the relevant feature flag needs to be enabled and supporting configuration needs to be added in the service configuration. Once enabled, a project administrator will be able to specify one of the available secret store backends as a preferred secret store for their project secrets. This secret store preference applies only to new secrets (key material) created or stored within that project. Existing secrets are not impacted. See http://docs.openstack.org/developer/barbican/setup/plugin_backends.html for instructions on how to setup Barbican multiple backends, and the API documentation for further details.

en: Now within a single deployment, multiple secret store plugin backends can be configured and used. With this change, a project adminstrator can pre-define a preferred plugin backend for storing their secrets. New APIs are added to manage this project level secret store preference.
en_GB: Now within a single deployment, multiple secret store plugin backends can be configured and used. With this change, a project administrator can pre-define a preferred plugin backend for storing their secrets. New APIs are added to manage this project level secret store preference.

en: System scope has been removed from the RBAC policies as specified in the Consistent and Secure Default RBAC community goal. See: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html APIs that required system scoped tokens can now be accessed by using a project scoped token with the "admin" role.
en_GB: System scope has been removed from the RBAC policies as specified in the Consistent and Secure Default RBAC community goal. See: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html APIs that required system-scoped tokens can now be accessed by using a project-scoped token with the "admin" role.

en: The 'http_proxy_to_wsgi' middleware can be used to help barbican respond with the correct URL refs when it's put behind a TLS proxy (such as HAProxy). This middleware is disabled by default, but can be enabled via a configuration option in the oslo_middleware group.
en_GB: The 'http_proxy_to_wsgi' middleware can be used to help Barbican respond with the correct URL refs when it's put behind a TLS proxy (such as HAProxy). This middleware is disabled by default, but can be enabled via a configuration option in the oslo_middleware group.

en: The default value of ``[oslo_policy] policy_file`` config option has been changed from ``policy.json`` to ``policy.yaml``. Operators who are utilizing customized or previously generated static policy JSON files (which are not needed by default), should generate new policy files or convert them in YAML format. Use the `oslopolicy-convert-json-to-yaml <https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-convert-json-to-yaml.html>`_ tool to convert a JSON to YAML formatted policy file in backward compatible way.
en_GB: The default value of ``[oslo_policy] policy_file`` config option has been changed from ``policy.json`` to ``policy.yaml``. Operators who are utilizing customized or previously generated static policy JSON files (which are not needed by default), should generate new policy files or convert them in YAML format. Use the `oslopolicy-convert-json-to-yaml <https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-convert-json-to-yaml.html>`_ tool to convert a JSON to YAML formatted policy file in backwards-compatible way.

en: The new secure-rbac policy allows consumers to be added and deleted by members.  This is a change from the previous policy which only allowed the secret's creator or admins or those that had a read acl on the secret.
en_GB: The new secure-rbac policy allows consumers to be added and deleted by members.  This is a change from the previous policy which only allowed the secret's creator or admins or those that had a read ACL on the secret.

en: This release notify that we will remove Certificate Orders and CAs from API.
en_GB: This release notify that we will remove Certificate Orders and CAs from the API.

en: This version adds support to the secret consumers and microversions functionalities.  The detailed secret consumers specification can be found on <https://specs.openstack.org/openstack/barbican-specs/specs/train/secret-consumers.html>. Microversions allow clients to interact with Barbican server to gather information on minimum and maximum versions supported by the server. More information can be found on <https://docs.openstack.org/barbican/latest/api/microversions.html>.
en_GB: This version adds support to the secret consumers and microversions functionalities.  The detailed secret consumers specification can be found on <https://specs.openstack.org/openstack/barbican-specs/specs/train/secret-consumers.html>. Microversions allow clients to interact with Barbican server to gather information on minimum and maximum versions supported by the server. More information can be found at <https://docs.openstack.org/barbican/latest/api/microversions.html>.

en: Why are we deprecating Certificate Issuance? There are a few reasons that were considered for this decision.  First, there does not seem to be a lot of interest in the community to fully develop the Certificate Authority integration with Barbican.  We have a few outstanding blueprints that are needed to make Certificate Issuance fully functional, but so far no one has committed to getting the work done.  Additionally, we've had very little buy-in from public Certificate Authorities.  Both Symantec and Digicert were interested in integration in the past, but that interest didn't materialize into robust CA plugins like we hoped it would. Secondly, there have been new developments in the space of Certificate Authorities since we started Barbican.  The most significant of these was the launch of the Let's Encrypt public CA along with the definition of the ACME protocol for certificate issuance.  We believe that future certificate authority services would do good to implement the ACME standard, which is quite different than the API the Barbican team had developed. Lastly, deprecating Certificate Issuance within Barbican will simplify both the architecture and deployment of Barbican.  This will allow us to focus on the features that Barbican does well -- the secure storage of secret material.
en_GB: Why are we deprecating Certificate Issuance? There are a few reasons that were considered for this decision.  First, there does not seem to be a lot of interest in the community to fully develop the Certificate Authority integration with Barbican.  We have a few outstanding blueprints that are needed to make Certificate Issuance fully functional, but so far no one has committed to getting the work done.  Additionally, we've had very little buy-in from public Certificate Authorities.  Both Symantec and Digicert were interested in integration in the past, but that interest didn't materialise into robust CA plugins like we hoped it would. Secondly, there have been new developments in the space of Certificate Authorities since we started Barbican.  The most significant of these was the launch of the Let's Encrypt public CA along with the definition of the ACME protocol for certificate issuance.  We believe that future certificate authority services would do good to implement the ACME standard, which is quite different than the API the Barbican team had developed. Lastly, deprecating Certificate Issuance within Barbican will simplify both the architecture and deployment of Barbican.  This will allow us to focus on the features that Barbican does well -- the secure storage of secret material.
