Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 340825

Summary: dev-vcs/subversion-1.6.13 on server and net-libs/neon-0.29.4 on client - ssl handshake failed on client side
Product: Gentoo Linux Reporter: Phillip Merensky <gentoo>
Component: [OLD] LibraryAssignee: Arfrever Frehtes Taifersar Arahesis (RETIRED) <arfrever>
Status: RESOLVED UPSTREAM    
Severity: normal    
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Emerge.info

Description Phillip Merensky 2010-10-13 09:38:49 UTC
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.
Comment 1 Phillip Merensky 2010-10-13 09:39:53 UTC
Created attachment 250443 [details]
Emerge.info
Comment 2 Samuli Suominen gentoo-dev 2010-10-13 09:50:58 UTC
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?

Comment 3 Samuli Suominen gentoo-dev 2010-10-13 09:52:06 UTC
Which would make this a duplicate of bug 339858.
Comment 4 Phillip Merensky 2010-10-13 10:03:54 UTC
(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.
Comment 5 Phillip Merensky 2010-10-13 10:07:04 UTC
I also did an Apache server restart, of course.
Comment 6 Phillip Merensky 2010-10-13 10:21:37 UTC
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?
Comment 7 Samuli Suominen gentoo-dev 2010-10-13 12:45:12 UTC
> 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 ->
Comment 8 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2010-10-16 01:22:02 UTC
Please test net-libs/neon-0.29.5.
Comment 9 Phillip Merensky 2010-10-17 20:29:50 UTC
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. 
Comment 10 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2010-10-17 20:33:04 UTC
Only Subversion client uses Neon / Serf. Subversion server doesn't use them.
Comment 11 Phillip Merensky 2010-10-18 20:22:16 UTC
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.





Comment 12 Phillip Merensky 2010-10-20 18:41:28 UTC
Regrettably this issue is  not resolved for me, because tortoise svn for example does not work with the upgraded server (see comment 11)
Comment 13 Phillip Merensky 2010-11-08 15:05:32 UTC
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.
Comment 14 Phillip Merensky 2010-11-08 15:27:45 UTC
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?
Comment 15 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2010-11-08 15:29:43 UTC
Please report the problem to upstream.
Comment 16 Phillip Merensky 2010-11-09 07:11:32 UTC
(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.