C. Michael Pilato wrote on Mon, Mar 26, 2012 at 09:00:19 -0400:
> On 03/25/2012 12:48 PM, Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Fri, Mar 23, 2012 at 12:21:20 -0400:
> >> 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
> >
> > What will the on-disk cache contain? Will it contain the
> > username/password credentials encrypted via the master password somehow?
>
> The on-disk cache will contain everything it does today where plaintext
> caching is enabled, save that the password won't be plaintext, and there
> will be a bit of known encrypted text (for passphrase validation).
>
> I was planning only to encrypt the password because that's the level of
> protection offered by the existing keyring integrations. However, if folks
> think the username should be encrypted too, that's cool (and should be a
> trivial change).
>
How would you implement encryption? We don't currently have encryption
code in the core.
> > Conversely -- suppose I know the master password, and I have read access
> > to the .subversion/auth/ directory. What is the process for me to
> > obtain the cache password in cleartext, to authenticate to the server
> > with?
>
> I thought some about this earlier. I know that I certainly make use of
> Firefox's "Show Passwords" feature on occasion, so I'd like Subversion to
> offer the same. Not sure about the details (UI, etc.) on this one, but I
> would also consider this a secondary feature not strictly required.
> Thoughts? Suggestions?
Perhaps it belongs in a tools/ utility.
Received on 2012-03-26 15:09:54 CEST