On 03/23/2012 11:59 AM, Markus Schaber wrote:
>> 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.
> :-)
That's certainly a fair criticism. :-)
>> 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.
The user benefit will be minimal for those folks who currently experience
encrypted storage with no prompting at all from Subversion -- probably
limited to solely the fact that their on-disk credential caches will now be
self-contained and able to moved from machine to machine (so long as they
use the same master passphrase on all those machines). Fortunately, these
folks will lose nothing by way of benefits, too.
But the benefits to the developers will be noticeable. Currently, the use
of the various "outsourced" providers is a mess. Every time we want to add
a new provider, we have to add flavors of it for all the various keyrings
and such. With the master passphrase paradigm in place, the on-disk cache
is *the sole cache* for Subversion credentials, and the keyrings have but a
single, shared, simple task: store the master passphrase securely. This
may not sound like a big deal, but if you were reading the authn code, you'd
breathe a sigh of relief.
>> 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.
Yes, but that situation is the case today. I am to make no backward steps
here. :-)
> So the question boils down to "will we optionally provide our own agent,
> or will we simply redirect the users to the existing solutions"?
I do not aim to provide our own agent because we are not security experts.
We do version control.
However, with the changes I specified above, if someone came along later to
do exactly that, they'd have a significantly easier job of it. :-)
> Is pageant / ssh-agent an additional option? (This might require using
> asymmetric cryptography...)
Can't tell ya. At the moment, that's outside the scope of my interest.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2012-03-23 17:22:00 CET