Senthil Kumaran S wrote:
> Mark Phippard wrote:
>> On Fri, May 9, 2008 at 8:29 PM, Branko Čibej <brane_at_xbc.nu> wrote:
>>> Mark Phippard wrote:
>>>> Why would you object to
>>>> moving this into our password storage area, which on Windows and OSX
>>>> is very secure?
>>> Tut, tut. Read the patch again. It doesn't try to integrate with the
>>> Keychain/CryptAPI stores -- likely because they're too specific to the
>>> password rather than passphrase workflow.
>> Thank you! Finally, someone has identified the disconnect here. I
>> agree if it is storing plain text passphrase this has a lot less
>> value. When I asked Senthil to work on this patch, the whole point
>> was to leverage this encryption. So it sounds like we need to go back
>> and look at this more. That must have also been the API suggestion
>> you made in your initial comment.
> Yes this patch does not use the crypto facilities available right now,
> which I have mentioned in my original patch email. But the plan is to
> get the passphrase into the auth area first, then we can make the
> providers of this passphrase to use the wincrypt, keychain, etc.,
> available. But coming up with a crypto provider as Branko suggested
> would make life easy when we have some other auth mechanism in future
> to store or cache passwords/passphrases.
I agree with Joe in this respect: it's totally useless to store
plain-text passphrases in the auth area, since that's essentially a
"feature" that we already have.
>> Before we do that, it would be good to get acknowledgment from Joe and
>> anyone else that was against this patch to see if they would be in
>> favor of it if it was using our crypto facilities to store the
> Yes, would like to hear from other developers, before we proceed. As
> Mark has said currently we allow to specify the passphrase in
> plaintext in servers file (which is bad), to start simple it could be
> moved to auth area.
IMHO we should only use the new cert-passphrase provider if it uses a
secure store. If that means we currently can't use it at all on Linux --
so be it. As for the servers file -- we can't remove that feature, but
we can very loudly deprecate it.
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-12 11:02:08 CEST