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: Thu, 05 Apr 2012 13:53:01 -0000
Message-ID: <20120405135301.82553.65129@eos.apache.org>
Subject: 
 =?utf-8?q?=5BSubversion_Wiki=5D_Update_of_=22AuthenticationCredentialCach?=
 =?utf-8?q?eStorageOverhaul=22_by_CMichaelPilato?=
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 "AuthenticationCredentialCacheStorageOverhaul" page has been changed by=
 CMichaelPilato:
http://wiki.apache.org/subversion/AuthenticationCredentialCacheStorageOverh=
aul?action=3Ddiff&rev1=3D2&rev2=3D3

Comment:
Add info about how we interact with third-party keychain-type providers.

  =3D Authentication Credential Cache Storage Overhaul =3D
  Subversion 1.7 and older uses, primarily, an on-disk storage solution for=
 cached authentication credentials.  Bits of the more private information m=
ay be outsourced for storage to various OS keyring provider mechanisms as (=
see EncryptedPasswordStorage), but certainly the primary storage container =
are the on-disk serialized hash files stored in `${HOME}/.subversion/auth/$=
{PROVIDERTYPE}/${REALMSTRING_MD5}`.  As we look to improve the client authe=
ntication subsystem in the future -- especially when considering major over=
hauls such as the master passphrase in-house encryption feature (see Master=
Passphrase), one area that stands out as in need of attention is the storag=
e of cached authentication credentials.
  =

+ =3D=3D Disk Cache =3D=3D
  Here's an attempt at summarizing what type of information is currently st=
ored on disk for each credential type:
- =

  ||'''Provider Type''' ||'''Subversion Realmstring (Key) Components''' ||'=
''What Else Gets Cached''' ||
  ||svn.username ||repos UUID ||username ||
  ||svn.simple ||server root URL (scheme, hostname, port), realm string ||u=
sername, password ||
- ||svn.ssl.client-cert ||             ||             ||
+ ||svn.ssl.client-cert || || ||
  ||svn.ssl.client-passphrase ||certificate file path ||password ||
- ||svn.ssl.client-passphrase (PKCS#11 PINs) ||static string containing PIN=
 token and slot ||             ||
+ ||svn.ssl.client-passphrase (PKCS#11 PINs) ||static string containing PIN=
 token and slot || ||
  ||svn.ssl.server ||server root URL (scheme, hostname, port) ||ASCII certi=
ficate, bitmask of acceptable failures ||
  =

  Also interesting is that individual RA implementations do not necessarily=
 agree on the realmstring.  ra_neon builds realmstrings for itself to use. =
 ra_serf builds some realmstrings for itself, but offloads some of that wor=
k to Serf (in the most common cases, even).
  =

+ =3D=3D Outsourced Secure Cache =3D=3D
+ =

+ Here's a table describing the keys and values (of sorts) used when storin=
g and retrieving passwords from third-party secure storage providers.
+ ||'''Keyring''' ||'''Keys''' ||'''Values''' ||
+ ||Win32 CryptoAPI ||static description string ||password ||
+ ||MacOS X Keychain ||realmstring, username ||password ||
+ ||Gnome Keyring ||realmstring, username ||password ||
+ ||KDE Wallet ||realmstring, username ||password ||
+ ||GPG Agent ||realmstring ||password ||
+=20