On Fri, Jan 21, 2022 at 7:22 PM Karl Fogel <kfo...@red-bean.com> wrote: > > On 21 Jan 2022, Mark Phippard wrote: > >One aspect of the previous thread that came up is that someone > >demonstrated a simple script to create a cached password (as a > >workaround for current users). That is what led to the idea of > >formalizing this using the svn auth command to create this file. > > > >I am the only one calling this a backdoor. I am saying that if I > >am an > >admin that does not want plaintext passwords being cached and you > >then > >create a simple way to do exactly that, then that is a backdoor > >around > >the policy I wanted. Maybe it is not the right term to use > >here. I am > >just saying if we are going to make someone compile their own > >binaries > >we might as well at least give them what they want. > > > >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. That said, I do not have a strong opinion on this one. Mark
