[gentoo-hardened] hardened glibc downgrade

[gentoo-hardened] hardened glibc downgrade

[Guillaume Castagnino]

Hi,

I noticed this in hardened profile :
# Mask off anything greater than glibc-2.6.x for now.
# 2009-02-11 gengor
>=sys-libs/glibc-2.7


Is there any good (means "critical") reason for this downgrade ?
Because it causes problem with some packages that needs higher glibc version.
For example :
- iproute2 needs >=glibc-2.7



  ('installed', '/', 'sys-libs/glibc-2.9_p20081201-r1', 'nomerge') pulled in 
by
    >=sys-libs/glibc-2.7 required by ('installed', '/', 'sys-
apps/iproute2-2.6.28', 'nomerge')
    (and 12 more)      


Thanks for your feedback

Regards,
Guillaume

-- 
Guillaume Castagnino
    guilc@laposte.net / casta@xwing.info

Re: [gentoo-hardened] hardened glibc downgrade

[Thomas Sachau]

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

Guillaume Castagnino schrieb:
> Hi,
> 
> I noticed this in hardened profile :
> # Mask off anything greater than glibc-2.6.x for now.
> # 2009-02-11 gengor
>> =sys-libs/glibc-2.7
> 
> 
> Is there any good (means "critical") reason for this downgrade ?
> Because it causes problem with some packages that needs higher glibc version.
> For example :
> - iproute2 needs >=glibc-2.7
> 
> 
> 
>   ('installed', '/', 'sys-libs/glibc-2.9_p20081201-r1', 'nomerge') pulled in 
> by
>     >=sys-libs/glibc-2.7 required by ('installed', '/', 'sys-
> apps/iproute2-2.6.28', 'nomerge')
>     (and 12 more)      
> 
> 
> Thanks for your feedback
> 
> Regards,
> Guillaume
> 

I talked to gengor yesterday, so i just copy some lines from IRC:

Feb 12 21:34:28 <gengor>	Tommy[D]: because I haven't tested it against stable + stable kernel.
Feb 12 21:37:57 <gengor>	its safe because stable glibc (2.6.1) doesn't take advantage of any new
API's between 2.6.{25,26} -> 2.6.27.  I don't know about the newer glibc though, hence the mask.
Feb 12 21:38:54 <gengor>	it was fine to leave it that way when glibc was unstable (because those who
run unstable should know what they are doing and be running unstable kernel too).  But they're
moving on glibc-2.8 stabilization right now.
Feb 12 21:40:33 <gengor>	and there are still some minor lingering issues w/ 2.6.27 and 2.6.28 so I
don't want to mark it stable yet.  Although we're getting to the point 2.6.26 is becoming out of
date, not getting updates from mainline and I don't have time for a bunch of backports this time
around - so my hand may be forced at some point.


-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 315 bytes --]

Re: [gentoo-hardened] hardened glibc downgrade

[Gordon Malm]

On Friday, February 13, 2009 07:27:04 Thomas Sachau wrote:
> Guillaume Castagnino schrieb:
> > Hi,
> >
> > I noticed this in hardened profile :
> > # Mask off anything greater than glibc-2.6.x for now.
> > # 2009-02-11 gengor
> >
> >> =sys-libs/glibc-2.7
> >
> > Is there any good (means "critical") reason for this downgrade ?
> > Because it causes problem with some packages that needs higher glibc
> > version. For example :
> > - iproute2 needs >=glibc-2.7
> >
> >
> >
> >   ('installed', '/', 'sys-libs/glibc-2.9_p20081201-r1', 'nomerge') pulled
> > in by
> >
> >     >=sys-libs/glibc-2.7 required by ('installed', '/', 'sys-
> >
> > apps/iproute2-2.6.28', 'nomerge')
> >     (and 12 more)
> >
> >
> > Thanks for your feedback
> >
> > Regards,
> > Guillaume
>
> I talked to gengor yesterday, so i just copy some lines from IRC:
>
> Feb 12 21:34:28 <gengor>	Tommy[D]: because I haven't tested it against
> stable + stable kernel. Feb 12 21:37:57 <gengor>	its safe because stable
> glibc (2.6.1) doesn't take advantage of any new API's between 2.6.{25,26}
> -> 2.6.27.  I don't know about the newer glibc though, hence the mask. Feb
> 12 21:38:54 <gengor>	it was fine to leave it that way when glibc was
> unstable (because those who run unstable should know what they are doing
> and be running unstable kernel too).  But they're moving on glibc-2.8
> stabilization right now.
> Feb 12 21:40:33 <gengor>	and there are still some minor lingering issues w/
> 2.6.27 and 2.6.28 so I don't want to mark it stable yet.  Although we're
> getting to the point 2.6.26 is becoming out of date, not getting updates
> from mainline and I don't have time for a bunch of backports this time
> around - so my hand may be forced at some point.

In the future please refrain from cutting and pasting select bits of 
conversation from IRC out of context.  Or any IRC conversation for that 
matter.  You don't even realize that the bits you selected for cut/paste 
don't even make sense w/o the other parts of the conversation.  This is very 
fscking rude.

To OP:  If you've already upgraded your glibc then you've package.keyworded 
it, so why not just package.unmask it as well?  You're not forced to 
downgrade.

Re: [gentoo-hardened] hardened glibc downgrade

[Guillaume Castagnino]

Le vendredi 13 février 2009, Gordon Malm a écrit :
> To OP:  If you've already upgraded your glibc then you've
> package.keyworded it, so why not just package.unmask it as well? 
> You're not forced to downgrade.

Hi,

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.

I have no problem to package.unmask it, it's just to know what is the 
reason for this mask :)
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)

Regards

-- 
Guillaume Castagnino
    guilc@laposte.net / casta@xwing.info

Re: [gentoo-hardened] hardened glibc downgrade

[Gordon Malm]

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.

[gentoo-hardened] Re: hardened glibc downgrade

[Peter Hjalmarsson]

fre 2009-02-13 klockan 09:48 -0800 skrev Gordon Malm:
> Because sys-libs/glibc-2.8 is about to go stable and stable hardened is not 
> ready for it.
> 

Could you please add that kind of information in the package.mask
comment? Just mention that it will go stable and hardened is not ready
for that yet should explain a whole lot more then the current comment,
that to be honest does not tell if it is a stabilization problem, a
security-problem, a compilation-problem or something totally diffrent.


Anyway, thanks for your hard work.

Re: [gentoo-hardened] Re: hardened glibc downgrade

[Gordon Malm]

On Friday, February 13, 2009 10:03:45 Peter Hjalmarsson wrote:
> Could you please add that kind of information in the package.mask
> comment? Just mention that it will go stable and hardened is not ready
> for that yet should explain a whole lot more then the current comment,
> that to be honest does not tell if it is a stabilization problem, a
> security-problem, a compilation-problem or something totally diffrent.

I changed it but I'll argue that it doesn't matter and doesn't clarify 
anything wasn't already implied by virtue of simply existing in package.mask.  
It is an all-of-the-above problem because there's been zero official tests of 
glibc-2.8 with currently stabled packages in hardened.  Part of the reason 
for stable and unstable is so that users don't have to pay attention to every 
detail and sometimes there are no details to give.

Users who need/want to know every detail of everything that goes on need to 
get more involved.  For everyone one item that is made an issue there are 
probably 87 more going on behinds the scenes that aren't known about and are 
never seen.  Which proves the fact that users don't need everything that goes 
on verbosely announced in order to use their systems and keep up with 
upgrades.

> Anyway, thanks for your hard work.

We need more contributors, Hardened is barely hanging on.  The few devs left 
can only allocate so much of their own time to the project.  But that's 
another thread for another day.  I will not answer any questions regarding 
this right now so don't ask - I simply lack the time for a spagetti thread.  
Just keep watching the ML.

Gordon Malm (gengor)

Re: [gentoo-hardened] hardened glibc downgrade

[Guillaume Castagnino]

Le vendredi 13 février 2009 18:48:03, Gordon Malm a écrit :
> 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 broken 
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 ?


Anyway, thanks for your work :)

-- 
Guillaume Castagnino
    guilc@laposte.net / casta@xwing.info

Re: [gentoo-hardened] hardened glibc downgrade

[Kerin Millar]

2009/2/13 Guillaume Castagnino <casta@xwing.info>:
> Le vendredi 13 février 2009 18:48:03, Gordon Malm a écrit :
>> 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 broken
> 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