Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "MasterPassphrase" page has been changed by CMichaelPilato: http://wiki.apache.org/subversion/MasterPassphrase New page: = Master Passphrase Support = Like all popular web browsers, [[http://www.mozilla.org/en-US/firefox/fx/|Mozilla 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 (or passphrase) 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, allowing users to optionally employ a master passphrase which is used to encrypt and decrypt other sensitive information stored in its [[EncryptedPasswordStorage|authentication credential cache(s)]]. Long-lived Subversion GUI clients could query the user for his or her master passphrase the first time the local credential cache is consulted, and remember that passphrase for the lifetime of the application, just like Firefox does. But what about the relatively short-lived command-client? Obviously, if naively implemented, a user would need to provide the master passphrase as often as they would their actual repository credentials if caching was not available at all. This would render the credential cache useful only insomuch as it reduces the potentially boundless amount of site credentials the user must memorize to a single item: the master password itself. Fortunately, both the command-line client and GUI clients can benefit from existing integrations with encrypted stores on the various operating systems. On Windows, command-line clients and GUI clients alike needn't query for the master passphrase once that passphrase itself has been cached using Windows Cryptographic Services. Similar is true on Mac OS X using the Keychain. Essentially, any existing keystore integration which today can be used to store a bunch of passwords could instead be used to store just a single master passphrase. == Benefits == * Centralization: Rather than spread repository credentials cross a variety of stores (on-disk, keystores, etc.), we return to a single, easy-to-manage storage solution: the on-disk store in ~/.subversion/auth/ * Portability: ~/.subversion/auth/ is portable across computers, allowing users to transfer what could be hundreds of different sets of stored repository credentials to other machines with ease. So long as they employed the same master passphrase on those other machines, or did a one-time passphrase change, they would be able to make use of previously cached credentials. == Concerns == * Implementation of built-in encryption mechanisms tied to a "master passphrase" 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. * Is the Subversion codebase -- and the authn subsystem specifically -- capable of handling this sort of approach? (Research continues.)
