Bugzilla Bug 116027

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 an attachment (id=77023) [details]
cm3-5.2.6-RUNPATH.patch

Fixing RUNPATH, by building the offensive program static

Created an attachment (id=77025) [details]
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 an attachment (id=77027) [details]
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