Daniel Sahlberg wrote on Tue, Feb 23, 2021 at 16:50:07 +0100: > Den tis 23 feb. 2021 16:40Nathan Hartman <hartman.nat...@gmail.com> 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
