On 2023-03-07 11:54:43 -0800 (-0800), Jay Faulkner wrote: [...]
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.
Well, the context here is not "supporting old versions of the PYCA/Cryptography library," it's rather "supporting downstream distributors who backport patches to their stable forks of PYCA/Cryptography." While it may sound like the same thing, there's a subtle difference. Obviously nobody should be running old versions of the library because they'll be missing critical security fixes, but there are stable distributions who take care of backporting security patches for their LTS versions and want newer OpenStack releases to still be usable there.
The PYCA/Cryptography library has been particularly challenging here, since it decided to go all-in on Rust which, while a very exciting and compelling language from a security perspective, is not exactly the most stabilized ecosystem yet and has seen a lot of churn over the past few years leading to Rust-based projects often being entirely unfit for inclusion in stable server distros due to continually requiring newer toolchain versions and replacing build systems.
This isn't just Ubuntu. The latest Debian stable release carries a python3-cryptography based on 3.3.2 from two years ago, older than what Corey's trying to support but still quite new from the perspective of an LTS server distribution. Rocky 9.1 (which I assume is the same as RHEL but I can never find where to look up RHEL package versions) is carrying a python3-cryptography based on 36.0.1 from 2021, so newer than what Corey is trying to support on Ubuntu but not by much (approximately 3 months).
The point is, we can't reasonably test with all these different versions of the library, and that's just one library out of hundreds we're depending on for that matter... but what we can do is say that if people find regressions due to us testing exclusively with newer features of these libraries than are available on platforms we expect our users to deploy on, we'll gladly accept patches to fix that situation.
I expect the TC is going to choose Ubuntu 22.04 LTS as a target platform for at least the OpenStack 2023.2 and 2024.1 coordinated releases, but almost certainly the 2024.2 coordinated release as well since Ubuntu 24.04 LTS won't be officially available before we start that development cycle. That means the first coordinated OpenStack release which would be able to effectively depend on features from a newer python3-cryptography package on Ubuntu is going to be 2025.1. Food for thought.