Am Fri, 7 Aug 2020 05:53:24 +0000
schrieb Daniel Shahaf <d.s_at_daniel.shahaf.name>:
> > > should work: the compile-time knob prevents passwords from being
> > > _written_, but doesn't prevent passwords already there from being
> > > read.
Then it might be a nice idea to allow users to intentionally trigger
that write when they know what they are doing. Well, that was of course
what the old behaviour did, but a bit implicitly. Once could imagine a
new command to make it explicit. Something like
svn store-password $user $repo
.
But I suspect subversion devs don't fancy adding extra cruft to support
the use-cases for passwordless operation. I'm not sure what games one
could play with client certificates or similar. Storing the password is
for sure a lot simpler and doesn't need setting up svnserve with SASL
(although I did that for encryption).
Building it myself is not that hard. So I have my script that installs
svn with plaintext password storage and I use that as part of
bootstrapping our systems.
I'm preparing my little add-on rant as reply to the initial post to
give some more colour. Short version, in case I don't make it:
Disabling plaintext passwords makes it harder to keep using Subversion
in cases where it is truly superior to DVCS. For code development it's
hard to justify Subversion nowadays, when there's not even a standard
property to differentiate between author and committer of a patch (I
guess one could just define one by convention?). I keep using it for
existing projects but feel increasingly stupid for doing so, despite my
opinion of the file tree semantics being superior to branching/tagging
elsewhere.
Alrighty then,
Thomas
--
Dr. Thomas Orgis
HPC @ Universität Hamburg
Received on 2020-08-07 09:41:41 CEST