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)
Den mån 1 mars 2021 kl 02:47 skrev Nathan Hartman :
> On Sun, Feb 28, 2021 at 10:51 AM Daniel Sahlberg
> 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:
> > On UNIX/Linux, Subversion supports up to four credential caches:
> >
> >
> > GNOME Keyring
> > KWallet
> > GPG-Agent
> > Plaintext cache in ~/.subversion
>
> 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.
>
> [[[
>
> How does Subversion cache credentials (plain text and encrypted)?
>
>title="Link to this section">
>
>
> To avoid having to type a password for each server operation, Subversion
> can cache credentials.
>
> 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.
>
>
>
>
> To show the credentials in your cache, use svn auth.
> Credentials
> are never removed automatically but may be removed manually using
> svn auth --remove.
>
>
> Windows
>
> On Windows, Subversion uses standard Windows APIs to encrypt the data,
> so
> only the user can decrypt the cached password. (Since Subversion
> 1.2.)
>
> macOS (formerly Mac OS X)
>
> On macOS, Subversion uses the system Keychain facility to encrypt/store
> the user's svn password. (Since Subversion 1.4.)
>
> UNIX/Linux
>
> On UNIX/Linux, Subversion supports up to four credential caches:
>
>
> GNOME Keyring
> KWallet
> GPG-Agent
> Plaintext cache in ~/.subversion/auth/.
>
>
> To determine which credential caches your Subversion client supports,
> run
> the svn --version command and look for "The following
> authentication
> credential caches are available" toward the end of its output.
>
> 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.
>
> TODO: Discuss GPG-Agent.
>
> Depending on a compile-time option (--enable-plaintext-password-storage)
> and runtime configurations (see below) Subversion may fallback to
> storing
> passwords in the Plaintext cache.
>
>
> 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.
>
>
> The directory which contains cached Plaintext passwords (usually
> ~/.subversion/auth/) has permissions of 700, meaning only the user
> (and root) can read them.
>
> "Subversion was compiled with support for Plaintext password cache but
> I
> want to prevent writing passwords to the Plaintext cache."
>
> 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):
>
>
> To allow encrypted stores like GNOME Keyring and KWallet, but not the
> Plaintext cache, set store-plaintext-passwords = no.
> To allow caching server certs but not passwords (encrypted or not), set
> store-passwords = no.
> To disable storing any kind of credentials (encrypted or not) set
> store-auth-creds = no.
>
>
>
>
> "I want to use the Plaintext cache but it wasn't enabled at compile
> time."
>
>
>
>
>
> In response to various questions and requests,
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
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...
> [[[
>
> How does Subversion cache credentials (plain text and encrypted)?
>
>title="Link to this section">
>
>
> To avoid having to type a password for each server operation, Subversion
> can cache credentials.
>
> 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.
>
>
>
>
> To show the credentials in your cache, use svn auth. Credentials
> are never removed automatically but Credentials may be removed manually using
In the above sentence, should the last mention of "Credentials" be
removed?
> svn auth --remove.
>
>
> Windows
>
> On Windows, Subversion uses standard Windows APIs to encrypt the data, so
> only the user can decrypt the cached password. (Since Subversion
> 1.2.)
>
> macOS (formerly Mac OS X)
>
> On macOS, Subversion uses the system Keychain facility to encrypt/store
> the user's svn password. (Since Subversion 1.4.)
>
> UNIX/Linux
>
> On UNIX/Linux, Subversion supports up to four credential caches:
>
>
> GNOME Keyring
> KWallet
> GPG-Agent
> Plaintext cache in ~/.subversion
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.
>
>
> To determine which credential caches your Subversion client supports, run
> the svn --version command and look for "The following authentication
> credential caches are available" toward the end of its output.
>
> 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.
>
> TODO: Discuss GPG-Agent.
>
> Depending on a compile-time option (--enable-plaintext-password-storage)
> and runtime configurations (see below) Subversion may fallback to
> storing
> passwords in the Plaintext cache.
>
>
> 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.
>
>
> The directory which contains cached Plaintext passwords (usually
> ~/.subversion/auth/) has permissions of 700, meaning only the user
> (and root) can read them.
>
> "Subversion was compiled with support for Plaintext password cache but I
> want to prevent writing passwords to the Plaintext cache!"
I originally put the exclamation points in these titles, but now I
think it would be better to replace them with periods.
> 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):
>
>
> To allow encrypted stores like GNOME Keyring and KWallet, but not the
> Plaintext cache, set store-plaintext-passwords = no.
> To allow caching server certs but not passwords (encrypted or not), set
> store-passwords = no.
> To disable storing any kind of credentials (encrypted or not) set
> store-auth-creds = no.
>
>
>
>
> "I want to use the Plaintext cache but it wasn't enabled at compile
> time!"
Same comment here about my exclamation point.
>
>
>
>
> 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:
>
> TODO: Link to the script.
>
> Additional Information
>
> More information on password caching is in Chapter 6 of the href="http://svnbook.red-bean.com/en/1.7/index.html;>Subversion book,
> under href="http://svnbook.red-bean.com/en/1.7/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache;
> >"Client Credentials Caching".
>
>
> ]]]
Here's the full text with my above suggestions applied... I didn't
remove the HTML comments,
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)
Den fre 26 feb. 2021 kl 14:43 skrev Daniel Shahaf :
> 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.
[[[
How does Subversion cache credentials (plain text and encrypted)?
To avoid having to type a password for each server operation, Subversion
can cache credentials.
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.
To show the credentials in your cache, use svn auth. Credentials
are never removed automatically but Credentials may be removed manually
using
svn auth --remove.
Windows
On Windows, Subversion uses standard Windows APIs to encrypt the data, so
only the user can decrypt the cached password. (Since Subversion
1.2.)
macOS (formerly Mac OS X)
On macOS, Subversion uses the system Keychain facility to encrypt/store
the user's svn password. (Since Subversion 1.4.)
UNIX/Linux
On UNIX/Linux, Subversion supports up to four credential caches:
GNOME Keyring
KWallet
GPG-Agent
Plaintext cache in ~/.subversion
To determine which credential caches your Subversion client supports, run
the svn --version command and look for "The following
authentication
credential caches are available" toward the end of its output.
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.
TODO: Discuss GPG-Agent.
Depending on a compile-time option (--enable-plaintext-password-storage)
and runtime configurations (see below) Subversion may fallback to
storing
passwords in the Plaintext cache.
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.
The directory which contains cached Plaintext passwords (usually
~/.subversion/auth/) has permissions of 700, meaning only the user
(and root) can read them.
"Subversion was compiled with support for Plaintext password cache but
I
want to prevent writing passwords to the Plaintext cache!"
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):
To allow encrypted stores like GNOME Keyring and KWallet, but not the
Plaintext cache, set store-plaintext-passwords = no.
To allow caching server certs but not passwords (encrypted or not), set
store-passwords = no.
To disable storing any kind of credentials (encrypted or not) set
store-auth-creds = no.
"I want to use the Plaintext cache but it wasn't enabled at compile
time!"
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:
TODO: Link to the script.
Additional Information
More information on password caching is in Chapter 6 of the http://svnbook.red-bean.com/en/1.7/index.html;>Subversion book,
under http://svnbook.red-bean.com/en/1.7/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache
"
>"Client Credentials Caching".
]]]
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
