Victoria Series Release Notes¶
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.
Added a new boolean option to the PKCS#11 backend: os_locking_ok. When set to True, the flag CKF_OS_LOCKING_OK will be passed to the C_Initialize function. The new option defaults to False.
A new “token_labels” option has been added to the PKCS#11 driver which supersedes the previous “token_label” option. The new option is used to specify a list of tokens that can be used by Barbican. This is required for some HSM devices that use separate tokens for load balancing. For most use cases the new option will just have a single token. The old option is deprecated, but will still be used if present.
The hsm subcommand for the barbican-manage command line tool no longer requires any parameters at run time. If any value used by the PKCS#11 value is needed it will be taken from /etc/barbican/barbican.conf. You may continue to specify any values on the command line, and those will take precedence over the values specified in barbican.conf, so any existing scripts that use barbican-manage should continue to work as expected.
The “token_label” option in the PKCS#11 driver is deprecated. Th new “token_labels” option should be used instead. If present, “token_label” will still be used by appending it to “token_labels”.
Fixed Story #2008649: Correctly reinitialize PKCS11 object after secondary failures.
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.
Fixed Story # 2007732: Migrations broken on MySQL 8.x.