On Thu, Jan 20, 2022 at 11:50 PM Karl Fogel <kfo...@red-bean.com> wrote: > > On 20 Jan 2022, Mark Phippard wrote: > >I have made the suggestion before and I want to say there was > >agreement from anyone that responded. So if nothing else anyone > >that > >objects to this is not speaking up. I think the main issue is > >that no > >one has wanted to step forward and make the change. > > > >I think we all know there are people who legitimately want the > >additional security. They are either not reading any of this or > >have > >decided they can accept having a compile time option and just > >want to > >wait and see what happens. Most likely it is the former. > > > >Making the change can at least make them come forward again. > > I've changed the Subject line to reflect that I'm concretely > proposing now that we do this. I'll volunteer to do it, though am > happy for anyone else to as well. > > I think it's just a matter of reverting r1845377, right? (And > updating CHANGES, etc.) > > If someone knows a reason why it's more complex than what I've > described above, please speak up.
First off, thanks for volunteering. In terms of what needs to be done, maybe I am wrong, but I did not think we had any mechanism in place where someone could choose not to compile in support for this feature. So that is new code that would need to be added. Putting the hat on of someone that wants to turn off plaintext passwords ... 1) I think there should be an easy way to know if the support exists or not. I am thinking "svn --version" maybe prints out if plaintext is available? So an admin could run this command and would look to confirm they do NOT see that in the output? Maybe this already exists? 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. I think closing the backdoor would be a nice addition to help soften any wounds this change creates. Mark
