| Summary: | dev-util/subversion-1.2.3-r1 contains insecure RUNPATH's | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Paul Varner (RETIRED) <fuzzyray> | ||||||||||||
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||||||||
| Status: | RESOLVED FIXED | ||||||||||||||
| Severity: | normal | CC: | anthony.staines, azarah, code, duke, gentoo-bugs, gentoobugs, Heinz.Hombergs, jacobs, jakub, job.gentoo.org, kamensky.fb, mcummings, moixa, mquezn8wfq, og, pauldv, perl, rene.rheaume, spam, weeve | ||||||||||||
| Priority: | High | ||||||||||||||
| Version: | unspecified | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | A2? [noglsa] jaervosz | ||||||||||||||
| Package list: | Runtime testing required: | --- | |||||||||||||
| Bug Depends on: | |||||||||||||||
| Bug Blocks: | 81745, 111947 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Paul Varner (RETIRED)
2005-09-06 12:46:11 UTC
Ok, is there someone on the security list with perl knowledge? The problem seems to exist in the perl bindings, and my knowledge of perl is almost nonexistent. I'd like to consider solving the problem in another way than disabling the perl bindings. Sometimes I'd like to shoot down libtool. Paul: will a similar trick used in bug 103776, comment 4 work? I'll look at it, and check whether it works. Not libtool's fault for the perl bindings .. that is MakeMaker being stupid. For the libsvn_*.la stuff, that is Spanky's fault .. I'll be fixing that :/ Created attachment 68102 [details, diff]
perl-5.8.7-MakeMaker-RUNPATH.patch
Ok, this patch against perl for MakeMaker fixes the issue for the bindings ...
Thanks to tigger^ and truedfx for helping with the perl.
-----
--- perl-5.8.7/lib/ExtUtils/MM_Unix.pm 2005-09-10 14:06:59.000000000 +0200
+++ perl-5.8.7.az/lib/ExtUtils/MM_Unix.pm 2005-09-10 14:07:05.000000000
+0200
@@ -1914,7 +1914,10 @@
if ($libs[0] or $libs[1] or $libs[2]){
# LD_RUN_PATH now computed by ExtUtils::Liblist
($self->{EXTRALIBS}, $self->{BSLOADLIBS},
- $self->{LDLOADLIBS}, $self->{LD_RUN_PATH}) = @libs;
+ $self->{LDLOADLIBS}) = @libs;
+ # We do not want the build root in RPATH
+ my @new_libs = grep m!^/usr!, split /:/, join ':', @libs;
+ $self->{LD_RUN_PATH} = join(':',@new_libs);
last;
}
}
Created attachment 68103 [details, diff]
perl-5.8.7-MakeMaker-RUNPATH.patch
Ok, I did not grok the perl that well, this should be better.
-----
--- perl-5.8.7/lib/ExtUtils/MM_Unix.pm 2005-09-10 14:06:59.000000000 +0200
+++ perl-5.8.7.az/lib/ExtUtils/MM_Unix.pm 2005-09-10 15:10:46.000000000
+0200
@@ -1915,6 +1915,9 @@
# LD_RUN_PATH now computed by ExtUtils::Liblist
($self->{EXTRALIBS}, $self->{BSLOADLIBS},
$self->{LDLOADLIBS}, $self->{LD_RUN_PATH}) = @libs;
+ # We do not want the build root in RPATH
+ $self->{LD_RUN_PATH} = join ':', grep m!^/(?:usr|opt)!, split /:/,
+ $self->{LD_RUN_PATH};
last;
}
}
Created attachment 68104 [details, diff]
perl-5.8.7-MakeMaker-RUNPATH-gentoo.patch
And this one might be the best, as it rather strips paths containing
PORTAGE_TMPDIR ... not sure if we still want it to strip non ^/(usr|opt) if
PORTAGE_TMPDIR is not set, but I left it like that for now.
-----
--- perl-5.8.7/lib/ExtUtils/MM_Unix.pm 2005-09-10 14:06:59.000000000 +0200
+++ perl-5.8.7.az/lib/ExtUtils/MM_Unix.pm 2005-09-10 15:13:01.000000000
+0200
@@ -1915,6 +1915,17 @@
# LD_RUN_PATH now computed by ExtUtils::Liblist
($self->{EXTRALIBS}, $self->{BSLOADLIBS},
$self->{LDLOADLIBS}, $self->{LD_RUN_PATH}) = @libs;
+ # We do not want the build root in RPATH
+ if (exists $ENV{PORTAGE_TMPDIR}) {
+ # If we have PORTAGE_TMPDIR set, strip that, as just testing for
+ # /usr and /opt might not be sufficient
+ $self->{LD_RUN_PATH} = join ':', grep /.../ &&
!/^\Q$ENV{PORTAGE_TMPDIR}/,
+ split /:/, $self->{LD_RUN_PATH};
+ } else {
+ # Else just use /usr and /opt paths, and hope for the best
+ $self->{LD_RUN_PATH} = join ':', grep m!^/(?:usr|opt)!, split
/:/,
+ $self->{LD_RUN_PATH};
+ }
last;
}
}
Created attachment 68107 [details, diff]
perl-5.8.7-MakeMaker-RUNPATH-gentoo.patch
This fixes another slight but non-fatal issue.
-----
--- perl-5.8.7/lib/ExtUtils/MM_Unix.pm 2005-09-10 14:06:59.000000000 +0200
+++ perl-5.8.7.az/lib/ExtUtils/MM_Unix.pm 2005-09-10 15:25:52.000000000
+0200
@@ -1915,6 +1915,17 @@
# LD_RUN_PATH now computed by ExtUtils::Liblist
($self->{EXTRALIBS}, $self->{BSLOADLIBS},
$self->{LDLOADLIBS}, $self->{LD_RUN_PATH}) = @libs;
+ # We do not want the build root in RPATH
+ if (exists $ENV{PORTAGE_TMPDIR}) {
+ # If we have PORTAGE_TMPDIR set, strip that, as just testing for
+ # /usr and /opt might not be sufficient
+ $self->{LD_RUN_PATH} = join ':', grep !/^\Q$ENV{PORTAGE_TMPDIR}/,
+ split /:/, $self->{LD_RUN_PATH};
+ } else {
+ # Else just use /usr and /opt paths, and hope for the best
+ $self->{LD_RUN_PATH} = join ':', grep m!^/(?:usr|opt)!, split
/:/,
+ $self->{LD_RUN_PATH};
+ }
last;
}
}
The .la issue is due to this typo (note that my_little_ninja_foo_3 was not set, so the elif was never executed): ----- Index: 1.5.10 =================================================================== RCS file: /var/cvsroot/gentoo-x86/eclass/ELT-patches/portage/1.5.10,v retrieving revision 1.1 diff -u -r1.1 1.5.10 --- 1.5.10 29 Jun 2005 10:51:11 -0000 1.1 +++ 1.5.10 10 Sep 2005 13:38:02 -0000 @@ -40,10 +40,10 @@ + fi + # We do not want portage's build root ($S) present. + my_little_ninja_foo_2=`echo $deplib |$EGREP -e "$S"` -+ if test -n "$my_little_ninja_foo_2" && test "$S"; then -+ mynewdependency_lib="" + # We do not want portage's install root ($D) present. + my_little_ninja_foo_3=`echo $deplib |$EGREP -e "$D"` ++ if test -n "$my_little_ninja_foo_2" && test "$S"; then ++ mynewdependency_lib="" + elif test -n "$my_little_ninja_foo_3" && test "$D"; then + eval mynewdependency_lib=`echo "$deplib" |sed -e "s:$D:/:g" -e 's:/\+:/:g'` + else Martin: feel free to commit the MakeMaker patch, should fix quite a bunch of these RPATH things. Roger. The question is still just if we should leave RUNPATH alone if PORTAGE_TMPDIR is set? User might have some strage setup for some custome modules/whatever? I would say no... screw the fucked-up setup. *looks in* einfo "We've decided that you can't have perl module .so's link to libs" einfo "outside of /opt and /usr by default. To reverse this:" einfo " cd blah; patch -R < blah .." einfo "Have a nice day !" Said fucked-up setup will work on all other distros, bar Gentoo .. I don't see the advantage here. OK, I may have read this bug a little too fast :) Stripping PORTAGE_TMPDIR may be sufficient. Tavis, your opinion on this ? do we really need the else clause in the patch in comment #8 ? the first part makes a lot of sense, but the 2nd part assumes too much i think (In reply to comment #15) > do we really need the else clause in the patch in comment #8 ? the first part > makes a lot of sense, but the 2nd part assumes too much i think The else was the first try, the specific PORTAGE_TMPDIR the second. Its not needed, and it will restrict manual installs, just wanted to know what the security guys thought about how anal it should be. I'll commit just the fist bit. PS, cc'd portage guys on this so that they know to either leave PORTAGE_TMPDIR around, or think about how we will handle this and stuff like the libtool patches that needs this ... think I heard that the rewrite might have changes in this department. Paul what is the status on this one? Added perl-5.8.6-r6.ebuild and perl-5.8.7-r1.ebuild, both ~. Arch teams should just test and stable which ever one they prefer. Sune: from what I understand this bug is more a problem with perl than with the subversion ebuild. Allthough I don't have a version of portage that can test this stuff, I understand that with the new perl ebuilds, subversion should just work with the original ebuilds. Let's just wait and see if it's fixed with the new Perl thing Archs, please test and mark perl-5.8.6-r6 stable (or perl-5.8.7-r1 if you prefer). Not sure that this fixes everything for subversion.
Handling perl stable marking on bug #106678
Well, there was two issues: 1) Blotched libtool patch which is fixed already. Not sure how the apr stuff work, but might have to remerge apr as well if it uses the libtool that apr installs. 2) MakeMaker from perl that messed up the RUNPATH's. This is fixed by the perl patch. Thx Martin. Tavis any more issues before we can close this one as fixed? After emerging the updated perl, I re-emerged subversion and did not encounter the issue. So it appears to be fixed from my end. Not sure how we should GLSA this one... I don't think it is a huge issue as this can only be exploited by users in the "trusted" portage group, or when the /var/tmp/portage dir is deleted. The latter is also restricted as long as /var/tmp permissions are set properly. I also wonder how many other packages are affected by this. I don't think it would only be subversion that is affected. Common GLSA with the other RUNPATH issues Paul: subversion will need a revbump so that affected users are forced to
rebuild (and the GLSA can specify a "fixed version".
The revbump must have the following Perl dep :
>=dev-lang/perl-5.8.6-r6
!=dev-lang/perl-5.8.7
I've bumped the ebuild. It should be marked stable for ppc-macos and mips (at least when they have allready stabilized the new apache layout) The 1.2.3 ebuild still uses the old layout, but making a separate revision just for these small archs seems kind of pointless. Even after re-emering perl, I'm still experiencing this issue on a ~sparc system. 99% of the packages on it are up to date as of today. Paul: I can't see the 1.2.3-r2 from here, sure you committed it ? Jason: did you get the exact same issue as fuzzyray ? Yup, same error as original poster. I also see no new subversion build but I wasn't sure if the new build was subversion or perl either. Sorry, the ebuild didn't pass repoman (new portage version) on silly space checks No change here. -r2 still has the same problems as the original poster posted. And you do have dev-lang/perl-5.8.6-r6 or dev-lang/perl-5.8.7-r1 installed? The 'fix' really just strip $PORTAGE_TMPDIR from -rpath ... so the linking output of the perl modules, etc might help if you have one of above ... Yup, using perl-5.8.7-r1 and I've even rebuild it to see if that helps but no love. Like I said .. the linking bit of the compile output of the perl modules of subversion will help. Also, please merge portage-utils, and do: # qfile /usr/lib/perl5/5.8.7/ExtUtils/MM_Unix.pm Weeve: please provide the requested info so that we can make progress on this one. Created attachment 72240 [details]
subversion emerge log
Sorry for the delay. The output of qfile is "dev-lang/perl
(/usr/lib/perl5/5.8.7/ExtUtils/MM_Unix.pm)". Also I've attached the log emerge
creates when I attempt to emerge subversion-1.2.3-r3
Jason, it is stable or unstable portage (ie, not the CVS 2.1 or such version) ? Any chance you can modify perl-5.8.7-MakeMaker-RUNPATH.patch to echo PORTAGE_TMPDIR and see if its set? Or some other debugging to see why it do not strip those from LD_RUN_PATH ? If not, anybody else know why perl-5.8.7-MakeMaker-RUNPATH.patch might screw up on sparc ? PS: over here linking the perl module looks something like: ----- Running Mkbootstrap for SVN::_Fs () chmod 644 _Fs.bs rm -f blib/arch/auto/SVN/_Fs/_Fs.so LD_RUN_PATH="" x86_64-pc-linux-gnu-gcc -shared svn_fs.o -o blib/arch/auto/SVN/_Fs/_Fs.so -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/bindings/swig/perl/libsvn_swig_perl/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_client/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_delta/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_fs/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_ra/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_repos/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_wc/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_diff/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_subr/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_ra_local/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_ra_svn/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_ra_dav/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_fs_base/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_fs_fs/.libs -lsvn_client-1 -lsvn_delta-1 -lsvn_fs-1 -lsvn_ra-1 -lsvn_repos-1 -lsvn_wc-1 -lsvn_diff-1 -lsvn_subr-1 -lsvn_swig_perl-1 chmod 755 blib/arch/auto/SVN/_Fs/_Fs.so cp _Fs.bs blib/arch/auto/SVN/_Fs/_Fs.bs chmod 644 blib/arch/auto/SVN/_Fs/_Fs.bs ----- while by Jason it looks like: ----- Running Mkbootstrap for SVN::_Fs () chmod 644 _Fs.bs rm -f blib/arch/auto/SVN/_Fs/_Fs.so LD_RUN_PATH="/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_client/.libs:/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_delta/.libs:/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_fs/.libs:/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_ra/.libs:/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_repos/.libs:/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_wc/.libs:/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_diff/.libs:/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_subr/.libs:/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/bindings/swig/perl/libsvn_swig_perl/.libs" sparc-unknown-linux-gnu-gcc -shared -L/usr/local/lib svn_fs.o -o blib/arch/auto/SVN/_Fs/_Fs.so -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/bindings/swig/perl/libsvn_swig_perl/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_client/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_delta/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_fs/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_ra/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_repos/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_wc/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_diff/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_subr/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_ra_local/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_ra_svn/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_ra_dav/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_fs_base/.libs -L/var/tmp/portage/subversion-1.2.3-r3/work/subversion-1.2.3/subversion/libsvn_fs_fs/.libs -lsvn_client-1 -lsvn_delta-1 -lsvn_fs-1 -lsvn_ra-1 -lsvn_repos-1 -lsvn_wc-1 -lsvn_diff-1 -lsvn_subr-1 -lsvn_swig_perl-1 chmod 755 blib/arch/auto/SVN/_Fs/_Fs.so cp _Fs.bs blib/arch/auto/SVN/_Fs/_Fs.bs chmod 644 blib/arch/auto/SVN/_Fs/_Fs.bs ----- which clearly shows PORTAGE_TMPDIR do not get stripped from LD_RUN_PATH ... I've used the latest ~arch versions of portage when testing this. So far that includes at least 2.0.53_rc5 through rc7. I'll try your suggestion on the echo and/or other debugging techniques and report back tomorrow night. So, finally figured out the culprit here. I had both dev-lang/perl and perl-core/ExtUtils-MakeMaker installed. They both provided MM_Unix.pm, but in different locations. ExtUtils-MakeMaker stores it at /usr/lib/perl5/vendor_perl/5.8.7/ExtUtils/MM_Unix.pm while perl stores it at /usr/lib/perl5/5.8.7/ExtUtils/MM_Unix.pm. Once I unmerged ExtUtils-MakeMaker, everything emerges fine. So it seems like perhaps subversion may want to include a blocker for ExtUtils-MakeMaker on this issue, and probably a seperate security bug should be opened for ExtUtils-MakeMaker That would do it :D The patch against perl applies fine, and I can add it .. not sure though if we should ask mcummings to do it since he is back ? CC'ing mcummings (wb!). Patch looks good. I really think at this point that dev-perl/EU::MM should be dropped. It's original inclusion was to help users get over the hump of the 5.6/5.8 differences, but if anyone is still using 5.6 at this point, they're pretty much on their own anyway. I vote in favor of the patch, along with the dropping of EU::MM from the tree (two bird with that stone). Patch is already in perl, so guess you can then just drop EU::MM. Michael do you want to drop dev-perl/EU::MM? About GLSA, we'll wait for a few more runpath things to pile up before releasing this one. Hm, in fact this one doesn't really need a GLSA, since the old Perl update takes care of it and the rest is due to EU:MM cruft... Closing without GLSA (consider it covered by GLSA 200510-14). Perl team should remove EU:MM (and maybe someone add a blocker on subversion) to avoid the specific problem Weeve encountered. Feel free to reopen / reassign the bug, but we're probably done from a security PoV. *** Bug 114253 has been marked as a duplicate of this bug. *** *** Bug 114415 has been marked as a duplicate of this bug. *** I don't think that dropping EU::MM is a good solution. Even if you do that, it can still be emerged via g-cpan (and for good reasons.) As far as I understand this (which is not very far), the problem is that a Makefile.PL might specify in something like -Lfoo for LIBS, where foo is a relative path. In this case ExtUtils::Liblist prefixes the foo with cwd. I don't know why it does this, but apparently at least from some point of view it's wrong, so this is a general problem/missing feature in ExtUtils::Liblist and the right thing would be to fix it upstream Well, EU::MM is still not removed, or patched, and now they went and bumped it, so I just patched it for now. *** Bug 117149 has been marked as a duplicate of this bug. *** *** Bug 117267 has been marked as a duplicate of this bug. *** *** Bug 117926 has been marked as a duplicate of this bug. *** I get this with subversion 1.3.0. The duplicate indicate I am not the only one. Please reopen. My fix: I ran the 'perl-cleaner' script, and it appears to have fixed the problem. I tried running the perl-cleaner, didn't work for me. Revdep-rebuild is clean as well. The current patch does not seem to work if, for example, /var/tmp/portage is really elsewhere. On my system, /var/tmp doesn't have enough space, so I made it a symlink to /home/var/tmp. In some places, this is translated, others it isn't, so the rpath has /home/var/tmp/portage, but this change only looks for /var/tmp/portage. I tried changing the patch, but couldn't figure out the right answer. Instead, I changed my environment to make /var/tmp a regular directory again by removing the link, and then running "mount --bind /home/var/tmp /var/tmp" and now "pwd -P" shows /var/tmp again, and then this problem goes away. I'm sure there's more patching required for this. Unmerging ExtUtils-MakeMaker-6.20 (which theoretically should contain a patch removing this issue) fixed my problem compiling subversion 1.3.0. See bug 114415. *** Bug 119497 has been marked as a duplicate of this bug. *** I am also still having this problem with subversion 1.3.0 and perl 5.8.7-r1. My /var/tmp/ sits at /data/var/tmp/ (on a dmcrypt encrypted partition) and is softlinked to /var/tmp. This seems to screw things up, because it also causes RUNPATH problems with Perl on other packages such as ImageMagick. Could you try adding the following line to your make.conf: PORTAGE_TMPDIR="/data/var/tmp" Good chance it works then. Probably the symlinks get resolved, so the path is wrong, and cleaning up then doesn't work as it uses the unresolved path. Setting the actual location then works. Changing PORTAGE_TMPDIR in /etc/make.conf fixed the problem. Thanks! Might think having portage resolve it (PORTAGE_TMPDIR) on startup if this starts to get a big issue. I know I have had it with sandbox already, and fixed it. Those sandbox issues got me into suggesting trying this. I've been bitten by it too ;-) I am still getting same issue with subversion on standard portage tree. So clearly not fixed...please reopen. making executable: /usr/lib/libsvn_wc-1.so.0.0.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/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_client/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_delta/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_fs/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_ra/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_repos/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_wc/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_diff/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_subr/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/bindings/swig/perl/libsvn_swig_perl/.libs:/usr/lib usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/SVN/_Fs/_Fs.so /var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_client/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_delta/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_fs/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_ra/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_repos/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_wc/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_diff/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_subr/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/bindings/swig/perl/libsvn_swig_perl/.libs:/usr/lib usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/SVN/_Ra/_Ra.so /var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_client/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_delta/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_fs/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_ra/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_repos/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_wc/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_diff/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_subr/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/bindings/swig/perl/libsvn_swig_perl/.libs:/usr/lib usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/SVN/_Wc/_Wc.so /var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_client/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_delta/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_fs/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_ra/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_repos/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_wc/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_diff/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_subr/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/bindings/swig/perl/libsvn_swig_perl/.libs:/usr/lib usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/SVN/_Core/_Core.so /var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_client/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_delta/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_fs/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_ra/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_repos/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_wc/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_diff/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_subr/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/bindings/swig/perl/libsvn_swig_perl/.libs:/usr/lib usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/SVN/_Delta/_Delta.so /var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_client/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_delta/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_fs/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_ra/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_repos/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_wc/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_diff/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_subr/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/bindings/swig/perl/libsvn_swig_perl/.libs:/usr/lib usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/SVN/_Repos/_Repos.so /var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_client/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_delta/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_fs/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_ra/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_repos/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_wc/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_diff/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/libsvn_subr/.libs:/var/tmp/portage/subversion-1.2.3-r2/work/subversion-1.2.3/subversion/bindings/swig/perl/libsvn_swig_perl/.libs:/usr/lib usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/SVN/_Client/_Client.so !!! ERROR: dev-util/subversion-1.2.3-r2 failed. !!! Function dyn_install, Line 1057, Exitcode 0 !!! Insecure binaries detected Noted the following: gentoo ~ # for i in `locate MM_Unix.pm` ; do ls -l $i ; done -r--r--r-- 1 root root 110176 Jan 18 00:13 /usr/lib/perl5/5.8.7/ExtUtils/MM_Unix.pm -r--r--r-- 1 root root 107053 Oct 24 2004 /usr/lib/perl5/vendor_perl/5.8.2/ExtUtils/MM_Unix.pm gentoo ~ # locate MM_Unix.pm /usr/lib/perl5/5.8.7/ExtUtils/MM_Unix.pm /usr/lib/perl5/vendor_perl/5.8.2/ExtUtils/MM_Unix.pm gentoo ~ # for i in `locate MM_Unix.pm` ; do ls -l $i ; done -r--r--r-- 1 root root 110176 Jan 18 00:13 /usr/lib/perl5/5.8.7/ExtUtils/MM_Unix.pm -r--r--r-- 1 root root 107053 Oct 24 2004 /usr/lib/perl5/vendor_perl/5.8.2/ExtUtils/MM_Unix.pm Different versions. So, now trying: gentoo ~ # perl-cleaner all ask I am not much of a guru, but ExtUtils-MakeMaker is part of perl-core, can it be safely unmerged if perl-cleaner doesn't work? Remove perl-core/ExtUtils-MakeMaker as perl provides its own MakeMaker. This should fix the problem. *** Bug 120384 has been marked as a duplicate of this bug. *** @pauldv: Please, block ExtUtils-MakeMaker in subversion ebuilds if better solution can't be found. Shouldn't makemaker be patched by now? Or are unpatched makemakers still around? (In reply to comment #74) > Shouldn't makemaker be patched by now? Or are unpatched makemakers still > around? Either people didn't upgrade or the patch doesn't work or they didn't run perl-updater or whatever. Since MM is not needed any more, we should force people to unmerge it. It's not good for anything and is causing just problems. :/ Yes, it should have been patched in stable MakeMaker as well as in stable Perl. I had the stable versions of both packages and had to remove MakeMaker to get Subversion merging. However, emerging MakeMaker now does not trigger the bug anymore with subversion. Don't know what happened, but a blocker would stop the duplicate bugs anyway. Ok, I've just added blockers for MakeMaker in all subversion ebuilds. (In reply to comment #76) > Yes, it should have been patched in stable MakeMaker as well as in stable Perl. > I had the stable versions of both packages and had to remove MakeMaker to get > Subversion merging. > However, emerging MakeMaker now does not trigger the bug anymore with > subversion. > Don't know what happened, but a blocker would stop the duplicate bugs anyway. > When emerging subversion 1.2.3.-r2 on a newly updated system with perl 5.8.7 it still breaks with a dyn_install error - "Insecure binaries detected" Portage 2.0.54 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2, 2.6.12-gent oo-r6 i686) ================================================================= System uname: 2.6.12-gentoo-r6 i686 Pentium III (Coppermine) Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share /config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kd e/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/default s/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips /config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config / /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict userpriv usersandbo x" GENTOO_MIRRORS="http://ftp.heanet.ie/pub/gentoo/ ftp://ftp.heanet.ie/pub/gentoo/ http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ ftp://ftp.mirrorserv ice.org/sites/www.ibiblio.org/gentoo/ " LINGUAS="en_GB en fr de es ca" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 X alsa apache2 apm arts audiofile avi berkdb bitmap-fonts blas bzip2 bz lib cdparanoia crypt cups curl eds emboss encode esd exif expat f77 fam foomatic db fortran gd gdbm gif glut gnome gpm gstreamer gtk gtk2 gtkhtml idn imagemagick imlib ipv6 java jpeg junit kde lcms ldap libg++ libwww lua mad mhash mikmod mmx mng modperl motif mozilla mp3 mpeg mysql ncurses nls ogg oggvorbis opengl oss p am pcre pda pdflib perl png ppds python qt quicktime readline samba sdl slang sp ell sse ssl svga tcpd tetex tiff truetype truetype-fonts type1-fonts udev vorbis xml xml2 xmms xv zlib linguas_en_GB linguas_en linguas_fr linguas_de linguas_es linguas_ca userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS I have tried the emerge unmerge ExtUtils-MakeMaker emerge -u subversion solution as suggested in bug #114253 Thanks to Martijn Koster and Paul De Vrieze This works well. However judging by the number of other packages for which this is an issue (Bugs 115513, 81745, 117434, 11760, 117603, 120366) there is still a problem - perhaps a message about this could be put onto the forums? *** Bug 124742 has been marked as a duplicate of this bug. *** *** Bug 129316 has been marked as a duplicate of this bug. *** *** Bug 148827 has been marked as a duplicate of this bug. *** |