| Summary: | >=media-libs/x264-0.0.20081006: position independant code support has been dropped upstream | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alexis Ballier <aballier> |
| Component: | Current packages | Assignee: | Gentoo Media-video project <media-video> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | minor | CC: | atoth, dan, hardened, pageexec, phajdan.jr, shentino |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Alexis Ballier
2008-10-07 06:08:36 UTC
jeez, what kind of idiots are writing x264? it's not at all about the amount of wasted memory due to COW, it's about the security impact. and it's not specific to PaX, SELinux users will also cry bloody murder as well as they'll have to adjust the policies too to allow textrels. someone please hit these devs with a clue stick, this is 2008 and you don't intentionally put textrels into anything, especially not revert already working code! Alexis, can you please put the reverted patch into portage and i'll take care of any new changes. (In reply to comment #1) > Alexis, can you please put the reverted patch into portage and i'll take care > of any new changes. Please contact Loren directly; he said PIC code will be broken at some point and I'm not skilled enough to do the work (and esp. since I consider x86 and its too few registers, making pic code slow and its 20 years old design is a dying arch). See: http://mailman.videolan.org/pipermail/x264-devel/2008-August/004838.html maybe you could convince him to do c) for him and git would make it easy. I have just became aware of the intentional TEXTRELs in this library. Here's a snippet of the changes just to provide a clue on their essential beliefs: -; - picgetgot computes the GOT address into the given register in PIC -; mode, otherwise does nothing. You need to do this before using GLOBAL. -; Before in both execution order and compiled code order (so GLOBAL knows -; which register the GOT is in). +; x86_32 doesn't require PIC. +; Some distros prefer shared objects to be PIC, but nothing breaks if +; the code contains a few textrels, so we'll skip that complexity. Unfortunately I'm in lack of time and skill for maintaining a TEXTREL free version of the library. I think only the Spanish inquisition could remedy this issue. If a group of adventurers would decide to start a quest on evangelizing the developers, they can count on a mountain dwarf warrior priest to join their party. However I still hope, that this disease won't infect vlc, since x264 is a project running alongside with the well-known media player. Regards, Dw. x86 does not have time to maintain that either...so maybe we should force upstream to change it somehow- The ebuild has now,
# if use x86 && use pic; then
# myconf="${myconf} --disable-asm"
# fi
I know it will be slow but better than having nothing, at least those hardened users with fast machine could use it. It's commented, as you can see... up to hardened to make use of it.
I just emerged x264 and got hit with a QA notice for TEXTREL: Offending package: media-libs/x264-0.0.20090908 *** Bug 301013 has been marked as a duplicate of this bug. *** media-libs/x264-0.0.20100605 - 08/31/2010 installed with USE flag pic ...no reported TEXTRELS system is ~amd64 with "CFLAGS="-march=native -O2 -pipe" seems everything is fine now, the pic asm should be worked with upstream if ever. *** Bug 357159 has been marked as a duplicate of this bug. *** |