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.
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.
(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
(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.
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.
(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
(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.
(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.
(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.
(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.
(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.
well, seemed to workforme at least
(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.
(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?
(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.
(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
(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
(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
(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/
(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
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.
(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.
*** Bug 551226 has been marked as a duplicate of this bug. ***
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?
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.
