| 2019-02-22 05:27:50 |
Douglas Mendizábal |
bug |
|
|
added bug |
| 2019-02-22 05:33:22 |
Douglas Mendizábal |
description |
The length parameter in KeyManager.create_key is not well defined in the interface. Specifically it is not clear whether the integer value passed in is the length in bits or the length in bytes.
Because of this, there is a mismatch in the way that BarbicanKeyManager and VaultKeyManager handle them.
BarbicanKeyManager assumes the value is bytes, but VaultKeyManager assumes the value is in bits. This, in turn, could result in unexpected behavior in applications using Castellan, since they would not have any knowledge at runtime about which backend is running and whether Castellan will return bits or bytes when asked to generate keys. |
The length parameter in KeyManager.create_key is not well defined in the interface. Specifically it is not clear whether the integer value passed in is the length in bits or the length in bytes.
Because of this, there is a mismatch in the way that BarbicanKeyManager and VaultKeyManager handle them.
BarbicanKeyManager assumes the value is bytes, but VaultKeyManager assumes the value is in bits. This, in turn, could result in unexpected behavior in applications using Castellan, since they would not have any knowledge at runtime about which backend is running and whether Castellan will return bits or bytes when asked to generate keys.
For example, consider the following:
keymgr = key_manager.API(CONF)
keymgr.create_key(ctx, "AES", 256)
Which currently generates a 256 bit AES key when Barbican is configured, but generates a 2048 bit AES key when Vault is configured. |
|
| 2019-02-22 05:33:32 |
Douglas Mendizábal |
description |
The length parameter in KeyManager.create_key is not well defined in the interface. Specifically it is not clear whether the integer value passed in is the length in bits or the length in bytes.
Because of this, there is a mismatch in the way that BarbicanKeyManager and VaultKeyManager handle them.
BarbicanKeyManager assumes the value is bytes, but VaultKeyManager assumes the value is in bits. This, in turn, could result in unexpected behavior in applications using Castellan, since they would not have any knowledge at runtime about which backend is running and whether Castellan will return bits or bytes when asked to generate keys.
For example, consider the following:
keymgr = key_manager.API(CONF)
keymgr.create_key(ctx, "AES", 256)
Which currently generates a 256 bit AES key when Barbican is configured, but generates a 2048 bit AES key when Vault is configured. |
The length parameter in KeyManager.create_key is not well defined in the interface. Specifically it is not clear whether the integer value passed in is the length in bits or the length in bytes.
Because of this, there is a mismatch in the way that BarbicanKeyManager and VaultKeyManager handle them.
BarbicanKeyManager assumes the value is bytes, but VaultKeyManager assumes the value is in bits. This, in turn, could result in unexpected behavior in applications using Castellan, since they would not have any knowledge at runtime about which backend is running and whether Castellan will return bits or bytes when asked to generate keys.
For example, consider the following:
keymgr = key_manager.API(CONF)
keymgr.create_key(ctx, "AES", 256)
Which currently generates a 256 bit AES key when Barbican is configured, but generates a 2048 bit AES key when Vault is configured. |
|
| 2019-02-22 05:34:51 |
Douglas Mendizábal |
description |
The length parameter in KeyManager.create_key is not well defined in the interface. Specifically it is not clear whether the integer value passed in is the length in bits or the length in bytes.
Because of this, there is a mismatch in the way that BarbicanKeyManager and VaultKeyManager handle them.
BarbicanKeyManager assumes the value is bytes, but VaultKeyManager assumes the value is in bits. This, in turn, could result in unexpected behavior in applications using Castellan, since they would not have any knowledge at runtime about which backend is running and whether Castellan will return bits or bytes when asked to generate keys.
For example, consider the following:
keymgr = key_manager.API(CONF)
keymgr.create_key(ctx, "AES", 256)
Which currently generates a 256 bit AES key when Barbican is configured, but generates a 2048 bit AES key when Vault is configured. |
The length parameter in KeyManager.create_key is not well defined in the interface. Specifically it is not clear whether the integer value passed in is the length in bits or the length in bytes.
Because of this, there is a mismatch in the way that BarbicanKeyManager and VaultKeyManager handle them.
BarbicanKeyManager assumes the value is bits, but VaultKeyManager assumes the value is in bytes. This, in turn, could result in unexpected behavior in applications using Castellan, since they would not have any knowledge at runtime about which backend is running and whether Castellan will return bits or bytes when asked to generate keys.
For example, consider the following:
keymgr = key_manager.API(CONF)
keymgr.create_key(ctx, "AES", 256)
Which currently generates a 256 bit AES key when Barbican is configured, but generates a 2048 bit AES key when Vault is configured. |
|
| 2019-02-22 13:51:03 |
Douglas Mendizábal |
castellan: assignee |
|
Moisés Guimarães de Medeiros (moguimar) |
|
| 2019-02-22 13:51:09 |
Douglas Mendizábal |
castellan: importance |
Undecided |
High |
|
| 2019-02-22 13:51:17 |
Douglas Mendizábal |
castellan: status |
New |
In Progress |
|
| 2019-02-22 16:59:35 |
OpenStack Infra |
castellan: status |
In Progress |
Fix Released |
|
