Mailing-List: contact commits-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@subversion.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache subversion Wiki <commits@subversion.apache.org>
To: Apache subversion Wiki <commits@subversion.apache.org>
Date: Tue, 20 Mar 2012 16:24:34 -0000
Message-ID: <20120320162434.74595.70617@eos.apache.org>
Subject: 
 =?utf-8?q?=5BSubversion_Wiki=5D_Update_of_=22MasterPassphrase=22_by_CMich?=
 =?utf-8?q?aelPilato?=
Auto-Submitted: auto-generated

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" fo=
r change notification.

The "MasterPassphrase" page has been changed by CMichaelPilato:
http://wiki.apache.org/subversion/MasterPassphrase?action=3Ddiff&rev1=3D8&r=
ev2=3D9

Comment:
More implementation thoughts.

   * Where do we store the known string?  As a field value in the serialize=
d hash file?
  =

  =3D=3D=3D The logic, conversationally =3D=3D=3D
- Today, the authn subsystem walks a virtual table of "providers", each of =
which can answer questions about a certain type of credential (simple usern=
ame/password, username only, client certificates, etc.) using a certain mec=
hanism (prompting the user, looking into the authn disk cache, consulting a=
n OS keyring, etc.).  See =E2=80=9CAN OVERVIEW=E2=80=9D in subversion/libsv=
n_subr/auth.c (http://svn.apache.org/viewvc/subversion/trunk/subversion/lib=
svn_subr/auth.c?view=3Dmarkup#l38) for details.  These next sections descri=
bed how Subversion would do the things it does today with the master passph=
rase construct in place.  This document assumes that the long-lived basic c=
onstructs of Subversion's authn subsystem are unchanged except where descri=
bed herein.
+ Today, the authn subsystem walks a virtual table of "providers", each of =
which can answer questions about a certain type of credential (simple usern=
ame/password, username only, client certificates, etc.) using a certain mec=
hanism (prompting the user, looking into the authn disk cache, consulting a=
n OS keyring, etc.).  See =E2=80=9CAN OVERVIEW=E2=80=9D in {{{subversion/li=
bsvn_subr/auth.c}}} (http://svn.apache.org/viewvc/subversion/trunk/subversi=
on/libsvn_subr/auth.c?view=3Dmarkup#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 b=
asic constructs of Subversion's authn subsystem are unchanged except where =
described herein.
+ =

+ =3D=3D=3D=3D The master passphrase challenge =3D=3D=3D=3D
+ {{{### TODO ###}}}
+ =

+ =3D=3D=3D=3D Setting/changing the master passphrase =3D=3D=3D=3D
+ Subversion will need to provide APIs and tooling (for example, an "svn ch=
ange-password" -- or "svn chpasswd" -- subcommand) for managing the master =
passphrase and encrypted credentials.
+ =

+ If the "use-master-passphrase" runtime configuration is enabled, "svn chp=
asswd" 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 decry=
pt any cached, encrypted credentials, and then the new passphrase to re-cry=
pt those credentials, before replacing the encrypted known text (in {{{~/.s=
ubversion/auth/svn.masterpassphrase/info}}}) with its re-encrypted form.
+ =

+ If the "use-master-passphrase" option is not set, "svn chpasswd"'s only u=
tility is to decrypt existing cache contents back into plaintext.
  =

  =3D=3D=3D=3D Consulting the authn cache =3D=3D=3D=3D
  When consulting the authn cache files (which employ Subversion's serializ=
ed hash format), the relevant provider(s) will look for a new hash key =E2=
=80=9Ccrypttext=E2=80=9D.  If no such key is found, Subversion will continu=
e much as it does today, assuming that any password stored in the authn cac=
he file is plaintext.  If, however, the =E2=80=9Ccrypttext=E2=80=9D key and=
 value are found, any password stored in the file is presumed to be encrypt=
ed using the same algorithm and secret key (the master passphrase, or deriv=
ed from it) which transformed the known text =E2=80=9CSubversion=E2=80=9D i=
nto value of the =E2=80=9Ccrypttext=E2=80=9D 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 =E2=80=9Csave_cre=
dentials=E2=80=9D callback of the file-based cache provider will fail and t=
he next provider in the chain will be given the opportunity to save the cre=
dentials.
  =

  =3D=3D Benefits =3D=3D
-  * Centralization:  Rather than spread repository credentials cross a var=
iety of stores (on-disk, keystores, etc.), we return to a single, easy-to-m=
anage storage solution:  the on-disk store in ~/.subversion/auth/
+  * Centralization:  Rather than spread repository credentials cross a var=
iety of stores (on-disk, keystores, etc.), we return to a single, easy-to-m=
anage storage solution:  the on-disk store in {{{~/.subversion/auth/}}}
-  * Portability:  ~/.subversion/auth/ is portable across computers, allowi=
ng users to transfer what could be hundreds of different sets of stored rep=
ository credentials to other machines with ease.  So long as they employed =
the same master passphrase on those other machines, or did a one-time passp=
hrase change, they would be able to make use of previously cached credentia=
ls.
+  * Portability:  {{{~/.subversion/auth/}}} is portable across computers, =
allowing users to transfer what could be hundreds of different sets of stor=
ed repository credentials to other machines with ease.  So long as they emp=
loyed 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 cre=
dentials.
  =

  =3D=3D Concerns =3D=3D
   * Implementation of built-in encryption mechanisms tied to a "master pas=
sphrase" secret key might possibly complicate Subversion's distribution per=
 the export control restrictions placed on such technologies. We need to un=
derstand and carefully consider the scope of that complication.