+++ This bug was initially created as a clone of Bug #238529 +++ metasploit can't be emerged when neon (either neon or serf is required for subversion) has been built with USE="gnutls". Emerge fails with the following error message: * subversion check out start --> * repository: https://metasploit.com/svn/framework3/branches/framework-3.1/@5699 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? svn: OPTIONS of 'https://metasploit.com/svn/framework3/branches/framework-3.1': Server certificate verification failed: issuer is not trusted (https://metasploit.com) * * ERROR: net-analyzer/metasploit-3.1_p5699-r1 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2241: Called subversion_src_unpack * environment, line 2504: Called subversion_fetch * environment, line 2419: Called die * The specific snippet of code: * ${ESVN_FETCH_CMD} ${options} "${repo_uri}" || die "${ESVN}: can't fetch to ${wc_path} from ${repo_uri}."; * The die message: * subversion: can't fetch to /usr/portage/distfiles/svn-src/metasploit/framework-3.1 from https://metasploit.com/svn/framework3/branches/framework-3.1/. If neon is emerged with USE="-gnutls", then metasploit emerges successfully. But if neon was built with USE="gnutls", then gnutls won't verify metasploit.com's certificate because (according to RFC 4346) it is invalid (see http://lists.gnu.org/archive/html/help-gnutls/2008-10/msg00005.html for more information). However, openssl and others verify it successfully despite this misconfiguration. I tried fixing the problem by modifying /etc/subversion/servers and manually adding Go Daddy's certificate bundle ("ssl-authority-files = /etc/ssl/certs/Go_Daddy_Certificate_Bundle.pem") but subversion still doesn't want to accept the certificate. Neither "ssl-trust-default-ca = yes" or manually adding ValiCert's certificate with ssl-authority-files did help. Also, accepting the certificate with root's account (and even mine) when doing an svn checkout (svn co https://metasploit.com/svn/framework3/trunk/) had no effect. In order to emerge metasploit and still have neon built with USE="gnutls" I had to set ESVN_OPTIONS to "--non-interactive --trust-server-cert". IMO emerge should first check if neon was built with the gnutls use flag and if so, print a warning that it's going to accept whatever certificate https://metasploit.com/ throws at it because it can't verify it even if it's valid. Then it should set ESVN_OPTIONS to "${ESVN_OPTIONS} --non-interactive --trust-server-cert" and then start the svn command. For more information about why this is happening, see http://bugs.gentoo.org/show_bug.cgi?id=238529#c7 . Even though that bug is marked as "FIXED", as you can see, the problem still exists. Reproducible: Always Steps to Reproduce: 0. USE="webdav-neon" emerge -av1 dev-util/subversion 1. USE="gnutls" emerge -av1 net-misc/neon 2. emerge -av net-analyzer/metasploit Actual Results: It fails to emerge with the error described above. Expected Results: I expected metasploit to emerge fine.
Heh, better fix upstream certificate... That said, I think we can do this: check if neon was built with the gnutls use flag and if so, print a warning and set ESVN_OPTIONS to "${ESVN_OPTIONS} --non-interactive --trust-server-cert" Could you help me and provide patch?
(In reply to comment #1) > Could you help me and provide patch? Of course :) Here's the patch (written with help from dzhus and zzam @ #gentoo-dev-help)
Created attachment 198905 [details, diff] patch for the ebuild that fixes the problem
+ 01 Mar 2010; Patrick Lauer <patrick@gentoo.org> +files/msfweb3.3.confd, + -metasploit-3.2_p6750.ebuild, +files/msfweb3.3.initd, + +metasploit-3.3.3.ebuild: + Bump to 3.3.3, fixes #277405 #282501 #296157