svn co on SSL repository fails ("SSL negotiation failed: Secure connection truncated") due to libneon bug

Thank you for taking the time to report this bug and helping to make Ubuntu better. Can't confirm this for Intrepid 32bit using OpenSSL, so it seems that this problem is related to libneon in combination with GnuTLS. Could you please remove libneon27-gnutls (not libneon27!) and try if this makes a change to your problem?

It seems subversion package relies on libneon27-gnutls. It's a build-dep.

What exactly do you want me to test?
Should I compile same subversion version but using package libneon or is it something else?
Please try to be more verbose and I can provide as much info as I can for you.

If I ask to remove libneon27-gnutls (which points to 0.28.2), it removes libsvn1 and also subversion.

I just installed Intrepid one another machine and got same issue.

Regards,

GB

Found the same problem as a Debian bug. This already provides a solution, I hope this works for you too.

This indeed solves the issue, as I already reported.

I had to compile manually the packages, since Intrepid has the minimum version of svn as 1.5.1. I added the Hardy repository to be able to install an older version, it worked... but my commits failed at random times.

From now I'll keep all experiments of this issue on my second machine, since I've been able to reproduce it. When I opened the bug report I was on a newly production server (EC2 instance).

Maybe I can even try to help you out with this fix... a couple of years without touch a single C line of code, but I can surely help. During the week I'll probably find some time to look at libneon's source.

Cheers,

GB

How does this affect git-core? Git does not use neon.

Invalidating bugtask added without any justification.

This issue still persists with new versions of Ubuntu, Kubuntu and Debian.

I couldn't reproduce the same issue with package git-core, but the issue still persists at the top of subversion.
Installing (compiling) an older version of neon fixes the issue.

Please, do not invalidate the task just because someone added another "affected" package without providing further explanation.
It's still persistent on other package != from git-core and I'm able to provide any more information that you want regarding this.

Cheers,

Guilherme Blanco

Guilherme:

Why are you protesting the invalidating of the git-core task when you yourself say you can't reproduce the problem with it? The tasks relating to Subversion and Neon remain open.

Also, could you explain how to reproduce the problem? (e.g. Is there a public server that exhibits the problem?) I'd be interested to understand more about it, but without an ability to reproduce it, there's not much that can be done.

Seems to be a problem with gnutls and TLS 1.1 at least on the site I'm having problems, eg.

gnutls-cli --priority "NORMAL:%COMPAT" dit-subversion.cbs.dk
Resolving 'dit-subversion.cbs.dk'...
Connecting to '130.226.47.44:443'...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GNUTLS ERROR: A TLS packet with unexpected length was received.

# Try with TLS1.1 disabled, ie. try with TLS1.0
gnutls-cli --priority "NORMAL:%COMPAT:-VERS-TLS1.1" dit-subversion.cbs.dk
Resolving 'dit-subversion.cbs.dk'...
Connecting to '130.226.47.44:443'...
 - Certificate type: X.509
 - Got a certificate list of 1 certificates.
....

The sites is a running a Cisco Netscaler for the SSL that does not support TLS 1.1, the version of gnutls being used in Ubuntu defaults to TLS 1.1 and does not try with TLS 1.0 when this fails.

This bug is present in Intrepid, Karmic and Lucid.

I have made a patch for this bug with lib neon27 by disabling TLS 1.1 :

https://bugs.launchpad.net/ubuntu/+source/neon27/+bug/580116