[barbican][requirements] incompatibility between cryptography and pykmip
Hello, It was recently discovered that the latest pykmip release is not compatible[1][2] with cryptography>42.0.0, which is currently in upper constraints for master and 2024.1. The latest release of pykmip is incompatible with even cryptography >= 39.0.0, because no release has been created since the compatibility fix[2] was merged. The stable/2023.2 branch currently uses cryptography 40.0.2 so the pykmip library has been broken since 2023.2, it seems. I wonder what would be the appropriate step to mitigate the problem, and I would like to ask for opinions. Especially the first question is a bit urgent because we have quite a short period to make deprecation for 2024.1 . 1. (To the barbican team and the operators subscribing this list) Can we deprecate the kmip secret store plugin in 2024.1 so that we can drop it in 2024.2 ? Or does anyone have any concern with removing it in a future release ? 2. (To requirements team) In case the proposed fix[3] is merged and a new pykmip release is created, can we bump the version in 2024.1 u-c and 2023.2 u-c ? As far as I've checked, pykmip is used only by Barbican so bumping it would have quite limited impact. Thank you, Takashi [1] https://meetings.opendev.org/irclogs/%23openstack-barbican/%23openstack-barb... [2] https://github.com/OpenKMIP/PyKMIP/issues/713 [3] https://github.com/OpenKMIP/PyKMIP/commit/652d5cab [4] https://github.com/OpenKMIP/PyKMIP/pull/714 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
While we do not use KMIP here as storage plugin, but it still feels quite important frankly speaking, given that this is currently the only driver that would allow to store secrets in HSM. And I see how this can be a hard requirement for certain use-cases. But given that there were no releases in last 4 years almost, even if your fix is merged, I fail to see any new tag coming anytime soon anyway, so it could be constrained. So feels like deprecation is pretty much the only way, given that OpenKMIP as a whole don't see any maintenance - other repos seems to be even in a worse shape... On Fri, Mar 29, 2024, 06:13 Takashi Kajinami <kajinamit@oss.nttdata.com> wrote:
Hello,
It was recently discovered that the latest pykmip release is not compatible[1][2] with cryptography>42.0.0, which is currently in upper constraints for master and 2024.1.
The latest release of pykmip is incompatible with even cryptography >= 39.0.0, because no release has been created since the compatibility fix[2] was merged. The stable/2023.2 branch currently uses cryptography 40.0.2 so the pykmip library has been broken since 2023.2, it seems.
I wonder what would be the appropriate step to mitigate the problem, and I would like to ask for opinions. Especially the first question is a bit urgent because we have quite a short period to make deprecation for 2024.1 .
1. (To the barbican team and the operators subscribing this list) Can we deprecate the kmip secret store plugin in 2024.1 so that we can drop it in 2024.2 ? Or does anyone have any concern with removing it in a future release ?
2. (To requirements team) In case the proposed fix[3] is merged and a new pykmip release is created, can we bump the version in 2024.1 u-c and 2023.2 u-c ? As far as I've checked, pykmip is used only by Barbican so bumping it would have quite limited impact.
Thank you, Takashi
[1] https://meetings.opendev.org/irclogs/%23openstack-barbican/%23openstack-barb... [2] https://github.com/OpenKMIP/PyKMIP/issues/713 [3] https://github.com/OpenKMIP/PyKMIP/commit/652d5cab [4] https://github.com/OpenKMIP/PyKMIP/pull/714
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
participants (2)
-
Dmitriy Rabotyagov
-
Takashi Kajinami