Den fre 26 feb. 2021 kl 14:43 skrev Daniel Shahaf <d...@daniel.shahaf.name>:
> Nathan Hartman wrote on Thu, Feb 25, 2021 at 13:29:48 -0500:
> > May I propose to have just one FAQ entry that simultaneously would
> answer:
> > * "what alternatives to plaintext caching are there?"
> > * "plaintext caching is supported but I want to *prevent* it"
> > * "plaintext caching is not supported but I want to use it anyway"
>
> Of course you may. _Prima facie_ I'm not sure that would be a good
> idea — one question per FAQ entry is similar to "Do one thing and do it
> well", and answering two questions per FAQ entry might make that entry
> less usable as a URL to be passed to someone who has either of these
> questions — but I'll reserve judgement until I've read the proposal.
>
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.
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.
[[[
<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
<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>
</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>
]]]
For those who prefer to rewiev the changes as a patch, I've attached it. It
should apply to Nathan's suggestioon (
https://mail-archives.apache.org/mod_mbox/subversion-users/202102.mbox/%3CCAJT2EHoiDPNnvxHPf8702p8WHKUBttowdfJ%3DyepPDPUT8hUzfw%40mail.gmail.com%3E
).
Kind regards,
Daniel Sahlberg
--- D:/temp/hartmannathan.txt sön feb 28 16:29:26 2021
+++ D:/temp/dsahlberg.txt sön feb 28 16:45:58 2021
@@ -2 +2,3 @@
-<h3>Password caching in plain-text on disk
+<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 -->
@@ -10,2 +12,4 @@ can cache credentials.</p>
-<p>Whether and how Subversion caches credentials depends on several factors,
-including the operating system, compile-time options, and settings in the
+<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
@@ -12,0 +17,4 @@ 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. -->
@@ -14,4 +22 @@ client's run-time config file.</p>
-<p>On some operating systems and configurations, Subversion can cache
-passwords on disk in plain-text. Some users want this, while others want to
-disallow it. This FAQ entry summarizes how credential caching works and
-attempts to answer both of these questons:</p>
+<!-- Removed the <p/> and <ul/> about what we try to answer -->
@@ -19,5 +24,5 @@ client's run-time config file.</p>
-<ul>
-<li>How to <b>prevent</b> caching passwords on disk in plain-text (with
- various alternatives provided), and</li>
-<li>How to cache passwords on disk in plain-text</li>
-</ul>
+<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
+<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 -->
@@ -53,4 +58,3 @@ encrypted. For Subversion to support these program
-they need to be available at compile-time and at run-time. Otherwise,
-Subversion <i>may</i> fallback to storing passwords in the Plaintext cache,
-if support for that is built in; see below.</p>
-
+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 -->
@@ -59,6 +63,4 @@ encrypted. For Subversion to support these program
-<p>On UNIX/Linux, the Plaintext cache is always supported for <b>reading</b>,
-but support for <b>writing</b> new passwords to the cache depends on build
-time configuration. Since Subversion 1.12, the default is <b>not</b> to
-support writing new passwords to the Plaintext cache, unless specifically
-enabled at build time, but Subversion will continue to use any previously
-cached passwords that are "grandfathered in."</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) -->Â
@@ -66 +68,6 @@ encrypted. For Subversion to support these program
-<p>The directory which contains the cached passwords (usually
+<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
@@ -70 +77,2 @@ encrypted. For Subversion to support these program
-<h4>"I want to prevent writing passwords to the Plaintext cache!"</h4>
+<h4>"Subversion was compiled with support for Plaintext password cache but I
+want to prevent writing passwords to the Plaintext cache!"</h4>
@@ -72 +80,3 @@ encrypted. For Subversion to support these program
-<p>The following options are available in your run-time config file:</p>
+<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>
@@ -76 +86 @@ encrypted. For Subversion to support these program
- Plaintext cache, set <tt>store-plaintext-passwords = no</tt>.
+ Plaintext cache, set <tt>store-plaintext-passwords = no</tt>.</li>
@@ -83 +93 @@ encrypted. For Subversion to support these program
-<h4>"I want to use the Plaintext cache but it wasn't enabled at build
time!"</h4>
+<!-- The <ul/> should cover most of Danielsh's #2. -->
@@ -85,3 +95,2 @@ encrypted. For Subversion to support these program
-<p>If your Subversion client was not built to cache passwords in plain-text,
-note that although it will not <i>save</i> new passwords to the cache, it
-will <i>use</i> any passwords that are already stored there.</p>
+<h4>"I want to use the Plaintext cache but it wasn't enabled at compile
+time!"</h4>
@@ -88,0 +98,8 @@ encrypted. For Subversion to support these program
+<!-- 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 -->
+
@@ -99 +116 @@ may find the script here:</p>
-<p>More information on password caching is in chapter 6 of the <a
+<p>More information on password caching is in Chapter 6 of the <a
