Hello. When using dev-vcs/subversion-1.6.13 (USE=webdav-neon) with net-libs/neon-0.29.3 over https I am getting the following error code on the client side. svn: OPTIONS von »repo-url«: SSL handshake failed: SSL error: Eine TLS-Warnmeldung wurde empfangen. (servername) With this bug https svn repositories are not longer usable. Reproducible: Always Steps to Reproduce: 1. Install Subversion and neon with the mentioned versions 2. svn update from a https enabled repository served by Apache 3. Get the error Actual Results: svn: OPTIONS von »repo-url«: SSL handshake failed: SSL error: Eine TLS-Warnmeldung wurde empfangen. (servername) Expected Results: Normal svn update Workaround: Compile subversion on client (and maybe server) with USE=-nowebdav apache2 ssl -webdav-neon webdav-serf sasl" to avoid the neon dependency and get a working svn update on the same working copy again.
Created attachment 250443 [details] Emerge.info
You propably forgot to # revdep-rebuild --library libcrypto.so.0.9.8 # revdep-rebuild --library libssl.so.0.9.8 after openssl-1 upgrade, like the postinst message told you?
Which would make this a duplicate of bug 339858.
(In reply to comment #2) > You propably forgot to > > # revdep-rebuild --library libcrypto.so.0.9.8 > # revdep-rebuild --library libssl.so.0.9.8 > > after openssl-1 upgrade, like the postinst message told you? > Actually I did these steps on client and server. I also verified that I did them by executing the command again.
I also did an Apache server restart, of course.
To be 100% sure I executed the revdep-rebuild command again: server: # revdep-rebuild --library libssl.so.0.9.8 && revdep-rebuild --library libcrypto.so.0.9.8 * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries using libssl.so.0.9.8 * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Checking dynamic linking [ 100% ] * There are no dynamic links to libssl.so.0.9.8... All done. * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries using libcrypto.so.0.9.8 * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Checking dynamic linking [ 100% ] * There are no dynamic links to libcrypto.so.0.9.8... All done. client: # revdep-rebuild --library libssl.so.0.9.8 && revdep-rebuild --library libcrypto.so.0.9.8 * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries using libssl.so.0.9.8 * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Checking dynamic linking [ 100% ] * There are no dynamic links to libssl.so.0.9.8... All done. * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries using libcrypto.so.0.9.8 * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Checking dynamic linking [ 38% ] * found /usr/lib32/libssl.so.0.9.8 [ 100% ] * Generated new 3_broken.rr * Assigning files to packages * /usr/lib32/libssl.so.0.9.8 -> app-emulation/emul-linux-x86-baselibs * Generated new 4_raw.rr and 4_owners.rr * Cleaning list of packages to rebuild * Generated new 4_pkgs.rr * Assigning packages to ebuilds * Generated new 4_ebuilds.rr * Evaluating package order * Generated new 5_order.rr * All prepared. Starting rebuild emerge --oneshot app-emulation/emul-linux-x86-baselibs:0 .......... Calculating dependencies... done! >>> Verifying ebuild manifests >>> Emerging (1 of 1) app-emulation/emul-linux-x86-baselibs-20100915-r1 * emul-linux-x86-baselibs-20100915.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * lcms-1.19.tbz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * talloc-2.0.1-r1.tbz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * Package: app-emulation/emul-linux-x86-baselibs-20100915-r1 * Repository: gentoo * Maintainer: amd64@gentoo.org * USE: amd64 elibc_glibc kernel_linux multilib userland_GNU >>> Unpacking source... >>> Unpacking emul-linux-x86-baselibs-20100915.tar.bz2 to /home/portage/tmp/portage/app-emulation/emul-linux-x86-baselibs-20100915-r1/work >>> Unpacking lcms-1.19.tbz2 to /home/portage/tmp/portage/app-emulation/emul-linux-x86-baselibs-20100915-r1/work bzip2: /home/portage/tmp/portage/app-emulation/emul-linux-x86-baselibs-20100915-r1/distdir/lcms-1.19.tbz2: trailing garbage after EOF ignored >>> Unpacking talloc-2.0.1-r1.tbz2 to /home/portage/tmp/portage/app-emulation/emul-linux-x86-baselibs-20100915-r1/work bzip2: /home/portage/tmp/portage/app-emulation/emul-linux-x86-baselibs-20100915-r1/distdir/talloc-2.0.1-r1.tbz2: trailing garbage after EOF ignored >>> Source unpacked in /home/portage/tmp/portage/app-emulation/emul-linux-x86-baselibs-20100915-r1/work >>> Compiling source in /home/portage/tmp/portage/app-emulation/emul-linux-x86-baselibs-20100915-r1/work ... >>> Source compiled. >>> Test phase [not enabled]: app-emulation/emul-linux-x86-baselibs-20100915-r1 >>> Install emul-linux-x86-baselibs-20100915-r1 into /home/portage/tmp/portage/app-emulation/emul-linux-x86-baselibs-20100915-r1/image/ category app-emulation >>> Completed installing emul-linux-x86-baselibs-20100915-r1 into /home/portage/tmp/portage/app-emulation/emul-linux-x86-baselibs-20100915-r1/image/ * QA Notice: The following shared libraries lack a SONAME * /usr/lib32/libEnhancedDisassembly.so * /usr/lib32/libLLVMHello.so * /usr/lib32/libLTO.so * /usr/lib32/libprofile_rt.so >>> Installing (1 of 1) app-emulation/emul-linux-x86-baselibs-20100915-r1 >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. * Build finished correctly. Removing temporary files... * You can re-run revdep-rebuild to verify that all libraries and binaries * are fixed. Possible reasons for remaining inconsistencies include: * orphaned files * deep dependencies * packages installed outside of portage's control * specially-evaluated libraries Can the remaining emul-linux-x86-baselibs-20100915-r1 /usr/lib32/libssl.so.0.9.8 be an issue?
> Can the remaining emul-linux-x86-baselibs-20100915-r1 > /usr/lib32/libssl.so.0.9.8 be an issue? No... can't think of any other reason why this would be filing so moving to subversion/neon maintainer ->
Please test net-libs/neon-0.29.5.
I tested these combinations: Server neon-0.29.5 + subversion webdav-neon + client webdav-serf and neon-0.29.3 -> working Server neon-0.29.5 + subversion webdav-neon + client subversion webdav-neo and neon-0.29.5 -> working Tomorrow I will additionally test the tortoise SVN client under Windows with the gentoo based server.
Only Subversion client uses Neon / Serf. Subversion server doesn't use them.
The strange thing is, that tortoise svn does not work in combination with the server. However it worked before. As it does neither work with serf nor with neon and the only thing I knowingly upgraded was openssl I suspect an incompatibility between openssl 0.9.8 and openssl 1.0 or a bug in neon 0.29.4. This assumption is based on the following data: Windows: TortoiseSVN 1.6.11, Build 20210 - 32 Bit , 2010/09/30 20:36:44 Subversion 1.6.13, apr 1.3.8 apr-utils 1.3.9 neon 0.29.4 OpenSSL 0.9.8o 01 Jun 2010 zlib 1.2.3 ->does not work (OPTIONS of 'repo url': SSL handshake failed: SSL error code -1/1/336032856 (server host name)) svn, Version 1.6.13 (SlikSvn/1.6.13) WIN32. ->works So I further suspect that SlikSVN is linked against another openssl library (maybe 1.0 already) or neon library which is compatible with the openssl server version. If the server does not use neon at all maybe neon 0.29.4 of the client is to blame. This however would be also strange because tortoise svn and server worked together before the ssl upgrade. Might this be a bug concerning the combination of neon 0.29.4 and openssl 1.0? The whole thing is a big issue to me because for all clients tortoisesvn is not longer usable.
Regrettably this issue is not resolved for me, because tortoise svn for example does not work with the upgraded server (see comment 11)
I downgraded TortoiseSVN from Version 1.6.11 to version TortoiseSVN 1.6.7, Build 18415 - 32 Bit , 2010/01/22 17:55:06 Subversion 1.6.9, apr 1.3.8 apr-utils 1.3.9 neon 0.29.3 OpenSSL 0.9.8k 25 Mar 2009 zlib 1.2.3 . This version with neon 0.29.3 WORKS with the server's openssl 1.0 and neon 0.29.3. I will try other TortoiseSVN versions when I have more time. At least this is a workaround.
So after further testing I found out that TortoiseSVN 1.6.10, Build 19898 - 64 Bit , 2010/07/16 15:46:08 Subversion 1.6.12, apr 1.3.8 apr-utils 1.3.9 neon 0.29.3 OpenSSL 0.9.8o 01 Jun 2010 zlib 1.2.3 WORKS but TortoiseSVN 1.6.11, Build 20210 - 32 Bit , 2010/09/30 20:36:44 Subversion 1.6.13, apr 1.3.8 apr-utils 1.3.9 neon 0.29.4 OpenSSL 0.9.8o 01 Jun 2010 zlib 1.2.3 DOES NOT WORK. The problem is reproducible without changing the neon 0.29.3 version of the server. For this reason I suppose neon 0.29.4 to be the culprit. Do you agree?
Please report the problem to upstream.
(In reply to comment #15) > Please report the problem to upstream. > Bug is noticed at http://svn.haxx.se/tsvnusers/archive-2010-10/0340.shtml . Until a new release, TortoiseSVN 1.6.10 or branch 1.6 developer release can be used.
