This issue (JENKINS-3912) is currently stalling our development effort, too. I'm trying a variety of things to work around the issue. The frustrating thing is that jsvn from the command line *works*, so the SVN plugin is taking this functioning library and *breaking* it somehow.
On Wednesday, July 13, 2011 5:40:50 AM UTC-7, michaelw wrote: > > Has this been resolved? Sorry to bring up such an old post but I have the > same problem. > > The scenario is as follows: > > 1. SSL is configured on our apache server to require a client certificate - > right at the front so you can't access any of the content if you don't have > the client certificate. > 2. The svn server is thus sitting behind the apache server - we thus use > https to reach our svn server. > 3. The svn server then has its own username/password resolution facilities, > this is to do thing like permissions on svn folders etc. > > I can't get Jenkins to checkout my code. > > When I select the username/password option I get the following exception > > <wrapping exceptions removed> > > Caused by: java.lang.NullPointerException > at > org.apache.commons.io.FileUtils.openInputStream(FileUtils.java:129) > at > org.apache.commons.io.FileUtils.readFileToByteArray(FileUtils.java:1135) > at > > hudson.scm.SubversionSCM$DescriptorImpl$SslClientCertificateCredential.<init>(SubversionSCM.java:1494) > at > > hudson.scm.UserProvidedCredential$AuthenticationManagerImpl.getFirstAuthentication(UserProvidedCredential.java:205) > at > > org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initialize(HTTPSSLKeyManager.java:319) > at > > org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initializeNoException(HTTPSSLKeyManager.java:301) > at > > org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.chooseClientAlias(HTTPSSLKeyManager.java:196) > at > sun.security.ssl.AbstractWrapper.chooseClientAlias(SSLContextImpl.java:282) > at > > sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:629) > at > sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:228) > at sun.security.ssl.Handshaker.processLoop(Handshaker.java:610) > at sun.security.ssl.Handshaker.process_record(Handshaker.java:546) > at > sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:913) > at > > sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1158) > at > sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:652) > at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:78) > at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > at > java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > at > > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.sendData(HTTPConnection.java:229) > at > > org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:166) > at > > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:364) > ... 59 more > > Almost as if it is looking for a client certificate file but as one isn't > set, it cannot find one. > > Then if I try the other option - client certificate I get: > > Attempting an SSL client certificate authentcation > Passing user name null and password you entered > Failed to authenticate: org.tmatesoft.svn.core.SVNErrorMessage: svn: > OPTIONS > of /OldMutual/sandbox/trunk/maven/parent: 401 Authorization Required > (https://svn.afrozaar.com) > > So it looks like it is getting passed the https level but being locked out > by the svn authentication. > > The interesting thing about this scenario is that the log says "Passing > username null and password you entered" - almost as if if the password was > set, it would work. > > The .subversion config is configured correctly - so I'm not sure if it is > reading this. > > -- > View this message in context: > http://jenkins.361315.n4.nabble.com/authenticating-with-certificates-username-password-tp373150p3664923.html > Sent from the Jenkins users mailing list archive at Nabble.com. > >
