On Mon, Jan 24, 2022 at 5:02 PM Mark Phippard <markp...@gmail.com> wrote: > > On Mon, Jan 24, 2022 at 10:44 AM Daniel Shahaf <d...@daniel.shahaf.name> > wrote: > > > > > >I return to my "two camps" argument. The people that do not want > > > > >plaintext passwords to be cached ... do not want them being > > > > >cached. > > > > > > > > I see what you mean. > > > > > > > > If svn is compiled to not cache passwords, but a legacy cached > > > > password exists on disk for a given repository, should svn not > > > > only not read it but actually warn the user that the cached > > > > password exists? > > > > > > IMO, it is not necessary and if a compiler option disables the code > > > then I would envision we do not even have any code running that is > > > looking for those files to give the warning. > > > > Plaintext passwords are saved in the "password" element of the > > serialized hash in ~/.subversion/auth/svn.simple/. > > > > Those are the same files that cache the username when the username is > > cached without its password. > > > > We can't know whether a file contains a password or not until we have > > opened, read, and parsed it. > > > > So, "not even have any code running that is looking for those files" > > isn't an option (unless we're willing to throw away cached usernames > > even if they were cached without a password) > > > > So, what should we do if we have parsed one of those files and the > > resulting apr_hash_t contains a "password" key? > > > > Ignore it? Erase it (memset() it to zero)? Warn about it? Use it? > > Good points and excellent questions. If we would already be > discovering this file then I suppose we could do something. I would be > fine with just ignoring the cached password but some kind of other > option would also be good. > > > > And for that matter, should there be a configure option that disables > > the --password command-line option? It, too, can be used insecurely > > (see above about filesystem-level encryption). > > Also a good question. A configure option to disable this might be > appreciated by some users.
Is this issue on someone's radar? It seems the discussion died out here, and I can't find anything further. Maybe worth taking another look now that we're getting closer to 1.15? We seemed to get stuck "finding consensus on desired behaviour". Various proposals were made, but none got over the "bar of objections", and we ran out of steam. Which leaves us with the status quo, however imperfect it is :-(. (This recently came up in my company, when we were looking at upgrading the svn client on a unix build machine -- oops can't upgrade past SVN 1.12 or so, because of the compiled-out plain-text pwd caching support) For some background (warning long read): https://lists.apache.org/thread/b6g2hx2m3s117wcmno08opl874ons3q8 https://lists.apache.org/thread/shzxh04l493qnj8pdt8vl0x4gkjrkvcy -- Johan
