[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: Karl Fogel <kfogel_at_red-bean.com>
Date: Sun, 29 Jun 2008 21:58:51 -0400

"Mark Phippard" <markphip_at_gmail.com> writes:
> On Sun, Jun 29, 2008 at 9:23 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
>> "Mark Phippard" <markphip_at_gmail.com> writes:
>>> So then how does the client find a cert in the default location? I
>>> thought what Joe was saying is that anyone that needs to use a client
>>> cert knows they have to configure it in some way.
>> I don't know how client certs get into the default location now, but
>> whatever way they do, that isn't affected by the proposed change. Joe
>> is merely saying that if the client does *not* find the cert there, that
>> (by default) we shouldn't prompt for some other path.
>> He also suggests that we improve the couldn't-find-it error to give some
>> more information about where to put certs, and (I assume) to mention the
>> new config option in case the user would like to be prompted.
> Well that is kind of what I am getting at. He seems to be proposing
> we replace our code with new code that finds certs somewhere. I am
> asking for the details. It could be relevant to caching the
> passphrases if the thing that stores the certificates also secures
> them.

Oh. I thought we already had code that looks for client certs in some
default location (under ~/.subversion/, presumably), and that the
prompting only happens if the client doesn't find any in that default

If that's not the case, then I don't understand how client certs could
work at all without prompting (but I also don't understand how they
could possibly ever have been useful, since that would imply that
everyone gets prompted every time).

> The issue is: http://subversion.tigris.org/issues/show_bug.cgi?id=2489
> Thread with patch:
> [...]

Thread added, and issues linked. Thanks.

> Not sure which message has the most recent patch. An issue that
> Senthil is dealing with is that he has to write the code for each
> place we can cache these (Gnome-keyring, KWallet, Windows crypt, OSX
> keychain) separately. Apparently, our current password encryption is
> not architected in a way that it can be reused. Perhaps after the
> patch is done, this can be modified so they can share common code?

Sounds sane; noted in issue #2489.

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 03:59:44 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.