| 1 |
Am Sonntag, 25. Februar 2018, 07:17:47 CET schrieb Benda Xu: |
| 2 |
> Hi all, |
| 3 |
> |
| 4 |
> Yes, it's 2018. But there are still RHEL 4 and 5 systems running |
| 5 |
> antique kernels such as 2.6.8 and 2.6.18. In my experience, many of |
| 6 |
> them are data acquisition hubs or computing clusters. No administrator |
| 7 |
> cares about security as long as they "work". |
| 8 |
> |
| 9 |
> Under the form "Prefix", Gentoo is set out to rescue users trapped in |
| 10 |
> these abandoned wastelands of antiques. After years of work, we have |
| 11 |
> achieved that goal, except one minor thing: glibc periodically drop |
| 12 |
> support for old linux kernels, the lastest glibc supporting linux 2.6.8 |
| 13 |
> is 2.16 and for linux-2.6.18 it is glibc-2.19. |
| 14 |
> |
| 15 |
> With the recent reunion of the Toolchain Project, old glibc versions are |
| 16 |
> masked and removed, accelerating the adoption of new versions. This |
| 17 |
> opens a new oppotunity for the Prefix: people stops caring about |
| 18 |
> unsupported glibc versions, the Prefix Project can take them over |
| 19 |
> without worrying about breaking other peoples' machines. |
| 20 |
|
| 21 |
Well, in principle the idea is OK. We already/still keep some old glibc, gcc, |
| 22 |
and binutils versions for that reason. |
| 23 |
|
| 24 |
However, I have a few conditions. |
| 25 |
|
| 26 |
* Only masked. Only prefix keywords. |
| 27 |
If you really must unmask them in a specific prefix profile, you must provide |
| 28 |
big fat warnings about the resulting security risks. |
| 29 |
(I dont know how things went in prehistoric times, but recently there have |
| 30 |
been a LOT of glibc-related CVEs. Many fixes can be backported, but definitely |
| 31 |
not all of them.) |
| 32 |
|
| 33 |
* No toolchain-glibc.eclass or eblits or similar abominations. Standard QA |
| 34 |
rules apply. |
| 35 |
|
| 36 |
* Try to stick to a minimum of required features (and a minimum of required |
| 37 |
versions). |
| 38 |
We want to strongly avoid adding conditionals to other packages. [#] |
| 39 |
|
| 40 |
* Please use our gentoo glibc repo to keep track of branches and patchsets. |
| 41 |
Happy to show you the details sometime soon. |
| 42 |
|
| 43 |
|
| 44 |
[#] If not for such "old version" considerations, we could soon move the |
| 45 |
libtirpc headers to the place where the glibc headers used to live. That could |
| 46 |
save us a ...load of patching and bugfixing. By keeping flexibility and |
| 47 |
compatibility, that is unfortunately not possible. |
| 48 |
|
| 49 |
|
| 50 |
|
| 51 |
-- |
| 52 |
Andreas K. Hüttel |
| 53 |
dilfridge@g.o |
| 54 |
Gentoo Linux developer |
| 55 |
(council, toolchain, perl, libreoffice, comrel) |
Archives