Den fre 14 aug. 2020 23:44Daniel Shahaf <d.s_at_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.s_at_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
>
Received on 2020-08-15 11:29:18 CEST