Thanks for taking the time to summarize the thread as well as the additional research you added.
On Sun, Oct 3, 2021 at 6:39 AM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > The decision to change the compile time default was made in 2018-10-31 within > less than 12 hours and without much debate. It was committed less than 19 > hours after the initial message. I had been wondering about this. It is interesting how quickly such an impactful decision was made. My recollection is that it was one of those "security trumps everything else" arguments where the impact was just brushed away. I kind of wish someone would just make the equally quick decision to reverse this commit so it could all be discussed again as I obviously think it was the wrong decision. > Until we completely remove the possibility to read the plaintext store > security conscious organisation might have issues. Exactly. This is why my preference is to put the feature back by default and if we do anything it should be to have a compile time option that security conscious orgs can use to completely remove the possibility. As I was responsible for the SVN product @ CollabNet for 14 years most of these customer complaints made their way to me eventually. I do not want to go so far as to say customers were satisfied with all of the warnings and options we had added over the years to give them some control over the plaintext feature, but I do recall most of the questions stopped coming in. What customers wanted was password caching that was more secure. I cannot recall a single customer that was ever satisfied with GNOME, KWallet or GPG options. I actually think most of them would have been happier if we just stored the password as a Base64 or ROT13 string .. of course they would have preferred some kind of encryption. I am sure we had a handful of customers that had a security team that would be happy with the new defaults because their mission is security and they do not care what havoc it wreaks on developer productivity. That said, these types of customers would probably be extremely unhappy if they realized there was a backdoor way to still have a plaintext password stored and used. So this type of user will not be happy with the svn auth add approach or the fact that there is a scripting option out in the wild. This is why my suggestion is we put things back the way they were prior to this change with all of the warnings and options we had etc. Then, what is really needed, is a compile time option that 100% removes all support for a plaintext password, even ones that are already stored. Finally, it has always been rejected out of hand as silly or deceptive, but I would just reiterate that most of these customers would be happy if we just used Base64 to store the plaintext password. We could also use real encryption and they would be even happier. The problem with that of course is the key. I would suggest we just store the default key in the source code. We know it is not truly secure but it would at least require non-trivial scripting that was specific to our encryption and we could support a compile time option to supply a different key which would actually make it fairly secure. We made a custom SVN client for one customer where we essentially did this for them. We told them the tradeoffs and that it was not really security but it was what they wanted and it satisfied their audits and requirements. Given that I am no longer @ CollabNet I cannot really help in terms of sharing the code we wrote. I know it was a hack for sure and not done in a way that we would commit as is. Thanks Mark
