On Mon, Oct 18, 2010 at 3:56 AM, Stephen Connolly <stephen.alan.conno...@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?
