On Mon, Aug 23, 2021 at 1:50 PM Nathan Hartman <hartman.nat...@gmail.com> wrote: > > On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn <jcor...@gmail.com> wrote: >> >> 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 > > > > Given the amount of complaints/trouble this change has led to, perhaps we > should rethink it and consider an approach where plaintext saving is always > compiled in but off until enabled by runtime config or something. > > In the meantime, even with plaintext support compiled out, SVN always > supports using passwords that are already stored.
Yes, I know. But with passwords being changed regularly, that's not going to help for long. > So, as a workaround, is it an option to use either Daniel Shahaf's zsh script > or Daniel Sahlberg's python script (both upthread I think) to store the > needed passwords? Thanks, those are good efforts (and thanks to both Daniels for writing them), but I'm afraid those workarounds are not good enough. The thing is: this is not for me alone. This needs to be handled in buildscripts that can be run by around 50 developers. I don't want to explain to them how to run an additional script when the password has been changed (and how / where do I manage the "canonical version" of such a script etc). I also don't want to write the additional plumbing in our buildscripts to automate this (capture a pwd failure from svn; propose to the user "hey, maybe the password was changed, want to type in a new one?"; run external script and handling its possible errors; all transparent to the user / dev that really doesn't want to know about all this ...). Maybe I should take a closer look at gnome-keyring or one of the alternatives, but ... first have to gather some energy to climb that hill. -- Johan
