I tried to update metasploit and it failed with the following error message: svn: Can't open file 'data/msfweb/app/views/ide/.svn/text-base/advanced.rhtml.svn-base': No such file or directory Reproducible: Always Steps to Reproduce: 1. emerge -1av metasploit 2. see it fail 3. Actual Results: It fails to emerge with the error described above Expected Results: I expect metaploit to emerge fine muelli@rootbox ~ $ sudo emerge -1av metasploit WARNING: repository at /usr/local/portage/muelli is missing a repo_name entry These are the packages that would be merged, in order: Calculating dependencies / * Missing digest for '/usr/local/portage/muelli/app-crypt/sims/sims-0.2.ebuild' | * Missing digest for '/usr/local/portage/muelli/media-plugins/xmms-goom/xmms-goom-1.99.5.ebuild' ... done! [ebuild U ] net-analyzer/metasploit-3.1_p5662 [3.1_p5539] USE="gtk sqlite sqlite3 -httpd -postgres" 0 kB Total: 1 package (1 upgrade), Size of downloads: 0 kB !!! The following installed packages are masked: - net-dns/dnsquery-0.60.6 (masked by: package.mask) /usr/portage/profiles/package.mask: # MATSUU Takuto <matsuu@gentoo.org> (10 Jul 2008) # mask for security bug #231283 - dev-util/eclipse-sdk-3.1.2-r3 (masked by: ~x86 keyword) - dev-cpp/poslib-1.0.6 (masked by: package.mask) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-analyzer/metasploit-3.1_p5662 * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * Adjusting permissions for FEATURES=distcc: '/mnt/ramdisk/portage/.distcc' * Adjusting permissions for FEATURES=distcc: '/mnt/ramdisk/portage/.distcc/lock' * Adjusting permissions for FEATURES=distcc: '/mnt/ramdisk/portage/.distcc/state' * Adjusting permissions for FEATURES=confcache: '/mnt/ramdisk/confcache' >>> Unpacking source... * subversion update start --> * repository: https://metasploit.com/svn/framework3/branches/framework-3.1/@5662 Error validating server certificate for 'https://metasploit.com:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: metasploit.com - Valid: from Sun, 01 Apr 2007 22:02:24 GMT until Thu, 01 Apr 2010 22:02:24 GMT - Issuer: 07969287, http://certificates.godaddy.com/repository, GoDaddy.com, Inc., Scottsdale, Arizona, US - Fingerprint: 20:a7:2e:df:6d:53:10:6c:dc:2a:ca:33:fd:35:76:2c:0e:62:b1:4d (R)eject, accept (t)emporarily or accept (p)ermanently? t svn: Can't open file 'data/msfweb/app/views/ide/.svn/text-base/advanced.rhtml.svn-base': No such file or directory * * ERROR: net-analyzer/metasploit-3.1_p5662 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2172: Called subversion_src_unpack * environment, line 2412: Called subversion_fetch * environment, line 2379: Called die * The specific snippet of code: * ${ESVN_UPDATE_CMD} ${options} || die "${ESVN}: can't update ${wc_path} from ${repo_uri}."; * The die message: * subversion: can't update /usr/portage/distfiles/svn-src/metasploit/framework-3.1 from https://metasploit.com/svn/framework3/branches/framework-3.1/. * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/net-analyzer:metasploit-3.1_p5662:20080924-010139.log'. * The ebuild environment file is located at '/mnt/ramdisk/portage/net-analyzer/metasploit-3.1_p5662/temp/environment'. * >>> Failed to emerge net-analyzer/metasploit-3.1_p5662, Log file: >>> '/var/log/portage/net-analyzer:metasploit-3.1_p5662:20080924-010139.log' muelli@rootbox ~ $
I'm not sure what could cause this problem but seems that svn sources inside distdir were corrupted somehow. To workaround this problem just do: # rm -rf /usr/portage/distfiles/svn-src/metasploit and try to emerge again.
The workaround seems to work. However, I consider it a bug to require user interaction with emerge and not providing a way to circumvent it.
(In reply to comment #2) > However, I consider it a bug to require user interaction with emerge and not > providing a way to circumvent it. ebuild uses svn co/svn up to update sources, and in normal situation such error should not happen. So I suppose your error was also triggered by some user intervention. Without some ideas how to reproduce this problem I don't know what to fix (thus impossible to say how). But... CC'ing Akinori Hattori. Akinori is it possible to make subversion.eclass more smart and handle such errors by itself. May be it is possible to clean svn-src completely in case of such error?
I actually meant that I have to confirm the certificate myself.
(In reply to comment #4) > I actually meant that I have to confirm the certificate myself. Well this part should be fixed now (by pointing on http:// instead of https://). But I still think initial bug could be fixed too. :)
(In reply to comment #5) > (In reply to comment #4) > > I actually meant that I have to confirm the certificate myself. > > Well this part should be fixed now (by pointing on http:// instead of > https://). Uh, that's even worse for me. I seriously don't want portage to install anything whichs integrety isn't checked and I thought it's a no-no anyway. Sure, the port-tree itself isn't signed, so an attacker could intercept rsync traffic and install proper checksums to wrong packages, but having two holes an attacker could inject malicious data is worse than having one. I think a proper fix would be to teach svn that the certicate is trusted by installing it in first place, or maybe better: have the root-ca installed.
Muelli, ok I've reverted that "fix" and found that we already install required CA certificates with ca-certificates package and with openssl everything works as it should. For currently unknown reasons this issue is triggered by subversion only when neon is built with gnutls. I've reported about this issue here: http://lists.gnu.org/archive/html/help-gnutls/2008-10/msg00004.html So as a workaround you can build neon without gnutls USE flag. Also saving once and have no problems in the future should work too :) That's said I'm marking this bug as fixed also question is it possible to handle broken repositories in subversion.eclass still stands...