The python ebuilds I brought over from Progress overlay call pax-mark m python from src_compile. We should determine the purpose of this. They also depend on sys-apps/paxctl. I believe this dependency was added to workaround some bug in scanelf when it is used to mark shared libraries. See bug 413671. I am able to build python successfully without this dependency, so I believe it may be dropped.
Dependency on sys-apps/paxctl was workaround for bug #411919. This dependency was removed from master ebuilds before bug #413671 was filed. http://code.google.com/p/gentoo-progress/source/detail?r=2037 This dependency was removed due to discussion in #gentoo-hardened in 2012-04-22. pax-mark() is called to fix bug #329499. If a potential better solution in libffi/ctypes is implemented and accepted by upstreams, then pax-mark() won't be needed.
Thanks for the explanation.
(In reply to comment #1) > Dependency on sys-apps/paxctl was workaround for bug #411919. > > pax-mark() is called to fix bug #329499. If a potential better solution in > libffi/ctypes is implemented and accepted by upstreams, then pax-mark() > won't be needed. This is disappointing to say the least because it puts a huge hole in hardened's security. Can we relax this condition and not insist on getting patches accepted upstream first, but rather just apply them conditionally. Then the hardened user will just have to take the lumps for using wild and crazy patches.
I agree with blueness, if we cannot get patches upstream and we know the patches are fine for those of us using hardened, then at the very least let the patch (or sed) be conditionally applied. It might be nice to note that the Pax feature "MPROTECT_COMPAT" helps in this area as well.
(In reply to comment #4) Have you even sent the patch to libffi upstream?
