Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 492312 - Reintroduce hardened desktop profiles
Summary: Reintroduce hardened desktop profiles
Status: IN_PROGRESS
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords:
: 551226 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-11-22 16:26 UTC by Rick Farina (Zero_Chaos)
Modified: 2019-03-30 00:30 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rick Farina (Zero_Chaos) gentoo-dev 2013-11-22 16:26:01 UTC
Some time ago, hardened offered a desktop profile which was removed due to issues.  The profile was very simple, containing only a parent file which looked like this:

..
../../../../targets/desktop

That translates to:

gentoo:hardened/linux/amd64
gentoo:targets/desktop

Which means essentially "pull in the hardened profile, then pull in the desktop profile".

This means that changes to the desktop profile will directly override what is in hardened.  If hardened profile sets USE=-jit and desktop sets USE=jit then the user will get USE=jit.

I propose we re-add the desktop profile and simply switch the order so that desktop is pulled in first, then hardened.  Changes to the desktop profile would still affect the users, but if the hardened team deems such a change "undesirable" it is as simple as setting the desired default in the hardened profile and it will override.

I was asked specifically NOT to add these profiles to the tree for testing, as such, here is how you test:

Remove your current make.profile symlink:
unlink /etc/portage/make.profile

Now we make a custom profile:
mkdir /etc/portage/make.profile
echo "gentoo:targets/desktop" > /etc/portage/make.profile/parent
echo "gentoo:hardened/linux/$arch" >> /etc/portage/make.profile/parent

In my testing, $arch can be amd64, x86, and armv7a with little to no side effects.  Anything undesirable can easily be fixed like this, simply by editing the base hardened profile or changing the new hardened desktop profile.
Comment 1 Magnus Granberg gentoo-dev 2013-11-22 17:04:38 UTC
Here is the stacking of the default/linux/amd64/13.0/desktop profile
/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/default/linux/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/eapi-5-files
/usr/portage/profiles/releases/13.0
/usr/portage/profiles/default/linux/amd64/13.0
/usr/portage/profiles/targets/desktop
/usr/portage/profiles/default/linux/amd64/13.0/desktop

Here is the stacking of the hardened/linux/amd64 profile
/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/eapi-5-files
/usr/portage/profiles/releases/13.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64

to make the desktop profile work is should be after the
profiles/releases/13.0 in the stack
if we pot it before the base... all that stuff will overrite the
desktop settings. If it is after hardened it will overrite all the hardened on.
Comment 2 Rick Farina (Zero_Chaos) gentoo-dev 2013-11-22 17:10:09 UTC
(In reply to Magnus Granberg from comment #1)
> Here is the stacking of the default/linux/amd64/13.0/desktop profile

You are looking at the wrong profile, I'm not inheriting default/linux/amd64/13.0/desktop nor would I ever suggest that.

I'm pulling in targets/desktop
Comment 3 Magnus Granberg gentoo-dev 2013-11-22 17:12:50 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #2)
> (In reply to Magnus Granberg from comment #1)
> > Here is the stacking of the default/linux/amd64/13.0/desktop profile
> 
> You are looking at the wrong profile, I'm not inheriting
> default/linux/amd64/13.0/desktop nor would I ever suggest that.
> 
> I'm pulling in targets/desktop
it was there for comperment.
Comment 4 Anthony Basile gentoo-dev 2013-11-22 18:04:42 UTC
Zero_Chaos, do you mind doing the following

1) rsync the current verison of $PORTDIR/profiles to the hardened-dev::profiles overlay branch.  You'll see that the latest commit was Jan 20, 2013 commit.

2) add your changes to the profiles

3) ping us back here, and we'll test by doing mount --bind of the test profiles over the $PORTDIR/profiles and we'll look at the stacking order as it actually resolves and not how we think it might resolve.
Comment 5 Rick Farina (Zero_Chaos) gentoo-dev 2013-11-22 22:47:18 UTC
(In reply to Anthony Basile from comment #4)

It seems pretty easy to follow my directions in comment #1, plus, you were the one that didn't want me to commit this even though I said I wouldn't be adding it to profiles.desc.

Please just follow the instructions in comment #1, it's easier, safer, and saner than committing to an overlay and bind mounting part of the overlay
Comment 6 Anthony Basile gentoo-dev 2013-11-23 00:31:50 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #5)
> (In reply to Anthony Basile from comment #4)
> 
> It seems pretty easy to follow my directions in comment #1, plus, you were
> the one that didn't want me to commit this even though I said I wouldn't be
> adding it to profiles.desc.
> 
> Please just follow the instructions in comment #1, it's easier, safer, and
> saner than committing to an overlay and bind mounting part of the overlay

The profile branch of the overlay is precisely for this testing.  We have used it this way in the past.  I asked you to do it so there would be no ambiguity about what you are proposing.
Comment 7 Anthony Basile gentoo-dev 2013-11-23 13:10:42 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #0)
> The profile was very simple, containing only a parent file which
> looked like this:
> 
> ..
> ../../../../targets/desktop
> 
> 
> I propose we re-add the desktop profile and simply switch the order so that
> desktop is pulled in first, then hardened. 
> 

If you change $PORTDIR/profiles/hardened/linux/amd64/desktop/parent to

../../../../targets/desktop
..

then you get the targets/desktop stacking before base which is even worse.  Zorry basically said that in comment #1:  "if we pot it before the base... all that stuff will overrite the desktop settings. If it is after hardened it will overrite all the hardened on."

/usr/portage/profiles/targets/desktop
/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/eapi-5-files
/usr/portage/profiles/releases/13.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64
/usr/portage/profiles/hardened/linux/amd64/desktop

You example of using /etc/portage is not equivalent because of the high priority given to /etc/portage/*.  The later stack with respect to the former as follows:

$PORTDIR/profiles/base
.... (others)
$PORTDIR/profiles/hardened/linux/amd64
/etc/profiles

If this is not what you are suggesting then at least a patch against the current profile tree so we can see clearly what you are proposing.
Comment 8 Rick Farina (Zero_Chaos) gentoo-dev 2013-11-23 16:33:48 UTC
(In reply to Anthony Basile from comment #7)
> You example of using /etc/portage is not equivalent because of the high
> priority given to /etc/portage/*.  The later stack with respect to the
> former as follows:
Portage doesn't give higher priority to a profile set this way, it's identical to the normal way because you use a symlink and that means the profile *IS* set in /etc/portage just the same

> If this is not what you are suggesting then at least a patch against the
> current profile tree so we can see clearly what you are proposing.

As noted in comment #1, I'm suggesting that a simple flipping of the order will take a large burden off of us and allow a nearly 100% functional desktop profile.  If there is a specific technical issue with this, rather than "but but, that one is called base!" then I'm happy to listen to it, but that would probably require actually testing my idea so we can find the technical issues.
Comment 9 Anthony Basile gentoo-dev 2013-11-24 17:11:56 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #8)
> (In reply to Anthony Basile from comment #7)
> > You example of using /etc/portage is not equivalent because of the high
> > priority given to /etc/portage/*.  The later stack with respect to the
> > former as follows:
> Portage doesn't give higher priority to a profile set this way, it's
> identical to the normal way because you use a symlink and that means the
> profile *IS* set in /etc/portage just the same
> 
> > If this is not what you are suggesting then at least a patch against the
> > current profile tree so we can see clearly what you are proposing.
> 
> As noted in comment #1, I'm suggesting that a simple flipping of the order
> will take a large burden off of us and allow a nearly 100% functional
> desktop profile.  If there is a specific technical issue with this, rather
> than "but but, that one is called base!" then I'm happy to listen to it, but
> that would probably require actually testing my idea so we can find the
> technical issues.

Okay here's an example of what the problem is and how to reproduce:

0) Start with

    stage3-amd64-hardened-20131024.tar.bz2

and 

    stage3-amd64-20131031.tar.bz2

We will be comparing two profiles:

    default/linux/amd64/13.0/desktop  # which currently exists

    hardened/linux/amd64/desktop      # which is proposed


1) Change $PORTDIR/profiles/hardened/linux/amd64/desktop to read

    ../../../../targets/desktop
    ..

and remove the deprecated notice.


2) In both stage3-amd64-hardened and stage3-amd64 do the following emerge:

    emerge -vp dev-libs/libxml2

In both environments, you will get 

   [ebuild   R    ] dev-libs/libxml2-2.9.1-r1:2  USE="ipv6 python* ...

In otherwords, re-emerge libxml2 with the profile's default = python enabled.

At this point we conclude "great!" no technical problem.


3) At some future point, some dev with all the best intentions in the world, but unaware of our hacky profiles, adds the following line to $PORTDIR/profiles/default/linux/package.use:

    #Python support causes problems on xyz
    #Don't pull it in if we don't neeed it
    dev-libs/libxml2  -python

4) Repeat step 2.  Now for the default/linux/amd64/13.0/desktop profile we get

    dev-libs/libxml2-2.9.1-r1:2  USE="ipv6 python* ...

but for the hardened/linux/amd64/desktop we get

    dev-libs/libxml2-2.9.1-r1:2  USE="ipv6 readline ... -python ...

5) Since libxml2 is used in some 111 packages we have serious breakage.  Devs go around yelling "why'd you break my stuff!" etc etc.

For quality assurance, we must not only make sure the profiles are working now, but under the dynamical environment where others are modifying other areas of the profiles.  For this reason, we should stick to the canonical order defined by default/linux/amd64/13.0, namely:

/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/default/linux/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/eapi-5-files
/usr/portage/profiles/releases/13.0
/usr/portage/profiles/default/linux/amd64/13.0
/usr/portage/profiles/targets/desktop
/usr/portage/profiles/default/linux/amd64/13.0/desktop


I am currently working on another solution that addresses all of the above issues in a hopefully satisfactory way.
Comment 10 Rick Farina (Zero_Chaos) gentoo-dev 2013-11-25 01:51:46 UTC
(In reply to Anthony Basile from comment #9)
> Okay here's an example of what the problem is and how to reproduce:
> 
Love it

> 0) Start with
> 
>     stage3-amd64-hardened-20131024.tar.bz2
> 
> and 
> 
>     stage3-amd64-20131031.tar.bz2
> 
> We will be comparing two profiles:
> 
>     default/linux/amd64/13.0/desktop  # which currently exists
> 
>     hardened/linux/amd64/desktop      # which is proposed
> 
> 
> 1) Change $PORTDIR/profiles/hardened/linux/amd64/desktop to read
> 
>     ../../../../targets/desktop
>     ..
> 
> and remove the deprecated notice.
> 
> 
> 2) In both stage3-amd64-hardened and stage3-amd64 do the following emerge:
> 
>     emerge -vp dev-libs/libxml2
> 
> In both environments, you will get 
> 
>    [ebuild   R    ] dev-libs/libxml2-2.9.1-r1:2  USE="ipv6 python* ...
> 
> In otherwords, re-emerge libxml2 with the profile's default = python enabled.
> 
> At this point we conclude "great!" no technical problem.
> 
> 
Love it

> 3) At some future point, some dev with all the best intentions in the world,
> but unaware of our hacky profiles, adds the following line to
> $PORTDIR/profiles/default/linux/package.use:
> 
>     #Python support causes problems on xyz
>     #Don't pull it in if we don't neeed it
>     dev-libs/libxml2  -python
> 
> 4) Repeat step 2.  Now for the default/linux/amd64/13.0/desktop profile we
> get
> 
>     dev-libs/libxml2-2.9.1-r1:2  USE="ipv6 python* ...
> 
> but for the hardened/linux/amd64/desktop we get
> 
>     dev-libs/libxml2-2.9.1-r1:2  USE="ipv6 readline ... -python ...
> 
You are mistaken.  Per Zorry in comment #1 the current hardened stacking order is this:

/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/eapi-5-files
/usr/portage/profiles/releases/13.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64

I propose adding /usr/portage/profiles/target/desktop to the TOP of that stack, nothing else changes in any way.

This means if someone changes $PORTDIR/profiles/default/linux/package.use as you suggest that is pulled in on the (now) third line of the new profile and NOTHING is broken.

Now, maybe instead of making up scenarios that prove my point, how about testing my idea so that instead of me explaining over and over you can see with your own eyes.

I'm trying to be polite here, but I'm getting really dissatisfied with people making up non-sense as an excuse to not test.  Your mis-explained "issue" with my profile only seems to prove that you should be practically testing rather than theoretically guessing.  PLEASE TEST, PLEASE, PLEASE.  I cannot be more polite.
Comment 11 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2013-11-25 02:26:11 UTC
well, seemed to workforme at least
Comment 12 Anthony Basile gentoo-dev 2013-11-25 12:53:25 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #10)

> testing rather than theoretically guessing.  PLEASE TEST, PLEASE, PLEASE.  I
> cannot be more polite.

I did.  The above was obtained from the test.
Comment 13 Rick Farina (Zero_Chaos) gentoo-dev 2013-11-25 13:53:08 UTC
(In reply to Anthony Basile from comment #12)
> (In reply to Rick Farina (Zero_Chaos) from comment #10)
> 
> > testing rather than theoretically guessing.  PLEASE TEST, PLEASE, PLEASE.  I
> > cannot be more polite.
> 
> I did.  The above was obtained from the test.

Given the stacking order shown above for my profile, that's not possible.

With a stacking order of:

/usr/portage/profile/target/desktop
/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/eapi-5-files
/usr/portage/profiles/releases/13.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64

any change in /usr/portage/profiles/default linux will affect both profiles in an identical way.  it is NOT POSSIBLE for a change to affect hardened differently than hardened desktop, it's only possible we may lose something from target/desktop which is significantly non-critical.

So, did you test the profile with my method or some other crazy method which I rejected?
Comment 14 Devan Franchini (RETIRED) gentoo-dev 2013-11-25 16:52:49 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #13)
> (In reply to Anthony Basile from comment #12)
> > (In reply to Rick Farina (Zero_Chaos) from comment #10)
> > 
> > > testing rather than theoretically guessing.  PLEASE TEST, PLEASE, PLEASE.  I
> > > cannot be more polite.
> > 
> > I did.  The above was obtained from the test.
> 
> Given the stacking order shown above for my profile, that's not possible.
> 
> With a stacking order of:
> 
> /usr/portage/profile/target/desktop
> /usr/portage/profiles/base
> /usr/portage/profiles/default/linux
> /usr/portage/profiles/arch/base
> /usr/portage/profiles/features/multilib
> /usr/portage/profiles/features/multilib/lib32
> /usr/portage/profiles/arch/amd64
> /usr/portage/profiles/releases
> /usr/portage/profiles/eapi-5-files
> /usr/portage/profiles/releases/13.0
> /usr/portage/profiles/hardened/linux
> /usr/portage/profiles/hardened/linux/amd64
> 
> any change in /usr/portage/profiles/default linux will affect both profiles
> in an identical way.  it is NOT POSSIBLE for a change to affect hardened
> differently than hardened desktop, it's only possible we may lose something
> from target/desktop which is significantly non-critical.
> 
> So, did you test the profile with my method or some other crazy method which
> I rejected?

I was with blueness today and we tested this out, I can confirm that with the method in comment #7 this does cause issues. It would be appreciated if some patch or directions to follow that could bring all of us to the same page was submitted because the procedure in comment #1 is ambiguous.
Comment 15 Rick Farina (Zero_Chaos) gentoo-dev 2013-11-25 22:20:22 UTC
(In reply to Devan Franchini from comment #14)
> I was with blueness today and we tested this out, I can confirm that with
> the method in comment #7 this does cause issues. It would be appreciated if
> some patch or directions to follow that could bring all of us to the same
> page was submitted because the procedure in comment #1 is ambiguous.

That is what comment #0 is... I included the full procedure for testing. Comment #7 incorrectly makes the statement that somehow having a directory for /etc/portage/make.profile is higher priority than having the original symlink there, which I suppose was the motivating factor for whatever hackory you all are doing.

To makes things easier, I dropped bdcac9b8115fa9ccd203052709b713c291817993 into the hardened-dev overlay.  Please SYMLINK the profile you want, just like you would use any other profile.

for instance:

ln -s /var/lib/layman/hardened-dev/profile/hardened/linux/amd64/desktop /etc/portage/make.profile
Comment 16 Rick Farina (Zero_Chaos) gentoo-dev 2013-11-25 22:21:02 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #15)

> To makes things easier, I dropped bdcac9b8115fa9ccd203052709b713c291817993
> into the hardened-dev overlay.  Please SYMLINK the profile you want, just
> like you would use any other profile.


Forgot to mention, I added amd64, x86, and armv7a
Comment 17 Anthony Basile gentoo-dev 2013-11-26 00:00:29 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #15)
> (In reply to Devan Franchini from comment #14)
> > I was with blueness today and we tested this out, I can confirm that with
> > the method in comment #7 this does cause issues. It would be appreciated if
> > some patch or directions to follow that could bring all of us to the same
> > page was submitted because the procedure in comment #1 is ambiguous.
> 
> That is what comment #0 is... I included the full procedure for testing.
> Comment #7 incorrectly makes the statement that somehow having a directory
> for /etc/portage/make.profile is higher priority than having the original
> symlink there, which I suppose was the motivating factor for whatever
> hackory you all are doing.
> 
> To makes things easier, I dropped bdcac9b8115fa9ccd203052709b713c291817993
> into the hardened-dev overlay.  Please SYMLINK the profile you want, just
> like you would use any other profile.
> 
> for instance:
> 
> ln -s /var/lib/layman/hardened-dev/profile/hardened/linux/amd64/desktop
> /etc/portage/make.profile

Thanks for putting this up.  It leads to the same breakage as in comment 9.  Let me show you how to reproduce:

1) Do as instructed above.  I used a fresh chroot and emerge layman first.  You should find that `emerge -vp dev-libs/libxml2` gives:

    [ebuild   R    ] dev-libs/libxml2-2.9.1-r1:2  USE="ipv6 python* ...


2) Add the following line

    dev-libs/libxml2  -python

to

    /usr/portage/profiles/default/linux/package.use

and run emerge -vp dev-libs/libxml2.  This time you get:

    [ebuild   R    ] dev-libs/libxml2-2.9.1-r1:2  USE="ipv6 readline  ... -python ...


3) To verify the profile stacking, run the following python script:

    #!/usr/bin/env python
    import portage
    for p in portage.settings.profiles:
	print("%s" % p)

You should get the following stacking order:

/usr/portage/profiles/targets/desktop
/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/eapi-5-files
/usr/portage/profiles/releases/13.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64
/var/lib/layman/hardened-development/profiles/hardened/linux/amd64/desktop
Comment 18 Devan Franchini (RETIRED) gentoo-dev 2013-11-27 21:31:16 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #15)
> (In reply to Devan Franchini from comment #14)
> > I was with blueness today and we tested this out, I can confirm that with
> > the method in comment #7 this does cause issues. It would be appreciated if
> > some patch or directions to follow that could bring all of us to the same
> > page was submitted because the procedure in comment #1 is ambiguous.
> 
> That is what comment #0 is... I included the full procedure for testing.
> Comment #7 incorrectly makes the statement that somehow having a directory
> for /etc/portage/make.profile is higher priority than having the original
> symlink there, which I suppose was the motivating factor for whatever
> hackory you all are doing.
> 
> To makes things easier, I dropped bdcac9b8115fa9ccd203052709b713c291817993
> into the hardened-dev overlay.  Please SYMLINK the profile you want, just
> like you would use any other profile.
> 
> for instance:
> 
> ln -s /var/lib/layman/hardened-dev/profile/hardened/linux/amd64/desktop
> /etc/portage/make.profile

I can verify that while using the method stated above I still run into the issue that we faced previously on a pristine hardened chroot:

http://bpaste.net/show/153595/
Comment 19 Anthony Basile gentoo-dev 2013-11-28 13:34:39 UTC
(In reply to Devan Franchini from comment #18)
> 
> http://bpaste.net/show/153595/

bpastes are eventually removed and we want the bug reports to persist.  Here's the paste for the records:

After symlinking the desktop profile:

ls -alh /etc/portage/:
total 32K
drwxr-xr-x  5 root root 4.0K Nov 27 21:12 .
drwxr-xr-x 29 root root 4.0K Nov 27 21:10 ..
drwxr-xr-x  2 root root 4.0K Oct 24 14:17 bin
-rw-r--r--  1 root root  630 Oct 24 16:19 make.conf
-rw-r--r--  1 root root  630 Oct 24 14:07 make.conf.catalyst
lrwxrwxrwx  1 root root   74 Nov 27 21:12 make.profile -> /var/lib/layman/hardened-development/profiles/hardened/linux/amd64/desktop
drwxr-xr-x  2 root root 4.0K Oct 24 14:17 postsync.d
drwxr-xr-x  3 root root 4.0K Oct 24 16:16 savedconfig

emerge -vp dev-libs/libxml2

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] dev-libs/libxml2-2.9.1-r1:2  USE="ipv6 python* readline -debug -examples -icu -lzma -static-libs {-test}" PYTHON_TARGETS="python2_7 python3_2 -python2_6 (-python3_3)" 5,052 kB

Total: 1 package (1 reinstall), Size of downloads: 5,052 kB

After editing /usr/portage/profiles/default/linux/package.use:

emerge -vp dev-libs/libxml2:

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] dev-libs/libxml2-2.9.1-r1:2  USE="ipv6 readline -debug -examples -icu -lzma -python -static-libs {-test}" PYTHON_TARGETS="python2_7 python3_2 -python2_6 (-python3_3)" 5,052 kB

Profile stack:
 
/usr/portage/profiles/targets/desktop
/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/eapi-5-files
/usr/portage/profiles/releases/13.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64
/var/lib/layman/hardened-development/profiles/hardened/linux/amd64/desktop
Comment 20 Anthony Basile gentoo-dev 2013-12-11 14:18:41 UTC
Okay, given the above issues, I'm going to propose that we maintain our own desktop profile at

    profiles/hardened/targets/desktop

and inherit profiles/hardened/linux/<arch>/desktop from it.  I have an example commit at

http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=commit;h=155e204497757a78f06367d7ebe99da92e786ffa

While this has the disadvantage of duplicating effort with profiles/targets, it does put hardened in control of the final use flags that the end users get.

Aside: if there are no objections, I'm going to clean out the ancient deprecated /developer and /server profiles.
Comment 21 Anthony Basile gentoo-dev 2013-12-20 14:39:00 UTC
(In reply to Anthony Basile from comment #20)
> Aside: if there are no objections, I'm going to clean out the ancient
> deprecated /developer and /server profiles.

As discussed in IRC during the hardened meeting yesterday, all /desktop /developer and /server profiles have been removed under profiles/hardened/linux.
Comment 22 Jason Zaman gentoo-dev 2015-06-04 14:50:15 UTC
*** Bug 551226 has been marked as a duplicate of this bug. ***
Comment 23 Magnus Granberg gentoo-dev 2017-10-03 11:15:33 UTC
If we move the hardened profile to features/hardened
Then we can have it last in the parent files.
In the default/amd64/hardened/parent
we have 
..
../../features/hardened/amd64/

Make the 17.0 profile like this?
Comment 24 Magnus Granberg gentoo-dev 2017-12-07 03:02:33 UTC
What desktop profiles do we need in the 17.0 profile for hardened?

parent:
..
../..XXX../features/hardened/archX

make.default may need some USE flags changes.

is what need to be added in a subprofile.