The same problem has just manifested when using ubuntu lucid either due to a package update or possibly changes on the server side. I now get the following error when attempting an svn update (svn info works fine). SSL handshake failed: SSL error: A TLS warning alert has been received.
I tried using the LD_PRELOAD=/usr/lib/libneon.so.27 before the command but this resulted in the error message: SSL handshake failed: SSL error code -1/1/336032856 The difference between these being that the first is using a version of libneon build against gnutls whereas the second uses openssl. It seems the error in the first case is down to a problem with libneon which according to the changelog has been fixed in version 0.29-5 (0.29-1 is the current version for lucid). By building my own libneon (using -with-ssl=gnutls to specift gnutls rather than openssl) and subversion has worked. Guess libneon package should be updated to version >= 0.29-5. Nico Kadel-Garcia-2 wrote: > > On Mon, Sep 6, 2010 at 5:40 AM, Bert Huijben <b...@qqmail.nl> wrote: >> >> >>> -----Original Message----- >>> From: Gero [mailto:g...@ieee.org] >>> Sent: maandag 6 september 2010 11:37 >>> To: users@subversion.apache.org >>> Subject: Re: SSL handshake failed: SSL error: A TLS warning alert has >>> been >>> received. >>> >>> On Wed, 2010-08-18 at 02:06 -0400, Nico Kadel-Garcia wrote: >>> On Wed, Aug 11, 2010 at 10:24 AM, Gero <g...@ieee.org> wrote: >>> > > Hi, >>> > > >>> > > After moving to a new system (Kubuntu Hardy -> Lucid) I can no >>> longer access >>> > > an SVN repository: >>> > > >>> > > $ svn update >>> > > svn: OPTIONS of 'https://example.com/path/to/svn/trunk': SSL >>> handshake >>> > > failed: SSL error: A TLS warning alert has been received. >>> > > (https://example.com) >>> > >>> > But 'svn info 'https://example.com/path/to/svn/trunk works? What >>> about >>> > doing a clean checkout to a new location? >>> >>> 'svn info' with no arguments works and shows info about the repository >>> in question. 'svn info <repo>', however, does not work, with the same >>> error message as above. A clean checkout doesn't work either. >>> >>> There is an Ubuntu bug report about Subversion not playing with the >>> latest libneon nor libneon-gnutls. Apparently, libneon now reports more >>> SSL problems that Subversion should ignore, but doesn't. >> >> Subversion uses neon and neon uses your SSL library. Subversion doesn't >> use >> the ssl library directly. >> >> So this should be fixed either in Neon or (to restore compatibility with >> the >> older version) in the SSL library. >> >> Bert > > Really? Why do you think this? > > For RHEL 5, the RPMforge packages actually have to include > compatibility versions of python, neon, and swig. Component drift for > the 4 major and several variant methods of accessing a Subversion > repository is a demonstrable issue: between local file access, > svnserve, HTTP, and the minor variants of HTTPS and ssh+svn, you have > a potential for a lot of subtle version skew in components themselves > and especially in the interfaces to those components. > > It's already awkward with enterprise operating systems, which are very > reluctant to upgrade system components. (See the RHEL 5 comment, and I > went through this with SCO OpenServer 5 myself.) It seems > unsurprising that Ubuntu, that tends to be leading edge, is > encountering version skew issues from the other side. > > -- View this message in context: http://old.nabble.com/SSL-handshake-failed%3A-SSL-error%3A-A-TLS-warning-alert-has-been-received.-tp29409554p32249793.html Sent from the Subversion Users mailing list archive at Nabble.com.