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. Mark