[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: Senthil Kumaran S <senthil_at_collab.net>
Date: Mon, 30 Jun 2008 10:09:47 +0530

Senthil Kumaran S wrote:
> Karl Fogel wrote:
>> * When we prompt the user for a client cert passphrase, do *not*
>> automagically store that passphrase in ~/.subversion/servers
>> (because it's bad to automagically store passphrases).
>> Instead, present a prompt like the one we do for regular plaintext
>> passwords, wherein we ask they user if they want to store it, and
>> also tell them what to set to avoid being asked in the future (a
>> new boolean that says whether or not to store client cert
>> passphrases after they've been read from prompt).
> The patch attached here
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=140222 for
> issue #2849 handles this. If there is no gnome-keyring mechanism, the
> user is prompted for storing plaintext passphrases as we do for storing
> plaintext passwords. There is also a boolean type already coded in that
> patch which decides whether or not to store client cert passphrases
> after they've been read from the prompt. Yet I need to receive a +1
> (long awaited patch, more than 2 months now) from some full committer to
> get this patch into trunk which will enable me to resume work on Windows
> CryptAPI, Keychain, Kwallet, etc :(

The complete patch with all the modifications as a result of review from
arfrever and stsp is given as attachment here

NOTE: The previous thread I ve mentioned includes the patch inline to my reply,
which may be difficult for people who wants to review the patch, to cut and
paste it in their working copy.

Senthil Kumaran S
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 06:40: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.