Den tis 28 mars 2023 kl 18:56 skrev Nathan Hartman <hartman.nat...@gmail.com >:
> On Tue, Mar 28, 2023 at 10:35 AM Daniel Sahlberg > <daniel.l.sahlb...@gmail.com> wrote: > > [...] reverting the previous change and changing the default config. I > don't know (didn't check, no time) what the default config is right now and > if it can be interpreted as "don't cache passwords" for old clients being > updated. > [...] * Set the default run-time config to store-plaintext-passwords = no > (if it isn't already; haven't checked) and instruct users on how to > change it. This makes the decision to store in plaintext an explicit > one that the user can opt into. (I appreciate that this could be > changed without the user's knowledge; perhaps the systemwide config > should always take precedence over the user-controlled one for this > setting?) > If I read the code correctly (subversion/libsvn_subr/auth.c) this is controlled by store-plaintext-passwords in the servers file. The default is SVN_CONFIG_DEFAULT_OPTION_STORE_PLAINTEXT_PASSWORDS, defined in subversion/include/svn_config.h to SVN_CONFIG_ASK. In the default servers file (see svn_config_ensure in subversion/libsvn_subr/config.c), the default config file has never had a setting for store-plaintext-passwords. If the user has not edited the servers file, we can change the default to no (probably FALSE, in svn_config.h) and have the same behaviour in 1.15 as in 1.12 to 1.14 even if we enable storing plaintext passwords compile-time. If someone has edited the servers file, I believe we have three cases (for default compile-time options): store-plaintext-passwords=yes: In pre-1.12: storing passwords without asking, 1.12 to 1.14: not storing/not asking, 1.15-later: storing passwords without asking. store-plaintext-passwords=no: In all versions: not storing/not asking. store-plaintext-passwords=ask: In pre-1.12: asking about storing passwords, 1.12 to 1.14: not storing/not asking, 1.15-later: asking about storing passwords. Disadvantages to making the above reversal: The FAQ entry will become > more complicated; possible complaints from those who prefer that the > client not support plaintext cache writing at all. > I'm sure we can come up with some cleaver wording in the FAQ, but good thing you brought this up so we don't forget. I would argue that since Subversion is open source, it is very easy for a user to compile their own version of Subversion and run it, so the administrators have very little options to control this anyway (unless it is possible to limit the executables that are possible to run on a machine - in Windows it would be possible with a group policy but I don't know what can be done in SELinux, much less in the different Unix flavours). As argued by Danielsh in the other threads, it is easy to pass the password on the command line or to write scripts to automatically answer the password prompt. So any administrator efforts to limit this will have little effect anyway. Kind regards, Daniel
