Den fre 14 aug. 2020 23:44Daniel Shahaf <d...@daniel.shahaf.name> skrev:
> 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. > That was way above my shell script comfort zone.. > 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.] > Good point and I agree with your analysis. No perfect solution there. Thanks for the bugfixes! > > Daniel >
