On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak <s...@editingarchive.com> wrote: > > Small rant here from a very long time subversion user, regarding subversion > project's decision to compile out plaintext password storage by default > (https://marc.info/?l=subversion-commits&m=154101482302608&w=2). > > There are a tremendous number of scenarios where users would desire to use > subversion without a keyring -- for me, that's today running Ubuntu 20.04 and > trying to set up an automated subversion client on a server VM. I obviously > can't be logging into a keyring every time the server reboots, that'd be > idiotic. > > I cannot fathom how the team thought this was a good decision. It reeks of > devs thinking "we know better, force the users to do it this way," without > actually understanding the needs of your users. > > I'm left with four solutions as far as I can see it: > > 1) Crowbarring one of the supported keyrings into not needing a keyring > password. Assuming this is even possible, it seems like a lot of extra work > with no benefit, and added fragility. I am loathe to dive into a whole set > of docs to try and figure this out (assuming it's even possible), when the > old methods worked just fine. > > 2) Compiling my own subversion with the enable-plaintext-password-storage > flag -- obviously insecure since there's no way I'll be able to keep up with > software updates. And I've heard it's quite difficult to compile subversion, > so that'll waste precious time I could be spending on something else that's > actually productive for my business. > > 3) Finding an ubuntu package overlay by a third party, questionably insecure > since now I have to trust an unofficial/unvetted third party with providing > svn builds. > > 4) Bite the bullet and just switch to another VCS > > Every time version control comes up in dev conversations among my peers, I go > to great lengths to defend SVN against the many criticisms my peers level at > it and promote it to other devs looking for a quality VCS. But honestly this > decision is one of the most myopic ones I've seen in years on any software > project and reeks of the project developers making an idealistic stand that > inconveniences users with no practical real-world benefit. The decision > should be left to the user, rather than forcing them into a difficult > situation. The earlier change to make plaintext something users have to > intentionally opt into makes total sense so that users are aware of what > they're opting into - but removing it entirely is too far. I guarantee you, > right now there are people trying to puzzle through this stack overflow > answer, giving up, and switching to git. > (https://stackoverflow.com/questions/2899209/how-to-save-password-when-using-subversion-from-the-console) > This is a downright awful decision for the overall long term health of > what's left of the subversion userbase. > > I would love to hear what the expected workaround is for users running > automated subversion clients on server VMs, because all the options look > rather terrible. > > Thanks for listening to my rant, and be assured it comes only from a place of > wanting to see subversion succeed. > > Best, > Robby
Late to te party, but I have to agree with Robby here. I'm only running into this now, since we'd like to upgrade the 1.9 client on our Solaris build machine to a more recent version ... sigh. I know the decision to disable plaintext pwd storage by default was briefly discussed on this very list [1], but sadly I didn't pay attention back then. I have a lot of respect for all people involved here, but I think this was a mistake, especially WRT server machines which don't have a GUI, no X11 etc. Or even if they have it installed, why force additional work on users / sysadmins that have been running these machines for years, and now have to jump through additional hoops, even if they decided before (through explicit configuration) that they were OK with plaintext password storage (= their decision / responsability). I have been defending Subversion at my company for a long time, highlighting its stability, simplicity and care for *backwards compatibility*. Unfortunately, backwards compatibility is broken here (I understand security can trump backwards compatibility, but to me this feels more like a "let's make this even more inconvenient" kind of security; not plugging a glaring security hole). So there goes one of my most important arguments pro SVN :-(. I know Stefan Sperling suggested in a reply to convince package maintainers, if necessary, to re-enable it with a configure flag (as he did for OpenBSD). But isn't that world upside down? Should every packager now explicitly enable it? Why not leave the default as it was, and tell package maintainers to disable it if they feel sensitive about this? Anyway, concerning package maintainers, for Solaris, I'm getting even more depressed ... * We were using Collab.net's distro, but apparently their Solaris build is no longer maintained: https://www.collab.net/downloads/subversion * Wandisco then? Nope: https://www.wandisco.com/source-code-management/subversion#solaris ... only Windows, Linux and MacOS. * Fortunately, there is still a relatively recent build on OpenCSW: https://www.opencsw.org/packages/subversion/ (-> Wandisco's link should be removed from http://subversion.apache.org/packages.html#solaris -- making that section empty ... or should we add a link to opencsw then?) (-> this abandoning of packagers / maintainers makes me feel our ecosystem is breaking down) So I guess my best shot is contacting the maintainer of the openCSW package, and asking him to add the --enable-plaintext-password-storage configure flag and make a new build then. Building it ourselves is not an option. [1] https://lists.apache.org/thread.html/6751582f2d8eda885722933f935a3c90d1b0adb0f9c9dbe536a5c2d7%40%3Cdev.subversion.apache.org%3E -- Johan
