Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Benda Xu]

Hi Andreas,

I really appreciate your interest as I am try to convince our fellows.

"Andreas K. Huettel" <dilfridge@g.o> writes:

> another option would be to (try to) revive glibc-2.5, 2.12, and 2.17
> instead.

> Yes I know they are even older, but these are the versions that RHEL
> uses, and for which RH still provides support (until 2020 for 2.5,
> 2024 for 2.12)...
> https://sourceware.org/glibc/wiki/Release#Distribution_Branch_Mapping

> That however would require that the RHEL patchsets are public
> somehwere. Which I doubt... after all there's an "E" in RHEL...

> [...]

> ... except that my personal motivation has dropped somewhat when
> noticing that the CentOS package applies 552 (!) patches on top of
> 2.17.

Carrying Redhat patches are not only technical unfeasible, but also out
of our best interest.  The reasons are the following.

glibc-2.5 does not support fortify, thus breaking gentoo version of gcc
since verison 4.3 (Bug 289757).  The original purpose of
prefix-standalone was to introduce newer glibc from gentoo to solve this
issue.  So shipping glibc-2.5 requires maintaining seperate versions of
gcc.

glibc has some tolerance for kernel.  2012 glibc-2.16 supports 2004
linux-2.6.8.  It buys us 8 years!  That's the basis for the magic of
prefix-standalone.  gcc in turn has some tolerance for glibc.  So far
glibc-2.16 is still supported by the newest gcc but glibc-2.5 is
definitely out of the game.

I hear your instinct for RHEL versions for security consideration.  But
in this use case, the kernels are usually outdated for many years and
prone to multiple privilege escalation CVE's.  If the administrators of
these systems cared about security, these antiques wouldn't have existed
in the first place.

Therefore, using edge versions of glibc-2.16 (newest glibc to support
linux 2.6+) and 2.19 (newest glibc to support linux 2.6.16+) makes more
sense.

Yours,
Benda