I guess this is already known, but just for completeness: QA Notice: the following files contain insecure RUNPATH's /var/tmp/portage/cm3-5.2.7_pre050331/work/m3-sys/m3quake/LINUXLIBC6:/var/tmp/portage/cm3-5.2.7_pre050331/work/m3-sys/m3middle/LINUXLIBC6:/var/tmp/portage/cm3-5.2.7_pre050331/work/m3-libs/libm3/LINUXLIBC6:/var/tmp/portage/cm3-5.2.7_pre050331/work/m3-libs/m3core/LINUXLIBC6:/usr/lib/cm3//lib usr/lib/cm3/pkg/m3cgcat/LINUXLIBC6/m3cgcat QA Notice: the following files contain runtime text relocations [long list] QA Notice: the following files contain executable stacks [long list] !!! ERROR: dev-lang/cm3-5.2.7_pre050331 failed.
cm3 is based upon gcc-3.2.x but it should be easy to fix the exec stacks
No clue, as usual.
Created attachment 77023 [details, diff] cm3-5.2.6-RUNPATH.patch Fixing RUNPATH, by building the offensive program static
Created attachment 77025 [details, diff] cm3-5.2.6.ebuild.patch change to the ebuild. hmm ... I applied those to 5.2.6 :/ Bug is related to 5.2.7 5.2.6 build and merge correctly. cm3 is not usable as produce the problem described by Bug 116028 I hope that solution works for 5.2.7
Created attachment 77027 [details, diff] cm3-5.2.7_pre050331.ebuild cm3-5.2.7 works :) with the same patch. Just rename the patch to cm3-5.2.7_pre050331-RUNPATH.patch
linking static is not the right solution.
(In reply to comment #6) > linking static is not the right solution. > I wonder why ... Any piece of cm3 suite is built standalone :/
(In reply to comment #7) > (In reply to comment #6) > > linking static is not the right solution. > > > > I wonder why ... > > Any piece of cm3 suite is built standalone :/ > linking static has sometimes some advantages but often disadvantages. Think what happens if there is some obscure vuln in glibc. You now have a copy of that vuln libc.a when the cm3 was built linked into the executable forever and no easy way to detect that it linked in the old libc. Linking static also makes larger in size and memory hungy apps. Often the simple way to fix the rpath problems is to replace the code in makefile's where you see -Wl,-R,"/path" with a simple -L "/path" That allows it to link and have no unresolved symbols, without having the hardcoded rpath value during normal runtime. If the -L does not work due to it needing that path so it can run itself after building itself and needs to find those libs which it linked to (which is not cross compile friendly) then we can sometimes export LD_RUNPATH=/path
I know what linking static imply. But if you look at all the binary that cm3 provide, they were are all static, except the one that I changed, and the compiler. Anyway, the compiler is the only piece that you can see where is linked. All the other piece are built with the "make" like cm3 system. There is no -L or rpath specification there. It is all elaborated automatically, with the same tools that cm3 provide. So, unless you fix this tools, so you can build in a different place that the one they are to be shipped, there is nothing you can do. Unless you build static. IMHO
vapier: your opinion as maintainer ?
Well, I suppose another solution is viable: writing a tool that strip from the runpath string of the exe or shared libs, the "/var/tmp/portage/xxx/image/" thing. And calling this for any exe/shared lib encountered during the merge phase, or manually driven inside the ebuild. I'm not able to do this now :(
The tool exists and is called chrpath... but that means pulling it as a build-time dep. Why not, I guess maintainer has now two choices :)
The next ~arch portage revision will auto repair evil rpaths and not bail. Maintainers should still fix the packages they maintain as portage will only die with FEATURES=stricter (but that is a maintainer & QA problem) no longer security@ http://bugs.gentoo.org/show_bug.cgi?id=124962
No longer a security issue with current stable portage, re-assigning to maintainer
cm3 no longer in portage
