You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nathan Hartman <ha...@gmail.com> on 2021/03/01 01:47:46 UTC
Re: A more permanent home for the add-a-password-to-a-cached-username
script? (was: Re: using svn cli with --non-interactive (in scripts) securely,
without exposing password)
On Sun, Feb 28, 2021 at 10:51 AM Daniel Sahlberg
<da...@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
Re: A more permanent home for the add-a-password-to-a-cached-username script? (was: Re: using svn cli with --non-interactive (in scripts) securely, without exposing password)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Sahlberg wrote on Wed, 03 Mar 2021 07:32 +00:00:
> This brings up the question of translation. Futatuki translated the
> text to Japanese last time - or can someone else volonteer? There is
> also a Chinese translation, but it has not been updated for a long time
> - is there someone who would be interested in updating the text?
First, we shouldn't ask translators to translate moving targets. The
text in staging/ may still change before it's published.
As to translating the text once it's stable: we don't have a process
for this. I suppose we could just email the relevant translators and
advise them that faq.en.html has been updated and they may want to
update their translations, just like we might ask translators to update
subversion/po/ before a release — but we should keep in mind that some
translators haven't been active in years, and may or may not be
interested in contributing further.
Both translations have text near the top identifying the English
revision that was translated. There's some room for improvement there:
1. The Chinese translation needs to get the +840074 bump (per ^/subversion/README).
2. Both translations state the revision number that was translated, but
leave the reader to do some footwork in order to determine whether
the translation is up-to-date. They could, say, link to the ViewVC
log view of the English FAQ.
3. Linking to the log view assumes some understanding of Subversion, and
in context, that assumption may not be desirable. So, the English
FAQ could state a "Last modified" date, and the translations could
indicate the date of the English version that was translated.
Cheers,
Daniel
Re: A more permanent home for the add-a-password-to-a-cached-username
script? (was: Re: using svn cli with --non-interactive (in scripts) securely,
without exposing password)
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tis 2 mars 2021 kl 13:58 skrev Nathan Hartman <hartman.nathan@gmail.com
>:
> On Mon, Mar 1, 2021 at 2:25 AM Daniel Sahlberg <
> daniel.l.sahlberg@gmail.com> wrote:
>
>>
>> I think we should put it in the staging website for a final review? This
>> should go under General questions?
>>
>
>
> Yes, please commit it to staging for now. There is already a FAQ entry
> with ID plaintext-passwords; this is the update/replacement of that
> question. Keeping the ID the same means that any URLs out there will still
> work, and direct visitors to the updated answer.
>
Found some time this morning: r1887129. (I also fixed a few HTML validation
errors in r1887130).
This brings up the question of translation. Futatuki translated the text to
Japanese last time - or can someone else volonteer? There is also a Chinese
translation, but it has not been updated for a long time - is there someone
who would be interested in updating the text?
Kind regards,
Daniel Sahlberg
Re: A more permanent home for the add-a-password-to-a-cached-username
script? (was: Re: using svn cli with --non-interactive (in scripts) securely,
without exposing password)
Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Mar 1, 2021 at 2:25 AM Daniel Sahlberg <da...@gmail.com>
wrote:
>
> I think we should put it in the staging website for a final review? This
> should go under General questions?
>
Yes, please commit it to staging for now. There is already a FAQ entry with
ID plaintext-passwords; this is the update/replacement of that question.
Keeping the ID the same means that any URLs out there will still work, and
direct visitors to the updated answer.
Thanks!
Nathan
Re: A more permanent home for the add-a-password-to-a-cached-username
script? (was: Re: using svn cli with --non-interactive (in scripts) securely,
without exposing password)
Posted by Daniel Sahlberg <da...@gmail.com>.
Den mån 1 mars 2021 kl 02:47 skrev Nathan Hartman <hartman.nathan@gmail.com
>:
> On Sun, Feb 28, 2021 at 10:51 AM Daniel Sahlberg
> <da...@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...
>
I think your suggestions make sense.
Only one small thing:
> > <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.
>
Maybe even ~/.subversion/auth/svn.simple/? Disclaimer: I don't fully
understand what the other directories contain but from a quick look at the
code it didn't seem to be passwords. Is svn.ssl.client-passphrase used to
store passphrases for SSL client certificates (in plaintext??) - then maybe
this should be considered but we don't discuss client certificates (this
was one of Danielsh's comments).
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. :-)
>
And the discussion about the script was moved to dev@... Let's stay here.
I think we should put it in the staging website for a final review? This
should go under General questions? I have to go to my day-job now but I'll
do it in the evening unless someone is quicker than me.
Kind regards
Daniel Sahlberg