Summary: | net-analyzer/metasploit-3.1_p5662 - svn: Can't open file 'data/msfweb/app/views/ide/.svn/text-base/advanced.rhtml.svn-base': No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Muelli <gentoo-bugs> |
Component: | New packages | Assignee: | Gentoo Netmon project <netmon> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hattya |
Priority: | High | ||
Version: | 2008.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Muelli
2008-09-24 01:06:19 UTC
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... |