|Summary:||sci-libs/gdal appeas to have RPATH issues|
|Product:||Gentoo Security||Reporter:||Jason Wever (RETIRED) <weeve>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Severity:||normal||CC:||dragonheart, nerdboy, sci|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Jason Wever (RETIRED) 2005-09-12 21:39:50 UTC
sci-libs/gdal appears to suffer the RPATH issues in bug #81745. This shows up for me as a problem on both versions 1.2.6-r3 and 1.3.0. Emerge error for 1.2.6-r3; prepallstrip: strip: sparc-unknown-linux-gnu-strip --strip-unneeded usr/lib/libgdal.so.1.7.0 usr/lib/python2.4/site-packages/_gdalmodule.so usr/bin/ogr2ogr usr/bin/ogrinfo usr/bin/ogrtindex usr/bin/gdalinfo usr/bin/gdal_translate usr/bin/gdaladdo usr/bin/gdalwarp usr/bin/gdal_contour usr/bin/gdaltindex making executable: /usr/lib/libgdal.so.1.7.0 QA Notice: the following files contain insecure RUNPATH's Please file a bug about this at http://bugs.gentoo.org/ For more information on this issue, kindly review: http://bugs.gentoo.org/81745 /var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/ogr2ogr /var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/ogrinfo /var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/ogrtindex /var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/gdalinfo /var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/gdal_translate /var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/gdaladdo /var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/gdalwarp /var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/gdal_contour /var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/gdaltindex !!! ERROR: sci-libs/gdal-1.2.6-r3 failed. !!! Function dyn_install, Line 1044, Exitcode 0 !!! Insecure binaries detected !!! If you need support, post the topmost build error, NOT this status message. Emerge error for 1.3.0 prepallstrip: strip: sparc-unknown-linux-gnu-strip --strip-unneeded usr/lib/libgdal.so.1.8.0 usr/lib/python2.4/site-packages/_gdalmodule.so usr/bin/ogr2ogr usr/bin/ogrinfo usr/bin/ogrtindex usr/bin/gdalinfo usr/bin/gdal_translate usr/bin/gdaladdo usr/bin/gdalwarp usr/bin/gdal_contour usr/bin/gdaltindex making executable: /usr/lib/libgdal.so.1.8.0 QA Notice: the following files contain insecure RUNPATH's Please file a bug about this at http://bugs.gentoo.org/ For more information on this issue, kindly review: http://bugs.gentoo.org/81745 /var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/ogr2ogr /var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/ogrinfo /var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/ogrtindex /var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/gdalinfo /var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/gdal_translate /var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/gdaladdo /var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/gdalwarp /var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/gdal_contour /var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/gdaltindex !!! ERROR: sci-libs/gdal-1.3.0 failed. !!! Function dyn_install, Line 1044, Exitcode 0 !!! Insecure binaries detected !!! If you need support, post the topmost build error, NOT this status message.
Comment 1 Thierry Carrez (RETIRED) 2005-09-21 05:34:11 UTC
Reporter : could you please check that it still happens after the latest Perl upgrade...
Comment 2 Jason Wever (RETIRED) 2005-09-21 10:13:21 UTC
No change here with the new perl (not even sure if gdal uses perl)
Comment 3 Daniel Black (RETIRED) 2005-10-02 04:18:58 UTC
Created attachment 69704 [details, diff] path against gdal ebuilds TOFIX: both sci-geosciences/grass and sci-libs/gdal depend on each other As such I haven't tested with use=grass TODO: test application - I've only done compile and install path tests. TODO: submit install path fix patch upstream fyi note: install path patch was generated with sed -i -e 's/\($(INSTALL.*\)$(INST_/\1$(DESTDIR)$(INST_/g' `find . -name GNUmakefile` with: GDALmake.opt.in -INST_DATA = @datadir@ +INST_DATA = @datadir@/gdal Jason - i think you're right - no perl is used.
Comment 4 Daniel Black (RETIRED) 2005-10-02 04:31:48 UTC
Created attachment 69708 [details, diff] gdal-1.2.6-installpathfix.patch
Comment 5 Daniel Black (RETIRED) 2005-10-02 04:33:31 UTC
Created attachment 69709 [details, diff] gdal-1.3.0-installpathfix.patch
Comment 6 Thierry Carrez (RETIRED) 2005-10-04 06:00:18 UTC
Pulling in herd as the maintainer doesn't seem to respond.
Comment 7 Steve Arnold 2005-10-05 00:17:03 UTC
It'll have to wait until after work tomorrow when I can see again...
Comment 8 Steve Arnold 2005-10-06 00:33:21 UTC
Updated and patched.
Comment 9 Daniel Black (RETIRED) 2005-10-06 01:25:02 UTC
TOFIX: both sci-geosciences/grass and sci-libs/gdal depend on each other gdal-1.2.5-r1.ebuild could be removed. for glsa's sake you probably need revision bumps on gdal-1.2.6-r3.ebuild -> -r4 and 1.3.0 -> -r1 A little credit to the patch contributor couldn't hurt either. I'm assuming you pushed a patch upstream. I will if you want me too.
Comment 10 Daniel Black (RETIRED) 2005-10-10 05:54:34 UTC
> TOFIX: both sci-geosciences/grass and sci-libs/gdal depend on each other http://lists.maptools.org/pipermail/gdal-dev/2005-September/006565.html not sure it helps - I tested and it really does seems as though they depend on each other. * bump * cause a solution is needed.
Comment 11 Daniel Black (RETIRED) 2005-10-13 13:53:15 UTC
Yes depenancy resolution is a hard problem. From above URL "The problem with GRASS and GDAL was solved as part of the Debian GIS effort and revolves around building the GDAL GRASS driver as a separate package using the plugin API. Presumably a similar approach would be advisable for Fedora." And the next email in the thread: http://lists.maptools.org/pipermail/gdal-dev/2005-September/006566.html Silke Reimer Silke.Reimer at intevation.de: "As I already tried to explain in the thread one year ago this can only be solved by packaging the grassgdal-plugin in a seperate package. It happens that I will build a new grass package for FC4 together with this plugin within the next few weeks (hopefully already this week)." I assume this is the thread from a year ago: http://lists.maptools.org/pipermail/gdal-dev/2004-August/003877.html Does debian's package dependancy structure help? packages.debian.org search gdal and grass
Comment 12 Steve Arnold 2005-10-13 18:49:30 UTC
I was thinking something similar last night, ie, it should work okay like so: Change the grass USE flag in gdal to "libgrass" and add an ebuild for libgrass (meaning a new ebuild in sci-libs where only the Grass6 libs are installed). I haven't worked out the details yet as far as the dependency subset for libgrass, but it sounds good after a couple of beers... :) It would conflict with the full Grass ebuild, but I think we have the ebuild functions to detect it and merge with it (or just make a reverse dep). I'm sure there are people with more portage foo than I have...
Comment 13 Thierry Carrez (RETIRED) 2005-10-15 01:31:17 UTC
Steve: how about splitting grass into grass-lib and grass-main, and make grass-main and gdal depend on grass-lib ? If you trim grass-main sufficiently there shouldn't be a conflict with grass-lib... and the "grass" USE flag would just be kept the same. disclaimer: I don't know the apps in question at all. disclaimer2: "grass-main" should probably just be called "grass".
Comment 14 Sune Kloppenborg Jeppesen (RETIRED) 2005-10-21 23:49:18 UTC
Any progress on this one?
Comment 15 Steve Arnold 2005-10-25 00:24:17 UTC
Removed grass dep from gdal; adding gdal-grass driver as gdal plugin (upstream approved).
Comment 16 Thierry Carrez (RETIRED) 2005-10-25 02:04:24 UTC
Thx Steve, this one is ready for GLSA
Comment 17 Thierry Carrez (RETIRED) 2005-11-01 05:09:45 UTC
GLSA Batch ready
Comment 18 Thierry Carrez (RETIRED) 2005-11-02 09:19:27 UTC