[Subversion Wiki] Update of "EncryptedPasswordStorage" by CMichaelPilato

[Apache subversion Wiki <co...@subversion.apache.org>]

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=16&rev2=17

Comment:
I've moved discussion of the master passphrase feature to its own page.

  
  == Improvements We Could Explore ==
  === 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.
+ Subversion could employ built-in encryption protected by a [[MasterPassphrase|master passphrase]].
  
- {{{#!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.
- }}}
  === Per-site Password Caching Options ===
  Using the web browsers again as an example, Subversion could ask before storing any not-currently-cached user-provided credentials and look for one of the following three responses:  "yes", "no", or "never".  A response of "never" is recorded by using a special "passtype" record value ("nocache" or somesuch) in the auth/ runtime configuration area, and can be used in the future to avoid prompting the user about caching for that particular realmstring.