On Tue, Jul 15, 2008 at 4:36 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
>>> + /* Don't store passphrase in any form if the user has told
>>> + us not to do so. */
>>> + if (! dont_store_passphrase)
>>> + {
>>> + svn_boolean_t may_save_passphrase = FALSE;
>>> +
>>> + /* If the passphrase is going to be stored encrypted, go right
>>> + ahead and store it to disk. Else determine whether saving
>>> + in plaintext is OK. */
>>> + if (strcmp(passtype, SVN_AUTH__GNOME_KEYRING_PASSWORD_TYPE) == 0)
>>> + {
>>
>> Why do we special-case gnome here? In simple_providers.c we have four
>> providers listed here:
>>
>> /* If the password is going to be stored encrypted, go right
>> * ahead and store it to disk. Else determine whether saving
>> * in plaintext is OK. */
>> if (strcmp(passtype, SVN_AUTH__WINCRYPT_PASSWORD_TYPE) == 0
>> || strcmp(passtype, SVN_AUTH__KEYCHAIN_PASSWORD_TYPE) == 0
>> || strcmp(passtype, SVN_AUTH__KWALLET_PASSWORD_TYPE) == 0
>> || strcmp(passtype, SVN_AUTH__GNOME_KEYRING_PASSWORD_TYPE) == 0)
>>
>> And, indeed, this function and the simple_providers.c functions (e.g.
>> svn_auth__simple_save_creds_helper) seem very similar, almost duplicates
>> of each other. (I said that on IRC, but repeating here for completion.)
>
> Thanks. Yes, as I mentioned in my mail (sent just a few moments ago,
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=141076),
> there's a lot of opportunity for abstraction/unification here.
>
> I assumed there was some difference between a password and a client-cert
> passphrase -- like: Gnome Keyring has some way of string the latter,
> whereas perhaps other systems don't, or have to do it by overloading
> their regular password-storage mechanism, which results in some kind of
> UI weirdness?
>
> But I don't know for sure. I have this sneaking memory that Senthil
> actually antcipated this question and told me the reason, too, but I
> can't remember it now. Senthil?
I think it was just that Senthil did not want to add any providers
without personally testing them. So he wanted to get the base code
and one provider committed, so he can move on to adding the other
providers. Which means setting up Windows, and OSX build systems. Of
course, it should now also be possible for others to pitch in and add
the other options.
Likewise, I think will eventually need someone to add the necessary
support into JavaHL (SVNClient.cpp). Should be a copy and paste from
cmdline.c.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-15 22:46:59 CEST