On Sun, Feb 28, 2021 at 10:51 AM Daniel Sahlberg
<daniel.l.sahlb...@gmail.com> wrote:
> When researching, I discovered that reading plain text passwords that are
> "grandfathered in" works the same way on Windows as on Unix. If the password
> is invalid it is switched to passtype==wincrypt when updated.
Thanks for documenting that!
> I have taken Nathan's suggestion and rearranged it slightly, trying to
> incorporate Danielsh' feedback. I have made notes as HTML comments: <!-- ...
> --> - these should be removed from the final commit.
Thanks also for improving the FAQ text. This is a big improvement over
the text I proposed earlier. I only have a few minor nits to pick,
mostly on things I wrote... I'll respond inline below, and below that
for convenience I'll give the text with my proposed minor changes
applied...
> [[[
> <div class="h3" id="plaintext-passwords">
> <h3>How does Subversion cache credentials (plain text and encrypted)?
> <!-- The other FAQ entries are questions and there are discussions of
> encrypted password stores in addition to the plain text store -->
> <a class="sectionlink" href="#plaintext-passwords"
> title="Link to this section">¶</a>
> </h3>
>
> <p>To avoid having to type a password for each server operation, Subversion
> can cache credentials.</p>
>
> <p>Passwords may have been cached unencrypted by older versions of Subversion
> ("grandfathered in") and Subversion always supports reading these. Whether and
> how Subversion caches new credentials depends on several factors, including
> the
> access method, operating system, compile-time options, and settings in the
> client's run-time config file.</p>
> <!-- Moved the first sentence (grandfathered passwords) here from the Unix
> section. Added 'access methods' to somewhat cater for Danielsh's comment
> regarding SSH password prompts / keys / client certs. I'm leaving the
> question open if we should mention what is not covered in the answer. -->
>
> <!-- Removed the <p/> and <ul/> about what we try to answer -->
>
> <p>To show the credentials in your cache, use <tt>svn auth</tt>. Credentials
> are never removed automatically but Credentials may be removed manually using
In the above sentence, should the last mention of "Credentials" be
removed?
> <tt>svn auth --remove</tt>.</p>
> <!-- Added info on how to review the cache and remove credentials. This should
> address part of Danielsh's #6 -->
>
> <h4>Windows</h4>
>
> <p>On Windows, Subversion uses standard Windows APIs to encrypt the data, so
> only the user can decrypt the cached password. <i>(Since Subversion
> 1.2.)</i></p>
>
> <h4>macOS (formerly Mac OS X)</h4>
>
> <p>On macOS, Subversion uses the system Keychain facility to encrypt/store
> the user's svn password. <i>(Since Subversion 1.4.)</i></p>
>
> <h4>UNIX/Linux</h4>
>
> <p>On UNIX/Linux, Subversion supports up to four credential caches:</p>
>
> <ul>
> <li>GNOME Keyring</li>
> <li>KWallet</li>
> <li>GPG-Agent</li>
> <li>Plaintext cache in ~/.subversion</li>
I think we should write "Plaintext cache in ~/.subversion/auth/".
This is a preexisting issue from the original FAQ and I meant to
change it before, but I forgot.
> </ul>
>
> <p>To determine which credential caches your Subversion client supports, run
> the <tt>svn --version</tt> command and look for "The following authentication
> credential caches are available" toward the end of its output.</p>
>
> <p>GNOME Keyring and KWallet both facilitate storing passwords on disk
> encrypted. For Subversion to support these programs (since Subversion 1.6),
> they need to be available at compile-time and at run-time.</p>
> <!-- Removing the sentence about fallback to plaintext - it is discussed after
> GPG-Agent -->
> <p class="todo">TODO: Discuss GPG-Agent.</p>
>
> <p>Depending on a compile-time option (--enable-plaintext-password-storage)
> and runtime configurations (see below) Subversion <i>may</i> fallback to
> storing
> passwords in the Plaintext cache.</p>
> <!-- From GNOME Keyring/KWallet merged with some of Danielsh's comments
> (1...6) -->
>
> <p>The default value of --enable-plaintext-password-storage was changed from
> True to False in Subversion 1.12, thus disabling the Plaintext cache unless
> explicitly enabled.</p>
> <!-- Danielsh's #2 -->
>
> <p>The directory which contains cached Plaintext passwords (usually
> <tt>~/.subversion/auth/</tt>) has permissions of 700, meaning only the user
> (and root) can read them.</p>
>
> <h4>"Subversion was compiled with support for Plaintext password cache but I
> want to prevent writing passwords to the Plaintext cache!"</h4>
I originally put the exclamation points in these titles, but now I
think it would be better to replace them with periods.
> <p>The following options are available in your run-time config file
> (per user ~/.subversion/config and ~/.subversion/servers,
> systemwide /etc/subversion/config and /etc/subversion/servers):</p>
>
> <ul>
> <li>To allow encrypted stores like GNOME Keyring and KWallet, but not the
> Plaintext cache, set <tt>store-plaintext-passwords = no</tt>.</li>
> <li>To allow caching server certs but not passwords (encrypted or not), set
> <tt>store-passwords = no</tt>.</li>
> <li>To disable storing any kind of credentials (encrypted or not) set
> <tt>store-auth-creds = no</tt>.</li>
> </ul>
>
> <!-- The <ul/> should cover most of Danielsh's #2. -->
>
> <h4>"I want to use the Plaintext cache but it wasn't enabled at compile
> time!"</h4>
Same comment here about my exclamation point.
> <!-- Removed If your Subversion client was not build ... <p/> since it
> is already covered in the header -->
>
> <!-- I've not added anything about rebuilding. I think most users will
> prefer the comfort of package managers (or other binary distributions
> - eg TSVN). Those who are comfortable building their own have already
> figured out from the description earlier. But I'm not opposed it -->
>
> <p>In response to various questions and requests, the Subversion developers
> have written a Python script that can store a plain-text password to the
> cache. If you understand the security implications, have ruled out other
> alternatives, and still want to cache your password in plain-text on disk, you
> may find the script here:</p>
>
> <p class="todo">TODO: Link to the script.</p>
>
> <h4>Additional Information</h4>
>
> <p>More information on password caching is in Chapter 6 of the <a
> href="http://svnbook.red-bean.com/en/1.7/index.html";>Subversion book</a>,
> under <a
> href="http://svnbook.red-bean.com/en/1.7/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache";
> >"Client Credentials Caching".</a></p>
>
> </div>
> ]]]
Here's the full text with my above suggestions applied... I didn't
remove the HTML comments, and the two other things remaining to be
done is the todo about GPG-Agent and to add the correct link to the
Python script, if we've figured out where that should be.
[[[
<div class="h3" id="plaintext-passwords">
<h3>How does Subversion cache credentials (plain text and encrypted)?
<!-- The other FAQ entries are questions and there are discussions of
encrypted password stores in addition to the plain text store -->
<a class="sectionlink" href="#plaintext-passwords"
title="Link to this section">¶</a>
</h3>
<p>To avoid having to type a password for each server operation, Subversion
can cache credentials.</p>
<p>Passwords may have been cached unencrypted by older versions of Subversion
("grandfathered in") and Subversion always supports reading these. Whether and
how Subversion caches new credentials depends on several factors, including the
access method, operating system, compile-time options, and settings in the
client's run-time config file.</p>
<!-- Moved the first sentence (grandfathered passwords) here from the Unix
section. Added 'access methods' to somewhat cater for Danielsh's comment
regarding SSH password prompts / keys / client certs. I'm leaving the
question open if we should mention what is not covered in the answer. -->
<!-- Removed the <p/> and <ul/> about what we try to answer -->
<p>To show the credentials in your cache, use <tt>svn auth</tt>. Credentials
are never removed automatically but may be removed manually using
<tt>svn auth --remove</tt>.</p>
<!-- Added info on how to review the cache and remove credentials. This should
address part of Danielsh's #6 -->
<h4>Windows</h4>
<p>On Windows, Subversion uses standard Windows APIs to encrypt the data, so
only the user can decrypt the cached password. <i>(Since Subversion
1.2.)</i></p>
<h4>macOS (formerly Mac OS X)</h4>
<p>On macOS, Subversion uses the system Keychain facility to encrypt/store
the user's svn password. <i>(Since Subversion 1.4.)</i></p>
<h4>UNIX/Linux</h4>
<p>On UNIX/Linux, Subversion supports up to four credential caches:</p>
<ul>
<li>GNOME Keyring</li>
<li>KWallet</li>
<li>GPG-Agent</li>
<li>Plaintext cache in ~/.subversion/auth/.
</ul>
<p>To determine which credential caches your Subversion client supports, run
the <tt>svn --version</tt> command and look for "The following authentication
credential caches are available" toward the end of its output.</p>
<p>GNOME Keyring and KWallet both facilitate storing passwords on disk
encrypted. For Subversion to support these programs (since Subversion 1.6),
they need to be available at compile-time and at run-time.</p>
<!-- Removing the sentence about fallback to plaintext - it is discussed after
GPG-Agent -->
<p class="todo">TODO: Discuss GPG-Agent.</p>
<p>Depending on a compile-time option (--enable-plaintext-password-storage)
and runtime configurations (see below) Subversion <i>may</i> fallback to storing
passwords in the Plaintext cache.</p>
<!-- From GNOME Keyring/KWallet merged with some of Danielsh's
comments (1...6) -->
<p>The default value of --enable-plaintext-password-storage was changed from
True to False in Subversion 1.12, thus disabling the Plaintext cache unless
explicitly enabled.</p>
<!-- Danielsh's #2 -->
<p>The directory which contains cached Plaintext passwords (usually
<tt>~/.subversion/auth/</tt>) has permissions of 700, meaning only the user
(and root) can read them.</p>
<h4>"Subversion was compiled with support for Plaintext password cache but I
want to prevent writing passwords to the Plaintext cache."</h4>
<p>The following options are available in your run-time config file
(per user ~/.subversion/config and ~/.subversion/servers,
systemwide /etc/subversion/config and /etc/subversion/servers):</p>
<ul>
<li>To allow encrypted stores like GNOME Keyring and KWallet, but not the
Plaintext cache, set <tt>store-plaintext-passwords = no</tt>.</li>
<li>To allow caching server certs but not passwords (encrypted or not), set
<tt>store-passwords = no</tt>.</li>
<li>To disable storing any kind of credentials (encrypted or not) set
<tt>store-auth-creds = no</tt>.</li>
</ul>
<!-- The <ul/> should cover most of Danielsh's #2. -->
<h4>"I want to use the Plaintext cache but it wasn't enabled at compile
time."</h4>
<!-- Removed If your Subversion client was not build ... <p/> since it
is already covered in the header -->
<!-- I've not added anything about rebuilding. I think most users will
prefer the comfort of package managers (or other binary distributions
- eg TSVN). Those who are comfortable building their own have already
figured out from the description earlier. But I'm not opposed it -->
<p>In response to various questions and requests, the Subversion developers
have written a Python script that can store a plain-text password to the
cache. If you understand the security implications, have ruled out other
alternatives, and still want to cache your password in plain-text on disk, you
may find the script here:</p>
<p class="todo">TODO: Link to the script.</p>
<h4>Additional Information</h4>
<p>More information on password caching is in Chapter 6 of the <a
href="http://svnbook.red-bean.com/en/1.7/index.html";>Subversion book</a>,
under <a
href="http://svnbook.red-bean.com/en/1.7/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache";
>"Client Credentials Caching".</a></p>
</div>
]]]
By the way, I realize that we've been having this discussion on users@
and it probably should have been on dev@, but since we're almost done
(I think), we may as well finish it here for continuity. :-)
Cheers,
Nathan
