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

["Andreas K. Huettel" <dilfridge@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

Am Sonntag, 25. Februar 2018, 07:17:47 CET schrieb Benda Xu:
> Hi all,
> 
> Yes, it's 2018.  But there are still RHEL 4 and 5 systems running
> antique kernels such as 2.6.8 and 2.6.18.  In my experience, many of
> them are data acquisition hubs or computing clusters.  No administrator
> cares about security as long as they "work".
> 
> Under the form "Prefix", Gentoo is set out to rescue users trapped in
> these abandoned wastelands of antiques.  After years of work, we have
> achieved that goal, except one minor thing: glibc periodically drop
> support for old linux kernels, the lastest glibc supporting linux 2.6.8
> is 2.16 and for linux-2.6.18 it is glibc-2.19.
> 
> With the recent reunion of the Toolchain Project, old glibc versions are
> masked and removed, accelerating the adoption of new versions.  This
> opens a new oppotunity for the Prefix: people stops caring about
> unsupported glibc versions, the Prefix Project can take them over
> without worrying about breaking other peoples' machines.

Well, in principle the idea is OK. We already/still keep some old glibc, gcc, 
and binutils versions for that reason.

However, I have a few conditions.

* Only masked. Only prefix keywords.
If you really must unmask them in a specific prefix profile, you must provide 
big fat warnings about the resulting security risks.
(I dont know how things went in prehistoric times, but recently there have 
been a LOT of glibc-related CVEs. Many fixes can be backported, but definitely 
not all of them.)

* No toolchain-glibc.eclass or eblits or similar abominations. Standard QA 
rules apply.

* Try to stick to a minimum of required features (and a minimum of required 
versions).
We want to strongly avoid adding conditionals to other packages. [#]

* Please use our gentoo glibc repo to keep track of branches and patchsets.
Happy to show you the details sometime soon.


[#] If not for such "old version" considerations, we could soon move the 
libtirpc headers to the place where the glibc headers used to live. That could 
save us a ...load of patching and bugfixing. By keeping flexibility and 
compatibility, that is unfortunately not possible.



-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]