Summary: | sci-libs/vtk-4.2.6 fails emerge due to insecure RUNPATH's | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Craig Finch <oanjao> |
Component: | Runpath Issues | Assignee: | Markus Dittrich (RETIRED) <markusle> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | cbm |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | [ebuild?] | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 81745 | ||
Attachments: |
CMake cache file for VTK 4.2.6
patch for vtk-4.2.6.ebuild |
Description
Craig Finch
2006-02-14 19:56:13 UTC
I just rebuild vtk but I cannot reproduce this with USE="java python tcltk threads -doc -examples -mpi -patented". What are your use flags for vtk? markusle please verify and provide new ebuilds if needed, thx (In reply to comment #2) > markusle please verify and provide new ebuilds if needed, thx > I'll have a look at it soon! Thanks for reporting. Thanks, Markus Unfortunately, I can not reproduce this here with identical use flags to yours. Which version of cmake are you currently running? Also, could you please post the cmake cache file CMakeCache.txt (should be located at /var/tmp/portage/vtk-4.2.6/work/VTK). Finally, it looks like your system is somewhat outdated, e.g. python, binutils, ... It might be a good idea to bring it up to the current x86 and then try again. Thanks, Markus Created attachment 80605 [details]
CMake cache file for VTK 4.2.6
cmake version 2.0.3
See attached CMakeCache.txt
I will try updating the system this weekend and re-emerge VTK.
Craig
Created attachment 80679 [details, diff]
patch for vtk-4.2.6.ebuild
Thanks for posting your cache file and I can see now where the problem
might be. Please try the attached patch for the ebuild and report
back.
Thanks,
Markus
I got VTK to emerge correctly. I tried upgrading binutils and python as recommended, but vtk still had the insecure RUNPATH problem. I then upgraded cmake to the latest stable version and I was able to install successfully. All this took place without the patch. So, it appears that cmake 2.0.6 is necessary to build VTK. Markus, sorry I was not able to try out your patch. -- Craig (In reply to comment #7) > I got VTK to emerge correctly. Hi Craig, I am glad that upgrading cmake took care of the problem. In any case, I applied the patch to the ebuild since it should prevent similar things from happening in the future. @security.g.o: It looks like the insecure RUNPATH problems have been resolved. Thanks, Markus 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 #9) > 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 > Hi solar, Thank you very much for the info and for pointing out the relevant bug. best, Markus Hi security folks, Can this bug be closed? It looks like the issue has been resolved and version 4.2.6. will be removed from the tree in the very near future anyway. Thanks, Markus No longer a security issue with current stable portage, re-assigning to maintainer. Just close it if it's no longer reproducable with current versions in portage. (In reply to comment #12) > No longer a security issue with current stable portage, re-assigning to > maintainer. > > Just close it if it's no longer reproducable with current versions in portage. > Thanks Jakub! Current versions are fine to the best of my knowledge, hence I'll close this one. best, Markus |