Open Stack

> The concern I have downstream in Ubuntu is that we need to continue being
> compatible with cryptography 3.4.8 through openstack 2024.1. This is
> because all releases through 2024.1 will be backported to the ubuntu 22.04
> cloud archives which will use cryptography 3.4.8. Once we get to 2024.2, we
> will be backporting to 24.04 cloud archives, which will have the new
> rust-based versions of cryptography.
>
> The current upper-constraint for cryptography is 38.0.2, but the various
> requirements.txt min versions are much lower (e.g. keystone has
> cryptography>=2.7). This is likely to lead to patches landing with features
> that are only in 38.0.2, so it will likely be difficult to enforce min
> version support. But perhaps a stance toward maintaining compatibility
> could be established.
>
>
What is the impetus needed for us to raise the lower-constraint? When do we
decide we should do that, generally -- is it just ad-hoc, someone requests
it, or is there a more involved process? We certainly don't dictate all
versions of required compilers and such in our TC testing docs (although
that is implied in distribution-platform) -- so I think there's another
piece to it when talking about python dependencies.


I do not think it's wise to commit to supporting older versions of
cryptography through 2024.1. In fact, you *must* have a cryptography
release that is rust-enabled in order to get OpenSSL 3 support. Not to
mention the memory safety benefits from using a rust version. I'm not
saying we should force newer cryptography immediately; but it is reason
enough to give me significant pause about answering a question about
supporting it through two additional releases.

Thanks,
Jay Faulkner
Ironic PTL
TC Member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230307/f9f293a4/attachment.htm>