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