On Fri, Jan 21, 2022 at 6:39 PM Karl Fogel <kfo...@red-bean.com> wrote:
> >2) If we have to add a new compile option, then I suggest we go > >all > >the way and also close the backdoor that exists. IOW, if svn is > >compiled without plaintext support then it also should not be > >able to > >read an existing stored plaintext credential. > > That was a deliberate compatibility move, and I'm not sure we > should change it. Can you describe the harm that would come from > keeping that behavior vs changing it as you describe above? I > guess I don't see how it's a "backdoor". 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. Mark
