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 Tue, 20 Mar 2012 16:24:34 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=8&rev2=9

Comment:
More implementation thoughts.

   * 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.
+ 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.
+ 
+ ==== The master passphrase challenge ====
+ {{{### TODO ###}}}
+ 
+ ==== Setting/changing the master passphrase ====
+ Subversion will need to provide APIs and tooling (for example, an "svn change-password"
-- or "svn chpasswd" -- subcommand) for managing the master passphrase and encrypted credentials.
+ 
+ If the "use-master-passphrase" runtime configuration is enabled, "svn chpasswd" will challenge
the user for the existing master passphrase (if any).  If the challenge is met successfully,
Subversion will prompt the user for a new passphrase (twice).  Subversion will use the old
passphrase to decrypt any cached, encrypted credentials, and then the new passphrase to re-crypt
those credentials, before replacing the encrypted known text (in {{{~/.subversion/auth/svn.masterpassphrase/info}}})
with its re-encrypted form.
+ 
+ If the "use-master-passphrase" option is not set, "svn chpasswd"'s only utility is to decrypt
existing cache contents back into plaintext.
  
  ==== Consulting the authn cache ====
  When consulting the authn cache files (which employ Subversion's serialized hash format),
the relevant provider(s) will look for a new hash key “crypttext”.  If no such key is
found, Subversion will continue much as it does today, assuming that any password stored in
the authn cache file is plaintext.  If, however, the “crypttext” key and value are found,
any password stored in the file is presumed to be encrypted using the same algorithm and secret
key (the master passphrase, or derived from it) which transformed the known text “Subversion”
into value of the “crypttext” hash member.
@@ -51, +61 @@

  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/
+  * 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.
+  * 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.

Mime
View raw message