Re: [Issue 4145] Master passphrase and encrypted credentials cache

Hi, Michael,

> Von: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> > On 03/22/2012 01:02 PM, Daniel Shahaf wrote:
> >>> Is it now time to review the design doc on the wiki? I've been
> >>> assuming it's WIP as I haven't seen a dev@ mail about this feature.
> >
> >> Review on the design doc is welcome, yes. I started to explicitly
> >> solicit as much, but I found myself in one of those situations where
> >> you feel you can't adequately describe implementation specifics
> >> because you're still picking through the existing code base. I
> >> didn't want to ask folks to review the design only to hear, "Looks
> >> good, but how will it work" with me unable to really answer that
> >> question. So, if/as you read the wiki page, you may find that some
> >> stuff is self-contradictory, unfinished, vague, etc. That's just my
> >> ignorance of the authn codebase showing through.
> >
> > For this to be usable, we'll need some kind of agent which can live
> > longer than individual processes. Otherwise, command line work will be
> > nearly unusable.
>
> I hear ya. Please read the design doc:
> http://wiki.apache.org/subversion/MasterPassphrase

I did, but it seems the statement regarding the agents was not explicit enough for my first try. Now, when reading it again, it works better. :-)

> Folks on Windows and MacOSX can have their master passphrases cached in
> the OS-provided crypto stores. GNOME keyring and KDE kwallets users on
> Unix can get the same.

So the question is whether users of Windows, MacOSX, Gnome Keyring and Kwallet have any usability benefit at all - right now they can already store their "normal" credentials in those storages.

> And with the new GPG-Agent support in 1.8, there's
> that option for medium-term-but-non-permanent caching, too.

Ok, so GPG-Agent just fulfills the role of the agent I requested.

> But even folks who don't have those options available a) won't be forced
> to use the master passphrase construct at all, and b) if they do use it,
> will need only supply a single master passphrase at the command-line. I
> dunno about you, but I'd much rather run 'svn update ~/projects/*' and
> have Subversion prompt me *once* for a master passphrase than what it does
> today, which is prompt me for credentials on each and every working copy
> in that directory, nearly all of which come from different servers with
> different credentials.

Yes, this is correct, it mitigates the problem a little. But most complex shell scripts tend to issue several SVN commands, and such will query the user several times if none of the abovementioned agents is available.

So the question boils down to "will we optionally provide our own agent, or will we simply redirect the users to the existing solutions"?

Is pageant / ssh-agent an additional option? (This might require using asymmetric cryptography...)

Best regards

Markus Schaber

-- 
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915