FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 10-27-2011, 09:03 AM
"Paweł Hajdan, Jr."
 
Default hardened glibc and gcc dependencies

As a part of my earlier threads I tried to figure out the migration plan
from not hardened glibc and not hardened gcc to both of them hardened.

That of course raises questions like - what we compile first, and what
are dependencies here?

Here's what I have figured out - by _experimenting_ not speculation:

1. Building glibc with USE=hardened works, no matter whether the
toolchain is hardened or not.

2. However, glibc won't apply one hardening-related patch if the used
toolchain is not pie-enabled.

3. Interestingly, gcc with USE=hardened compiles fine even if glibc is
-hardened. The vanilla spec works. I haven't tested the hardened spec.

Based on that, I suggest the following dependency changes (conceptually):

In glibc: DEPEND="gcc[hardened?]"
In gcc: PDEPEND="elibc_glibc? glibc[hardened?]"

Thoughts?
 
Old 10-27-2011, 04:08 PM
"Paweł Hajdan, Jr."
 
Default hardened glibc and gcc dependencies

On 10/27/11 11:03 AM, "Paweł Hajdan, Jr." wrote:
> In glibc: DEPEND="gcc[hardened?]"
> In gcc: PDEPEND="elibc_glibc? glibc[hardened?]"

I even got an OK on #gentoo-hardened, but I just realized that EAPI-0
(that both packages in question use) doesn't allow use deps like
[hardened?].

I guess bumping the EAPI on those packages is not an option (is it?), so
I'm going to do some more experiments to see if there are more possible
problems.
 
Old 10-27-2011, 04:49 PM
Duncan
 
Default hardened glibc and gcc dependencies

Paweł Hajdan, Jr. posted on Thu, 27 Oct 2011 18:08:36 +0200 as excerpted:

> On 10/27/11 11:03 AM, "Paweł Hajdan, Jr." wrote:
>> In glibc: DEPEND="gcc[hardened?]"
>> In gcc: PDEPEND="elibc_glibc? glibc[hardened?]"
>
> I even got an OK on #gentoo-hardened, but I just realized that EAPI-0
> (that both packages in question use) doesn't allow use deps like
> [hardened?].
>
> I guess bumping the EAPI on those packages is not an option (is it?), so
> I'm going to do some more experiments to see if there are more possible
> problems.

AFAIK, it's an option, but a tough one. But as with profiles, at some
point it's worth considering whether holding back on toolchain EAPI bumps
is worth it any longer. It'll need to happen eventually, and AFAIK, for
a system without EAPI-1 or 2 or whatever, portage is already borked.
Same with the tree in general, since a bash of that vintage isn't going
to parse certain ebuilds due to the bash 4.1 thing.

Actually, but for the patience of toolchain maintainers, that bump might
have already happened. So I guess it's sort of up to them, tho getting
the blessing of council on something that big is probably a reasonable
idea. But that's probably a good idea for moving toward hardened by
default anyway, so I don't see that as a huge block.

I'm reminded of the move to cascading profiles... Plus the bash 4.1
thing. At some point, you just accept current reality and move on. But
toolchain's say will matter a lot. If they don't believe it's time to
leave EAPI-0 for gcc and glibc, I don't think it's worth pushing against
them on their own packages.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 10-27-2011, 05:33 PM
Nirbheek Chauhan
 
Default hardened glibc and gcc dependencies

On Thu, Oct 27, 2011 at 9:38 PM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
> On 10/27/11 11:03 AM, "Paweł Hajdan, Jr." wrote:
>> In glibc: DEPEND="gcc[hardened?]"
>> In gcc: PDEPEND="elibc_glibc? glibc[hardened?]"
>
> I even got an OK on #gentoo-hardened, but I just realized that EAPI-0
> (that both packages in question use) doesn't allow use deps like
> [hardened?].
>
> I guess bumping the EAPI on those packages is not an option (is it?), so
> I'm going to do some more experiments to see if there are more possible
> problems.
>

As per council approval in the last meeting, profiles/ is now EAPI 1.
EAPI 2 usage in profiles was not a blocker due to portage version
problems, but due to unresolved questions about cat/pkg[use] atoms in
package.mask etc. Barring those, EAPI 2 would've been approved for
profiles/ as well.

So, I honestly see no reason why toolchain should not start using EAPI 2.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
 
Old 10-27-2011, 11:47 PM
Ryan Hill
 
Default hardened glibc and gcc dependencies

On Thu, 27 Oct 2011 23:03:12 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:

> So, I honestly see no reason why toolchain should not start using EAPI 2.

I await your patch to toolchain.eclass. :P


--
fonts, gcc-porting, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it free anytime
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 
Old 10-27-2011, 11:50 PM
Mike Frysinger
 
Default hardened glibc and gcc dependencies

On Fri, Oct 28, 2011 at 01:47, Ryan Hill wrote:
> On Thu, 27 Oct 2011 23:03:12 +0530 Nirbheek Chauhan wrote:
>> So, I honestly see no reason why toolchain should not start using EAPI 2.
>
> I await your patch to toolchain.eclass. :P

i wouldn't bother as it's most likely not going to be accepted at this time

(i haven't kept up-to-date with the hardened threads as i'm traveling atm)
-mike
 
Old 10-28-2011, 03:03 AM
Nirbheek Chauhan
 
Default hardened glibc and gcc dependencies

On Fri, Oct 28, 2011 at 5:17 AM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> On Thu, 27 Oct 2011 23:03:12 +0530
> Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
>
>> So, I honestly see no reason why toolchain should not start using EAPI 2.
>
> I await your patch to toolchain.eclass. :P
>

Sure, whenever I'm feeling particularly masochistic and have devalued
my sanity, I'll be sure to spend a few days on that...

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
 
Old 10-28-2011, 11:36 AM
"Anthony G. Basile"
 
Default hardened glibc and gcc dependencies

On 10/27/2011 07:50 PM, Mike Frysinger wrote:
> On Fri, Oct 28, 2011 at 01:47, Ryan Hill wrote:
>> On Thu, 27 Oct 2011 23:03:12 +0530 Nirbheek Chauhan wrote:
>>> So, I honestly see no reason why toolchain should not start using EAPI 2.
>> I await your patch to toolchain.eclass. :P
> i wouldn't bother as it's most likely not going to be accepted at this time
>
> (i haven't kept up-to-date with the hardened threads as i'm traveling atm)
> -mike
>

I wouldn't even worry about the hardened stuff right now, just getting
toolchain.eclass EAPI>=2 would be a step forward.

Approaching this naively, can't we just set EAPI="2" in the eclass, see
what breaks and fix? Or is it more involved because some EAPI="0"
ebuilds would be inheriting it and we'd need a lot of if "${EAPI}" == 0
checks interspersed through the eclass?

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
 
Old 10-28-2011, 05:20 PM
Nirbheek Chauhan
 
Default hardened glibc and gcc dependencies

On Fri, Oct 28, 2011 at 5:06 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> Approaching this naively, can't we just set EAPI="2" in the eclass, see
> what breaks and fix? *Or is it more involved because some EAPI="0"
> ebuilds would be inheriting it and we'd need *a lot of if "${EAPI}" == 0
> checks interspersed through the eclass?
>

afaik, eclasses aren't supposed to be setting EAPI. They can choose to
not support some EAPIs and error out, but they need checks.

Mostly, eclasses read ${EAPI} to do conditional exporting of phases
and conditional usage of features.


--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
 
Old 10-30-2011, 09:24 PM
Petteri Rty
 
Default hardened glibc and gcc dependencies

On 28.10.2011 2.50, Mike Frysinger wrote:
> On Fri, Oct 28, 2011 at 01:47, Ryan Hill wrote:
>> On Thu, 27 Oct 2011 23:03:12 +0530 Nirbheek Chauhan wrote:
>>> So, I honestly see no reason why toolchain should not start using EAPI 2.
>>
>> I await your patch to toolchain.eclass. :P
>
> i wouldn't bother as it's most likely not going to be accepted at this time
>

Why not? EAPI 2 was approved more than 3 years ago. I don't think
there's a problem policy wise making all ebuilds able to use it these days.

Regards,
Petteri
 

Thread Tools




All times are GMT. The time now is 07:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org