You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by Apache subversion Wiki <co...@subversion.apache.org> on 2012/02/14 18:06:33 UTC
[Subversion Wiki] Update of "EncryptedPasswordStorage" by CMichaelPilato
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "EncryptedPasswordStorage" page has been changed by CMichaelPilato:
http://wiki.apache.org/subversion/EncryptedPasswordStorage?action=diff&rev1=15&rev2=16
Comment:
There *is* actually value in the master password concept, even where it must be provided per-invocation.
=== Built-in Encryption with a Master Passphrase ===
Like all popular web browsers, Firefox allows you to optionally cache passwords used for site logins. Site credentials are cached on disk, and in plaintext by default. However, Firefox allows you to optionally configure a "Master Password". This password is used to encrypt the on-disk cached site credentials, functioning effectively the same way that a keyring provider and associated passphrase would work. Firefox will challenge the user for the master password the first time it needs to consult its credentials cache, and will leave the cache "unlocked" for the duration of the application's lifetime. (Reference: http://luxsci.com/blog/master-password-encryption-in-firefox-and-thunderbird.html)
+ Subversion should be able to do something similar. Now, the short-lived nature of the command-line client means that if naively implemented, a user would need to provide the master password (or passphrase) as often as they would their repository credentials today were caching not available. This would render the credential cache itself useful only insomuch as it reduces the potentially boundless amount of site credentials the user must memorize to a single item: the master password. The overall approach would be much more convenient if there was a way to securely persist the master passphrase across command-line client invocations for at least some period of time, perhaps by using a daemon-based persistence layer (for example, the GPG Agent) to hold the user-provided master passphrase in memory.
- In theory, Subversion could do something similar, but the short-lived nature of the command-line client means that a user would typically need to provide the master password (or passphrase) as often as they would their repository credentials, rendering the credential cache rather pointless. This approach would only be useful if there was a way to securely persist the master passphrase across command-line client invocations for at least some period of time.
-
- One way to do so would be to use a daemon-based persistence layer (for example, the GPG Agent) to hold the user-provided master passphrase in memory.
{{{#!wiki warning
Implementation of built-in encryption mechanisms tied to a "master password" secret key might possibly complicate Subversion's distribution per the export control restrictions placed on such technologies. We need to understand and carefully consider the scope of that complication.