[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

A strong WTF on compiling out plaintext password support by default?!

From: Robby Zinchak <sim9_at_editingarchive.com>
Date: Thu, 6 Aug 2020 18:56:55 -0700

 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. (
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.

Received on 2020-08-07 07:01:18 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.