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

Re: [PATCH] Cache ssl client certificate passphrases

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 8 May 2008 10:19:27 -0400

On Thu, May 8, 2008 at 9:57 AM, Joe Orton <jorton_at_redhat.com> wrote:
> On Thu, May 08, 2008 at 02:06:48PM +0530, Senthil Kumaran S wrote:
> > I am attaching a patch along with this email which adds support for caching
> > ssl client certificate passphrases in the subverison config auth area (just
> > like how we cache our passwords).
> >
> > Already there is an option (ssl-client-cert-password) to specify the
> > passphrase in the servers file (which could be deprecated with this). But
> > yet it will be better if we can cache this passphrase instead of specifying
> > it in the servers file, which will help us in extending this to use the
> > features of wincrypt, keyring, etc in future.
> I think this is a bad idea. The only reason to store a client cert in
> encrypted form is to prevent anybody who can get a filesystem
> dump/backup from using it. If you want to store the passphrase on disk,
> it's implicit that you don't care about that threat model - so just
> store the client cert on disk in unencrypted form, and you'll never have
> to enter a passphrase. (Yes, I think ssl-client-cert-password is a bad
> idea too, FWIW)

I think a certificate passphrase is not all that different from a
password provided to a basic response challenge. Given that every
Subversion command is a new session and a passphrase has to be entered
every time, people are going to want to cache them. And it does not
make sense to store these in plain-text when we have the ability to
encrypt them.

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-05-08 16:19:39 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.