Tracking issue for manylinux_2_34 image about manylinux HOT 13 OPEN

Thanks for the tracking issue.

manylinux_2_34 is already supported by auditwheel so there's no need for a new version: pypa/auditwheel#405

While UBI added support for gcc-toolset, it might still not support some -devel packages so, IMHO, it's fine to use AlmaLinux for now as is done for manylinux_2_28.

They'll keep ABI-compatibility (which is by far the most important), but will drop bug-for-bug compatibility (which is IMO not a big deal for us).

Indeed, we only aim for ABI-compatibility.

from manylinux.

showed comprehensively that we should stick with a RHEL-derivative
I hold a different opinion on this and just left a few comments in the original issues to explain why. Mainly,

1. RHEL is not free. Neither the derivations can provide enough security updates for free.
2. From supply chain point of view you would not want to bind to a single supplier

I would suggest not going further on this road. Instead, give the existing users enough time to transit to an alternative solution. For example, as you said half of the pypi users already have glibc>=2.34, which means they also have a decent GCC compiler and very new libstdc++, which dims the need of using devtoolset when time goes by.

from manylinux.

From supply chain point of view you would not want to bind to a single supplier

So far all relevant¹ manylinux images have been based on RHEL-derivatives, and this system has worked very well. Red Hat itself - though a single vendor - is about as far as possible from a supply chain risk as any single company can be.

Your proposal in #1012 is not feasible (in my opinion). Your argument against UBI in #1282 may be correct, but then we can still stay with alma (which will fix security issues also in the rpms).

For example, as you said half of the pypi users already have glibc>=2.34, which means they also have a decent GCC compiler and very new libstdc++, which dims the need of using devtoolset when time goes by.

Try telling maintainers that they should halve their user base. Said differently, a lot of projects care about providing support that is a broad as possible across many different uses (many of which get stuck on old distros for whatever reason), and raising their glibc baseline is done extremely conservatively. This creates an obvious tension between needing to support old systems while wanting to use +/- contemporary compilers. The only sustainable solution to this over the relevant lifecycles has been the devtoolset.

from manylinux.

Functionally the existing Alma based images work very well, but if you run a security scanner to see if any of the components in the images needs be patched, it will be a different story. So my concern is more from supply chain point of view. If the toolchains you use has a known vulnerability, it could be get used to inject a backdoor in the package you are building. We do not see a reliable way to get security patches for the RHEL-derivatives, mainly because Red Hat doesn't want to provide them for free.

from manylinux.

RHEL is not free. Neither the derivations can provide enough security updates for free.

RHEL Universal Base Image is free (and redistributable), fwiw.

https://catalog.redhat.com/software/base-images

I believe many of the downsides of CentOS Stream were addressed since the previous discussion also, although the 5 year lifecycle remains. For that reason either UBI or Alma images would (I assume) probably be preferred.

from manylinux.

Yes, the image is free. But anything users installed to the image are not covered. manylinux_2_34 needs to install GCC compiler and a lot of other software from dnf repos. These software may or may not be able to get security updates, that's my biggest concern. For example, GCC depends on GMP. The gmp package in UBI's repo has a known security vulnerability. The UBI8 base image is well patched, but the packages hosted in UBI8's official repos are not. If manylinux doesn't need to manually install any RPM package(i.e. an official UBI image can provide everything we need), I would be less concerned.

from manylinux.

@carlwgeorge ^ can you speak to those concerns

from manylinux.