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)
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)
Den tis 2 mars 2021 kl 13:58 skrev Nathan Hartman : > On Mon, Mar 1, 2021 at 2:25 AM Daniel Sahlberg < > daniel.l.sahlb...@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)
On Mon, Mar 1, 2021 at 2:25 AM Daniel Sahlberg 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)
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
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)
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. > > Password caching in plain-text on disk How about "Does Subversion cache passwords in plain text?" or "Configuring plain text password caching"? >title="Link to this section">¶ > > > To avoid having to type a password for each server operation, Subversion > can cache credentials. > > 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. > Should this mention that ssh password prompts / keys aren't covered here? And what about client certs? > 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: > > > How to prevent caching passwords on disk in plain-text (with > various alternatives provided), and > How to cache passwords on disk in plain-text > > See https://m.xkcd.com/1343/.¹ How about dropping the , deleting the above it, and in the latter's stead mention, in the Unix , that plaintext password caching is configurable because it's not everyone's cup of tea? > 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. Otherwise, > Subversion may fallback to storing passwords in the Plaintext cache, > if support for that is built in; see below. 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"). > TODO: Discuss GPG-Agent. > > On UNIX/Linux, the Plaintext cache is always supported for > reading, > but support for writing new passwords to the cache depends on build > time configuration. Since Subversion 1.12, the default is not 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." 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. > The directory which contains the cached passwords (usually > ~/.subversion/auth/) has permissions of 700, meaning only the user > (and root) can read them. > > "I want to prevent writing passwords to the Plaintext cache!" > > The following options are available in your run-time config file: > > > 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. It's noting here that the settings can be set in both ~/.subversion/co
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 Thu, Feb 25, 2021 at 2:00 AM Daniel Shahaf
wrote:
> Daniel Sahlberg wrote on Wed, Feb 24, 2021 at 23:27:18 +0100:
> > Suggestion for new FAQ entry:
> > [[[
> > Ahhh! I just discovered that my Subversion client is NOT caching
> passwords
> > in plain-text on disk! AHHH!
>
> Having two entry titles that differ only by a "not" isn't a good idea.
>
> > Calm down, take a deep breath.
> >
> > This is the opposite of the previous question. After changing the compile
> > time default to not store passwords in plain-text there has been a number
> > of requests in the mailing lists to store the password.
>
> "A number of requests on the mailing lists" seems like too fine a level
> of abstraction. I think the context basically needs to be "The default
> is X but you may want Y; here's how to do that".
>
> > If you understand the security implications, you have ruled out other
>
> s/, you/, /
>
> > alternatives and still want to cache your password in plain-text on disk
>
> s/ and/, and/
>
> > you can use the script
> >
> https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/store-plaintext-password-py
> > to store the password in the directory which contains the cached
> passwords
> > (usually ~/.subversion/auth/). The script can also be used to list any
> > existing passwords stored in plain-text.
>
> This should just point to `svn auth`, surely?
>
> Should this explicitly say to run the script with --help to get its
> usage message?
>
> > ]]]
> >
> > I'm also suggesting to change the existing FAQ entry (Ahhh! I just
> > discovered that my Subversion client is caching passwords in plain-text
> on
> > disk! AHHH!) to mention the changed compile time default since 1.12 to
> not
> > store plain-text passwords:
> >
> > [[[
> > s/Otherwise, the client will fall back/Otherwise, the client can fall
> back/
> >
> > Since svn 1.12 the compile time default has been to disable storing new
> > passwords in plain-text, but old passwords can still be used. Certain
> > distributions may also have selected to use the compile time option to
> > enable plain-text password storage.
>
> Spell out that "old" passwords means passwords already cached on disk
> ("grandfathered") — as opposed to, say, passwords that had been changed.
>
> The wording "Certain distributions may…" sounds like indirect
> finger-pointing. Why not s/speculation/fact/: a compile-time option to
> enable plaintext passwords storage is provided and may have been
> selected by whoever built the binaries you're using (the term "distro"
> doesn't capture VisualSVN and TortoiseSVN).
>
> > s/However .*/In case Subversion is compiled with support for storing
> > plain-text passwords, you can disable it in your run-time config file by
> > setting 'store-plaintext-passwords = no' (so that encrypted stores like
> > GNOME Keyring and KWallet will still be used - this is already done in at
> > least one distribution which has selected to enable the plain-text
> password
> > storage in svn 1.12). If you want to disable storing any kind of
> > credentials you may instead set 'store-auth-creds = no', or you can use
> the
> > more narrowly-defined 'store-passwords = no' (so that server certs are
> > still cached). More information on password cacheing is in chapter 6 of
> the
> > "Nightly Build" Subversion book, under "Client Credentials Caching"./
>
> Is the information only available in the nightly build? If not,
> s/"Nightly Build"//.
>
> > ]]]
> >
> > The "Since svn 1.12..." should probably go in the end of the first "On
> > UNIX/Linux" section, after "(Since svn 1.6.)"
>
> At this point, a «svn diff -x-U10» unidiff might be easier for everyone.
>
> By the way, how about changing "if you're really worried" in the
> preëxisting text. This phrasing crosses the line from discussing the
> reader's risk assessment to discussing their mental state.
>
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"
I took the FAQ entry we have right now, expanded it, fixed a few
mistakes, updated a few out-of-date things, incorporated some of
dsahlberg's text, incorporated some of danielsh's feedback, added new
information, and now the following bears little resemblance
to any of the above...
But I've introduced some flaws, but I'm out of time for the day to fix
them. Please feel free to edit/reorganize/spindle/mutilate!!
Notes: INSTALL doesn't seem to document what is needed for Subversion
to support GPG-Agent on disk.
[[[
Password caching in plain-text on disk
¶
To avoid having to type a password for each server operation, Subversion
can cache credentials.
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.
On some operating syste
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)
Daniel Sahlberg wrote on Wed, Feb 24, 2021 at 23:27:18 +0100: > Learning Python has been on my todo list for ages, so I've cobbled > together something that seems to do the job. ☺ > There are basically two modes of operation: > > ./store-plaintext-password.py --listpassword|--list > > Which lists all cached realms/usernames (and passwords). I've intentionally > split it in two in case someone prefer not to put the password on-screen, > but I've also added the option to display to show that the password is > really in plain text. Isn't this what `svn auth` does? Also, "do one thing and do it well". Reasons: - So users have less code to audit before they run it. - Extensibility of interface - Clarity of interface (cf. «svn switch --relocate») > ./store-plaintext-password.py realm password [username] > > Which stores/updates the password for the given realm. If username is given > it is stored/updated as well. If there is no cached entry for the specified > realm a new file will be created (and username is a mandatory argument). Passwords shouldn't be passed in argv because the values in argv are visible to other non-root users. > TODO: > - Is the license ok? I stole it from svn.c I assume you're asking about the header format as opposed to the choice of license. Sure, svn.c's header ought to be fine. > - Improve Python code Reviewing. > - Improve documentation - especially on where to find the 'realm' string For one, by running `svn info` interactively and ^C'ing it at the prompt. > - Decide where to put it - I've gone with contrib for now as per Nathan's > and Daniel's suggestions This was a patch submission and my reply contains a review. We may want to move to dev@. > > > > Regarding the FAQ, currently we have [1] "Ahhh! I just discovered that > > > > my Subversion client is caching passwords in plain-text on disk! > > > > AHHH!" That is still applicable to 1.10, but now we need an entry to > > > > answer the opposite question: how to cache the password for svn use > > > > with cron jobs and non-X environments where Kwallet and GNOME-Keyring > > > > aren't applicable, and the particularly annoying case in which the > > > > machine itself has a GUI but the user is logged in via ssh; in this > > > > case the svn client will "freeze" while waiting for password entry in > > > > an inaccessible GUI window; I think this would occur with Kwallet, > > > > GNOME-Keyring, and macOS's Keychain.) > > > > > > > > But, as there doesn't seem to be one well-established way to handle > > > > this, other than just storing the password on disk, would the new FAQ > > > > entry say just that? Do we have any other concrete suggestions? > > > > If a cron job needs authentication, its credentials need to be stored > > somewhere, either in plaintext or in "as good as" plaintext. I think > > storing the passwords in unobfuscated plaintext was a deliberate > > decision, informed by CVS's design choices in this regard, but I wasn't > > around in the early days. > > > > On the other hand, for GUI-less environments and for headful > > environments ssh'd into, we should simply document the capabilities and > > workarounds of the libraries we use (possibly by pointing to those > > libraries' documentations). > > > > Suggestion for new FAQ entry: > [[[ > Ahhh! I just discovered that my Subversion client is NOT caching passwords > in plain-text on disk! AHHH! Having two entry titles that differ only by a "not" isn't a good idea. > Calm down, take a deep breath. > > This is the opposite of the previous question. After changing the compile > time default to not store passwords in plain-text there has been a number > of requests in the mailing lists to store the password. "A number of requests on the mailing lists" seems like too fine a level of abstraction. I think the context basically needs to be "The default is X but you may want Y; here's how to do that". > If you understand the security implications, you have ruled out other s/, you/, / > alternatives and still want to cache your password in plain-text on disk s/ and/, and/ > you can use the script > https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/store-plaintext-password-py > to store the password in the directory which contains the cached passwords > (usually ~/.subversion/auth/). The script can also be used to list any > existing passwords stored in plain-text. This should just point to `svn auth`, surely? Should this explicitly say to run the script with --help to get its usage message? > ]]] > > I'm also suggesting to change the existing FAQ entry (Ahhh! I just > discovered that my Subversion client is caching passwords in plain-text on > disk! AHHH!) to mention the changed compile time default since 1.12 to not > store plain-text passwords: > > [[[ > s/Otherwise, the client will fall back/Otherwise, the client can fall back/ > > Since svn 1.12 the compile time default has been to disable storing new > passwords in p
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 tis 23 feb. 2021 kl 17:46 skrev Daniel Shahaf : > Daniel Sahlberg wrote on Tue, Feb 23, 2021 at 16:50:07 +0100: > > Den tis 23 feb. 2021 16:40Nathan Hartman > skrev: > > > I think it's a good candidate for contrib (though it might be better > > > to port it to portable Bourne shell first). > > > > > > Would a Python version be useful? > > Porting isa rewrite and as such may introduce bugs. > > Porting will increase the number of developers able to maintain the script. > > Porting may let some users run the script without installing zsh first. > However, it's perhaps worth noting (in any eventual FAQ entry as well) > that running the script doesn't require chsh(1)ing to zsh: there's > nothing preventing bash users from installing zsh just so as to run > scripts written in it. > > Porting wouldn't be a matter of translating line-by-line, since the > «select» > builtin ( > http://zsh.sourceforge.net/Doc/Release/Shell-Grammar.html#index-select) > doesn't have a direct equivalent in other languages. For translating to > sh(1) > specifically, the use of arrays would also be an issue. > > As to contrib/, even though it's deprecated, I don't have a better idea. > (tools/ is probably not appropriate, unless more devs speak zsh than > I know.) > Learning Python has been on my todo list for ages, so I've cobbled together something that seems to do the job. There are basically two modes of operation: ./store-plaintext-password.py --listpassword|--list Which lists all cached realms/usernames (and passwords). I've intentionally split it in two in case someone prefer not to put the password on-screen, but I've also added the option to display to show that the password is really in plain text. ./store-plaintext-password.py realm password [username] Which stores/updates the password for the given realm. If username is given it is stored/updated as well. If there is no cached entry for the specified realm a new file will be created (and username is a mandatory argument). TODO: - Is the license ok? I stole it from svn.c - Improve Python code - Improve documentation - especially on where to find the 'realm' string - Decide where to put it - I've gone with contrib for now as per Nathan's and Daniel's suggestions > > Regarding the FAQ, currently we have [1] "Ahhh! I just discovered that > > > my Subversion client is caching passwords in plain-text on disk! > > > AHHH!" That is still applicable to 1.10, but now we need an entry to > > > answer the opposite question: how to cache the password for svn use > > > with cron jobs and non-X environments where Kwallet and GNOME-Keyring > > > aren't applicable, and the particularly annoying case in which the > > > machine itself has a GUI but the user is logged in via ssh; in this > > > case the svn client will "freeze" while waiting for password entry in > > > an inaccessible GUI window; I think this would occur with Kwallet, > > > GNOME-Keyring, and macOS's Keychain.) > > > > > > But, as there doesn't seem to be one well-established way to handle > > > this, other than just storing the password on disk, would the new FAQ > > > entry say just that? Do we have any other concrete suggestions? > > If a cron job needs authentication, its credentials need to be stored > somewhere, either in plaintext or in "as good as" plaintext. I think > storing the passwords in unobfuscated plaintext was a deliberate > decision, informed by CVS's design choices in this regard, but I wasn't > around in the early days. > > On the other hand, for GUI-less environments and for headful > environments ssh'd into, we should simply document the capabilities and > workarounds of the libraries we use (possibly by pointing to those > libraries' documentations). > Suggestion for new FAQ entry: [[[ Ahhh! I just discovered that my Subversion client is NOT caching passwords in plain-text on disk! AHHH! Calm down, take a deep breath. This is the opposite of the previous question. After changing the compile time default to not store passwords in plain-text there has been a number of requests in the mailing lists to store the password. If you understand the security implications, you have ruled out other alternatives and still want to cache your password in plain-text on disk you can use the script https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/store-plaintext-password-py to store the password in the directory which contains the cached passwords (usually ~/.subversion/auth/). The script can also be used to list any existing passwords stored in plain-text. ]]] I'm also suggesting to change the existing FAQ entry (Ahhh! I just discovered that my Subversion client is caching passwords in plain-text on disk! AHHH!) to mention the changed compile time default since 1.12 to not store plain-text passwords: [[[ s/Otherwise, the client will fall back/Otherwise, the client can fall back/ Since svn 1.12 the compile time default has been to disable storing new passwords in plain-text, but
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 Tue, Feb 23, 2021 at 3:15 PM Branko Čibej wrote: > > On 23.02.2021 17:46, Daniel Shahaf wrote: > > If a cron job needs authentication, its credentials need to be stored > > somewhere, either in plaintext or in "as good as" plaintext. I think > > storing the passwords in unobfuscated plaintext was a deliberate > > decision, informed by CVS's design choices in this regard, but I wasn't > > around in the early days. > > It was deliberate. Reading those passwords requires access to the > filesystem, so an attacker either has the affected user's credentials -- > in which case they probably have access to any encrypted password store > as well -- or they're root, and in _that_ case all bets are off anyway. Sadly, with docker, VM's, filesystem snapshots ,and home directories on NFS shares exported to the world at large without Kerberos authenticaiton (which I saw a bunch of computer science professors at MIT insist on, until finally MIT's IT group stepped on them for it and shoved them behind NAT), it's too easy to steal such credentials. > Note that recently operating systems have gone in the direction of _not_ > letting root do everything without extra checks, so maybe the second > assumption needs to be reconsidered. > > In any case, encrypted or otherwise protected password stores have > master passwords that have to be stored somewhere for unattended > operation, so that's just moving the problem one level of indirection away. No. They don'.t. A session can be unlocked with which the live user or service user can make a successful connection. The private key lives in RAM, not on disk, and the key needs to be unlocked at user login or at system start. This was what the old "keychain" perl script provided along with ssh-agent.
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 23.02.2021 17:46, Daniel Shahaf wrote: If a cron job needs authentication, its credentials need to be stored somewhere, either in plaintext or in "as good as" plaintext. I think storing the passwords in unobfuscated plaintext was a deliberate decision, informed by CVS's design choices in this regard, but I wasn't around in the early days. It was deliberate. Reading those passwords requires access to the filesystem, so an attacker either has the affected user's credentials -- in which case they probably have access to any encrypted password store as well -- or they're root, and in _that_ case all bets are off anyway. Note that recently operating systems have gone in the direction of _not_ letting root do everything without extra checks, so maybe the second assumption needs to be reconsidered. In any case, encrypted or otherwise protected password stores have master passwords that have to be stored somewhere for unattended operation, so that's just moving the problem one level of indirection away. -- Brane
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)
Daniel Sahlberg wrote on Tue, Feb 23, 2021 at 16:50:07 +0100: > Den tis 23 feb. 2021 16:40Nathan Hartman skrev: > > I think it's a good candidate for contrib (though it might be better > > to port it to portable Bourne shell first). > > > > Would a Python version be useful? Porting isa rewrite and as such may introduce bugs. Porting will increase the number of developers able to maintain the script. Porting may let some users run the script without installing zsh first. However, it's perhaps worth noting (in any eventual FAQ entry as well) that running the script doesn't require chsh(1)ing to zsh: there's nothing preventing bash users from installing zsh just so as to run scripts written in it. Porting wouldn't be a matter of translating line-by-line, since the «select» builtin (http://zsh.sourceforge.net/Doc/Release/Shell-Grammar.html#index-select) doesn't have a direct equivalent in other languages. For translating to sh(1) specifically, the use of arrays would also be an issue. As to contrib/, even though it's deprecated, I don't have a better idea. (tools/ is probably not appropriate, unless more devs speak zsh than I know.) > > Regarding the FAQ, currently we have [1] "Ahhh! I just discovered that > > my Subversion client is caching passwords in plain-text on disk! > > AHHH!" That is still applicable to 1.10, but now we need an entry to > > answer the opposite question: how to cache the password for svn use > > with cron jobs and non-X environments where Kwallet and GNOME-Keyring > > aren't applicable, and the particularly annoying case in which the > > machine itself has a GUI but the user is logged in via ssh; in this > > case the svn client will "freeze" while waiting for password entry in > > an inaccessible GUI window; I think this would occur with Kwallet, > > GNOME-Keyring, and macOS's Keychain.) > > > > But, as there doesn't seem to be one well-established way to handle > > this, other than just storing the password on disk, would the new FAQ > > entry say just that? Do we have any other concrete suggestions? If a cron job needs authentication, its credentials need to be stored somewhere, either in plaintext or in "as good as" plaintext. I think storing the passwords in unobfuscated plaintext was a deliberate decision, informed by CVS's design choices in this regard, but I wasn't around in the early days. On the other hand, for GUI-less environments and for headful environments ssh'd into, we should simply document the capabilities and workarounds of the libraries we use (possibly by pointing to those libraries' documentations). > As for the script, IIRC there was a need for the username (?) to be cached > before running the script. Where should that be stored? In the md5(realm)-named file in ~/.subversion/auth/ which the script ed(1)s. (The --no-auth-cache flag and the store-auth-creds configuration knob may affect whether the username is saved to disk.) The easiest way to populate that is to run `svn info` on the URL and authenticate manually. A script that takes a URL/username/password and inserts that tuple into the cache would be nice, of course, but it'd need to compute the realm string of the URL. 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)
Den tis 23 feb. 2021 16:40Nathan Hartman skrev: > On Tue, Feb 23, 2021 at 8:35 AM Daniel Shahaf > wrote: > >> Nathan Hartman wrote on Mon, Feb 22, 2021 at 14:36:58 -0500: >> > In a recent discussion on our dev mailing list, there is an example >> > shell script (for zsh) that saves a password file. See [2] and note >> > that there were a few corrections to the script so be sure to use the >> > latest version in that mail list thread. >> > >> > [1] >> https://subversion.apache.org/docs/release-notes/1.12.html#client-server-improvements >> > >> > [2] >> https://lists.apache.org/thread.html/r0eef40236aeddd1db18bc7882454dd3b18bcd721d8fd8c9e21aca52a%40%3Cdev.subversion.apache.org%3E >> > >> > I hope the above is helpful; feel free to ask as many questions as you >> > need to, or propose improvements to the above-mentioned script or >> > Subversion itself. We have gotten quite a few questions about this and >> >> I'm starting to wonder if that script deserves a home more permanent >> than the end of a random dev@ thread whose subject line contains "WTF" >> and "?!"; e.g., perhaps that script should be linked from the FAQ or >> the release notes. > > > > I agree we need a better place for the script, especially as the above > mail thread contains more than one version of it. > > I think it's a good candidate for contrib (though it might be better > to port it to portable Bourne shell first). > > Would a Python version be useful? > > Regarding the FAQ, currently we have [1] "Ahhh! I just discovered that > my Subversion client is caching passwords in plain-text on disk! > AHHH!" That is still applicable to 1.10, but now we need an entry to > answer the opposite question: how to cache the password for svn use > with cron jobs and non-X environments where Kwallet and GNOME-Keyring > aren't applicable, and the particularly annoying case in which the > machine itself has a GUI but the user is logged in via ssh; in this > case the svn client will "freeze" while waiting for password entry in > an inaccessible GUI window; I think this would occur with Kwallet, > GNOME-Keyring, and macOS's Keychain.) > > But, as there doesn't seem to be one well-established way to handle > this, other than just storing the password on disk, would the new FAQ > entry say just that? Do we have any other concrete suggestions? > I would go with a new FAQ entry. I can prepare a draft in staging. As for the script, IIRC there was a need for the username (?) to be cached before running the script. Where should that be stored? Kind regards Daniel Sahlberg > [1] https://subversion.apache.org/faq.html#plaintext-passwords > > 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)
On Tue, Feb 23, 2021 at 8:35 AM Daniel Shahaf wrote: > Nathan Hartman wrote on Mon, Feb 22, 2021 at 14:36:58 -0500: > > In a recent discussion on our dev mailing list, there is an example > > shell script (for zsh) that saves a password file. See [2] and note > > that there were a few corrections to the script so be sure to use the > > latest version in that mail list thread. > > > > [1] > https://subversion.apache.org/docs/release-notes/1.12.html#client-server-improvements > > > > [2] > https://lists.apache.org/thread.html/r0eef40236aeddd1db18bc7882454dd3b18bcd721d8fd8c9e21aca52a%40%3Cdev.subversion.apache.org%3E > > > > I hope the above is helpful; feel free to ask as many questions as you > > need to, or propose improvements to the above-mentioned script or > > Subversion itself. We have gotten quite a few questions about this and > > I'm starting to wonder if that script deserves a home more permanent > than the end of a random dev@ thread whose subject line contains "WTF" > and "?!"; e.g., perhaps that script should be linked from the FAQ or > the release notes. I agree we need a better place for the script, especially as the above mail thread contains more than one version of it. I think it's a good candidate for contrib (though it might be better to port it to portable Bourne shell first). Would a Python version be useful? Regarding the FAQ, currently we have [1] "Ahhh! I just discovered that my Subversion client is caching passwords in plain-text on disk! AHHH!" That is still applicable to 1.10, but now we need an entry to answer the opposite question: how to cache the password for svn use with cron jobs and non-X environments where Kwallet and GNOME-Keyring aren't applicable, and the particularly annoying case in which the machine itself has a GUI but the user is logged in via ssh; in this case the svn client will "freeze" while waiting for password entry in an inaccessible GUI window; I think this would occur with Kwallet, GNOME-Keyring, and macOS's Keychain.) But, as there doesn't seem to be one well-established way to handle this, other than just storing the password on disk, would the new FAQ entry say just that? Do we have any other concrete suggestions? [1] https://subversion.apache.org/faq.html#plaintext-passwords Nathan
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)
Nathan Hartman wrote on Mon, Feb 22, 2021 at 14:36:58 -0500: > In a recent discussion on our dev mailing list, there is an example > shell script (for zsh) that saves a password file. See [2] and note > that there were a few corrections to the script so be sure to use the > latest version in that mail list thread. > > [1] > https://subversion.apache.org/docs/release-notes/1.12.html#client-server-improvements > > [2] > https://lists.apache.org/thread.html/r0eef40236aeddd1db18bc7882454dd3b18bcd721d8fd8c9e21aca52a%40%3Cdev.subversion.apache.org%3E > > I hope the above is helpful; feel free to ask as many questions as you > need to, or propose improvements to the above-mentioned script or > Subversion itself. We have gotten quite a few questions about this and I'm starting to wonder if that script deserves a home more permanent than the end of a random dev@ thread whose subject line contains "WTF" and "?!"; e.g., perhaps that script should be linked from the FAQ or the release notes. Cheers, Daniel > it has been frustrating for anyone who uses svn as part of cron jobs > in non-X environments, where the available encrypted password stores, > Kwallet and Gnome-keyring, aren't much help, and GPG-Agent doesn't > persist the passwords indefinitely. We would be really grateful if > someone could propose a solution that works well in these scenarios > while alleviating people's concerns about storing passwords on disk in > plaintext. > > Cheers, > Nathan
Re: using svn cli with --non-interactive (in scripts) securely,without exposing password
In article nka...@gmail.com writes: > Sorry for message without content, re-sending with content. > > > On Mon, Feb 22, 2021 at 3:25 PM Yasuhito FUTATSUKI > > > > If you want to use ssh key other than default key or alternative tcp port > > > other than 22, you can use them by overriding ssh tunnel setting with > > > SVN_SSH > > > environment variable or config file, etc. (Of course, if you want to use > > > non > > > standard port for ssh connection you also need to change configuration of > > > sshd on server side). > > No. SSh keys without passphrases are much like Post-it notes with > passwords on them, or stored passwords in Subversion. It is ture, but as I wrote in another message, I think there is no safer way, as far as using automation kicked by cron, directly. > Tools that can > write to a source control without anyone unlocking the key are quite > dangerous. It's no need to give write access for the purpose of this thread and threre is a way to give read only permisson, but it is off topic. > It's straightforward to use ssh-agent to unlock and store access to > the key after a server is booted, but requiring a console to set up > *once* and save long-term. The old "keychain" tool works quite well > for this, and can enable ephemereal access to a live ssh-agent as > needed. For automated build tools like Jenkins, they can even store > the private key internally, encrypted with the SSH server's > encryption, and restricted to certain Jenkins "folders" for project > specific access. I use this approach regularly for Jenkins and source > control. Then how do the agent distinguish process kicked by cron and those process created by someone which has a privillage to start cron daemon, or even has a privillage to modify cron jobs? I think giving secrets to some process on system boot without storing file system or non-volatile memory has only advantage against off line attacks. I think it is a balance of confidentiality and availability. Anyways I'm using svn+ssh in my enrionment, but please do risk assessment in your own environment, even though I thought it was needless to say. Cheers, -- Yasuhito FUTATSUKI
Re: using svn cli with --non-interactive (in scripts) securely, without exposing password
Sorry for message without content, re-sending with content. > On Mon, Feb 22, 2021 at 3:25 PM Yasuhito FUTATSUKI > > If you want to use ssh key other than default key or alternative tcp port > > other than 22, you can use them by overriding ssh tunnel setting with > > SVN_SSH > > environment variable or config file, etc. (Of course, if you want to use non > > standard port for ssh connection you also need to change configuration of > > sshd on server side). No. SSh keys without passphrases are much like Post-it notes with passwords on them, or stored passwords in Subversion. Tools that can write to a source control without anyone unlocking the key are quite dangerous. It's straightforward to use ssh-agent to unlock and store access to the key after a server is booted, but requiring a console to set up *once* and save long-term. The old "keychain" tool works quite well for this, and can enable ephemereal access to a live ssh-agent as needed. For automated build tools like Jenkins, they can even store the private key internally, encrypted with the SSH server's encryption, and restricted to certain Jenkins "folders" for project specific access. I use this approach regularly for Jenkins and source control. SSH access is also vulnerable to changing host keys in DHCP based environments. Do look up SSH hostkeys and the keyword "/dev/null" to find many notes about how to disable this, including ones I've been publishing for decades.
Re: using svn cli with --non-interactive (in scripts) securely, without exposing password
On Mon, Feb 22, 2021 at 3:25 PM Yasuhito FUTATSUKI wrote: > > Hello, > > On 2021/02/23 2:40, CoolCold wrote: > > Good day! > > (please CC me, I'm not subscribed to the list) > > > > A bit of context: > > I was using subversion to store my serves' configs versioned for > > almost a decade, with bash wrapping around it. Simplified, it had repo > > per server name, wrapper called by cron to checkout, rsync over, > > commit changes back, sending email on diffs ( > > https://github.com/coolcold/svnbackup ). Had no issue with it, when > > password store was enabled. It's runned under root user and saved > > credentials are not exposed to non-admin users on the system. > > > > Issue: with recent changes hitting packages in distributions ( > > https://marc.info/?l=subversion-commits&m=154101482302608&w=2 ), that > > seems to be not possible anymore. > > I did adjust my script to use command line switch --password, but this > > makes it visible for anyone who does simple commands like ps aux. > > I've tried to look around for possible support of environment > > variables / password file support, but couldn't find any except some > > old proposals like > > http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html > > > > Rebuilding subversion from source is not an option for many reasons. > > > > Seeking for your help on this, what is the proper way of doing this > > with recent versions? > > Thanks in advance. > > For this purpose, I'm just using svn+ssh:// with dedicated user on > server side and public key authentication with empty pass phrase. > > e.g. svn+ssh://svn-ag...@svnhost.example.org/repo/ > > On svnhost.example.org, authorized_key file for user svn-agent could be: > [[[ > # only for svn agent via ssh. all lines shoud be started with following > # command and option specification: > command="/usr/bin/svnserve -t -r /base/path/to/repo > --tunnel-user=root-on-hostA",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty > ssh-ed25519 (public key A) r...@hosta.example.org > command="/usr/bin/svnserve -t -r /base/path/to/repo > --tunnel-user=root-on-hostB",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty > ssh-ed25519 (public key B) r...@hostb.example.org > ... > ]]] > > Cf. > http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks > > If you want to use ssh key other than default key or alternative tcp port > other than 22, you can use them by overriding ssh tunnel setting with SVN_SSH > environment variable or config file, etc. (Of course, if you want to use non > standard port for ssh connection you also need to change configuration of > sshd on server side). > > Cheers, > -- > Yasuhito FUTATSUKI
Re: using svn cli with --non-interactive (in scripts) securely,without exposing password
In article coolthec...@gmail.com writes: > As I see it, at the end of the day, cleartext password / token / > ssh-key would be saved anyway, if you need to have it to work in an > automated way. > Most convenient for me would be having: > a) --pasword-file=... command option > b) SVN_PASSWORD environment variable > > both of them should not be hard to implement and both provide access > to current and/or root user, compared to current implementation, when > running "ps aux" to reveal --password=... param executed by any user > (this param could be at least googled fast and majority of people > won't go deep into crafting simple auth file themselves). Environment variables passed by a parent can be seen by others, too. Some implementation of ps(1) utility has an option to display it. Also, procfs on Linux provide /proc/$pid/environ. I don't think there is a safe way that a process kicked by cron can get credentials but other processes which have same privilage can't get them. Cheers, -- Yasuhito FUTATSUKI
Re: using svn cli with --non-interactive (in scripts) securely, without exposing password
Hello! On Tue, Feb 23, 2021 at 2:37 AM Nathan Hartman wrote: > > On Mon, Feb 22, 2021 at 1:17 PM CoolCold wrote: > > > > Good day! > > (please CC me, I'm not subscribed to the list) > > > > A bit of context: > > I was using subversion to store my serves' configs versioned for > > almost a decade, with bash wrapping around it. Simplified, it had repo > > per server name, wrapper called by cron to checkout, rsync over, > > commit changes back, sending email on diffs ( > > https://github.com/coolcold/svnbackup ). Had no issue with it, when > > password store was enabled. It's runned under root user and saved > > credentials are not exposed to non-admin users on the system. > > > > Issue: with recent changes hitting packages in distributions ( > > https://marc.info/?l=subversion-commits&m=154101482302608&w=2 ), that > > seems to be not possible anymore. > > I did adjust my script to use command line switch --password, but this > > makes it visible for anyone who does simple commands like ps aux. > > I've tried to look around for possible support of environment > > variables / password file support, but couldn't find any except some > > old proposals like > > http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html > > > > Rebuilding subversion from source is not an option for many reasons. > > > > Seeking for your help on this, what is the proper way of doing this > > with recent versions? > > Thanks in advance. > > Hello, > > Recent versions (1.12.x and newer [1]) by default don't _save_ > passwords to disk in plaintext (unless configured to do so at > build-time). > > However, Subversion will _use_ the password, if it is already stored > on disk. > > So, as a workaround, you could use some out-of-band method to save the > password to disk either by using an older SVN client or by generating > a file with the right bits in it: That's good news for me, will poke around. > > In a recent discussion on our dev mailing list, there is an example > shell script (for zsh) that saves a password file. See [2] and note > that there were a few corrections to the script so be sure to use the > latest version in that mail list thread. > > [1] > https://subversion.apache.org/docs/release-notes/1.12.html#client-server-improvements Thanks for the links with discussion and proposed solution, really helpful. Also it expresses the same feeling and reaction I have, but stated in much better English. > > [2] > https://lists.apache.org/thread.html/r0eef40236aeddd1db18bc7882454dd3b18bcd721d8fd8c9e21aca52a%40%3Cdev.subversion.apache.org%3E > > I hope the above is helpful; feel free to ask as many questions as you > need to, or propose improvements to the above-mentioned script or > Subversion itself. We have gotten quite a few questions about this and > it has been frustrating for anyone who uses svn as part of cron jobs > in non-X environments, where the available encrypted password stores, > Kwallet and Gnome-keyring, aren't much help, and GPG-Agent doesn't > persist the passwords indefinitely. > We would be really grateful if > someone could propose a solution that works well in these scenarios > while alleviating people's concerns about storing passwords on disk in > plaintext. As I see it, at the end of the day, cleartext password / token / ssh-key would be saved anyway, if you need to have it to work in an automated way. Most convenient for me would be having: a) --pasword-file=... command option b) SVN_PASSWORD environment variable both of them should not be hard to implement and both provide access to current and/or root user, compared to current implementation, when running "ps aux" to reveal --password=... param executed by any user (this param could be at least googled fast and majority of people won't go deep into crafting simple auth file themselves). Live examples of cleartext passwords/tokens are numerous - SAMBA mount passwords, AWS access tokens, deployment ssh keys and so on, which are stored in cleartext anyway - I'd say industry made it's choice already. For advanced feature, it could be having something like SVN_ASK_PASS_PROGRAM helper support, it can be sophisticated enough to connect to some URL and get password from there, without storing it on any local disk, but that's much harder to implement and setup by end user. If such helpers would be bundled with subversion (like email notification scripts in Perl, for example), there is a non-zero chance someone will use it. > > Cheers, > Nathan Thanks again for your reply, Nathan! -- Best regards, [COOLCOLD-RIPN]
Re: using svn cli with --non-interactive (in scripts) securely, without exposing password
Hello, On Tue, Feb 23, 2021 at 3:23 AM Yasuhito FUTATSUKI wrote: > > Hello, > > On 2021/02/23 2:40, CoolCold wrote: > > Good day! > > (please CC me, I'm not subscribed to the list) > > > > A bit of context: > > I was using subversion to store my serves' configs versioned for > > almost a decade, with bash wrapping around it. Simplified, it had repo > > per server name, wrapper called by cron to checkout, rsync over, > > commit changes back, sending email on diffs ( > > https://github.com/coolcold/svnbackup ). Had no issue with it, when > > password store was enabled. It's runned under root user and saved > > credentials are not exposed to non-admin users on the system. > > > > Issue: with recent changes hitting packages in distributions ( > > https://marc.info/?l=subversion-commits&m=154101482302608&w=2 ), that > > seems to be not possible anymore. > > I did adjust my script to use command line switch --password, but this > > makes it visible for anyone who does simple commands like ps aux. > > I've tried to look around for possible support of environment > > variables / password file support, but couldn't find any except some > > old proposals like > > http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html > > > > Rebuilding subversion from source is not an option for many reasons. > > > > Seeking for your help on this, what is the proper way of doing this > > with recent versions? > > Thanks in advance. > > For this purpose, I'm just using svn+ssh:// with dedicated user on > server side and public key authentication with empty pass phrase. > > e.g. svn+ssh://svn-ag...@svnhost.example.org/repo/ > > On svnhost.example.org, authorized_key file for user svn-agent could be: > [[[ > # only for svn agent via ssh. all lines shoud be started with following > # command and option specification: > command="/usr/bin/svnserve -t -r /base/path/to/repo > --tunnel-user=root-on-hostA",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty > ssh-ed25519 (public key A) r...@hosta.example.org > command="/usr/bin/svnserve -t -r /base/path/to/repo > --tunnel-user=root-on-hostB",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty > ssh-ed25519 (public key B) r...@hostb.example.org > ... > ]]] Thanks for sharing this - I still see such a way as a workaround, but as a reasonable workaround. One may want to prefer it due to data transfer encryption it provides. >From the other side, it's a trade of "cleartext" password vs "unprotected ssh key" (while key can be IP bound in .ssh/authorized_keys thus making it a bit better protected in case of leakage). > > Cf. > http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks > > If you want to use ssh key other than default key or alternative tcp port > other than 22, you can use them by overriding ssh tunnel setting with SVN_SSH > environment variable or config file, etc. (Of course, if you want to use non > standard port for ssh connection you also need to change configuration of > sshd on server side). > > Cheers, > -- > Yasuhito FUTATSUKI -- Best regards, [COOLCOLD-RIPN]
Re: using svn cli with --non-interactive (in scripts) securely, without exposing password
Hello, On 2021/02/23 2:40, CoolCold wrote: > Good day! > (please CC me, I'm not subscribed to the list) > > A bit of context: > I was using subversion to store my serves' configs versioned for > almost a decade, with bash wrapping around it. Simplified, it had repo > per server name, wrapper called by cron to checkout, rsync over, > commit changes back, sending email on diffs ( > https://github.com/coolcold/svnbackup ). Had no issue with it, when > password store was enabled. It's runned under root user and saved > credentials are not exposed to non-admin users on the system. > > Issue: with recent changes hitting packages in distributions ( > https://marc.info/?l=subversion-commits&m=154101482302608&w=2 ), that > seems to be not possible anymore. > I did adjust my script to use command line switch --password, but this > makes it visible for anyone who does simple commands like ps aux. > I've tried to look around for possible support of environment > variables / password file support, but couldn't find any except some > old proposals like > http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html > > Rebuilding subversion from source is not an option for many reasons. > > Seeking for your help on this, what is the proper way of doing this > with recent versions? > Thanks in advance. For this purpose, I'm just using svn+ssh:// with dedicated user on server side and public key authentication with empty pass phrase. e.g. svn+ssh://svn-ag...@svnhost.example.org/repo/ On svnhost.example.org, authorized_key file for user svn-agent could be: [[[ # only for svn agent via ssh. all lines shoud be started with following # command and option specification: command="/usr/bin/svnserve -t -r /base/path/to/repo --tunnel-user=root-on-hostA",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 (public key A) r...@hosta.example.org command="/usr/bin/svnserve -t -r /base/path/to/repo --tunnel-user=root-on-hostB",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 (public key B) r...@hostb.example.org ... ]]] Cf. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks If you want to use ssh key other than default key or alternative tcp port other than 22, you can use them by overriding ssh tunnel setting with SVN_SSH environment variable or config file, etc. (Of course, if you want to use non standard port for ssh connection you also need to change configuration of sshd on server side). Cheers, -- Yasuhito FUTATSUKI
Re: using svn cli with --non-interactive (in scripts) securely, without exposing password
On Mon, Feb 22, 2021 at 1:17 PM CoolCold wrote: > > Good day! > (please CC me, I'm not subscribed to the list) > > A bit of context: > I was using subversion to store my serves' configs versioned for > almost a decade, with bash wrapping around it. Simplified, it had repo > per server name, wrapper called by cron to checkout, rsync over, > commit changes back, sending email on diffs ( > https://github.com/coolcold/svnbackup ). Had no issue with it, when > password store was enabled. It's runned under root user and saved > credentials are not exposed to non-admin users on the system. > > Issue: with recent changes hitting packages in distributions ( > https://marc.info/?l=subversion-commits&m=154101482302608&w=2 ), that > seems to be not possible anymore. > I did adjust my script to use command line switch --password, but this > makes it visible for anyone who does simple commands like ps aux. > I've tried to look around for possible support of environment > variables / password file support, but couldn't find any except some > old proposals like > http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html > > Rebuilding subversion from source is not an option for many reasons. > > Seeking for your help on this, what is the proper way of doing this > with recent versions? > Thanks in advance. Hello, Recent versions (1.12.x and newer [1]) by default don't _save_ passwords to disk in plaintext (unless configured to do so at build-time). However, Subversion will _use_ the password, if it is already stored on disk. So, as a workaround, you could use some out-of-band method to save the password to disk either by using an older SVN client or by generating a file with the right bits in it: In a recent discussion on our dev mailing list, there is an example shell script (for zsh) that saves a password file. See [2] and note that there were a few corrections to the script so be sure to use the latest version in that mail list thread. [1] https://subversion.apache.org/docs/release-notes/1.12.html#client-server-improvements [2] https://lists.apache.org/thread.html/r0eef40236aeddd1db18bc7882454dd3b18bcd721d8fd8c9e21aca52a%40%3Cdev.subversion.apache.org%3E I hope the above is helpful; feel free to ask as many questions as you need to, or propose improvements to the above-mentioned script or Subversion itself. We have gotten quite a few questions about this and it has been frustrating for anyone who uses svn as part of cron jobs in non-X environments, where the available encrypted password stores, Kwallet and Gnome-keyring, aren't much help, and GPG-Agent doesn't persist the passwords indefinitely. We would be really grateful if someone could propose a solution that works well in these scenarios while alleviating people's concerns about storing passwords on disk in plaintext. Cheers, Nathan
using svn cli with --non-interactive (in scripts) securely, without exposing password
Good day! (please CC me, I'm not subscribed to the list) A bit of context: I was using subversion to store my serves' configs versioned for almost a decade, with bash wrapping around it. Simplified, it had repo per server name, wrapper called by cron to checkout, rsync over, commit changes back, sending email on diffs ( https://github.com/coolcold/svnbackup ). Had no issue with it, when password store was enabled. It's runned under root user and saved credentials are not exposed to non-admin users on the system. Issue: with recent changes hitting packages in distributions ( https://marc.info/?l=subversion-commits&m=154101482302608&w=2 ), that seems to be not possible anymore. I did adjust my script to use command line switch --password, but this makes it visible for anyone who does simple commands like ps aux. I've tried to look around for possible support of environment variables / password file support, but couldn't find any except some old proposals like http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html Rebuilding subversion from source is not an option for many reasons. Seeking for your help on this, what is the proper way of doing this with recent versions? Thanks in advance.
