On Tue, Aug 24, 2021 at 02:37:57AM -0700, Robby Zinchak wrote: > Oh, hello all :) > > Yeah, between this cli obstacle, problems with rapidsvn corrupting local > repo during file moves, and svn Apache frequently corrupting server repo > unrecoverably in large check-ins (>200mb) and requiring a nuke and reload > from backup... it's been pretty rough year for my use cases of svn. :'(
I am sorry to hear that you have been having much so trouble with SVN lately. It would be interesting to learn more about repository corruption issues and how they could be prevented, but this is unrelated to the discussion at hand. Let's try to keep a positive outlook on things :) > I have been using the stored credential work around (thanks for that), but > it's hard to imagine new users finding this thread to know about > undocumented workaround. I agree that a script is unlikely to get as the same level of exposure as a built-in command would receive. > Stefan - I recall the previous behavior being to warn the user that > password is being stored in plaintext during entry. That seems like it > would somewhat mitigate the evil actor using an official svn build threat > case. This prompt can be disabled in the run-time configuration, which Eve would not hesitate to take advantage of. > The big Pandora's Box here is that if someone has shell access, they > can probably install or alias their own binary that does even more > nefarious things, making any official behavior moot except for systems that > only allow specific executable hashes to run. (And even then, a shell > script could mimic svns output in a phishing style attack). Sure, the story doesn't end here. Eve will always be looking for another trick. But only if forced to! What matters is that these are additional hoops to jump through and may be easier to identify as something out of the ordinary. Whereas the previous attack was trivially concealed as harmless configuration file edits apparently made by Alice herself.
