Old (readonly) SVNKit Issues Tracker, new one is at http://issues.tmatesoft.com/
ATTENTION: You are browsing old (readonly) SVNKit Issues Tracker!
Please find new one at http://issues.tmatesoft.com/
If you have an account here, it should work in the new tracker as well.

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000301SVNKitbugpublic2009-03-17 04:082011-01-25 16:50
Assigned Tooka 
PlatformOSOS Version
Product Version1.2.2 
Target VersionFixed in Version 
Summary0000301: SSL handshaking failure in HTTPConnection results in infinite loop
DescriptionThe request method (to be exact, it's request(String method, String path, HTTPHeader header, InputStream body, int ok1, int ok2, OutputStream dst, DefaultHandler handler, SVNErrorMessage context) throws SVNException) has a big while(true) loop, and inside this loop is a catch block for SSLHandshakeException. I copied the code for your convenience below:

        while(true) {
            try {
            } catch (SSLHandshakeException ssl) {
                myRepository.getDebugLog().logFine(SVNLogType.NETWORK, ssl);
                if (ssl.getCause() instanceof SVNSSLUtil.CertificateNotTrustedException) {
                    SVNErrorManager.cancel(ssl.getCause().getMessage(), SVNLogType.NETWORK);
                SVNErrorMessage sslErr = SVNErrorMessage.create(SVNErrorCode.RA_NOT_AUTHORIZED, "SSL handshake failed: ''{0}''", new Object[] { ssl.getMessage() }, SVNErrorMessage.TYPE_ERROR, ssl);
                    if (keyManager != null) {
                err = SVNErrorMessage.create(SVNErrorCode.RA_DAV_REQUEST_FAILED, ssl);

As you can see, in the end, this code just does "continue", which brings it back to the top of the while loop. Since the catch block doesn't seem to do anything that changes the outcome of the next attempt, it'll cause the same problem landing in the same catch clause, and causes the infinite loop.

And this catch block diligently computes the 'err' variable, which gets thrown away as soon as the next iteration of the while loop starts.

Is this a merge failure or something? The 'continue' statement aeppars out of place.

Or does this code really intend to retry the request? If so, I suggest some measure be added to avoid infinite loop.
TagsNo tags attached.
planned for version
Attached Files

- Relationships

-  Notes
oka (administrator)
2009-03-17 19:24

I think that "continue" intentionally placed there. The reason is that SSLHandshakeException is thrown when server doesn't accept client SSL certificate, so connection should be reopened and request resent with new client certificate, if available. Also, in catch clause HTTPSSLKeyManager.acknowledge..(...) is called which may throw exception.
oka (administrator)
2009-03-17 19:27

Do you get infinite loop without a chance to interrupt it in your ISVNAuthenticationManager implementation which should be asked for client SSL credentials?
kohsuke (viewer)
2009-03-17 19:51

While I could work around the problem with your suggestion. SVNKit behavior is nontheless inconsistent. In all the other authentication modes, such as ISVNAuthenticationManager.SSH or ISVNAuthenticationManager.PASSWORD, the semantics is that SVNKit retries authentications as long as I provide more SVNAuthentication objects from my getNextAuthentication method.

But that is not the case with your suggestion. You are saying that I need to explicitly throw an exception from the acknowledgeAuthentication method to abort the authentication attempt (which none of the built-in ISVNAuthenticationManagers in SVNKit does.)

Moreover, if I'm reading the code correctly, even if my ISVNAuthenticationManager wanted to try multiple SSL client certificate svia getFirst/NextAuthentication methods, HTTPSSLKeyManager doesn't handle the situation correctly. It'll always just call the getFirstAuthentication method, and attempts the authentication with that certificate.

So in conclusion, either SVNKit should acknowledge that SSL client certificates cannot be retried and remove the continue statement (which would avoid the infinite loop), or make a bigger surgery with HTTPSSLKeyManager so that it correctly calls the getNextAuthentication method at the right moment.
oka (administrator)
2009-03-18 20:42

I think just removing "continue" statement is not an option - there should be a way to [re]prompt for client certificate, behavior similar to those of processing HTTP 401 response.

I'm not suggesting to throw exception in acknowledge...(...) method, but rather return "null" in getFirst/NextAuthentication when prompted from SSL credentials (client SSL certificate) - this will cancel authentication and terminate operation with SVNAuthenticationException.

You're right though, that getFirst/Next methods should be called in proper order for SSL credentials, this looks like a bug.
keiw (viewer)
2010-02-27 18:47

The same behavior(an infinite loop) can be reproduced with the DefaultAuthenticationManager implementation in the same situation as http://svnkit.com/tracker/bug_view_advanced_page.php?bug_id=347&history=1 [^]
but in my case - with an attempt to get annotation by SVNLogClient via https.

It looks odd - to get the same exceptional situation (and by the same reasons - SSL handshake failure due to OpenJDK implementation) as in that mentioned bug but no exception is thrown.

How can it be fixed?
tomsontom (viewer)
2010-06-10 11:58
edited on: 2010-06-14 12:47

I think this problem is responsible that SVN-integrations like Subclipse, Subversive, ... are not working anymore. I think the mentioned change from OpenJDK got introduced in to Sun JDK 1.6 Update 20 which is also reflected on the latest Updates of Apples Java implementation.

This makes SVNKit useless on system which typically not use JavaHL (e.g. OS-X users) and is a severe problem.

oka (administrator)
2011-01-25 16:30

Please take a look at http://java.sun.com/javase/javaseforbusiness/docs/TLSReadme.html [^] - setting -sun.security.ssl.allowUnsafeRenegotiation system property to "true" may resolve this problem.
tomsontom (viewer)
2011-01-25 16:50

I can confirm that seeting this property the authentification starts working again

- Issue History
Date Modified Username Field Change
2009-03-17 04:08 kohsuke New Issue
2009-03-17 19:09 oka Status new => assigned
2009-03-17 19:09 oka Assigned To => oka
2009-03-17 19:24 oka Note Added: 0000575
2009-03-17 19:27 oka Note Added: 0000576
2009-03-17 19:51 kohsuke Note Added: 0000577
2009-03-18 20:42 oka Note Added: 0000580
2010-02-27 18:47 keiw Note Added: 0000777
2010-06-10 11:58 tomsontom Note Added: 0000860
2010-06-14 12:47 tomsontom Note Edited: 0000860
2011-01-25 16:30 oka Note Added: 0000903
2011-01-25 16:50 tomsontom Note Added: 0000904

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker