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

Re: Review requested on issue #2410 (SSL client certs option)

From: Mark Phippard <markphip_at_gmail.com>
Date: Sun, 29 Jun 2008 19:18:44 -0400

On Sun, Jun 29, 2008 at 7:14 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> Joe Orton <jorton_at_redhat.com> writes:
>> The current behaviour (svn prompting for a filename when an SSL client
>> cert is requested) is pretty unusual - I don't know why it works like
>> this. I can't think of a common use case where the behaviour is
>> particularly useful, and certainly there are lots where it is actively
>> unhelpful, e.g. as per the referenced bug.
>> If you are using an SSL server which requires client cert auth, you will
>> most likely have configured that beforehand. If you are using it
>> regularly you certainly won't be typing in that filename every commit.
>> If you are using such a server, and you *don't know* that it requires
>> client cert auth, chances are you don't have one.
>> If you're using some global-ish PKI with lots of servers which might
>> require client cert auth, you will have configured that beforehand too.
>> Rather than pushing yet-more config knobs down into ra_* I would suggest
>> adding a config toggle which only adds the prompting provider if a
>> config boolean is enabled (but is off by default). That would solve
>> this bug and make the default behaviour correct to boot.
> I rarely use client certs myself, so I don't have much direct experience
> with our client cert UI, but what you say seems reasonable to me. And
> it's a much simpler solution.
>> Possible problems:
>> 1) this is arguably a backwards compat break, but it's not like this is
>> going to break scripts since it's only removing a case which always
>> requires interactive input.
> Right; it's not a compatibility problem with any practical consequences,
> I think.
>> 2) the default error for the "SSL server requested a client cert but
>> none was provided" is probably an obscure SSL error message; this is the
>> only real value of the current prompt. This could probably be improved.
> Agreed.
>> Thoughts?
> Uhmph. I've attached this thread to the issue. I'd like to make your
> suggested patch, but I've got some (read: twenty) other threads to take
> care of first. So if someone were to beat me to it, that'd be fine.

So in the end, in terms of implementation, what is Joe suggesting? It
sounds like he'd expect anyone using client certs to configure them in
the servers file? And we should just not prompt for a certificate and
instead error out if one is required but not configured?

I am not sure if that is better or worse. What I do think is
important is that Senthil's patch to allow the passphrase for the
client certificate to be cached like we cache passwords. We have a
customer that is eager to get this feature.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-30 01:18:56 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.