On Sun, Oct 3, 2021 at 7:17 PM Johan Corveleyn <jcor...@gmail.com> wrote: > > On Sun, Oct 3, 2021 at 12:39 PM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> > wrote: > > > > Hi, > > > > I would like to reboot this thread once again. I have read through all > > messages and I have tried to make a summary of the important points. The > > date/time references are as seen in > > https://mail-archives.apache.org/mod_mbox/subversion-dev/. > >
(snip) Thanks, Daniel, for restarting the discussion and for this detailed summary. I agree that whatever direction we take on this, we should do so after some careful thought. Currently I like the idea of 'svn auth --add' in combination with Mark's idea to scramble the password using a built-in key that could be changed at compile time, plus a compile-time option to eliminate all support for plaintext passwords. Like all other proposed solutions, this comes with a few caveats: Danielsh once pointed out (I can't seem to find the email now, so I'm paraphrasing, hopefully accurately) that if the SVN client is built with no support for plaintext passwords whatsoever, users may be unaware that there are passwords cached on their system, leftover from earlier clients. I don't currently have any viable suggestion about this, other than documenting it. As Mark points out, the idea to just scramble the password has been criticized, but since we are calling it a *plaintext* cache, and we don't claim that it's secure by any means, I think a little bit of obfuscation is slightly better than no obfuscation at all. It also (deliberately) makes it non-trivial to read/write the passwords via scripting, which is the intention but may come with side effects for anyone who needs to do so without using the SVN client binary or library, for some legitimate purpose, though I don't know whether there are actually any such use cases. I like the idea Martin brought up: to put the plaintext support into a separate library that could be removed or installed separately, but this idea comes with the following challenge: if SVN is installed by a package manager and the user subsequently (manually) removes a library, the package manager will probably reinstall it again later, possibly without the user noticing; to work correctly, the plaintext support library would need to be provided by a separate package; this then becomes additional work for the package maintainer, who may not be aware that a separate optional package is needed. Johan wrote: > Also, we seem to have a wiki page about our options (and possible future > avenues) for (encrypted) password storage: > https://cwiki.apache.org/confluence/display/SVN/EncryptedPasswordStorage > I haven't yet studied the CWIKI page mentioned (thanks for pointing it out). I'm a bit short on time today but this is a good discussion. Thanks to everyone for participating. Cheers, Nathan
