Oh, hello all :) Yeah, between this cli obstacle, problems with rapidsvn corrupting local repo during file moves, and svn Apache frequently corrupting server repo unrecoverably in large check-ins (>200mb) and requiring a nuke and reload from backup... it's been pretty rough year for my use cases of svn. :'( I have been using the stored credential work around (thanks for that), but it's hard to imagine new users finding this thread to know about undocumented workaround.
Stefan - I recall the previous behavior being to warn the user that password is being stored in plaintext during entry. That seems like it would somewhat mitigate the evil actor using an official svn build threat case. The big Pandora's Box here is that if someone has shell access, they can probably install or alias their own binary that does even more nefarious things, making any official behavior moot except for systems that only allow specific executable hashes to run. (And even then, a shell script could mimic svns output in a phishing style attack). On Tue, Aug 24, 2021, 1:27 AM Stefan Sperling <s...@elego.de> wrote: > On Mon, Aug 23, 2021 at 09:05:33PM +0200, Daniel Sahlberg wrote: > > Has there been any complaints about Subversion's ability to store > passwords > > in plaintext? > > Of course :) Years ago, before any encrypted storage was available > on Unix systems, this was a common complaint. > > The FAQ entry which you improved in https://svn.apeche.org/r1887129 > was previously using language which reflected the nature of complaints > that were received: "Ahhh! I just discovered that my Subversion client > is caching passwords in plain-text on disk! - AHHH!" > > > (I tried to search the mailing list but didn't come up with > > anything, possibly because of a lack of imagination on proper keywords). > > Maybe these complaints would have gone to the different distributions? > > Perhaps some of them arrived via internal support channels of the various > companies involved in SVN's development. Not all communication with users > occurs via public channels. > > > For reference, here is the e-mail where Stefan Sperling mentions the > change > > in OpenBSD to re-enable support for plaintext passwords in OpenBSD: [2] I > > would encourage everyone to re-read that message since it has a good > > summary of arguments (including a link to a request from a corporate > > security group to TortoiseSVN to avoid storing a password in plaintext in > > memory). > > > > For me the route taken by OpenBSD seems reasonable: > > - Enable plaintext passwords in the compile time defaults > > - Disable plaintext passwords in the default runtime configuration > > - Let the users re-enable it in their configuration if they want to > > > > Pros: > > * It would not change the default behaviour. > > * It would enable users to enable plaintext passwords in configuration > > without having to recompile. > > > > Cons: > > * Potentially some security group would argue about the possibility to > > enable plaintext passwords at all. > > As someone who supported the original change to disable this feature at > compile-time, I backtracked a bit when I saw the consequences on OpenBSD > servers where unattended operation of svn in scripts is relatively common. > > But I still think that Brane's concerns are warranted. > In particular (from #svn-dev IRC just now): > > 09:30 <@brane> the only issue i have with that is that users rarely look > at > ~/.subversion/config and may not even be aware that the > option > is enabled. > > A potential attack would be Alice leaving her desktop unlocked, > and Eve using this chance to enable the option in Alice's config. > Eve would also clear the password cache with svn auth --remove > and disable the plaintext password prompt by setting the appropriate > option in ~/.subversion/servers. > Now Alice comes back and uses SVN as usual, unaware that her password > is being cached in plaintext, perhaps assuming it is being cached in > encrypted storage as she would reasonably expect. > When Alice leaves her desktop unlocked another time Eve collects > Alice's SVN password from plaintext storage. > > The above may seem ridiculous to some (after all, Alice should not have > left her desktop defenseless!) but this is indeed a threat scenario > which is considered in some deployments. The TortoiseSVN discussion > linked earlier is based on a similar threat model where an unlocked > Windows desktop is abused to spy out passwords cached by TortoiseSVN, > which will reveal encrypted passwords in plaintext when asked to do so. > > To protect Alice from this attack, writing plaintext passwords must > remain disabled during regular usage of SVN. We could provide a special > mechanism to add a plaintext password under a set of conditions: > > - The command to run is not a regularly used SVN command. > 'svn auth' would be a good candidate since its sole purpose > is to inspect and manage the cached credentials store. > > - The user provides the password and authentication with this > password against the server succeeds. > > - If a non-plaintext storage backend is available, that backend > is used instead of storing the password in plaintext (but perhaps > the plaintext backend could be forced via a command line switch). > > - The user gives consent to the password being stored in plaintext > by answering 'yes' to the plaintext password prompt, in a way that > cannot be overridden by configuration files (i.e. the value of the > store-plaintext-passwords option in the servers configuration file > would be ignored by this command). > > We could have 'svn auth add https://svn.example.com/svn/foo' as a > one-shot operation that satisfies the above constraints, while leaving > all other code paths compiled out which would otherwise store passwords > in plaintext. A regular 'svn update' still won't cache a password in > plaintext, unless --enable-plaintext-passwords was passed at compile-time. > > Now Alice can store a plaintext password (and will be aware of its > existence), > but Eve cannot fool Alice into doing so unless Subversion was compiled with > the --enable-plaintext-passwords option. > > Would this work? > > Regards, > Stefan >
