[gentoo-hardened] Help testing full end-to-end xattr support in portage

[gentoo-hardened] Help testing full end-to-end xattr support in portage

[Anthony G. Basile]

Hi Everyone,

It has take a long time to finalize XATTR_PAX support in Gentoo, but I 
think the final step is done.  The thorniest problem was getting portage 
wrappers to `/usr/bin/install` to preserve extended attributes.  We 
could have hacked up ebuilds to do the markings after install, but in 
some cases this meant having to do double markings in ebuilds and left a 
gap in our end-to-end support for other packages needing xattrs not 
necessarily related to PaX.  I took the harder but "correct" path and 
wrote a wrapper.  My first wrapper was written in python and worked 
great except it was slooooow --- actually I had one in bash which used 
associated arrays but that requires bash4 and portage only supports 
bash3!  I rewrote the wrapper in C and it worked great when I by-passed 
the portage install machinary and used it directly, but the point was to 
get it working in portage!  I finally traced the bug down to how the 
environment $PATH changes during the ebuild phases and added 
intelligence to the C wrapper.

Anyhow, I'd like victims ... err ... I mean testers:

1) Have USE=xattr and PAX_MARKINGS="XT" in you make.conf file

2) Your kernel should have CONFIG_PAX_XATTR_PAX_FLAGS=y.  If you are 
brave have CONFIG_PAX_PT_PAX_FLAGS not set.

3) emerge =sys-apps/install-xattr-0.2, sys-apps/elfix.  If you can 
emerge elfix with USE="ptpax xtpax" but if you are brave try USE="-ptpax 
xtpax".  You must have at least xtpax in there.

4) You need to apply the following patch to portage:

https://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9089c2d755b0ecb1b340fc23dda461163f589c43

You can just manually apply it after `cd /usr/lib/portage/`

5) Then emerge any package needing pax markings (maybe not python just 
in case something breaks).   Like johntheripper which should give

~ # paxctl-ng -v /usr/sbin/john
/usr/sbin/john:
	PT_PAX    : -emr-
	XATTR_PAX : -emr-

or just

/usr/sbin/john:
	XATTR_PAX : -emr-

If you removed all PT_PAX above.

Let me know if you hit issues.  The final step will be to just make sure 
our releases have XATTR_PAX markings and that we document how to 
properly installed them so you don't loose the markings.


Finally, some may wonder, why XATTR_PAX markings?  The main reason is 
that it doesn't touch the ELF binaries and makes them more consistent 
with what other distros ship.  Also, marking can be done while the ELF 
is busy (eg  `paxctl -m /bin/bash`, leads to "Text file busy" but you 
can always do `paxctl-ng -lm /bin/bash`, ie set only XATTR_PAX).  This 
allows you to work with a live system which is useful if you ever need 
to do a revdep-pax to migrate pax flags from a library to the 
executables that link against it.  The disadvantage is that xattr 
support requires more work and so are more fragile.


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Alex Efros]

Hi!

If fails on my package dev-inferno/inferno (take it from "powerman"
overlay or just view here
https://code.google.com/p/powerman-overlay/source/browse/dev-inferno/inferno/inferno-20140617.ebuild

Here is emerge output:

cc -m32  -o o.out styxtest.o /var/tmp/portage/dev-inferno/inferno-20140617/work/inferno/Linux/386/lib/libstyx.a /var/tmp/portage/dev-inferno/inferno-20140617/work/inferno/Linux/386/lib/lib9.a 
rm -f /var/tmp/portage/dev-inferno/inferno-20140617/work/inferno/Linux/386/bin/styxtest && cp o.out /var/tmp/portage/dev-inferno/inferno-20140617/work/inferno/Linux/386/bin/styxtest
 * XT PaX marking -pems with paxctl-ng
 *      Linux/386/bin/emu
 *      Linux/386/bin/emu-g
>>> Source compiled.
>>> Test phase [not enabled]: dev-inferno/inferno-20140617

>>> Install inferno-20140617 into /var/tmp/portage/dev-inferno/inferno-20140617/image/ category dev-inferno
install-xattr: setxattr() failed: No such file or directory
!!! doins: Linux/386/bin/emu-g does not exist
install-xattr: setxattr() failed: No such file or directory
!!! doins: Linux/386/bin/emu does not exist
 * ERROR: dev-inferno/inferno-20140617::powerman failed (install phase):
 *   doins failed

P.S. This package (OS Inferno) contains about 22000 files, and since
switching to PAX_XATTR it took few minutes to compile and then about a
hour or two to install because of that python-install-wrapper.
So, please Please PLEASE release C wrapper ASAP! :)

-- 
			WBR, Alex.

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Anthony G. Basile]

Thanks Alex, perfinion hit this bug and fixed it.  Can you test with 
install-xattr-9999.  I don't want to push out a minor bump just for one 
patch until we get more testing done.

On 06/24/14 13:25, Alex Efros wrote:
> Hi!
>
> If fails on my package dev-inferno/inferno (take it from "powerman"
> overlay or just view here
> https://code.google.com/p/powerman-overlay/source/browse/dev-inferno/inferno/inferno-20140617.ebuild
>
> Here is emerge output:
>
> cc -m32  -o o.out styxtest.o /var/tmp/portage/dev-inferno/inferno-20140617/work/inferno/Linux/386/lib/libstyx.a /var/tmp/portage/dev-inferno/inferno-20140617/work/inferno/Linux/386/lib/lib9.a
> rm -f /var/tmp/portage/dev-inferno/inferno-20140617/work/inferno/Linux/386/bin/styxtest && cp o.out /var/tmp/portage/dev-inferno/inferno-20140617/work/inferno/Linux/386/bin/styxtest
>   * XT PaX marking -pems with paxctl-ng
>   *      Linux/386/bin/emu
>   *      Linux/386/bin/emu-g
>>>> Source compiled.
>>>> Test phase [not enabled]: dev-inferno/inferno-20140617
>
>>>> Install inferno-20140617 into /var/tmp/portage/dev-inferno/inferno-20140617/image/ category dev-inferno
> install-xattr: setxattr() failed: No such file or directory
> !!! doins: Linux/386/bin/emu-g does not exist
> install-xattr: setxattr() failed: No such file or directory
> !!! doins: Linux/386/bin/emu does not exist
>   * ERROR: dev-inferno/inferno-20140617::powerman failed (install phase):
>   *   doins failed
>
> P.S. This package (OS Inferno) contains about 22000 files, and since
> switching to PAX_XATTR it took few minutes to compile and then about a
> hour or two to install because of that python-install-wrapper.
> So, please Please PLEASE release C wrapper ASAP! :)
>


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Alex Efros]

Hi!

On Thu, Jun 26, 2014 at 08:57:12AM -0400, Anthony G. Basile wrote:
> Thanks Alex, perfinion hit this bug and fixed it.  Can you test with 
> install-xattr-9999.  I don't want to push out a minor bump just for one 
> patch until we get more testing done.

I've re-emerged all packages which use paxmarking on my system, including
pythons and inferno - everything is fine now.


-- 
			WBR, Alex.

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

["Tóth Attila"]

I've applied the patch. I have USE=xattr enabled, the kernel has both
CONFIG_PAX_XATTR_PAX_FLAGS=y and CONFIG_PAX_PT_PAX_FLAGS=y set, and elfix
was emerged with USE="ptpax xtpax" combo (since I'm not brave enough). The
only exception from the instructions is that I have PAX_MARKINGS="PT XT"
specified in make.conf.

Taken this difference, I've emerged some packages. The install process is
faster - although I wouldn't say it's lightning fast. All binaries had
their PT fields set and XT fields missing. I can only blame the
PAX_MARKINGS variable. I believe that the install mechanism should take
care both PT and XT flags if both were specified in PAX_MARKINGS
environmental variable. I'm not sure if you agree with me about this.

I can repeat the test it with PAX_MARKINGS="XT" only.

Thank you for your efforts: Dw.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2014.Június 24.(K) 15:53 időpontban Anthony G. Basile ezt írta:
> Hi Everyone,
>
> It has take a long time to finalize XATTR_PAX support in Gentoo, but I
> think the final step is done.  The thorniest problem was getting portage
> wrappers to `/usr/bin/install` to preserve extended attributes.  We
> could have hacked up ebuilds to do the markings after install, but in
> some cases this meant having to do double markings in ebuilds and left a
> gap in our end-to-end support for other packages needing xattrs not
> necessarily related to PaX.  I took the harder but "correct" path and
> wrote a wrapper.  My first wrapper was written in python and worked
> great except it was slooooow --- actually I had one in bash which used
> associated arrays but that requires bash4 and portage only supports
> bash3!  I rewrote the wrapper in C and it worked great when I by-passed
> the portage install machinary and used it directly, but the point was to
> get it working in portage!  I finally traced the bug down to how the
> environment $PATH changes during the ebuild phases and added
> intelligence to the C wrapper.
>
> Anyhow, I'd like victims ... err ... I mean testers:
>
> 1) Have USE=xattr and PAX_MARKINGS="XT" in you make.conf file
>
> 2) Your kernel should have CONFIG_PAX_XATTR_PAX_FLAGS=y.  If you are
> brave have CONFIG_PAX_PT_PAX_FLAGS not set.
>
> 3) emerge =sys-apps/install-xattr-0.2, sys-apps/elfix.  If you can
> emerge elfix with USE="ptpax xtpax" but if you are brave try USE="-ptpax
> xtpax".  You must have at least xtpax in there.
>
> 4) You need to apply the following patch to portage:
>
> https://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9089c2d755b0ecb1b340fc23dda461163f589c43
>
> You can just manually apply it after `cd /usr/lib/portage/`
>
> 5) Then emerge any package needing pax markings (maybe not python just
> in case something breaks).   Like johntheripper which should give
>
> ~ # paxctl-ng -v /usr/sbin/john
> /usr/sbin/john:
> 	PT_PAX    : -emr-
> 	XATTR_PAX : -emr-
>
> or just
>
> /usr/sbin/john:
> 	XATTR_PAX : -emr-
>
> If you removed all PT_PAX above.
>
> Let me know if you hit issues.  The final step will be to just make sure
> our releases have XATTR_PAX markings and that we document how to
> properly installed them so you don't loose the markings.
>
>
> Finally, some may wonder, why XATTR_PAX markings?  The main reason is
> that it doesn't touch the ELF binaries and makes them more consistent
> with what other distros ship.  Also, marking can be done while the ELF
> is busy (eg  `paxctl -m /bin/bash`, leads to "Text file busy" but you
> can always do `paxctl-ng -lm /bin/bash`, ie set only XATTR_PAX).  This
> allows you to work with a live system which is useful if you ever need
> to do a revdep-pax to migrate pax flags from a library to the
> executables that link against it.  The disadvantage is that xattr
> support requires more work and so are more fragile.
>
>
> --
> Anthony G. Basile, Ph. D.
> Chair of Information Technology
> D'Youville College
> Buffalo, NY 14201
> (716) 829-8197
>

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Luis Ressel]

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

My kernel has been XT-only for ages now, so no change required here. I
installed install-xattr and applied the portage patch. So far I've
reemerged python:2.7 - it worked fine and the duration was much more
bearable than with the python-based install wrapper (down from 8
minutes to 4 minutes, but still worse than the ~2 minutes in the good
ol' days with vanilla install). I'll test more ebuilds in the next days.

PS: I wonder if sys-apps/paxctl could be removed from the @system set
now, as it's obsolete and superseded by elfix.


Regards,
Luis Ressel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Anthony G. Basile]

On 06/26/14 18:17, Luis Ressel wrote:
> My kernel has been XT-only for ages now, so no change required here. I
> installed install-xattr and applied the portage patch. So far I've
> reemerged python:2.7 - it worked fine and the duration was much more
> bearable than with the python-based install wrapper (down from 8
> minutes to 4 minutes, but still worse than the ~2 minutes in the good
> ol' days with vanilla install). I'll test more ebuilds in the next days.
>
> PS: I wonder if sys-apps/paxctl could be removed from the @system set
> now, as it's obsolete and superseded by elfix.
>
>
> Regards,
> Luis Ressel
>

There are two advantages to paxctl over paxctl-ng from elfix: 1) It 
doesn't depend on elfutils to do its manipulation of elf phdr's.  2) It 
does try to convert or create a PT_PAX_FLAGS phdr by either creating 
(-C) or converting (-c) a PT_GNU_STACK phdr.

The advantage of paxctl-ng over paxctl is 1) it is designed to do both 
PT_PAX and/or XATTR_PAX markings, 2) it is consciously designed to not 
try to create/convert ELF phdr's.

If we ever drop the PT_PAX_FLAGS patch from binutils then paxctl would 
no longer be needed and paxctl-ng can be reduced to just doing XATTR_PAX 
markings.

One step at a time ;)


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Luis Ressel]

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

On Sat, 28 Jun 2014 07:47:26 -0400
"Anthony G. Basile" <basile@opensource.dyc.edu> wrote:

> There are two advantages to paxctl over paxctl-ng from elfix: 1) It 
> doesn't depend on elfutils to do its manipulation of elf phdr's.  2)
> It does try to convert or create a PT_PAX_FLAGS phdr by either
> creating (-C) or converting (-c) a PT_GNU_STACK phdr.
> 
> The advantage of paxctl-ng over paxctl is 1) it is designed to do
> both PT_PAX and/or XATTR_PAX markings, 2) it is consciously designed
> to not try to create/convert ELF phdr's.
> 
> If we ever drop the PT_PAX_FLAGS patch from binutils then paxctl
> would no longer be needed and paxctl-ng can be reduced to just doing
> XATTR_PAX markings.
> 
> One step at a time ;)

Okay, that sounds reasonable. And as paxctl is a small program, it
doesn't hurt to have it around on XATTR_PAX-only systems even though
it's not needed.

But there's still an issue. According to [1], 15 packages still depend
on or invoke paxctl directly. One example is dev-lisp/sbcl, which needs
pax markings at one point right in the middle of the build process and
therefore can't use the pax eclass, at least not in a simple way. This
doesn't work on systems like mine which don't respect PT_PAX flags.

I'm currently working on a patch for sbcl (there are selinux-related
issues as well), but please have a look at the other ebuilds.

[1] $ echo /usr/portage/*/*/*.ebuild|xargs -n1000 grep -P 'paxctl(?!-ng)'|cut -d: -f1


Regards,
Luis Ressel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Anthony G. Basile]

On 07/02/14 09:41, Luis Ressel wrote:
> On Sat, 28 Jun 2014 07:47:26 -0400
> "Anthony G. Basile" <basile@opensource.dyc.edu> wrote:
>
>> There are two advantages to paxctl over paxctl-ng from elfix: 1) It
>> doesn't depend on elfutils to do its manipulation of elf phdr's.  2)
>> It does try to convert or create a PT_PAX_FLAGS phdr by either
>> creating (-C) or converting (-c) a PT_GNU_STACK phdr.
>>
>> The advantage of paxctl-ng over paxctl is 1) it is designed to do
>> both PT_PAX and/or XATTR_PAX markings, 2) it is consciously designed
>> to not try to create/convert ELF phdr's.
>>
>> If we ever drop the PT_PAX_FLAGS patch from binutils then paxctl
>> would no longer be needed and paxctl-ng can be reduced to just doing
>> XATTR_PAX markings.
>>
>> One step at a time ;)
>
> Okay, that sounds reasonable. And as paxctl is a small program, it
> doesn't hurt to have it around on XATTR_PAX-only systems even though
> it's not needed.
>
> But there's still an issue. According to [1], 15 packages still depend
> on or invoke paxctl directly. One example is dev-lisp/sbcl, which needs
> pax markings at one point right in the middle of the build process and
> therefore can't use the pax eclass, at least not in a simple way. This
> doesn't work on systems like mine which don't respect PT_PAX flags.
>
> I'm currently working on a patch for sbcl (there are selinux-related
> issues as well), but please have a look at the other ebuilds.
>
> [1] $ echo /usr/portage/*/*/*.ebuild|xargs -n1000 grep -P 'paxctl(?!-ng)'|cut -d: -f1
>
>
> Regards,
> Luis Ressel
>

Yep open a tracker bug for packages that invoke paxctl directly, and 
attach that to the main tracker bug, bug #427888.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Anthony G. Basile]

On 07/03/14 06:43, Anthony G. Basile wrote:
> On 07/02/14 09:41, Luis Ressel wrote:
>> On Sat, 28 Jun 2014 07:47:26 -0400
>> "Anthony G. Basile" <basile@opensource.dyc.edu> wrote:
>>
>>> There are two advantages to paxctl over paxctl-ng from elfix: 1) It
>>> doesn't depend on elfutils to do its manipulation of elf phdr's.  2)
>>> It does try to convert or create a PT_PAX_FLAGS phdr by either
>>> creating (-C) or converting (-c) a PT_GNU_STACK phdr.
>>>
>>> The advantage of paxctl-ng over paxctl is 1) it is designed to do
>>> both PT_PAX and/or XATTR_PAX markings, 2) it is consciously designed
>>> to not try to create/convert ELF phdr's.
>>>
>>> If we ever drop the PT_PAX_FLAGS patch from binutils then paxctl
>>> would no longer be needed and paxctl-ng can be reduced to just doing
>>> XATTR_PAX markings.
>>>
>>> One step at a time ;)
>>
>> Okay, that sounds reasonable. And as paxctl is a small program, it
>> doesn't hurt to have it around on XATTR_PAX-only systems even though
>> it's not needed.
>>
>> But there's still an issue. According to [1], 15 packages still depend
>> on or invoke paxctl directly. One example is dev-lisp/sbcl, which needs
>> pax markings at one point right in the middle of the build process and
>> therefore can't use the pax eclass, at least not in a simple way. This
>> doesn't work on systems like mine which don't respect PT_PAX flags.
>>
>> I'm currently working on a patch for sbcl (there are selinux-related
>> issues as well), but please have a look at the other ebuilds.
>>
>> [1] $ echo /usr/portage/*/*/*.ebuild|xargs -n1000 grep -P
>> 'paxctl(?!-ng)'|cut -d: -f1
>>
>>
>> Regards,
>> Luis Ressel
>>
>
> Yep open a tracker bug for packages that invoke paxctl directly, and
> attach that to the main tracker bug, bug #427888.
>

Actually I'll do it.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Anthony G. Basile]

On 07/03/14 06:48, Anthony G. Basile wrote:
> On 07/03/14 06:43, Anthony G. Basile wrote:
>> On 07/02/14 09:41, Luis Ressel wrote:
>>> On Sat, 28 Jun 2014 07:47:26 -0400
>>> "Anthony G. Basile" <basile@opensource.dyc.edu> wrote:
>>>
>>>> There are two advantages to paxctl over paxctl-ng from elfix: 1) It
>>>> doesn't depend on elfutils to do its manipulation of elf phdr's.  2)
>>>> It does try to convert or create a PT_PAX_FLAGS phdr by either
>>>> creating (-C) or converting (-c) a PT_GNU_STACK phdr.
>>>>
>>>> The advantage of paxctl-ng over paxctl is 1) it is designed to do
>>>> both PT_PAX and/or XATTR_PAX markings, 2) it is consciously designed
>>>> to not try to create/convert ELF phdr's.
>>>>
>>>> If we ever drop the PT_PAX_FLAGS patch from binutils then paxctl
>>>> would no longer be needed and paxctl-ng can be reduced to just doing
>>>> XATTR_PAX markings.
>>>>
>>>> One step at a time ;)
>>>
>>> Okay, that sounds reasonable. And as paxctl is a small program, it
>>> doesn't hurt to have it around on XATTR_PAX-only systems even though
>>> it's not needed.
>>>
>>> But there's still an issue. According to [1], 15 packages still depend
>>> on or invoke paxctl directly. One example is dev-lisp/sbcl, which needs
>>> pax markings at one point right in the middle of the build process and
>>> therefore can't use the pax eclass, at least not in a simple way. This
>>> doesn't work on systems like mine which don't respect PT_PAX flags.
>>>
>>> I'm currently working on a patch for sbcl (there are selinux-related
>>> issues as well), but please have a look at the other ebuilds.
>>>
>>> [1] $ echo /usr/portage/*/*/*.ebuild|xargs -n1000 grep -P
>>> 'paxctl(?!-ng)'|cut -d: -f1
>>>
>>>
>>> Regards,
>>> Luis Ressel
>>>
>>
>> Yep open a tracker bug for packages that invoke paxctl directly, and
>> attach that to the main tracker bug, bug #427888.
>>
>
> Actually I'll do it.
>

https://bugs.gentoo.org/show_bug.cgi?id=516158

Please open up bugs against individual packages and have them block 
against bug #516158



-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Luis Ressel]

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

On Thu, 03 Jul 2014 07:20:51 -0400
"Anthony G. Basile" <basile@opensource.dyc.edu> wrote:

> https://bugs.gentoo.org/show_bug.cgi?id=516158
> 
> Please open up bugs against individual packages and have them block 
> against bug #516158

Thanks for handling this! I'm atm working on getting dev-lisp/sbcl to
work (there are SELinux issues as well), I'll file the bug about
its paxctl usage in a short while.

It's been helpful that you mentioned paxmark.sh, I didn't know about
that script before.

I'll see if I can have a look at more of the potentially problematic
ebuilds.


Regards,
Luis Ressel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Luis Ressel]

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

I found another bug in dev-lisp/sbcl (#517008). sbcl does the pax-mark
in src_compile() because it's already needed during the compile process
itself. But the ebuild is also using sbcl's custom install.sh script
during src_install() -- and this script, while it naturally did
preserve ELF headers, doesn't preserve xattrs; therefore, a separate
pax-mark in src_install() is required.

I bet there are more bugs like this one in other packages.

Btw: Should such bugs block #427888?


Regards,
Luis Ressel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Alex Efros]

Hi!

On Thu, Jun 26, 2014 at 08:57:12AM -0400, Anthony G. Basile wrote:
> Thanks Alex, perfinion hit this bug and fixed it.  Can you test with 
> install-xattr-9999.  I don't want to push out a minor bump just for one 
> patch until we get more testing done.

Are you going to release this any time soon?

-- 
			WBR, Alex.

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Jason Zaman]

On Tue, Aug 05, 2014 at 05:48:23AM +0300, Alex Efros wrote:
> Hi!
> 
> On Thu, Jun 26, 2014 at 08:57:12AM -0400, Anthony G. Basile wrote:
> > Thanks Alex, perfinion hit this bug and fixed it.  Can you test with 
> > install-xattr-9999.  I don't want to push out a minor bump just for one 
> > patch until we get more testing done.
> 
> Are you going to release this any time soon?

install-xattr-0.3 has all the fixes in it and is stable on most arches
already. Portage 2.2.11 has the patch to use it too and is ~ still so
you do not need to patch anything manually anymore.

It has been working for me the last few days but please test :)

-- Jason

Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Alex Efros]

Hi!

On Wed, Aug 06, 2014 at 01:21:56PM +0400, Jason Zaman wrote:
> install-xattr-0.3 has all the fixes in it and is stable on most arches
> already. Portage 2.2.11 has the patch to use it too and is ~ still so
> you do not need to patch anything manually anymore.
> 
> It has been working for me the last few days but please test :)

Yeah, everything works after updating to ~amd64 portage-2.2.11-r1.

Thanks!

-- 
			WBR, Alex.