subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "MasterPassphrase" by CMichaelPilato
Date Fri, 16 Mar 2012 18:32:40 GMT
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?action=diff&rev1=5&rev2=6

Comment:
Identify a problem with my proposed approach.  Corrections to account for it to follow.

   * How do we handle an accurately provided master password that fails to decrypt some cached
data?  Toss the data out?  Leave it as-is?
   * Where do we store the known string?  As a field value in the serialized hash file?
  
- 
- 
  === The logic, conversationally ===
  Today, the authn subsystem walks a virtual table of "providers", each of which can answer
questions about a certain type of credential (simple username/password, username only, client
certificates, etc.) using a certain mechanism (prompting the user, looking into the authn
disk cache, consulting an OS keyring, etc.).  See “AN OVERVIEW” in subversion/libsvn_subr/auth.c
(http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/auth.c?view=markup#l38)
for details.  These next sections described how Subversion would do the things it does today
with the master passphrase construct in place.  This document assumes that the long-lived
basic constructs of Subversion's authn subsystem are unchanged except where described herein.
  
@@ -45, +43 @@

  When encryption is in use, Subversion will need to acquire the master passphrase by consulting
the chain of providers registered for a new “svn.masterpassphrase” authn type (one of
which is empowered to prompt the user for the master passphrase).  Upon receiving the master
passphrase, that passphrase will be used to decrypt the “crypttext” hash member as a self-check
of the passphrase's validity; a valid passphrase can then be used to decrypt the cached password
in that authn file, and from there processing resumes as if no encryption was present at all.
 Failure to acquire a valid master passphrase means that the file-based authn provider is
unable to supply credentials to the caller who requested them.
  
  ==== Updating the authn cache ====
- When caching credentials, Subversion will check the runtime configuration to determine if
encryption should be used.  If not, no change in behavior is necessary.  If, however, the
user has indicated that a master passphrase should be used, Subversion will once again work
to obtain that passphrase, consulting its in-memory cache for a successfully applied passphrase
gathered in the “Consulting the authn cache” phase, then working again through the “svn.masterpassphrase”
providers until a valid passphrase is found.  That passphrase will be used to encrypt the
credentials when storing them on disk.  If no valid master passphrase is obtained, the “save_credentials”
callback of the file-based cache provider will fail and the next provider in the chain will
be given the opportunity to save the credentials.
+ When caching credentials, Subversion will check the runtime configuration to determine if
encryption should be used.  If not, no change in behavior is necessary.  If, however, the
user has indicated that a master passphrase should be used, Subversion will once again work
to obtain that passphrase, consulting its in-memory cache for a successfully applied passphrase
gathered in the “Consulting the authn cache” phase, then working again through the “svn.masterpassphrase”
providers until a valid passphrase is found.
+ 
+ {{{#!wiki warning
+ Uh-oh!  If this is the first time this set of credentials is being cached, with what known-text
will Subversion compare the obtained master passphrase to validate it?  Looks like the known-text
needs to live instead in a provider- and realmstring-independent location.
+ }}}
+ That passphrase will be used to encrypt the credentials when storing them on disk.  If no
valid master passphrase is obtained, the “save_credentials” callback of the file-based
cache provider will fail and the next provider in the chain will be given the opportunity
to save the credentials.
  
  == 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/

Mime
View raw message