Summary: | dev-lang/python: Investigate and test pax markings | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mike Gilbert <floppym> |
Component: | [OLD] Unspecified | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | arfrever.fta, h.v.bruinehsen, nikoli, pageexec, spender |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 413671 | ||
Bug Blocks: |
Description
Mike Gilbert
2012-04-27 16:14:20 UTC
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? |