Daniel Sahlberg wrote on Fri, 14 Aug 2020 23:01 +0200: > Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf <d...@daniel.shahaf.name>: > > > It successfully adds a password to the storage, in the sense that > > after running it, a subsequent `svn auth --show-passwords` shows the > > password. Still, a subsequent `svn info` doesn't use the password. > > Why? By source inspection, SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE > > affects svn_auth__simple_creds_cache_set() but not > > svn_auth__simple_creds_cache_get(), > > so why doesn't the latter use the password? > > > > It seems you also need to set passtype = simple for > svn_auth__simple_creds_cache_get() to accept the password. >
Good catch. > Updated script, I changed to use /usr/bin/env to find zsh > and explicitly set LANG to make sure svn auth return the expected > text (normally I'm running sv_SE.UTF-8). Another good catch. Further improvements: it should set LC_ALL rather than LANG, and the setting can be pushed into the $(…) subshell. Furthermore, since this doesn't even try to be a POSIX script, the «autoload -Uz _comp_locale; … $(_comp_locale; …)» idiom is also available. > I even think [SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE] could > prevent reading an already stored password. So what would be done with the already-stored password? - Deleting it would be data loss. - Keeping it but not using it would needlessly increase the attack surface: Mallory might find the plaintext password, but since svn itself won't use it, it won't show up in audits' syscall traces and so on. - [There may very well be a third option, but I haven't the time to think one up right now.] Thanks for the bugfixes! Daniel