Hi,
I would like to reboot this thread once again. I have read through all
messages and I have tried to make a summary of the important points. The
date/time references are as seen in
https://mail-archives.apache.org/mod_mbox/subversion-dev/.
There are numerous descriptions of problems with the different keyrings. I
think the most important are:
- Some requiring GUI boxes to unlock, even showing GUI boxes on the local
display while running over SSH
- No easy way to work with the keyrings non-interactive
The original request was to find some way to store credentials in the
plaintext cache.
Two different solutions have been presented:
- Reverting the compile time default to enable the plaintext password
store, while setting runtime configuration options to disable it, following
the example set by OpenBSD.
Four persons seem to have expressed support for this idea (Mark Phippard,
Johan Corveleyn, myself (2021-08-26 13:34 to 2021-08-27 07:56) and Martin
Edgar Furter Rathod (2021-08-31 12:46)). The former three prefering it over
the svn auth, but accepting the idea of svn auth. Martin suggested to move
the plaintext support to a separate library that could be installed
separately (or removed after installation), no-one picked up this idea.
- Adding an svn auth add command
One person seem to have expressed support for this (Stefan Sperling
(2021-08-24 08:27 and again 2021-08-27 12:40)). The first message is the
earliest suggestion of svn auth add that I can find. In the latter message,
Stefan clarifies that he belives svn auth add is the better design but
wouldn't stand in the way of consensus. He also wrote he had been willing
to invest time in writing the code for svn auth add but not for switching
the default compile-time behaviour.
Regarding the need to validate the credentials with the server, it seems
this was based on pseudocode by Johan Corveleyn (2021-08-24 14:25) doing
svn ls, and then asking for a new password if svn ls failed. It was
mentioned by Daniel Shahaf that svn ls might succeed even if the
credentials were incorrect (as with svn.apache.org offering anonymous
access) or that the check only verified "r" access and later code might
require "w" access.
It seems to be a general agreement that it is currently not possible to
validate if some credentials have a certain level of access to a certain
path, in a general case. It was suggested to add RA API calls, but these
would only work with new versions of both the server and the client.
There has been a significant discussion whether to verify the credentials
and whose responsibility it is to store correct credentials (with
appropriate access).
---- This is the end of the summary. Below are my personal reflections
I have ignored the discussion regarding rethorics since I hope we can
continue without it. If someone feels hurt because of the discussion I hope
it can be worked out without affecting the future discussion in this
thread. I think all contributors have come with valuable input on the
design questions so far.
It seems most messages are concerning the svn auth add solution. To add
this command without contacting the server seems to be quite a bit of code
but not impossible. It would also be a client-side only solution not
requiring any specific server version. To add support on the server side
might be difficult, especially considering that (part of) the
authentication/authorization might be done outside of the Subversion code.
The decision to change the compile time default was made in 2018-10-31
within less than 12 hours and without much debate. It was committed less
than 19 hours after the initial message.
I'm assume the impact of an incorrect password in the store is application
dependant but a password can grow stale even if it was correct at the time
of writing so the administrator would have to manage this anyhow. From my
point of view, verifying the credentials is nice but not necessary to solve
the initial use case.
Until we completely remove the possibility to read the plaintext store
security conscious organisation might have issues. Having svn auth add as
an official command makes it more obvious that this possibility exists -
instead of users running unofficial scripts or even manually editing the
config files. Anyone who feel it should not even read the plaintext
password store could convince their vendor to remove it or roll their own.
---- Below is my understanding of the decision tree and my proposal:
The first point where we must reach agreement is whether or not to do
anything at all:
* There has been several complaints from several different users over
the last years who's workflow has been interrupted. There may be users
or organisations who disprove of storing passwords in the plaintext
stores. Whatever we choose there will be someone who feels we make
the wrong choice.
* If we decide it is a reasonable use case store passwords in plaintext
and that we should support writing this store we need to decide which
solution to use:
* Revert r1845377 and enable plaintext password store by default. I
have not been able to find any complaints in the public archives
about subversion's ability to store passwords in plaintext. As
pointed out by Stefan Sperling (2021-08-24 08:27) there was a FAQ
entry based on the nature of complaints received, some that might
have gone directly to the companies involved in Subversion
development.
* Create an svn auth add command. This option has the advantage that
one person has expressed interest to invest time to write the code.
* Script in contrib. The least visible option and several people
have expressed that it will be difficult for them to maintain a
local copy of the script. Only advantage is that it gives us
plausible deniability: "Subversion doesn't store passwords but
we can't prevent your users from downloading a script and using".
* If we go for svn auth add we must decide how important it is to
verify that the credentials have the correct access.
Based on the reasoning above I'm proposing:
- Adding an svn auth add command that more or less does what the scripts
are already doing. It should require typing the password in a loop until
repeated correctly but not do anything to verify that the password is
correct. Anyone requiring to validate the password can do it with an
appropriate svn command based on their authn/authz setup and their
requirements.
- Adding this in SVN 1.15.0.
I don't have much time to contribute but I will help as much as I can in
testing.
Kind regards
Daniel Sahlberg
