On Sun, Oct 3, 2021 at 12:39 PM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > > 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
Thank you for picking this up again, Daniel. It's tempting to think consensus is within reach, and we've not really heard that many complaints of subversion's plaintext storage feature (as Daniel Sahlberg's search did not find any). However, before we proceed any further, and potentially shoot ourselves in the foot again, I think it's important to have a good enough picture of both sides of the argument. Now, I do remember one particularly vocal participant on users@ who regularly brought up the issue: Nico Kadel-Garcia. If you search the users@ archives for posts from Nico, in combination with "plaintext" or "clear text" or some similar keyword, I'm sure you'll find several interesting posts (regardless whether or not you agree with them). (sidenote: unfortunately, it's pretty hard to search the entirety of our archives this way -- somehow the different archives find different matches, but none find all of them -- searching my own gmail archive worked best, but obviously that's not portable) I've quickly selected a couple of them: https://svn.haxx.se/users/archive-2006-07/0591.shtml https://svn.haxx.se/users/archive-2006-08/1006.shtml "In fact, I'd *love* to be able to compile Subversion so that it's svn client refuses to store such passwords. If I wrote in such a compile-time option as a patch, could I get support for it? I'd definitely prefer to see the clients compiled this paranoid way. " https://svn.haxx.se/users/archive-2010-07/0179.shtml https://svn.haxx.se/users/archive-2010-08/0000.shtml https://svn.haxx.se/users/archive-2010-10/0133.shtml https://svn.haxx.se/users/archive-2011-12/0161.shtml "The other, and more powerful reason, is that Linux and UNIX clients for Subversion store the passwords, by default, as plain-text in a well-known location in your home directory. It's possible to set up more clever password storage schemes, such as Gnome or KDE "wallets", but they remain awkward and difficult to use for unattended behavior such as nightly auto-build systems. So wherever feasible, I use svn+ssh. I've also seen reports that Kerberized access can work well, ..." https://svn.haxx.se/users/archive-2012-06/0311.shtml "It's also unreliable, since *any* arbitrary client can and will store the plain-text password for HTTP or HTTPS access *unless* you can control the client setups enough to block the feature." https://svn.haxx.se/users/archive-2012-12/0058.shtml https://mail-archives.apache.org/mod_mbox/subversion-users/202102.mbox/%3CCAOCN9rzwh2Dht8%2BU2siK3x-srAuD%3DKvXE0ype8Tu%2Bo7eTt8juw%40mail.gmail.com%3E Also, we seem to have a wiki page about our options (and possible future avenues) for (encrypted) password storage: https://cwiki.apache.org/confluence/display/SVN/EncryptedPasswordStorage Now, I know it's not easy to rehash old arguments and look back at discussions from years ago. Nonetheless, I think it's important that we don't ignore them, and do what we can to analyse and understand the issue from all sides. I have copied Nico here in cc, so he might clarify / summarize / offer more suggestions / ... himself, if he wants to. Nico, I hope you don't mind that I've singled out your posts :-), but they are good examples of complaints about the plaintext password storage. Feel free to add more to this thread, or simply ignore it if you prefer. -- Johan
