[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: client cert auth provider

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Thu, 09 Jun 2011 21:17:46 +0200

On 09.06.2011 21:11, Philip Martin wrote:
> Stefan Sperling<stsp_at_elego.de> writes:
>
>> On Thu, Jun 09, 2011 at 07:56:47PM +0200, Stefan Küng wrote:
>>> Hi,
>>>
>>> The callback for client certs currently has the following format:
>>> svn_error_t* callback(svn_auth_cred_ssl_client_cert_t **cred, void
>>> *baton, const char * realm, svn_boolean_t /*may_save*/, apr_pool_t
>>> *pool);
>>>
>>> As you can see, the callback expects a path to a file.
>>>
>>> Would it be possible to extend that callback so that not a file but
>>> the *content* of that cert file can be passed back? Maybe with two
>>> more parameters, one the pointer to the data and the second the
>>> length of the data in bytes.
>>>
>>> The reason I would like this extension is that I can get the client
>>> certificates from the Windows cert store, but there I get the
>>> certificates in memory only. So now I have to save that memory cert
>>> first to a file so I can pass it back in the callback.
>>>
>>> Thoughts?
>
> It sounds like a good thing to support.
>
>> The API would need to be rev'd of course so this would be for 1.7 only.
>>
>> Maybe change svn_auth_cred_ssl_client_cert_t to contain an svn_stream_t
>> instead of a file name? That would solve both use cases.
>> TSVN could create a stream to wrap the buffer, and existing callers
>> (and the compat code) would wrap the file in a stream.
>
> Just to be clear: we can't change svn_auth_cred_ssl_client_cert_t, it is
> one of the things that would need to rev'd with a new definition such as
> svn_auth_cred_ssl_client_cert2_t. Then you need to rev the callback,
> etc.

Yes, of course.
I looked at the code a little bit, and it seems that for this to work,
at least neon would have to be patched as well. Because neon expects the
certificate in a file (ne_ssl_clicert_read - haven't found a function
which would do the same as ne_ssl_clicert_read but with data from memory).

So I guess even though I think this would be great to have, it just
won't work for now... :(

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
Received on 2011-06-09 21:18:28 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.