I did it!
I looked at the files hudson.scm.SubversionSCM.xml and
jobs/<jobname>/subversion.credentials. Both of them had, from a previous
repository, an entry that looked like:
<entry>
<string><https://www.example.com/></string>
<hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential>
<userName>username</userName>
<password>YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=</password>
</hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential>
</entry>
and an entry that looked like:
<entry>
<string><https://www.example.com/> Subversion
Repositories</string>
<hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential>
<userName>username</userName>
<password>YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=</password>
</hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential>
</entry>
so I gathered the former was for the *server* and the latter was for the *basic
realm*. Even that wasn't true, this got me to realize that SVNKit would be *
forced* to distinguish between the two: the realm isn't available until
after the security has been negotiated, so if SVNKit is going to supply a
password, it can only use the hostname. Then once the secure connection has
been established, it will try to look up credentials in this map using the
host and realm name. So I ginned up two entries: one with the certificate
authentication and *only* the hostname, and another with password
authentication and the host *and *realm names, just like above (only using
certificate authentication for the first example). So far, crossing my
fingers and toes, this seems to work!
On Wednesday, May 2, 2012 10:41:14 AM UTC-7, Dustin Parker wrote:
>
> 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.
>>
>>
