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