On Mon, Oct 18, 2010 at 3:56 AM, Stephen Connolly
<stephen.alan.connolly_at_gmail.com> wrote:
> Add a capability called "keyringenabled" to Subversion and now Nico
> will probably be much happier... but of course he doesn't trust his
> users so he cannot trust that they report "keyringenabled"
> correctly... but he might be pragmatic enough to accept that as a
> compromise.
Now, now. Don't put words in my mouth. I'm concerned about obvious and
possible and documented attack vectorrs: passwords in cleartext are
one of them. Eventually, any idiot can write a script that stores
passwords in clear-text to mishandle local passwords or passphrase
protected keys, but putting the capability in as the default behavior
is extremely poor practice and should not be supported by default
configuration or behavior.
I don't think that "keyring enabled" is sufficient. A protocol shift
that *requires* a better protected password and blocks the currently
unsecured local password storage access would be interesting, I
thought the gpg-agent changes would do that, but Stefan pointed out
the flaws, dang it.
svn+ssh actually works reasonably well: it just doesn't suppor the
"use my normal login password" approach to managing user access.
> and that's probably a feature we could add in 1.6.14 with only minor
> effort (most of the work being deciding what the feature name should
> be ;-) )
>
> -Stephen
If it could require the client to actually *use* the keyring, I could
see it. How would we support that for TortoiseSVN clients?
Received on 2010-10-19 03:20:18 CEST