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.

> <div class="h3" id="plaintext-passwords">
> <h3>Password caching in plain-text on disk

How about "Does Subversion cache passwords in plain text?" or
"Configuring plain text password caching"?

>   <a class="sectionlink" href="#plaintext-passwords"
>     title="Link to this section">&para;</a>
> </h3>
> 
> <p>To avoid having to type a password for each server operation, Subversion
> 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
> client's run-time config file.</p>
> 

Should this mention that ssh password prompts / keys aren't covered
here?  And what about client certs?

> <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>
> 
> <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>
> 

See https://m.xkcd.com/1343/.¹  How about dropping the <ul/>, deleting
the <p/> above it, and in the latter's stead mention, in the Unix <h4/>,
that plaintext password caching is configurable because it's not
everyone's cup of tea?

> <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. Otherwise,
> Subversion <i>may</i> fallback to storing passwords in the Plaintext cache,
> if support for that is built in; see below.</p>

Suggest s/if.*built in/if so configured/, since there are both run-time
and compile-time knobs.  The term "built in" in particular is ambiguous
(could mean either "enabled at compile time" or "is available
always rather than as a module").

> <p class="todo">TODO: Discuss GPG-Agent.</p>
> 
> <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>

This jumps back and forth between reading and writing.  How about
separating several concerns here:

1. State that writing new passwords to the cache is configurable because
it's not everyone's cup of tea.

2. Describe the relevant compile- and run-time knobs, where they live,
and their defaults on various versions: --enable-plaintext-password-storage,
SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE, --no-auth-cache, store-passwords,
store-auth-creds.

3. State that writing is only done if all those planets align (if all
knobs have the right values).

4. State that reading is always done.

5. In the sections for "How to enable plaintext cachnig" and "How to
disable plaintext caching", build on top of this description.

6. Consider adding discussion of when cache entries are deleted
automatically (even if that's just "Never") and how to delete them
manually.

#5 would be a good reason to keep the answers to the two questions as
h4's under a single top-level entry.

> <p>The directory which contains the cached passwords (usually
> <tt>~/.subversion/auth/</tt>) has permissions of 700, meaning only the user
> (and root) can read them.</p>
> 
> <h4>"I want to prevent writing passwords to the Plaintext cache!"</h4>
> 
> <p>The following options are available in your run-time config file:</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>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>

It's noting here that the settings can be set in both
~/.subversion/config and ~/.subversion/servers.

> </ul>
> 
> <h4>"I want to use the Plaintext cache but it wasn't enabled at build
> time!"</h4>
> 
> <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>
> 

Suggest to move this paragraph to the end of the <h4/> subsection, since
it's relevant but is not an answer to the question.

Suggest to mention here the option of rebuilding.

> <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

Capitalize "Chapter"?  (Preëxisting issue)

> 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>
> 
> ]]]
> 
> Cheers,
> Nathan

Cheers,

Daniel

¹ Other references for "ease of use", in case they're useful to someone:

  - search://monkey+lake+smartphone+photo/

  - hwright's remark about user interfaces, years ago, in person: "[User
    interfaces] should be like, 1. Profit!"

Reply via email to