From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 866B71382C5 for ; Sat, 3 Mar 2018 14:38:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 177A3E0A87; Sat, 3 Mar 2018 14:38:36 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BD051E0A02 for ; Sat, 3 Mar 2018 14:38:35 +0000 (UTC) Received: from germanium (p212068.mirai.ne.jp [210.172.212.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: heroxbd) by smtp.gentoo.org (Postfix) with ESMTPSA id 40E8B335C2C for ; Sat, 3 Mar 2018 14:38:34 +0000 (UTC) From: Benda Xu To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels References: <87o9kdsid0.fsf@gentoo.org> <20180228102036.6d13cd2d@symphony.aura-online.co.uk> <9399023.4aE4nyEdi7@porto> <6096855.60RXL381jp@porto> Date: Sat, 03 Mar 2018 23:36:19 +0900 In-Reply-To: <6096855.60RXL381jp@porto> (Andreas K. Huettel's message of "Wed, 28 Feb 2018 22:10:42 +0100") Message-ID: <87woyti5uk.fsf@gentoo.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Archives-Salt: bf67ef9e-90b7-4718-a6ca-41e87e87350a X-Archives-Hash: 2a89f2d3ff0acbe67d924d62a2df7180 --=-=-= Content-Type: text/plain Hi Andreas, I really appreciate your interest as I am try to convince our fellows. "Andreas K. Huettel" 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEENTS8ZhMowhj4Iw2H33YQtSHxcSIFAlqasuMACgkQ33YQtSHx cSJkchAAn766Sqgl3zEX3kp6Q838uIIDCGOL8SbIZeQUt54+V5gGERFXNL/coPjN ZXCwkxrYC/M9W8o12NPpGdHWtpS8Fv4z0V8qmoUIyc4K1qYwGyHg0Um/0/G77O51 8XvsRWtkd81PGbHIaD8zQ4kSDXMq/E0CUYUTXgN9cDu1gNxS0lXBbqEQGB6ioYNg VGfv1cGIPo+1cHzXOdzpTJN9FkrgceeVtlwsIh7J1wX4mnawUEoU4XzIliMnCMEF EmRsMVO3LfarJB0d639X9M4Rjg5/K+khDvb+BdECx8oronW5/S+7fm6MoZlajWji Jyd2qUxq0YGydCtg633XSz+YdEsYnQOmDyb03s0nLEi663zF1sMBGv/UbMovgDJi OMiNHDFSbchdesykzfVBMHIN0cSP/7LZQg50T+JhCYIPve15BMwN1xQbn1X0y9Lf /Jj2FMZKXwPwodXfi2r1DYOX96D6bcCVlYLJxK3g3v1RrCfelPAotZahwxMk6jof 2CNirBb+Uag3AczFRFgtEf8GysrfSr1X9jR3cWzVVd+DBnbNP/ogBz0s1/RK0sDJ WAAIIEBlqyF3iwTigElQpOa04tEwu3akru8w0dLY+de8Wt6ljLcKt9eQaASOpSr0 TQJe+pt3qJ7ZOVYtL362IP7M/2lhhROP3Gj/EXKB7nVobbpH0fo= =xdCc -----END PGP SIGNATURE----- --=-=-=--