| Summary: | gnome-base/librsvg-2.12.{6|7} insecure RUNPATH | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Michal <doman1> |
| Component: | Runpath Issues | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gnome |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | ~3 [ebuild] DerCorny | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 81745 | ||
|
Description
Michal
2006-01-08 02:01:20 UTC
dear gnome herd, please provide fixed ebuilds. It would be nice if you could check if stable versions are affected, too. Thanks in advance. This does not appear to be a librsvg but, but rather an autoconf bug. None of the .am or .in files in librsvg contain any references to any kind of runpath, and we don't use the configure from the package, because we run autoconf in the ebuild. Therefore, any references to a runpath are generated by configure. I do not get these errors when I install, therefore at least my autoconf is safe. (In reply to comment #2) > This does not appear to be a librsvg but, but rather an autoconf bug. None of > the .am or .in files in librsvg contain any references to any kind of runpath, > and we don't use the configure from the package, because we run autoconf in the > ebuild. Therefore, any references to a runpath are generated by configure. > > I do not get these errors when I install, therefore at least my autoconf is > safe. > I'm sorry, but i don't understand what's wrong with my autoconf ? I use: Gentoo ~ # autoconf --version autoconf (GNU Autoconf) 2.59 [ebuild R ] sys-devel/autoconf-2.59-r7 USE="-emacs" 0 kB what should i do now ? Reopening and reassigning to base-system so that they confirm the problem lies in autoconf. has nothing to do with autoconf, libtool generates the libraries emerge cleanly here I've got the same output as in the first comment. In order to have librsvg emerged I need to modify its ebuild, by adding
chrpath -r /usr/bin ${D}/usr/bin/rsvg
chrpath -r /usr/bin ${D}/usr/bin/rsvg-view
chrpath -r /usr/lib ${D}/usr/lib/gtk-2.0/2.4.0/engines/libsvg.so
chrpath -r /usr/lib ${D}/usr/lib/gtk-2.0/2.4.0/loaders/svg_loader.so
at the end of src_install function.
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 (In reply to comment #8) > 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 > Obviously, with portage-2.1_pre6 and over there is no rpath error :) |
