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/
