"Mark Phippard" <markphip_at_gmail.com> writes:
>> It is true that from the user's point of view, the passphrase is just
>> another password. But the user-visible behavior would be the same
>> whether the passphrase or the cert were stored unencrypted: namely, that
>> the user wouldn't get prompted for the passphrase.
>
> I must be missing something because I do not see how this is any
> better. It would still rely on physical security otherwise someone
> could just grab your unencrypted cert and use it to impersonate you.
>
> I do not follow the logic for treating this different from any other
> password. In the current code someone using client certs has to enter
> a passphrase for every command. In a GUI like TortoiseSVN, if they
> want to browse a repository they have to enter it everytime they
> expand a folder. So now they want to cache the passphrase but have to
> enter it in plaintext and rely on physical security to protect it. On
> Windows and OSX we have a much better way to do this, and if any of
> these branches work out maybe we will soon have it on Unix too. What
> would be the reason to not want this feature?
Well, I feel like I'm sort of making Joe's argument for him, so I might
not make it as well as he would, but:
I think the point is that what the user wants is not to have to type the
passphrase. Which is different from "wants to cache the passphrase".
Caching is an implementation detail: the user would be just as happy if
Subversion used magical telepathic powers to read the passphrase from
the user's brain each time. All the user cares about is "I don't want
to type that thing."
Joe is asking why we would bother add an extra level of indirection. If
we're going to store something in plaintext on disk, let it be the
actual cert. The user-visible behavior will be exactly the same, and
we'll have removed a useless (for our purposes) middle layer.
One possible objection to Joe's point is: external mechanisms for
caching passphrases may not work so well for certs. Since we want to
integrate with those mechanisms, we too should be passphrase-oriented.
On the other hand, a point in Joe's favor is that sometimes a user may
change the passphrase without changing the cert. For example, if their
passphrase gets compromised by being accidentally displayed on screen
while someone was watching over their shoulder, the user may change the
passphrase immediately afterwards. But that's no reason to force a
reprompt in Subversion ever -- if we have the cert itself, everything
will still work, so why even care about the passphrase? Or maybe that's
an argument against: if we cache the passphrase, instead of the cert,
then the user gets an opportunity to invalidate the cache by changing
the passphrase, which can be handy!
I dunno. I'm not sure I'm contributing much to the discussion, and I
don't know which answer is right; possibly they're both right. I just
wanted to make sure Joe's point got understood.
A passphrase that decrypts local data is somewhat different from a
passphrase that authenticates you to a remote server. After you use the
former, you get a new object that (in theory) you can save and not
bother with the passphrase anymore. But in the latter case, you need to
provide the passphrase every time. I'm using "passphrase" and
"password" synonymously here, of course.
---------------------------------------------------------------------
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-09 00:03:48 CEST