Open Stack

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.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230307/e08ae19f/attachment.sig>