subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <>
Subject [Subversion Wiki] Update of "EncryptedPasswordStorage" by CMichaelPilato
Date Thu, 05 Jan 2012 19:16:20 GMT
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:

Add a block about how Firefox handles this stuff, and what we might take from it.

  == Concerns/Complaints ==
  Subversion today doesn't force users to employ an encrypted storage mechanism for cached
credentials.  It will at least prompt users before caching a password in plaintext, but if
the answer is "no", then generally no caching happens at all.  There are a number of runtime
configuration gyrations which users can make to toggle related behaviors:  which keychain
services to attempt to use, whether passwords should be stored in plaintext or not ... or
at all, etc.  But enterprise Subversion administrators are looking for something more turn-key.
 Ideally, the decision to store passwords in plaintext should be taken out of the users' hands
altogether (such as is the case in Windows and Mac OS X), but at what cost?  At the cost of
not caching credentials at all?  At the cost of requiring custom-built Unix Subversion client
binaries with hard-coded encryption key "magic"?  At the cost of a hard requirement on one
of the third-party crypto keychain providers?
+ == Suggestions From Other Software ==
+ === Firefox ===
+ 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:
+ 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 as often as they
would their repository credentials (which renders credential caching rather pointless).  This
approach would only be useful if there was a way to securely persist the master password across
command-line client invocations.

View raw message