[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: A strong WTF on compiling out plaintext password support by default?!

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 14 Aug 2020 21:44:12 +0000

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.

> 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
Received on 2020-08-14 23:44:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.