From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LY36K-00076S-Go for garchives@archives.gentoo.org; Fri, 13 Feb 2009 18:49:25 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 22293E047E; Fri, 13 Feb 2009 18:49:22 +0000 (UTC) Received: from mail-gx0-f175.google.com (mail-gx0-f175.google.com [209.85.217.175]) by pigeon.gentoo.org (Postfix) with ESMTP id E7AE3E047E for ; Fri, 13 Feb 2009 18:49:21 +0000 (UTC) Received: by gxk23 with SMTP id 23so1221669gxk.10 for ; Fri, 13 Feb 2009 10:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ffSKNEsr8SdB8g1R3GRflr9MOBhQellYorxwiY5GJwY=; b=ouDLLHPrBJ0CLLFn28JDuT7dWJVSoSyVzI0GcFDGTylY4nzOFZqsHjM9DeEo5mTcGb cZbuv0FjMuCEtE/Z82voOV1m5i63KEpSSPicBSQ9L+pnq7NqnzaALgZvRQNzpQissIF/ rkNII8C4VBl974N7dvbeZ7hhxCIx4m64N9n8k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=CTVJM8w6cIC8hhSIbWURIIJTK6VNZVSUV0SLUA03FXaUSE5I8DY9atTedxd8IhxK37 k7fYFKWp/BjQcIUDKsAIqOrHzfgALr059zIwzOy5bQ0WZRArLqsZI3b0wn8sUgTzMF6s 4MbqJsxMuroeIq9f0Il8qGnle/hI3QjBo1va8= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@lists.gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org MIME-Version: 1.0 Received: by 10.100.142.19 with SMTP id p19mr1303513and.3.1234550961379; Fri, 13 Feb 2009 10:49:21 -0800 (PST) In-Reply-To: <200902131909.05093.casta@xwing.info> References: <200902131005.22853.casta@xwing.info> <200902131815.19099.casta@xwing.info> <200902130948.03565.gengor@gentoo.org> <200902131909.05093.casta@xwing.info> Date: Fri, 13 Feb 2009 18:49:21 +0000 Message-ID: <279fbba40902131049n4cceb80dm51440beb35791d28@mail.gmail.com> Subject: Re: [gentoo-hardened] hardened glibc downgrade From: Kerin Millar To: gentoo-hardened@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 8c231f44-f442-45ce-bc41-7d298a229531 X-Archives-Hash: ca1460c37efdd2133c766c5430a77ce9 2009/2/13 Guillaume Castagnino : > Le vendredi 13 f=E9vrier 2009 18:48:03, Gordon Malm a =E9crit : >> On Friday, February 13, 2009 09:15:18 Guillaume Castagnino wrote: >> > In fact, no: glibc-2.9 was allready keyworded on hardened ~x86 in the >> > portage tree, and not masked until 2009-02-11. >> > So ~x86 hardened was naturally upgraded to glibc 2.9 without any >> > intervention. >> >> And naturally if you're running ~ARCH you should know how to >> manipulate /etc/portage. >> >> > I have no problem to package.unmask it, it's just to know what is the >> > reason for this mask :) >> >> Because sys-libs/glibc-2.8 is about to go stable and stable hardened is = not >> ready for it. >> >> > But keep in mind that for ~x86 hardened, this mask has a dependency >> > problem, since ~x86 iproute2 depends on glibc that is now masked on >> > ~x86 hardened (and was not before 2009-02-11) >> >> So put sys-libs/glibc into /etc/portage/package.unmask. > > Yes of course. > I perfectly know how to do to fix this problem *for me* as ~arch user for= many > years. > > > But what I want to point, is that currently, depdency tree seems to be br= oken > for ~x86 : some packages in the ~x86 tree (iproute2 for example) ask for > package not available in ~x86 (glibc). > Doesn't it sounds wrong to have such situation in the official tree ? > It is not ideal but, as has already been established, it poses only the most trivial inconvenience for users such as yourself. On the other hand, if that is what it takes to be absolutely assured that Hardened Gentoo users who are using the stable tree will continue to have a functional system then it is surely a sensible precaution on the part of the maintainer. The needs of this demographic should not be (potentially) jepoardized so as to prevent the ~arch users from having to enter a single line into package.unmask. Under the circumstances, what would you have done? In terms of how other packages are stabilised, bear in mind that the developers concerned - unlike Gordon - will seldom have the interests of the Hardened userbase first and foremost in their minds ... a situation exacerbated by the current disparity between the vanilla and hardened toolchain/kernel versions and the limited manpower at the disposal of the project. Nevertheless, things continue to move forwards but there will be occasions - such as this - where special measures need to be enacted. Those of us using a bleeding-edge toolchain might consider thoroughly testing the current stable kernel so as to determine whether this precaution is indeed necessary. Regards, --Kerin