Bugzilla Bug 90886

I emerged libiconv to be able to build glib2 on a uclibc-based install. Few
days later, I checked my system using a script I made and I got this output:

>Searching ELF binaries on the system. It will take a while.
>These binaries have RPATH set:
>/usr/bin/iconv
>  RPATH       /var/tmp/portage/libiconv-1.9.2/image//usr/lib

I also ran readelf on it
$ readelf -d /usr/bin/iconv | egrep 'RPATH|RUNPATH'
 0x0000000f (RPATH)                      Library rpath:
[/var/tmp/portage/libiconv-1.9.2/image//usr/lib]
 0x0000001d (RUNPATH)                    Library runpath:
[/var/tmp/portage/libiconv-1.9.2/image//usr/lib]

This is similar to bug #75181 , a.k.a GLSA 200503-01. Gentoo BSD team should be
informed of this bug as soon as possible.

Reproducible: Always
Steps to Reproduce:




Expected Results:  
No insecure RPATH is hard-coded into /usr/bin/iconv

I originnaly thought a dosed or a patch would do the trick. Unfortunately, this
issue more arcane. I found out that if libiconv was not installed (whether
never on unmerged prior to emerging), the iconv executable will contain an
RPATH. But if I emerge again without prior unmerging (a rebuild), RPATH is
gone!

Created an attachment (id=57629) [details]
libiconv-1.9.2-chrpath-ebuild.patch

This patch makes use of the chrpath command to remove the rpath in the
src_install() phase. chrpath is tiny (13k)

I'm going to test if chrpath works on g/fbsd, if it doesn't we need to find a
new way to handle this.

Please next time cc me as I'm libiconv's maintainer.

Seems like the problem isn't there on g/fbsd but just on linux.
Need KERNEL USE_EXPANDED to fix this, really need that ASAP now.

Added a new revision which uses chrpath unconditionally but is masked on fbsd,
waiting to have KERNEL in USE_EXPAND.


Added sparc to cc as I had to drop ~sparc keyword as it misses chrpath.

cant we fix this without resorting to chrpath ?

Diego, we normally CC people on any security bugs as soon as it gets wrangled,
which is now. Solar was just faster than me this time around.

Created an attachment (id=57664) [details]
libiconv-1.9.2-RPATH-fix.patch

Whoever added the libtool support should be shot.

Created an attachment (id=57666) [details]
libiconv-1.9.2-RPATH-fix-2.patch

This works also if you want the more minimal solution.

Thanks I've added your patch and libiconv is happy both on linux and fbsd.

It also has again the ~sparc keyword.

As this is unstable -> closing with NO GLSA.