Re: A strong WTF on compiling out plaintext password support by default?!
On 21 Jan 2022, Bernard Boudet wrote: - There should be a single option in the repository config to define whether that repo permits client-side plaintext password storage (or perhaps define which are the permitted/denied caching methods). Hmm. A design principle that I think is generally solid but is especially important in free software: since the server by definition cannot reliably dictate policy about matters that can't affect the server -- matters that the server cannot in fact even discern -- the server should to try to in the first place. It's like a chat app that obeys a server-sent signal to destroy a local copy of a message. That app is ultimately not serving the needs of the user whose hands are holding the device. There is a better way to achieve what you want: by distributing recommended run-time configurations to users (perhaps even by keeping those configurations under version control and distributing them that way!). This is a purely client-side issue, and client-side run-time config controls the client. If organizations want to influence client behavior, that run-time config is where to do it. If the organization wants to monitor the users' computers to see if that config is ever changed, well, I wouldn't want to work there, but they can do that -- it's common enough for organizations to monitor work-owned machines. Let me be very clear: if Subversion had this "feature", I would definitely be compiling my client to disobey the signal and lie to the server :-). Best regards, -Karl
Re: A strong WTF on compiling out plaintext password support by default?!
Hi all, The current situation makes certain work-flows, unworkable. It also encourages the use of a modified or out-dated client, to "get the job done", which then itself becomes a security risk more generally. Reverting to the "old way" and adding a compile-time option is viable, IMHO, only as a temporary solution in the absence of something better. Common pre-built distribution binaries benefit the user with convenience *and* security. From what I have read, it seems that a compile-time option will not be the final word on the matter. As for "auth add", as I understand it, this leaves open some security concerns, so would not be the final word on the matter either. The issue manifests itself at the client side. I will suggest it can be solved looking at the server side. This is my RFC (and bearing in mind I'm just an interested user/admin rather than a dev): - There should be a single option in the repository config to define whether that repo permits client-side plaintext password storage (or perhaps define which are the permitted/denied caching methods). - The configuration option should apply to the entire repository, that is it should be path independent. - The configuration option should apply regardless of client username. - The configuration option should apply regardless of read/write request. - The configuration may differ per repository, if the server instance serves multiple repos. - So I think it belongs in svnserve.conf. Then, either: - during authentication the client shall signal to the server the password storage method in use and the server shall deny auth if it cares - and/or the client shall have means to query the server as to permitted storage methods and determine its own behaviour accordingly - in any case, the user's work-flow should be unchanged from that as it has ever been. Default behaviours: - The default unconfigured behaviour should be that the server signals to the client that plaintext password storage is prohibited. - There should be no compile-time option in either the server or client to alter this behaviour. - There should be no run-time option in the client to alter this behaviour (obviously). Backwards compatibility: - When accessing an older server, the new client behaviour should be as it is currently. That is the user has no way to enable plaintext password storage. - For older version clients, the behaviour should be whatever it is currently for that version. - If that is unacceptable, the server could deny auth to prior version clients, with a separate run-time option to control this. In any case, if it's a problem, it's also one which is unaddressed by the current situation. - In case of an already stored plaintext password, use of this will be permitted only if the repository enables it. Benefits: - No change to client UI, documentation, or work-flow. - It is a simple matter for the admin to allow plaintext password storage for clients of their repository. - It provides for multiple repo's running from a single svnserve instance to dictate differing security models. - It provides for the user to access multiple repo's from their same client software, intentionally mixing password caching methods, and without fear of leaking important credentials. - Enforcement is at the central admin's discretion, as must be expected from an "Enterprise Class" solution. Flaws: - The scheme is dependent upon client software honouring the rules and can be defeated with hacked/rebuilt/ported client software, as is the case currently. - There are many authentication schemes. I don't know, but this could entail a lot of work. - Probably some things I haven't thought of. Sorry for rambling on. ;) I hope it may be of use, even if for now the "old way" is resumed. Bernard.
Re: [PROPOSAL] Allow plaintext passwords again. (was: Re: A strong WTF on compiling out plaintext password support by default?!)
On Fri, Jan 21, 2022 at 7:35 AM Mark Phippard wrote: > On Thu, Jan 20, 2022 at 11:50 PM Karl Fogel wrote: > > > Putting the hat on of someone that wants to turn off plaintext passwords > ... > > 1) I think there should be an easy way to know if the support exists > or not. I am thinking "svn --version" maybe prints out if plaintext is > available? So an admin could run this command and would look to > confirm they do NOT see that in the output? Maybe this already exists? Yes, svn --version does print this information. See near the end: [[[ $ svn --version svn, version 1.15.0-dev (under development) compiled Apr 12 2021, 15:50:36 on x86_64-pc-linux-gnu Copyright (C) 2021 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ WARNING: Plaintext password storage is enabled! The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.3.9 (compiled with 1.3.9) - handles 'http' scheme - handles 'https' scheme The following authentication credential caches are available: * Plaintext cache in /home/nate/.subversion * Gnome Keyring * GPG-Agent * KWallet (KDE) ]]] Cheers, Nathan
Re: [PROPOSAL] Allow plaintext passwords again. (was: Re: A strong WTF on compiling out plaintext password support by default?!)
On Thu, Jan 20, 2022 at 11:50 PM Karl Fogel wrote: > > On 20 Jan 2022, Mark Phippard wrote: > >I have made the suggestion before and I want to say there was > >agreement from anyone that responded. So if nothing else anyone > >that > >objects to this is not speaking up. I think the main issue is > >that no > >one has wanted to step forward and make the change. > > > >I think we all know there are people who legitimately want the > >additional security. They are either not reading any of this or > >have > >decided they can accept having a compile time option and just > >want to > >wait and see what happens. Most likely it is the former. > > > >Making the change can at least make them come forward again. > > I've changed the Subject line to reflect that I'm concretely > proposing now that we do this. I'll volunteer to do it, though am > happy for anyone else to as well. > > I think it's just a matter of reverting r1845377, right? (And > updating CHANGES, etc.) > > If someone knows a reason why it's more complex than what I've > described above, please speak up. First off, thanks for volunteering. In terms of what needs to be done, maybe I am wrong, but I did not think we had any mechanism in place where someone could choose not to compile in support for this feature. So that is new code that would need to be added. Putting the hat on of someone that wants to turn off plaintext passwords ... 1) I think there should be an easy way to know if the support exists or not. I am thinking "svn --version" maybe prints out if plaintext is available? So an admin could run this command and would look to confirm they do NOT see that in the output? Maybe this already exists? 2) If we have to add a new compile option, then I suggest we go all the way and also close the backdoor that exists. IOW, if svn is compiled without plaintext support then it also should not be able to read an existing stored plaintext credential. I think closing the backdoor would be a nice addition to help soften any wounds this change creates. Mark
[PROPOSAL] Allow plaintext passwords again. (was: Re: A strong WTF on compiling out plaintext password support by default?!)
On 20 Jan 2022, Mark Phippard wrote: I have made the suggestion before and I want to say there was agreement from anyone that responded. So if nothing else anyone that objects to this is not speaking up. I think the main issue is that no one has wanted to step forward and make the change. I think we all know there are people who legitimately want the additional security. They are either not reading any of this or have decided they can accept having a compile time option and just want to wait and see what happens. Most likely it is the former. Making the change can at least make them come forward again. I've changed the Subject line to reflect that I'm concretely proposing now that we do this. I'll volunteer to do it, though am happy for anyone else to as well. I think it's just a matter of reverting r1845377, right? (And updating CHANGES, etc.) If someone knows a reason why it's more complex than what I've described above, please speak up. Best regards, -Karl
Re: A strong WTF on compiling out plaintext password support by default?!
On Thu, Jan 20, 2022 at 4:06 PM Karl Fogel wrote: > So: shall we just go back to the old way, but with a compile-time option > to remove support for it? I have made the suggestion before and I want to say there was agreement from anyone that responded. So if nothing else anyone that objects to this is not speaking up. I think the main issue is that no one has wanted to step forward and make the change. I think we all know there are people who legitimately want the additional security. They are either not reading any of this or have decided they can accept having a compile time option and just want to wait and see what happens. Most likely it is the former. Making the change can at least make them come forward again. Mark
Re: A strong WTF on compiling out plaintext password support by default?!
On 20 Jan 2022, Mark Phippard wrote: ... my main idea has always been that we put things back the way they were. I would be completely in favor of that. The old status quo was fine: it presented warnings to users at the appropriate moments, and otherwise let them decide their own threat model, which they know best. For those who consider *any* support of plain text passwords to be a major security problem, you are right: they will not like any of these solutions, and that's not going to change. I think the way we already managed the warnings was the right way to handle this for camp 2. It was just enough warning to make a user aware without making it too difficult to use. What we then need to do is also add some new compile time option to disable plain text passwords. This would give the people in camp 1 an option. +1 to that plan. This problem only exists on *nix and the people in camp 1 are capable of solving this problem if we give them the tools to do so. Whereas the people in camp 2 are less able to solve it themselves. So I think our defaults should cater more to camp 2 and we should provide options that can be leveraged by camp 1 if they must go that route. Agreed. So: shall we just go back to the old way, but with a compile-time option to remove support for it? Best regards, -Karl
Re: A strong WTF on compiling out plaintext password support by default?!
On 20 Jan 2022, Stefan Sperling wrote: You may have missed that we have added the 'svn auth' command while you were not looking :) I totally did miss that :-). Removing cached creds can already be done with 'svn auth --remove'. Hah! Now that you mention it, I even remember learning about that (a while ago) and actually using it. What I don't remember is forgetting about it afterwards... Having both 'svn authn' and 'svn auth' commands would be confusing. The names are too close and the proposed functionalty overlaps. So I would prefer if the existing 'svn auth' command was extended. 100% agree. I like your proposal. Great! Best regards, -Karl
Re: A strong WTF on compiling out plaintext password support by default?!
On Wed, Jan 19, 2022 at 9:08 PM Karl Fogel wrote:
>
> This thread has been dormant for a while, but the question hasn't
> gone away. It would be great if we could reach a consensus. Here
> is a combined proposal (based on proposals quoted below from
> Daniel Sahlberg and Stefan Sperling):
>
> 1) Re-enable plaintext passwords in compile time defaults.
>
> 2) Disable plaintext passwords in default runtime configuration.
>Users can re-enable it in their configuration when they want
>it.
>
> 3) When running a regular Subversion command like 'update' or
> 'commit',
>if authentication is required and there is a "safe"
>password-storage mechanism available (such as kwallet or
>gpg-agent or whatever), then that safe mechanism would be used
>automatically, as it is today.
>
>But if no safe mechanism is available, *then* the user would be
>told to run 'svn authn' (see below).
>
> 4) There is a new 'svn authn' command to authenticate to any
>repository. E.g., 'svn authn [ --username jrandom ]
>REPOS_URL'.
>See detailed description of it below.
>
> The new 'svn authn' command is a generic entry point to
> authentication-related functionality.
>
> If you run 'svn authn' and a "safe" password-storage mechanism is
> available, then it'll just store the password using that mechanism
> -- the same way 'update' or 'commit' would have done.
>
> But when no safe mechanism is available, then 'svn authn' will
> print the big warning message that svn traditionally printed when
> about to store a plaintext password, and then, if the user
> indicates "yes", caches the password in plaintext in the same way
> we did before.
>
> Notice that, in practice, users will only be steered to 'svn
> authn' when there is no safe mechanism available, becuase
> otherwise whatever regular svn command they were running would
> have simply used the safe mechanism.
>
> Thus, users will not become habituated to using the 'authn'
> command. It'll be a rare event, and the user will be aware of
> what she's doing and be likely to read and understand the warning
> about plaintext password storage, instead of skimming or ignoring
> that warning because she's right in the middle of a common
> end-goal operation like 'update' or 'commit' and just wants to
> complete it as fast as possible.
>
> ('svn authn' could also support a '--remove' flag to clear out the
> authn cache for a given repository. It could also support
> wildcards / offer a way to clear auth for all repositories / offer
> a --remove-plaintext-passwords option to clear all plaintexts,
> etc. The point is, with this new subcommand, we would now have a
> UI entry point to a number of cleanup / change-one's-mind
> features.)
>
> I suggest the command name 'authn' rather than 'auth' in order to
> keep "authentication" (authn) distinct from "authorization"
> (authz). Although though we don't have an "authz" subcommand,
> Subversion does have server-side authz features, so keeping this
> distinction clear seems worthwhile. However, I don't feel
> strongly about it -- if everyone prefers "auth", I'm not going to
> argue too hard :-).
>
> Thoughts?
Before I say why I do not think this is the right approach, I want to
emphasize that I do think something needs to be done. So if this is
the proposal everyone agrees with then consider me a +1 as well.
That said ... I do not think this is the way to go.
Practically speaking, there are two camps here.
1. Those who consider any support of plain text passwords a major
security vulnerability. Potentially a deal breaker to their usage of
Subversion.
2. Everyone else (realizing that this camp is split across a wide
spectrum of levels of concern)
The current versions of SVN have swung the pendulum completely in
favor of the first camp. The problem I have with Karl's proposal is
that I do not think it really satisfies either camp.
The fact that the user can jump through a bunch of hoops and store a
password in plain text is still a deal breaker to camp 1.
The fact that the user has to jump through a bunch of hoops is not
very helpful to a lot of the users in camp 2.
In composing this reply I had an idea how we might satisfy both camps
and I have sent it to dev@ as a new thread. That said, aside from that
idea my main idea has always been that we put things back the way they
were. I think the way we already managed the warnings was the right
way to handle this for camp 2. It was just enough warning to make a
user aware without making it too difficult to use. What we then need
to do is also add some new compile time option to disable plain text
passwords. This would give the people in camp 1 an option.
This problem only exists on *nix and the people in camp 1 are capable
of solving this problem if we give them the tools to do so. Whereas
the people in camp 2 are less able to solve it themselves. So I think
our defaults should cater more to camp 2 and we should provide options
that can be leveraged by camp
Re: A strong WTF on compiling out plaintext password support by default?!
On Wed, Jan 19, 2022 at 08:08:06PM -0600, Karl Fogel wrote:
> ('svn authn' could also support a '--remove' flag to clear out the authn
> cache for a given repository.)
You may have missed that we have added the 'svn auth' command while
you were not looking :)
Removing cached creds can already be done with 'svn auth --remove'.
> I suggest the command name 'authn' rather than 'auth' in order to keep
> "authentication" (authn) distinct from "authorization" (authz).
Having both 'svn authn' and 'svn auth' commands would be confusing.
The names are too close and the proposed functionalty overlaps.
So I would prefer if the existing 'svn auth' command was extended.
I like your proposal.
Cheers,
Stefan
Re: A strong WTF on compiling out plaintext password support by default?!
On 20 Jan 2022, Dr. Thomas Orgis wrote: Am Wed, 19 Jan 2022 20:08:06 -0600 schrieb Karl Fogel : 2) Disable plaintext passwords in default runtime configuration. Users can re-enable it in their configuration when they want it. But when no safe mechanism is available, then 'svn authn' will print the big warning message The latter would happen with the default config, right? And the config setting would just disable the warning? I think it would be useless/overbearing nagging otherwise. No, actually I was thinking one would have to *also* enable plaintext-passwords in the config. If it's not enabled in run-time config, then 'svn authn' would first let the user know that she would have to enable it in run-time config. Once she has done so, 'svn authn' would then actually be able to store plaintext passwords. The regular svn command that led to 'svn authn' could also make the same point -- when recommending 'svn authn', it could also point out that run-time config would need to change before plaintext passwords are possible. (Open to discussion on all the above; I'm just clarifying what I meant in my original post.) But back on topic: Yes, please make use of simple password storage usable for everyone again. The use cases are real. Glad you agree! Best regards, -Karl
Re: A strong WTF on compiling out plaintext password support by default?!
Am Wed, 19 Jan 2022 20:08:06 -0600 schrieb Karl Fogel : > 2) Disable plaintext passwords in default runtime configuration. >Users can re-enable it in their configuration when they want >it. > But when no safe mechanism is available, then 'svn authn' will > print the big warning message The latter would happen with the default config, right? And the config setting would just disable the warning? I think it would be useless/overbearing nagging otherwise. > Notice that, in practice, users will only be steered to 'svn > authn' when there is no safe mechanism available I'll have to learn about how to use gpg-agent for this, for example. That might be workable for interactive cases. But I did not miss this dearly so far. I manage permissions server-side and thus have effectively machine-passwords for automated cases, and if somebody captures such, any bad actions are nicey documented on the server. (And if someone captures my running client's login session, as opposed to an encrypted backup, the safe password store is also lying open to any intruder.) A more interesting feature for long-term security of sensitive repository contents would be commit signing (easily added using properties?) that enables for example a cryptographic check of the complete history of code used in a CI/CD pipeline. You still would have your automated commits with those stored passwords, but they won't have signatures. Then, it would be a nice feature to be able review/sign those afterwards. But back on topic: Yes, please make use of simple password storage usable for everyone again. The use cases are real. Alrighty then, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg
Re: A strong WTF on compiling out plaintext password support by default?!
This thread has been dormant for a while, but the question hasn't
gone away. It would be great if we could reach a consensus. Here
is a combined proposal (based on proposals quoted below from
Daniel Sahlberg and Stefan Sperling):
1) Re-enable plaintext passwords in compile time defaults.
2) Disable plaintext passwords in default runtime configuration.
Users can re-enable it in their configuration when they want
it.
3) When running a regular Subversion command like 'update' or
'commit',
if authentication is required and there is a "safe"
password-storage mechanism available (such as kwallet or
gpg-agent or whatever), then that safe mechanism would be used
automatically, as it is today.
But if no safe mechanism is available, *then* the user would be
told to run 'svn authn' (see below).
4) There is a new 'svn authn' command to authenticate to any
repository. E.g., 'svn authn [ --username jrandom ]
REPOS_URL'.
See detailed description of it below.
The new 'svn authn' command is a generic entry point to
authentication-related functionality.
If you run 'svn authn' and a "safe" password-storage mechanism is
available, then it'll just store the password using that mechanism
-- the same way 'update' or 'commit' would have done.
But when no safe mechanism is available, then 'svn authn' will
print the big warning message that svn traditionally printed when
about to store a plaintext password, and then, if the user
indicates "yes", caches the password in plaintext in the same way
we did before.
Notice that, in practice, users will only be steered to 'svn
authn' when there is no safe mechanism available, becuase
otherwise whatever regular svn command they were running would
have simply used the safe mechanism.
Thus, users will not become habituated to using the 'authn'
command. It'll be a rare event, and the user will be aware of
what she's doing and be likely to read and understand the warning
about plaintext password storage, instead of skimming or ignoring
that warning because she's right in the middle of a common
end-goal operation like 'update' or 'commit' and just wants to
complete it as fast as possible.
('svn authn' could also support a '--remove' flag to clear out the
authn cache for a given repository. It could also support
wildcards / offer a way to clear auth for all repositories / offer
a --remove-plaintext-passwords option to clear all plaintexts,
etc. The point is, with this new subcommand, we would now have a
UI entry point to a number of cleanup / change-one's-mind
features.)
I suggest the command name 'authn' rather than 'auth' in order to
keep "authentication" (authn) distinct from "authorization"
(authz). Although though we don't have an "authz" subcommand,
Subversion does have server-side authz features, so keeping this
distinction clear seems worthwhile. However, I don't feel
strongly about it -- if everyone prefers "auth", I'm not going to
argue too hard :-).
Thoughts?
Ever since Subversion removed plaintext password caching, I have
watched users lives get harder (some of our company's trees are in
Subversion, so I get to watch a diverse group of people use
Subversion on a regular basis close up, and I heard the complaints
about this change).
Generally, a user knows enough about her actual threat model to
make informed decisions about whether to cache passwords locally.
And there are many situations in which the convenience of local
caching is *immense*, especially when automating Subversion
operations.
The decision (see r1845377) to disable password caching took away
users' ability to use their domain knowledge to make those
informed decisions. The justification was that sometimes people
might unknowingly put themselves risk -- while the threat model
might be rare, the consequences could be severe. This is
understandable, but I think in the end we picked the wrong place
on the security/convenience trade-off spectrum. The loss of
convenience is so huge that it's a make-or-break usability
question for many people.
While we can't reduce the risk to *zero*, we can reduce it pretty
far by implementing 1-4 above.
(By the way, by "plaintext" I just mean "not strongly encrypted".
I don't care if we rot13- or base64-encode it or whatever -- those
seem like good ideas, to avoid non-malicious exposure events, but
IMHO doing or not doing that encoding isn't central to this
proposal.)
Things like kwallet / gpg-agent / etc are great and I use them
every day, but they are not trivial to set up nor reliable for
many users. They also aren't available in some situations anyway
(again, especially in automated operations in constrained
environments).
Best regards,
-Karl
On 24 Aug 2021, Stefan Sperling wrote:
On Mon, Aug 23, 2021 at 09:05:33PM +0200, Daniel Sahlberg wrote:
Has there been any complaints about Subversion's ability to
store passwords
in plaintext?
Of course :)
Re: A strong WTF on compiling out plaintext password support by default?!
On Sun, Oct 3, 2021 at 7:17 PM Johan Corveleyn wrote: > > On Sun, Oct 3, 2021 at 12:39 PM Daniel Sahlberg > 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/. > > (snip) Thanks, Daniel, for restarting the discussion and for this detailed summary. I agree that whatever direction we take on this, we should do so after some careful thought. Currently I like the idea of 'svn auth --add' in combination with Mark's idea to scramble the password using a built-in key that could be changed at compile time, plus a compile-time option to eliminate all support for plaintext passwords. Like all other proposed solutions, this comes with a few caveats: Danielsh once pointed out (I can't seem to find the email now, so I'm paraphrasing, hopefully accurately) that if the SVN client is built with no support for plaintext passwords whatsoever, users may be unaware that there are passwords cached on their system, leftover from earlier clients. I don't currently have any viable suggestion about this, other than documenting it. As Mark points out, the idea to just scramble the password has been criticized, but since we are calling it a *plaintext* cache, and we don't claim that it's secure by any means, I think a little bit of obfuscation is slightly better than no obfuscation at all. It also (deliberately) makes it non-trivial to read/write the passwords via scripting, which is the intention but may come with side effects for anyone who needs to do so without using the SVN client binary or library, for some legitimate purpose, though I don't know whether there are actually any such use cases. I like the idea Martin brought up: to put the plaintext support into a separate library that could be removed or installed separately, but this idea comes with the following challenge: if SVN is installed by a package manager and the user subsequently (manually) removes a library, the package manager will probably reinstall it again later, possibly without the user noticing; to work correctly, the plaintext support library would need to be provided by a separate package; this then becomes additional work for the package maintainer, who may not be aware that a separate optional package is needed. Johan wrote: > 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 > I haven't yet studied the CWIKI page mentioned (thanks for pointing it out). I'm a bit short on time today but this is a good discussion. Thanks to everyone for participating. Cheers, Nathan
Re: A strong WTF on compiling out plaintext password support by default?!
On Sun, Oct 3, 2021 at 12:39 PM Daniel Sahlberg 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. >
Re: A strong WTF on compiling out plaintext password support by default?!
Thanks for taking the time to summarize the thread as well as the additional research you added. On Sun, Oct 3, 2021 at 6:39 AM Daniel Sahlberg wrote: > 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 had been wondering about this. It is interesting how quickly such an impactful decision was made. My recollection is that it was one of those "security trumps everything else" arguments where the impact was just brushed away. I kind of wish someone would just make the equally quick decision to reverse this commit so it could all be discussed again as I obviously think it was the wrong decision. > Until we completely remove the possibility to read the plaintext store > security conscious organisation might have issues. Exactly. This is why my preference is to put the feature back by default and if we do anything it should be to have a compile time option that security conscious orgs can use to completely remove the possibility. As I was responsible for the SVN product @ CollabNet for 14 years most of these customer complaints made their way to me eventually. I do not want to go so far as to say customers were satisfied with all of the warnings and options we had added over the years to give them some control over the plaintext feature, but I do recall most of the questions stopped coming in. What customers wanted was password caching that was more secure. I cannot recall a single customer that was ever satisfied with GNOME, KWallet or GPG options. I actually think most of them would have been happier if we just stored the password as a Base64 or ROT13 string .. of course they would have preferred some kind of encryption. I am sure we had a handful of customers that had a security team that would be happy with the new defaults because their mission is security and they do not care what havoc it wreaks on developer productivity. That said, these types of customers would probably be extremely unhappy if they realized there was a backdoor way to still have a plaintext password stored and used. So this type of user will not be happy with the svn auth add approach or the fact that there is a scripting option out in the wild. This is why my suggestion is we put things back the way they were prior to this change with all of the warnings and options we had etc. Then, what is really needed, is a compile time option that 100% removes all support for a plaintext password, even ones that are already stored. Finally, it has always been rejected out of hand as silly or deceptive, but I would just reiterate that most of these customers would be happy if we just used Base64 to store the plaintext password. We could also use real encryption and they would be even happier. The problem with that of course is the key. I would suggest we just store the default key in the source code. We know it is not truly secure but it would at least require non-trivial scripting that was specific to our encryption and we could support a compile time option to supply a different key which would actually make it fairly secure. We made a custom SVN client for one customer where we essentially did this for them. We told them the tradeoffs and that it was not really security but it was what they wanted and it satisfied their audits and requirements. Given that I am no longer @ CollabNet I cannot really help in terms of sharing the code we wrote. I know it was a hack for sure and not done in a way that we would commit as is. Thanks Mark
Re: A strong WTF on compiling out plaintext password support by default?!
On Sun, Oct 03, 2021 at 12:38:48PM +0200, Daniel Sahlberg wrote: > * Create an svn auth add command. This option has the advantage that > one person has expressed interest to invest time to write the code. > 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. I still support this idea, but please don't wait for me to implement it. I have too many other commitments for the time being. Thank you for writing this summary. From my point of view it captures the current situation well, and it is very useful for us to have all the important points listed in one message. Cheers, Stefan
Re: A strong WTF on compiling out plaintext password support by default?!
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 ne
Re: Subversion on Solaris (was Re: A strong WTF on compiling out plaintext password support by default?!)
On Thu, Sep 2, 2021 at 7:29 AM Daniel Sahlberg wrote: > > Den mån 23 aug. 2021 kl 12:15 skrev Johan Corveleyn : >> >> Anyway, concerning package maintainers, for Solaris, I'm getting even >> more depressed ... >> * We were using Collab.net's distro, but apparently their Solaris >> build is no longer maintained: >> https://www.collab.net/downloads/subversion >> * Wandisco then? Nope: >> https://www.wandisco.com/source-code-management/subversion#solaris ... >> only Windows, Linux and MacOS. >> * Fortunately, there is still a relatively recent build on OpenCSW: >> https://www.opencsw.org/packages/subversion/ > > > I have been working with Dagobert Michelsen of OpenCSW to build Subversion > 1.14.1 (mailing list thread starting at > http://lists.opencsw.org/pipermail/users/2021-August/010493.html). > > Due to my relative inexperience with Solaris I have not been able to compile > Subversion myself so I have had some problems to execute the complete test > suite but I have run the majority of tests and it all seems fine. The failing > tests are because some missing tooling and not because of errors in the > Subversion build. > >> >> (-> Wandisco's link should be removed from >> http://subversion.apache.org/packages.html#solaris -- making that >> section empty ... or should we add a link to opencsw then?) >> (-> this abandoning of packagers / maintainers makes me feel our >> ecosystem is breaking down) > > > This was implemented in the main site as r1892681 > >> So I guess my best shot is contacting the maintainer of the openCSW >> package, and asking him to add the --enable-plaintext-password-storage >> configure flag and make a new build then. > > > I have raised this question, see mailing list thread above. > > Kind regards, > Daniel Thanks Daniel. You're a star! :-) -- Johan
Subversion on Solaris (was Re: A strong WTF on compiling out plaintext password support by default?!)
Den mån 23 aug. 2021 kl 12:15 skrev Johan Corveleyn : > Anyway, concerning package maintainers, for Solaris, I'm getting even > more depressed ... > * We were using Collab.net's distro, but apparently their Solaris > build is no longer maintained: > https://www.collab.net/downloads/subversion > * Wandisco then? Nope: > https://www.wandisco.com/source-code-management/subversion#solaris ... > only Windows, Linux and MacOS. > * Fortunately, there is still a relatively recent build on OpenCSW: > https://www.opencsw.org/packages/subversion/ I have been working with Dagobert Michelsen of OpenCSW to build Subversion 1.14.1 (mailing list thread starting at http://lists.opencsw.org/pipermail/users/2021-August/010493.html). Due to my relative inexperience with Solaris I have not been able to compile Subversion myself so I have had some problems to execute the complete test suite but I have run the majority of tests and it all seems fine. The failing tests are because some missing tooling and not because of errors in the Subversion build. > (-> Wandisco's link should be removed from > http://subversion.apache.org/packages.html#solaris -- making that > section empty ... or should we add a link to opencsw then?) > (-> this abandoning of packagers / maintainers makes me feel our > ecosystem is breaking down) > This was implemented in the main site as r1892681 So I guess my best shot is contacting the maintainer of the openCSW > package, and asking him to add the --enable-plaintext-password-storage > configure flag and make a new build then. > I have raised this question, see mailing list thread above. Kind regards, Daniel
Re: A strong WTF on compiling out plaintext password support by default?!
On 30.08.21 03:38, Barry wrote: On 26 Aug 2021, at 11:30, Stefan Sperling wrote: I think this may still be better than the alternative where configuration files can be tweaked to trick Alice into unknowingly saving her password in plaintext while running regular SVN operations. Having 'svn auth' be the only command which would write a plaintext password does provide some protection in this scenario, regardless of whether credentials are checked against the server before they get cached. A person who can trick Alice to save plaintext passwords by changing her config file can also trick her to run something else instead of svn or maybe also log key presses, take screenshots, turn on the camera and a lot more. The evil maid simply gets the plain text of the passwords by asking key ring for them. That works today with plaintext disabled. Only in the case of a stolen machine is plaintext on disk a problem. And that assumes that you did not use full disk encryption. Barry Or in the case of an attacker getting remote access to a machine. Thanks for mentioning that. Another problem I saw with some password stores is, that they sometimes insisted on opening a window asking for a passphrase. Local this is just annoying, remote there is a (small) chance that the window is presented to somebody else. I'm not sure if his has been fixed since I just disabled all password stores. I would prefer it if it stayed the way it was before, just tell the users when a password is saved as plaintext. An option which could work for everybody is to move the plaintext password storage code also to a library libsvn_auth_plaintext.so like it is done with the other providers. If people feel it is not enough to remove it from the "password-stores" config they could also delete that library. Martin
Re: A strong WTF on compiling out plaintext password support by default?!
> On 26 Aug 2021, at 11:30, Stefan Sperling wrote: > > I think this may still be better than the alternative where configuration > files can be tweaked to trick Alice into unknowingly saving her password > in plaintext while running regular SVN operations. Having 'svn auth' be > the only command which would write a plaintext password does provide some > protection in this scenario, regardless of whether credentials are checked > against the server before they get cached. The evil maid simply gets the plain text of the passwords by asking key ring for them. That works today with plaintext disabled. Only in the case of a stolen machine is plaintext on disk a problem. And that assumes that you did not use full disk encryption. Barry
Re: A strong WTF on compiling out plaintext password support by default?!
On Fri, Aug 27, 2021 at 9:26 AM Johan Corveleyn wrote: > > On Fri, Aug 27, 2021 at 2:03 PM Daniel Shahaf wrote: > > > > Consensus can only result from an open discussion. That's a standard > > ASF operating principle. > > > > The rhetoric in this thread effects chill on anyone who has an opinion > > different from the opinion of certain speakers. > > I must say I have not seen / felt any rhetoric. Only on-topic > arguments pro and contra certain approaches. So I'm a bit lost here. Agreed. I am at a loss to understand what undesirable argument or rhetoric took place. I think this is a productive thread and hopefully after sleeping on it for a while, we can revisit it and come up with a good compromise solution that works for folks in both situations, those who need simple password management for build servers and text-only ssh where GUI dialogs are inaccessible, as well as those who need to ensure that passwords are not saved in plaintext, in a way that hopefully doesn't require a custom build while still being safe for everyone. That pretty much sums up what everyone wants, right? Stay safe and have a good weekend. Cheers, Nathan
Re: A strong WTF on compiling out plaintext password support by default?!
On Fri, Aug 27, 2021 at 2:03 PM Daniel Shahaf wrote: > > Consensus can only result from an open discussion. That's a standard > ASF operating principle. > > The rhetoric in this thread effects chill on anyone who has an opinion > different from the opinion of certain speakers. I must say I have not seen / felt any rhetoric. Only on-topic arguments pro and contra certain approaches. So I'm a bit lost here. I rebooted this thread last Monday after it lay low for a week or so. Not because I wanted to start an argument, but mainly to express my frustration over this issue *as an svn admin* (because I was investigating, in our company, the upgrade to a more recent svn client on a build server -- which I have since postponed, possibly forever, mainly because of this issue). I was happy to see so many people weighing in with their thoughts and suggestions. As far as I could see, this was a productive thread. > Therefore, this thread _cannot_ consense at this time. > > I think we should (US)table the matter for a few weeks and then (UK)table > it again. Np from my part, we can (US)table it for a while. For me, there is no urgency. We'll just not upgrade svn on our build machine for the time being (no rush). But of course, there are others (including the OP of this thread) who might be interested in a solution. Anyway, what's a couple of weeks in an svn release cycle ;-) ... -- Johan
Re: A strong WTF on compiling out plaintext password support by default?!
On Fri, Aug 27, 2021 at 12:02:58PM +, Daniel Shahaf wrote: > Consensus can only result from an open discussion. That's a standard > ASF operating principle. > > The rhetoric in this thread effects chill on anyone who has an opinion > different from the opinion of certain speakers. Could you please be more specific instead of making vauge statements that make me feel like they're addressed at me without actually saying so? > Therefore, this thread _cannot_ consense at this time. My impression is that consensus is going into the direction of reverting the default of the compile-time configuration option to yes and disabling the feature in configuration files by default. That is what most people have expressed support for. I do believe that leaving the feature off at compile-time and having a special-purpose command to save plaintext passwords is the better design. But since there is no clear consensus in favour of this idea we should not do it. I am 100% fine with that. The prospect of actually having to push through and write the code wasn't something I took on lightly, given that I have many other projects to juggle already. Not having to do that work is in fact a small relief. While I was willing to invest time into the proposed feature, I won't volunteer time for switching the default compile-time behaviour. It would be great if someone else could pick this up and get it committed. People who have an issue with plaintext support will simply have to ask their packagers to compile the feature out. I don't think they will have any success in convincing major distributors to use a non-default build option. But if they care strongly enough they can make use of software freedoms and compile their own binaries. That's going to be my answer to those folks. Given what you wrote above I do agree that it is now time to put an end to the discussion. I don't do NOT want this topic to explode into another argument between you and me, as we had last year; where I feel we could easily resolve things together over a friendly face-to-face chat, but it's absolutely impossible to resolve over email. That is not worth it, Daniel. It burns me out horribly every time this happens between us. Cheers, Stefan
Re: A strong WTF on compiling out plaintext password support by default?!
Consensus can only result from an open discussion. That's a standard ASF operating principle. The rhetoric in this thread effects chill on anyone who has an opinion different from the opinion of certain speakers. Therefore, this thread _cannot_ consense at this time. I think we should (US)table the matter for a few weeks and then (UK)table it again.
Re: A strong WTF on compiling out plaintext password support by default?!
On Fri, Aug 27, 2021 at 11:38:57AM +, Daniel Shahaf wrote: > The solution to "credentials can't be used to commit with" is not > *necessarily* "cache a password for a different username". It could > also be that the authz file has a business logic error («r» rather than > «rw»), or that the server admin temporarily disabled all writes to the > repository, or that the working copy should be switched from a tag back > to trunk, and so on. > > The specific case of one username with two passwords can be implemented > with httpd modules, I believe. I don't know if anyone does that in > mod_dav_svn specifically, but I know it's used in other contexts. Indeed. The dynamic nature of auth/authz settings and the complexities of HTTPD authentication features makes this difficult to solve in general with a client-side only implementation. I don't think making any server-side changes to support a potential 'svn auth add' command would be worth it. Making server-side changes would push this idea way too far.
Re: A strong WTF on compiling out plaintext password support by default?!
Johan Corveleyn wrote on Thu, Aug 26, 2021 at 17:26:50 +0200: > I.e. shouldn't the more general problem statement be "Replace cached > username+passwords that can't be used to commit with"? +1 > (hence my first response with "huh, shouldn't a --username make that > problem moot"? I.e. the user knows which user he's willing to connect > with, and he knows the authz rules, he just wants the password to be > checked and "re-cached" if need be) The solution to "credentials can't be used to commit with" is not *necessarily* "cache a password for a different username". It could also be that the authz file has a business logic error («r» rather than «rw»), or that the server admin temporarily disabled all writes to the repository, or that the working copy should be switched from a tag back to trunk, and so on. The specific case of one username with two passwords can be implemented with httpd modules, I believe. I don't know if anyone does that in mod_dav_svn specifically, but I know it's used in other contexts.
Re: A strong WTF on compiling out plaintext password support by default?!
Den fre 27 aug. 2021 kl 09:15 skrev Johan Corveleyn : > On Thu, Aug 26, 2021 at 3:44 PM Mark Phippard wrote: > > > > On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling wrote: > > > > > The answer might be that 'svn authz add' should simply not contact the > > > server to check credentials. Which means we cannot check upfront > whether > > > the user running 'svn auth add' knows valid credentials. > > > > Yeah that seems reasonable. Basically an "official" version of what > > the scripts are doing. > > > > All that said, I still favor restoring the previous behavior where > > this is enabled by default and a packager can compile it out if they > > so choose. > > +1, I would prefer that as well (was quite happy with the previous > behavior :-)). > > If that's not an option (because of $security-reasons / loud voices), > a workaround with some 'svn auth' extension would definitely help > mitigate the break in usability / backwards compatibility that now > occurred. > I'm also +1 to enable by default but disabling in config. I'm not against the svn auth option but I prefer the "old" way since it is integrated in the normal flow. Of course we should consider any loud voices (and according to Stefan Sperling upthread there might have been issues raised in private forums) but will an svn auth option make them happier? Kind regards /Daniel Sahlberg
Re: A strong WTF on compiling out plaintext password support by default?!
On Thu, Aug 26, 2021 at 3:44 PM Mark Phippard wrote: > > On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling wrote: > > > The answer might be that 'svn authz add' should simply not contact the > > server to check credentials. Which means we cannot check upfront whether > > the user running 'svn auth add' knows valid credentials. > > Yeah that seems reasonable. Basically an "official" version of what > the scripts are doing. > > All that said, I still favor restoring the previous behavior where > this is enabled by default and a packager can compile it out if they > so choose. +1, I would prefer that as well (was quite happy with the previous behavior :-)). If that's not an option (because of $security-reasons / loud voices), a workaround with some 'svn auth' extension would definitely help mitigate the break in usability / backwards compatibility that now occurred. -- Johan
Re: A strong WTF on compiling out plaintext password support by default?!
On Thu, Aug 26, 2021 at 04:08:34PM -0400, Nathan Hartman wrote: > On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling wrote: > > One consequence is that when Alice mistypes the --username option, or > > mistypes the username or password at the prompt, invalid credentials will > > be cached. Which should make any regular SVN operation fail and ask for > > credentials again. I don't think this would be a problem, apart from the > > possibility that invalid plaintext credentials would not be overwritten > > by SVN binaries compiled without support for writing plaintext passwords > > during regular operation. > > That could be mitigated by providing a "svn auth remove" that deletes > a cached credential. Yes, removing the credential would also unblock the situation, as would updating the credential. Thankfully, svn auth --remove already exists :) auth: Manage cached authentication credentials. usage: 1. svn auth [PATTERN ...] 2. svn auth --remove PATTERN [PATTERN ...]
Re: A strong WTF on compiling out plaintext password support by default?!
On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling wrote: > One consequence is that when Alice mistypes the --username option, or > mistypes the username or password at the prompt, invalid credentials will > be cached. Which should make any regular SVN operation fail and ask for > credentials again. I don't think this would be a problem, apart from the > possibility that invalid plaintext credentials would not be overwritten > by SVN binaries compiled without support for writing plaintext passwords > during regular operation. That could be mitigated by providing a "svn auth remove" that deletes a cached credential. Nathan
Re: A strong WTF on compiling out plaintext password support by default?!
On Thu, Aug 26, 2021 at 4:31 PM Daniel Shahaf wrote: > > Johan Corveleyn wrote on Thu, 26 Aug 2021 12:41 +00:00: > > On Wed, Aug 25, 2021 at 8:52 PM Daniel Shahaf > > wrote: > > > This thread is on dev@ as opposed to users@, so I'm trying to solve the > > > problem generically, rather than just your specific $WORK scenario. > > > > I get the feeling I'm missing something, but I still don't understand > > what authz has to do with the problem at hand here (i.e. detecting > > expired passwords so we can ask the user for the new one). > > Your problem statement is "Replace cached passwords that are expired". > > I'm solving a more general problem statement, "Replace cached passwords > that can't be used to commit with", regardless of why. Okay, sure, but that's another question than what we started with. BTW, I don't really follow how you can replace just a cached password for getting "write access". Doesn't "upgrading from read-only to read-write access" also imply using another username? Or can I have two passwords for one user, where one gives me read-only access and one gives me write access? I.e. shouldn't the more general problem statement be "Replace cached username+passwords that can't be used to commit with"? (hence my first response with "huh, shouldn't a --username make that problem moot"? I.e. the user knows which user he's willing to connect with, and he knows the authz rules, he just wants the password to be checked and "re-cached" if need be) -- Johan
Re: A strong WTF on compiling out plaintext password support by default?!
Johan Corveleyn wrote on Thu, 26 Aug 2021 12:41 +00:00: > On Wed, Aug 25, 2021 at 8:52 PM Daniel Shahaf wrote: > > This thread is on dev@ as opposed to users@, so I'm trying to solve the > > problem generically, rather than just your specific $WORK scenario. > > I get the feeling I'm missing something, but I still don't understand > what authz has to do with the problem at hand here (i.e. detecting > expired passwords so we can ask the user for the new one). Your problem statement is "Replace cached passwords that are expired". I'm solving a more general problem statement, "Replace cached passwords that can't be used to commit with", regardless of why.
Re: A strong WTF on compiling out plaintext password support by default?!
Branko Čibej wrote on Thu, 26 Aug 2021 12:49 +00:00: > On 26.08.2021 14:10, Daniel Shahaf wrote: > > Branko Čibej wrote on Thu, 26 Aug 2021 08:11 +00:00: > >> On 25.08.2021 21:01, Mark Phippard wrote: > >>> Solving with svn auth is a nice idea but I do not see it working > >>> unless we have a way to authenticate for write access without writing > >>> something. > >> There isn't in general, since authz can complicate matters. And there > >> isn't currently, we don't have server-side support for that. I'm not > >> even sure we could add a server-side method for this check, since the > >> check for write access can be done entirely outside of Subversion. "svn > >> authz write-check $url" sounds plausible until you consider all the > >> various possible authn/authz checking combinations. > > I don't see the problem. What's implausible about writing an RA API > > that authenticates the client, takes a path and an "is recursive?" bit, > > and returns the result of «svnauthz accessof» on that path? That's > > basically what the revprop edit codepath will do in the default > > configuration (with the pre- hook not existing). > > That part is not implausible. It would have to be implemented in a way > that works when part of the authz processing is done outside of > Subversion, e.g., it should use an HTTP method that requires write > access. An HTTPv2 POST, then? > It's also not backward-compatible, I'd expect "svn auth add" to > work reasonably well against older servers. It's not possible to test write access against older servers, but that doesn't mean we have to wait until 2.0 to make that possible: it's a new feature, not an incompatible change. > I'm not comfortable with the idea of updating the authn cache without > contacting the server when we could. …why? Cheers, Daniel
Re: A strong WTF on compiling out plaintext password support by default?!
On Thu, Aug 26, 2021 at 04:17:16PM +0200, Daniel Sahlberg wrote: > Den tors 26 aug. 2021 kl 16:10 skrev Stefan Sperling : > > > On Thu, Aug 26, 2021 at 02:41:44PM +0200, Johan Corveleyn wrote: > > > I get the feeling I'm missing something, but I still don't understand > > > what authz has to do with the problem at hand here (i.e. detecting > > > expired passwords so we can ask the user for the new one). > > > > The problem is that some repositories (like our own) do not require > > any authentication in order to read data. > > > > Your case where 'svn ls' asks for a password is not applicable for > > public repositories on svn.apache.org, for example. The 'svn auth add' > > command would not get an authentication challenge by running the > > equivalent of what 'svn ls' is doing. We do not have a way to trigger > > the challenge without modifying the repository somehow. > > > > Is it possible to have the client "throw" the username/password at the > server even if the server doesn't issue a challenge? Would the server > validate the username/password (even though authz would allow anonymous > access)? > > /Daniel Sahlberg Unfortunately, it is not. There are many authentication schemes and at least two protocols to consider (HTTP + svn). Some authentication schemes even require data that is generated on the server when it sends the authentication request, such as a nonce.
Re: A strong WTF on compiling out plaintext password support by default?!
Den tors 26 aug. 2021 kl 16:10 skrev Stefan Sperling : > On Thu, Aug 26, 2021 at 02:41:44PM +0200, Johan Corveleyn wrote: > > I get the feeling I'm missing something, but I still don't understand > > what authz has to do with the problem at hand here (i.e. detecting > > expired passwords so we can ask the user for the new one). > > The problem is that some repositories (like our own) do not require > any authentication in order to read data. > > Your case where 'svn ls' asks for a password is not applicable for > public repositories on svn.apache.org, for example. The 'svn auth add' > command would not get an authentication challenge by running the > equivalent of what 'svn ls' is doing. We do not have a way to trigger > the challenge without modifying the repository somehow. > Is it possible to have the client "throw" the username/password at the server even if the server doesn't issue a challenge? Would the server validate the username/password (even though authz would allow anonymous access)? /Daniel Sahlberg
Re: A strong WTF on compiling out plaintext password support by default?!
On Thu, Aug 26, 2021 at 12:15:39PM +, Daniel Shahaf wrote: > Stefan Sperling wrote on Thu, 26 Aug 2021 10:30 +00:00: > > And while we are considering read-only vs. read-write access: > > Plaintext passwords or not, in my contrived scenario Eve could always > > trick Alice into using a different user account by caching a set of > > valid credentials which Eve knows. Apart from not caching credentials > > at all I don't see a way to prevent this. > > That scenario is called an "evil maid attack". I don't think we should > try to prevent it. We are not in the business of posting guards to watch > over unattended laptops. The plaintext password pishing scenario also requires access to local configuration files. We could simply declare it out of scope, but that means we'd be ignoring users who are unhappy that plaintext storage is even allowed. Just as they are unhappy about TortoiseSVN's decryption shortcut in its cached password dialog (note that in this case the windows domain password is often the same as the SVN password, so leaving a laptop unlocked means anyone can get at domain creds).
Re: A strong WTF on compiling out plaintext password support by default?!
On Thu, Aug 26, 2021 at 02:41:44PM +0200, Johan Corveleyn wrote: > I get the feeling I'm missing something, but I still don't understand > what authz has to do with the problem at hand here (i.e. detecting > expired passwords so we can ask the user for the new one). The problem is that some repositories (like our own) do not require any authentication in order to read data. Your case where 'svn ls' asks for a password is not applicable for public repositories on svn.apache.org, for example. The 'svn auth add' command would not get an authentication challenge by running the equivalent of what 'svn ls' is doing. We do not have a way to trigger the challenge without modifying the repository somehow.
Re: A strong WTF on compiling out plaintext password support by default?!
On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling wrote: > The answer might be that 'svn authz add' should simply not contact the > server to check credentials. Which means we cannot check upfront whether > the user running 'svn auth add' knows valid credentials. Yeah that seems reasonable. Basically an "official" version of what the scripts are doing. All that said, I still favor restoring the previous behavior where this is enabled by default and a packager can compile it out if they so choose. Mark
Re: A strong WTF on compiling out plaintext password support by default?!
On 26.08.2021 14:10, Daniel Shahaf wrote: Branko Čibej wrote on Thu, 26 Aug 2021 08:11 +00:00: On 25.08.2021 21:01, Mark Phippard wrote: Solving with svn auth is a nice idea but I do not see it working unless we have a way to authenticate for write access without writing something. There isn't in general, since authz can complicate matters. And there isn't currently, we don't have server-side support for that. I'm not even sure we could add a server-side method for this check, since the check for write access can be done entirely outside of Subversion. "svn authz write-check $url" sounds plausible until you consider all the various possible authn/authz checking combinations. I don't see the problem. What's implausible about writing an RA API that authenticates the client, takes a path and an "is recursive?" bit, and returns the result of «svnauthz accessof» on that path? That's basically what the revprop edit codepath will do in the default configuration (with the pre- hook not existing). That part is not implausible. It would have to be implemented in a way that works when part of the authz processing is done outside of Subversion, e.g., it should use an HTTP method that requires write access. It's also not backward-compatible, I'd expect "svn auth add" to work reasonably well against older servers. I'm not comfortable with the idea of updating the authn cache without contacting the server when we could. -- Brane
Re: A strong WTF on compiling out plaintext password support by default?!
On Wed, Aug 25, 2021 at 8:52 PM Daniel Shahaf wrote:
> Johan Corveleyn wrote on Wed, 25 Aug 2021 07:16 +00:00:
> > On Tue, Aug 24, 2021 at 7:03 PM Daniel Shahaf
> > wrote:
> > > Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> > > > On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf
> > > > wrote:
> > > > > Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25 +00:00:
> > > > > > OTOH, if this kind of behaviour is too far-fetched for a single
> > > > > > subcommand, I might be able to do it by invoking two commands, if I
> > > > > > could succesfully (and invisibly) detect that a cached password is
> > > > > > no
> > > > > > longer correct. As in:
> > > > > >
> > > > > > svn ls --non-interactive $URL >/dev/null
> > > > > > # if exit-code != 0, parse error code to see if it indicates
> > > > > > "auth failed"
> > > > > > if ("auth failed"):
> > > > > > svn auth add $URL
> > > > > >
> > > > >
> > > > > What happens if a valid username/password are cached that have read-
> > > > > only access and one wants to preseed a username/password that have
> > > > > read-
> > > > > write access?
> > > >
> > > > I don't know. We don't have that use case at $company, trying to keep
> > > > things simple :-).
> > > >
> > > > Ah but shouldn't 'svn auth' carry an optional --username parameter? In
> > > > that case, I don't see the problem, I guess.
> > >
> > > My point here is that that pseudocode doesn't handle ensuring that the
> > > cached credentials have read-write access. Existence of «svn auth
> > > --username»
> > > won't change that, because the «svn auth» call is inside an if() block
> > > whose condition will false negative.
> > >
> > > Is there a way to test whether one has rw access without actually doing
> > > a commit or a revprop edit? It's possible with hooks, of course, but is
> > > it also possible without hooks?
> >
> > I'm not sure I understand: why would I need to know that the cached
> > credentials have read-write access?
> >
>
> Your pseudocode detects credentials that have no read access, whether
> for lack of authz or for failing to authn.
Oh? I was assuming that we would be able to discern failed authn (as
in "incorrect username or password") from failed authz (as in "403
Forbidden"). Is that not the case? Do both failed authn and failed
authz yield the same error code / message?
I'm only interested in failed authn, because this entire thread is
about the disabling of the plaintext password cache, and I just want
to know if the cached password is now invalid (with failed authn) so I
have to ask the user for a new one (to potentially use another tool to
inject that new password into the plaintext cache).
> I was asking how to
> generalize this to detecting credentials that successfully authn and
> authz but only for read-only access rather than for full access. That
> would be necessary if the "preseeded" credentials are to be used for
> a write operation (a commit or a revprop edit).
>
> > I only want to verify the authentication part,
>
> This thread is on dev@ as opposed to users@, so I'm trying to solve the
> problem generically, rather than just your specific $WORK scenario.
I get the feeling I'm missing something, but I still don't understand
what authz has to do with the problem at hand here (i.e. detecting
expired passwords so we can ask the user for the new one).
--
Johan
Re: A strong WTF on compiling out plaintext password support by default?!
Stefan Sperling wrote on Thu, 26 Aug 2021 10:30 +00:00: > And while we are considering read-only vs. read-write access: > Plaintext passwords or not, in my contrived scenario Eve could always > trick Alice into using a different user account by caching a set of > valid credentials which Eve knows. Apart from not caching credentials > at all I don't see a way to prevent this. That scenario is called an "evil maid attack". I don't think we should try to prevent it. We are not in the business of posting guards to watch over unattended laptops.
Re: A strong WTF on compiling out plaintext password support by default?!
Branko Čibej wrote on Thu, 26 Aug 2021 08:11 +00:00: > On 25.08.2021 21:01, Mark Phippard wrote: > > Solving with svn auth is a nice idea but I do not see it working > > unless we have a way to authenticate for write access without writing > > something. > > There isn't in general, since authz can complicate matters. And there > isn't currently, we don't have server-side support for that. I'm not > even sure we could add a server-side method for this check, since the > check for write access can be done entirely outside of Subversion. "svn > authz write-check $url" sounds plausible until you consider all the > various possible authn/authz checking combinations. I don't see the problem. What's implausible about writing an RA API that authenticates the client, takes a path and an "is recursive?" bit, and returns the result of «svnauthz accessof» on that path? That's basically what the revprop edit codepath will do in the default configuration (with the pre- hook not existing).
Re: A strong WTF on compiling out plaintext password support by default?!
On Thu, Aug 26, 2021 at 10:11:44AM +0200, Branko Čibej wrote: > On 25.08.2021 21:01, Mark Phippard wrote: > > On Wed, Aug 25, 2021 at 3:16 AM Johan Corveleyn wrote: > > > > > > Is there a way to test whether one has rw access without actually doing > > > > a commit or a revprop edit? It's possible with hooks, of course, but is > > > > it also possible without hooks? > > > I'm not sure I understand: why would I need to know that the cached > > > credentials have read-write access? > > I think it was a good question. It is hard to predict if a build > > process just needs read access or read-write. If it needs the latter > > it could complicate the effectiveness of a solution that goes down > > this path. For example, imagine a scenario where the server allows > > anonymous read access .. it will not even be possible to check > > credentials unless you attempt a write operation. > > > > I was never super excited about this change to disallow plain text > > passwords but I figured fighting against a security issue is a losing > > battle. I personally prefer the suggestion of making it a compile > > option to disallow plain text passwords and have them enabled by > > default and just turned off in the default configuration. The > > alice/eve scenario while valid just does not concern me. > > > > Solving with svn auth is a nice idea but I do not see it working > > unless we have a way to authenticate for write access without writing > > something. Thanks for bringing this up, Daniel and Mark. This is indeed an important point. > There isn't in general, since authz can complicate matters. And there isn't > currently, we don't have server-side support for that. I'm not even sure we > could add a server-side method for this check, since the check for write > access can be done entirely outside of Subversion. "svn authz write-check > $url" sounds plausible until you consider all the various possible > authn/authz checking combinations. The answer might be that 'svn authz add' should simply not contact the server to check credentials. Which means we cannot check upfront whether the user running 'svn auth add' knows valid credentials. I think this may still be better than the alternative where configuration files can be tweaked to trick Alice into unknowingly saving her password in plaintext while running regular SVN operations. Having 'svn auth' be the only command which would write a plaintext password does provide some protection in this scenario, regardless of whether credentials are checked against the server before they get cached. One consequence is that when Alice mistypes the --username option, or mistypes the username or password at the prompt, invalid credentials will be cached. Which should make any regular SVN operation fail and ask for credentials again. I don't think this would be a problem, apart from the possibility that invalid plaintext credentials would not be overwritten by SVN binaries compiled without support for writing plaintext passwords during regular operation. In the absence of non-plaintext auth caches SVN would then keep asking for a password until 'svn authz add --plaintext' is used again to store valid credentials. This problem also applies to any helper scripts that people might be running right now in order to add plaintext credentials to the auth cache. To mitigate this problem a bit, we could have 'svn auth add' ask for the password twice and repeat the prompt in a loop in case of a mismatch. And while we are considering read-only vs. read-write access: Plaintext passwords or not, in my contrived scenario Eve could always trick Alice into using a different user account by caching a set of valid credentials which Eve knows. Apart from not caching credentials at all I don't see a way to prevent this.
Re: A strong WTF on compiling out plaintext password support by default?!
On 25.08.2021 21:01, Mark Phippard wrote: On Wed, Aug 25, 2021 at 3:16 AM Johan Corveleyn wrote: Is there a way to test whether one has rw access without actually doing a commit or a revprop edit? It's possible with hooks, of course, but is it also possible without hooks? I'm not sure I understand: why would I need to know that the cached credentials have read-write access? I think it was a good question. It is hard to predict if a build process just needs read access or read-write. If it needs the latter it could complicate the effectiveness of a solution that goes down this path. For example, imagine a scenario where the server allows anonymous read access .. it will not even be possible to check credentials unless you attempt a write operation. I was never super excited about this change to disallow plain text passwords but I figured fighting against a security issue is a losing battle. I personally prefer the suggestion of making it a compile option to disallow plain text passwords and have them enabled by default and just turned off in the default configuration. The alice/eve scenario while valid just does not concern me. Solving with svn auth is a nice idea but I do not see it working unless we have a way to authenticate for write access without writing something. There isn't in general, since authz can complicate matters. And there isn't currently, we don't have server-side support for that. I'm not even sure we could add a server-side method for this check, since the check for write access can be done entirely outside of Subversion. "svn authz write-check $url" sounds plausible until you consider all the various possible authn/authz checking combinations. -- Brane
Re: A strong WTF on compiling out plaintext password support by default?!
On Wed, Aug 25, 2021 at 3:16 AM Johan Corveleyn wrote: > > Is there a way to test whether one has rw access without actually doing > > a commit or a revprop edit? It's possible with hooks, of course, but is > > it also possible without hooks? > > I'm not sure I understand: why would I need to know that the cached > credentials have read-write access? I think it was a good question. It is hard to predict if a build process just needs read access or read-write. If it needs the latter it could complicate the effectiveness of a solution that goes down this path. For example, imagine a scenario where the server allows anonymous read access .. it will not even be possible to check credentials unless you attempt a write operation. I was never super excited about this change to disallow plain text passwords but I figured fighting against a security issue is a losing battle. I personally prefer the suggestion of making it a compile option to disallow plain text passwords and have them enabled by default and just turned off in the default configuration. The alice/eve scenario while valid just does not concern me. Solving with svn auth is a nice idea but I do not see it working unless we have a way to authenticate for write access without writing something. Mark
Re: A strong WTF on compiling out plaintext password support by default?!
Johan Corveleyn wrote on Wed, 25 Aug 2021 07:16 +00:00:
> On Tue, Aug 24, 2021 at 7:03 PM Daniel Shahaf wrote:
> > Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> > > On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf
> > > wrote:
> > > > Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25 +00:00:
> > > > > OTOH, if this kind of behaviour is too far-fetched for a single
> > > > > subcommand, I might be able to do it by invoking two commands, if I
> > > > > could succesfully (and invisibly) detect that a cached password is no
> > > > > longer correct. As in:
> > > > >
> > > > > svn ls --non-interactive $URL >/dev/null
> > > > > # if exit-code != 0, parse error code to see if it indicates
> > > > > "auth failed"
> > > > > if ("auth failed"):
> > > > > svn auth add $URL
> > > > >
> > > >
> > > > What happens if a valid username/password are cached that have read-
> > > > only access and one wants to preseed a username/password that have read-
> > > > write access?
> > >
> > > I don't know. We don't have that use case at $company, trying to keep
> > > things simple :-).
> > >
> > > Ah but shouldn't 'svn auth' carry an optional --username parameter? In
> > > that case, I don't see the problem, I guess.
> >
> > My point here is that that pseudocode doesn't handle ensuring that the
> > cached credentials have read-write access. Existence of «svn auth
> > --username»
> > won't change that, because the «svn auth» call is inside an if() block
> > whose condition will false negative.
> >
> > Is there a way to test whether one has rw access without actually doing
> > a commit or a revprop edit? It's possible with hooks, of course, but is
> > it also possible without hooks?
>
> I'm not sure I understand: why would I need to know that the cached
> credentials have read-write access?
>
Your pseudocode detects credentials that have no read access, whether
for lack of authz or for failing to authn. I was asking how to
generalize this to detecting credentials that successfully authn and
authz but only for read-only access rather than for full access. That
would be necessary if the "preseeded" credentials are to be used for
a write operation (a commit or a revprop edit).
> I only want to verify the authentication part,
This thread is on dev@ as opposed to users@, so I'm trying to solve the
problem generically, rather than just your specific $WORK scenario.
> and see if the password
> that was cached is no longer valid (in which case we need to ask the
> new one to the user). I don't really care at this point whether we're
> talking about read-only or read-write access, just want to refresh the
> password in the cache (for whatever username the user is using ...
> it's his business to use the correct username for whatever use case
> he's using here :-)).
No one was assuming an incorrect username had been cached.
Re: A strong WTF on compiling out plaintext password support by default?!
On Tue, Aug 24, 2021 at 7:03 PM Daniel Shahaf wrote:
> Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> > On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf
> > wrote:
> > > Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25 +00:00:
> > > > OTOH, if this kind of behaviour is too far-fetched for a single
> > > > subcommand, I might be able to do it by invoking two commands, if I
> > > > could succesfully (and invisibly) detect that a cached password is no
> > > > longer correct. As in:
> > > >
> > > > svn ls --non-interactive $URL >/dev/null
> > > > # if exit-code != 0, parse error code to see if it indicates "auth
> > > > failed"
> > > > if ("auth failed"):
> > > > svn auth add $URL
> > > >
> > >
> > > What happens if a valid username/password are cached that have read-
> > > only access and one wants to preseed a username/password that have read-
> > > write access?
> >
> > I don't know. We don't have that use case at $company, trying to keep
> > things simple :-).
> >
> > Ah but shouldn't 'svn auth' carry an optional --username parameter? In
> > that case, I don't see the problem, I guess.
>
> My point here is that that pseudocode doesn't handle ensuring that the
> cached credentials have read-write access. Existence of «svn auth --username»
> won't change that, because the «svn auth» call is inside an if() block
> whose condition will false negative.
>
> Is there a way to test whether one has rw access without actually doing
> a commit or a revprop edit? It's possible with hooks, of course, but is
> it also possible without hooks?
I'm not sure I understand: why would I need to know that the cached
credentials have read-write access?
I only want to verify the authentication part, and see if the password
that was cached is no longer valid (in which case we need to ask the
new one to the user). I don't really care at this point whether we're
talking about read-only or read-write access, just want to refresh the
password in the cache (for whatever username the user is using ...
it's his business to use the correct username for whatever use case
he's using here :-)).
--
Johan
Re: A strong WTF on compiling out plaintext password support by default?!
Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf wrote:
> > Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25 +00:00:
> > > OTOH, if this kind of behaviour is too far-fetched for a single
> > > subcommand, I might be able to do it by invoking two commands, if I
> > > could succesfully (and invisibly) detect that a cached password is no
> > > longer correct. As in:
> > >
> > > svn ls --non-interactive $URL >/dev/null
> > > # if exit-code != 0, parse error code to see if it indicates "auth
> > > failed"
> > > if ("auth failed"):
> > > svn auth add $URL
> > >
> >
> > What happens if a valid username/password are cached that have read-
> > only access and one wants to preseed a username/password that have read-
> > write access?
>
> I don't know. We don't have that use case at $company, trying to keep
> things simple :-).
>
> Ah but shouldn't 'svn auth' carry an optional --username parameter? In
> that case, I don't see the problem, I guess.
My point here is that that pseudocode doesn't handle ensuring that the
cached credentials have read-write access. Existence of «svn auth --username»
won't change that, because the «svn auth» call is inside an if() block
whose condition will false negative.
Is there a way to test whether one has rw access without actually doing
a commit or a revprop edit? It's possible with hooks, of course, but is
it also possible without hooks?
Re: A strong WTF on compiling out plaintext password support by default?!
On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf wrote:
>
> Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25 +00:00:
> > OTOH, if this kind of behaviour is too far-fetched for a single
> > subcommand, I might be able to do it by invoking two commands, if I
> > could succesfully (and invisibly) detect that a cached password is no
> > longer correct. As in:
> >
> > svn ls --non-interactive $URL >/dev/null
> > # if exit-code != 0, parse error code to see if it indicates "auth
> > failed"
> > if ("auth failed"):
> > svn auth add $URL
> >
>
> What happens if a valid username/password are cached that have read-
> only access and one wants to preseed a username/password that have read-
> write access?
I don't know. We don't have that use case at $company, trying to keep
things simple :-).
Ah but shouldn't 'svn auth' carry an optional --username parameter? In
that case, I don't see the problem, I guess.
> > But then the burden is on me detecting the "auth failed" correctly,
> > and making sure it's the "password refused" kind of auth failure (I
> > guess there's an error code for that).
>
> There's an error code for that, but it's the E42 value in stderr,
> not the exit code. The exit code is generally 1 (unless segfault or
> something).
Yup, parsing the error code from stderr was what I was thinking of.
Not great, but it'd work.
--
Johan
Re: A strong WTF on compiling out plaintext password support by default?!
Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25 +00:00:
> OTOH, if this kind of behaviour is too far-fetched for a single
> subcommand, I might be able to do it by invoking two commands, if I
> could succesfully (and invisibly) detect that a cached password is no
> longer correct. As in:
>
> svn ls --non-interactive $URL >/dev/null
> # if exit-code != 0, parse error code to see if it indicates "auth failed"
> if ("auth failed"):
> svn auth add $URL
>
What happens if a valid username/password are cached that have read-
only access and one wants to preseed a username/password that have read-
write access?
> But then the burden is on me detecting the "auth failed" correctly,
> and making sure it's the "password refused" kind of auth failure (I
> guess there's an error code for that).
There's an error code for that, but it's the E42 value in stderr,
not the exit code. The exit code is generally 1 (unless segfault or
something).
Re: A strong WTF on compiling out plaintext password support by default?!
On Tue, Aug 24, 2021 at 1:24 PM Stefan Sperling wrote:
>
> On Tue, Aug 24, 2021 at 12:16:48PM +0200, Johan Corveleyn wrote:
> > But: obviously I have disabled, in the runtime config area, the
> > warning prompt that "Your password will be stored in plaintext" (I
> > have disabled it system-wide, in /etc/subversion). Yes, we know this
> > and we accept it. I would not like this nag screen to be forced with
> > no way for an admin to disable it. Ah, I might be able to write a
> > wrapper script to dev/null the warning :-). All this effort for ...
> > nothing (from my perspective).
> >
> > Perhaps a meta-itch here: the old behaviour has been there for 20
> > years, and then we decided to change this. In the
> > super-stable-mature-super-backwards-compatible part of our lifecycle.
> > Not the best timing I think. Perhaps this should have rather been on
> > the 2.0-wishlist ("Come up with a better pwd caching solution on
> > non-Windows platforms").
>
> OK, I see why my proposal as it is wouldn't help you.
> But if we tweak it slightly, it could work?
>
> We could make 'svn auth add' only ask for a password if no valid
> password can be found in the cache. The command would first contact
> the server and if it manages to authenticate it would do nothing else.
Thanks for thinking along, Stefan :-).
Yes, that might work. But perhaps 'add' wouldn't be a great name for
this kind of behaviour. Maybe something like 'svn auth cache-validate
$URL' or 'cache-freshen' or something like that.
OTOH, if this kind of behaviour is too far-fetched for a single
subcommand, I might be able to do it by invoking two commands, if I
could succesfully (and invisibly) detect that a cached password is no
longer correct. As in:
svn ls --non-interactive $URL >/dev/null
# if exit-code != 0, parse error code to see if it indicates "auth failed"
if ("auth failed"):
svn auth add $URL
But then the burden is on me detecting the "auth failed" correctly,
and making sure it's the "password refused" kind of auth failure (I
guess there's an error code for that).
> And we could avoid showing a plaintext prompt. Instead we could require
> a --plaintext command line option to allow storage in plaintext.
> Without --plaintext, 'svn auth add' would fail if the password cannot
> be stored encrypted and general plaintext-support was not enabled at
> compile time. The only interactive component presented to the user would
> be a password prompt.
Uhuh, sound sensible. Perhaps it should be '--allow-plaintext' or
something, so that, like now, it tries to use encrypted storage if
available, but is allowed to fallback to plaintext if there is nothing
else. Or do we rather want an option to force plaintext, even if there
is encrypted storage available (should that be named --force-plaintext
then?)? Dunno.
> Failing that, I agree that the best solution would be to simply
> revert the default setting of the compile-time switch back to 'yes'.
>
> This won't make the hardline "no plaintext, please" crowd very happy.
> But the middle ground, where all this can be configured at run-time
> probably won't satisfy them either. I guess that is why a compile-time
> switch exists in the first place.
To make things even more complicated, we could add another
compile-time switch (which would not be on by default!) to
compile-time disable support for the --allow-plaintext option to 'svn
auth add' :-). Companies / packagers that are extra sensitive can roll
their own then.
--
Johan
Re: A strong WTF on compiling out plaintext password support by default?!
On Tue, Aug 24, 2021 at 02:37:57AM -0700, Robby Zinchak wrote: > Oh, hello all :) > > Yeah, between this cli obstacle, problems with rapidsvn corrupting local > repo during file moves, and svn Apache frequently corrupting server repo > unrecoverably in large check-ins (>200mb) and requiring a nuke and reload > from backup... it's been pretty rough year for my use cases of svn. :'( I am sorry to hear that you have been having much so trouble with SVN lately. It would be interesting to learn more about repository corruption issues and how they could be prevented, but this is unrelated to the discussion at hand. Let's try to keep a positive outlook on things :) > I have been using the stored credential work around (thanks for that), but > it's hard to imagine new users finding this thread to know about > undocumented workaround. I agree that a script is unlikely to get as the same level of exposure as a built-in command would receive. > Stefan - I recall the previous behavior being to warn the user that > password is being stored in plaintext during entry. That seems like it > would somewhat mitigate the evil actor using an official svn build threat > case. This prompt can be disabled in the run-time configuration, which Eve would not hesitate to take advantage of. > The big Pandora's Box here is that if someone has shell access, they > can probably install or alias their own binary that does even more > nefarious things, making any official behavior moot except for systems that > only allow specific executable hashes to run. (And even then, a shell > script could mimic svns output in a phishing style attack). Sure, the story doesn't end here. Eve will always be looking for another trick. But only if forced to! What matters is that these are additional hoops to jump through and may be easier to identify as something out of the ordinary. Whereas the previous attack was trivially concealed as harmless configuration file edits apparently made by Alice herself.
Re: A strong WTF on compiling out plaintext password support by default?!
On Tue, Aug 24, 2021 at 12:16:48PM +0200, Johan Corveleyn wrote:
> But: obviously I have disabled, in the runtime config area, the
> warning prompt that "Your password will be stored in plaintext" (I
> have disabled it system-wide, in /etc/subversion). Yes, we know this
> and we accept it. I would not like this nag screen to be forced with
> no way for an admin to disable it. Ah, I might be able to write a
> wrapper script to dev/null the warning :-). All this effort for ...
> nothing (from my perspective).
>
> Perhaps a meta-itch here: the old behaviour has been there for 20
> years, and then we decided to change this. In the
> super-stable-mature-super-backwards-compatible part of our lifecycle.
> Not the best timing I think. Perhaps this should have rather been on
> the 2.0-wishlist ("Come up with a better pwd caching solution on
> non-Windows platforms").
OK, I see why my proposal as it is wouldn't help you.
But if we tweak it slightly, it could work?
We could make 'svn auth add' only ask for a password if no valid
password can be found in the cache. The command would first contact
the server and if it manages to authenticate it would do nothing else.
And we could avoid showing a plaintext prompt. Instead we could require
a --plaintext command line option to allow storage in plaintext.
Without --plaintext, 'svn auth add' would fail if the password cannot
be stored encrypted and general plaintext-support was not enabled at
compile time. The only interactive component presented to the user would
be a password prompt.
Failing that, I agree that the best solution would be to simply
revert the default setting of the compile-time switch back to 'yes'.
This won't make the hardline "no plaintext, please" crowd very happy.
But the middle ground, where all this can be configured at run-time
probably won't satisfy them either. I guess that is why a compile-time
switch exists in the first place.
Re: A strong WTF on compiling out plaintext password support by default?!
Oh, hello all :) Yeah, between this cli obstacle, problems with rapidsvn corrupting local repo during file moves, and svn Apache frequently corrupting server repo unrecoverably in large check-ins (>200mb) and requiring a nuke and reload from backup... it's been pretty rough year for my use cases of svn. :'( I have been using the stored credential work around (thanks for that), but it's hard to imagine new users finding this thread to know about undocumented workaround. Stefan - I recall the previous behavior being to warn the user that password is being stored in plaintext during entry. That seems like it would somewhat mitigate the evil actor using an official svn build threat case. The big Pandora's Box here is that if someone has shell access, they can probably install or alias their own binary that does even more nefarious things, making any official behavior moot except for systems that only allow specific executable hashes to run. (And even then, a shell script could mimic svns output in a phishing style attack). On Tue, Aug 24, 2021, 1:27 AM Stefan Sperling wrote: > On Mon, Aug 23, 2021 at 09:05:33PM +0200, Daniel Sahlberg wrote: > > Has there been any complaints about Subversion's ability to store > passwords > > in plaintext? > > Of course :) Years ago, before any encrypted storage was available > on Unix systems, this was a common complaint. > > The FAQ entry which you improved in https://svn.apeche.org/r1887129 > was previously using language which reflected the nature of complaints > that were received: "Ahhh! I just discovered that my Subversion client > is caching passwords in plain-text on disk! -AHHH!" > > > (I tried to search the mailing list but didn't come up with > > anything, possibly because of a lack of imagination on proper keywords). > > Maybe these complaints would have gone to the different distributions? > > Perhaps some of them arrived via internal support channels of the various > companies involved in SVN's development. Not all communication with users > occurs via public channels. > > > For reference, here is the e-mail where Stefan Sperling mentions the > change > > in OpenBSD to re-enable support for plaintext passwords in OpenBSD: [2] I > > would encourage everyone to re-read that message since it has a good > > summary of arguments (including a link to a request from a corporate > > security group to TortoiseSVN to avoid storing a password in plaintext in > > memory). > > > > For me the route taken by OpenBSD seems reasonable: > > - Enable plaintext passwords in the compile time defaults > > - Disable plaintext passwords in the default runtime configuration > > - Let the users re-enable it in their configuration if they want to > > > > Pros: > > * It would not change the default behaviour. > > * It would enable users to enable plaintext passwords in configuration > > without having to recompile. > > > > Cons: > > * Potentially some security group would argue about the possibility to > > enable plaintext passwords at all. > > As someone who supported the original change to disable this feature at > compile-time, I backtracked a bit when I saw the consequences on OpenBSD > servers where unattended operation of svn in scripts is relatively common. > > But I still think that Brane's concerns are warranted. > In particular (from #svn-dev IRC just now): > > 09:30 <@brane> the only issue i have with that is that users rarely look > at >~/.subversion/config and may not even be aware that the > option >is enabled. > > A potential attack would be Alice leaving her desktop unlocked, > and Eve using this chance to enable the option in Alice's config. > Eve would also clear the password cache with svn auth --remove > and disable the plaintext password prompt by setting the appropriate > option in ~/.subversion/servers. > Now Alice comes back and uses SVN as usual, unaware that her password > is being cached in plaintext, perhaps assuming it is being cached in > encrypted storage as she would reasonably expect. > When Alice leaves her desktop unlocked another time Eve collects > Alice's SVN password from plaintext storage. > > The above may seem ridiculous to some (after all, Alice should not have > left her desktop defenseless!) but this is indeed a threat scenario > which is considered in some deployments. The TortoiseSVN discussion > linked earlier is based on a similar threat model where an unlocked > Windows desktop is abused to spy out passwords cached by TortoiseSVN, > which will reveal encrypted passwords in plaintext when asked to do so. > > To protect Alice from this attack, writing plaintext passwords must > remain disabled during regular usage of SVN. We could provide a special > mechanism to add a plaintext password under a set of conditions: > > - The command to run is not a regularly used SVN command. > 'svn auth' would be a good candidate since its sole purpose > is to inspect and manage the cached credentials s
Re: A strong WTF on compiling out plaintext password support by default?!
[ sorry Robby, I left you out of a previous reply -- looping you back
in in case you're interested in this tangent ... ]
On Tue, Aug 24, 2021 at 10:34 AM Stefan Sperling wrote:
>
> On Mon, Aug 23, 2021 at 02:45:44PM +0200, Johan Corveleyn wrote:
> > Thanks, those are good efforts (and thanks to both Daniels for writing
> > them), but I'm afraid those workarounds are not good enough. The thing
> > is: this is not for me alone. This needs to be handled in buildscripts
> > that can be run by around 50 developers.
>
> One thing is unclear to me:
>
> At some point, someone has to run an svn command to get the passward
> cached on Solaris in the first place or build scripts would be failing.
>
> How is this done? Each of the 50 developers ran 'svn checkout' or
> something similar to get the password cached? Or does the password
> get cached in a non-interactive, automated way?
>
> The point of this question is to understand whether my 'svn auth add'
> proposal described elsewhere in this thread would solve your problem.
These buildscripts are run manually / interactively on this machine
(developers take turns for this weekly task, for different
applications). For most applications there is a canonical (shared)
working copy on this build-server, so they reuse that (or otherwise
they can set one up quickly with a script). The buildscripts are
written in ant (we're building Java applications actually).
The ant targets that do something with svn have a
"depends=svn-checkpwd" clause, which makes them first call the
"svn-checkpwd" target. This does a minimal password-requiring thing
with svn (I think it is something like 'svn ls https://svnserver/repo
>/dev/null'). If the cached password is still correct, user sees
nothing (carry on), if not they get a password prompt and type in the
new password.
I suppose I could rewrite that 'svn-checkpwd' target to use 'svn auth
add' or something similar, but I should also have a way to verify
whether the cached password is still valid (so I can get the same
behaviour as before: only bother the user if the cached password is no
longer valid).
But: obviously I have disabled, in the runtime config area, the
warning prompt that "Your password will be stored in plaintext" (I
have disabled it system-wide, in /etc/subversion). Yes, we know this
and we accept it. I would not like this nag screen to be forced with
no way for an admin to disable it. Ah, I might be able to write a
wrapper script to dev/null the warning :-). All this effort for ...
nothing (from my perspective).
Perhaps a meta-itch here: the old behaviour has been there for 20
years, and then we decided to change this. In the
super-stable-mature-super-backwards-compatible part of our lifecycle.
Not the best timing I think. Perhaps this should have rather been on
the 2.0-wishlist ("Come up with a better pwd caching solution on
non-Windows platforms").
--
Johan
Re: A strong WTF on compiling out plaintext password support by default?!
On Mon, Aug 23, 2021 at 02:45:44PM +0200, Johan Corveleyn wrote: > Thanks, those are good efforts (and thanks to both Daniels for writing > them), but I'm afraid those workarounds are not good enough. The thing > is: this is not for me alone. This needs to be handled in buildscripts > that can be run by around 50 developers. One thing is unclear to me: At some point, someone has to run an svn command to get the passward cached on Solaris in the first place or build scripts would be failing. How is this done? Each of the 50 developers ran 'svn checkout' or something similar to get the password cached? Or does the password get cached in a non-interactive, automated way? The point of this question is to understand whether my 'svn auth add' proposal described elsewhere in this thread would solve your problem.
Re: A strong WTF on compiling out plaintext password support by default?!
On Mon, Aug 23, 2021 at 09:05:33PM +0200, Daniel Sahlberg wrote: > Has there been any complaints about Subversion's ability to store passwords > in plaintext? Of course :) Years ago, before any encrypted storage was available on Unix systems, this was a common complaint. The FAQ entry which you improved in https://svn.apeche.org/r1887129 was previously using language which reflected the nature of complaints that were received: "Ahhh! I just discovered that my Subversion client is caching passwords in plain-text on disk! -AHHH!" > (I tried to search the mailing list but didn't come up with > anything, possibly because of a lack of imagination on proper keywords). > Maybe these complaints would have gone to the different distributions? Perhaps some of them arrived via internal support channels of the various companies involved in SVN's development. Not all communication with users occurs via public channels. > For reference, here is the e-mail where Stefan Sperling mentions the change > in OpenBSD to re-enable support for plaintext passwords in OpenBSD: [2] I > would encourage everyone to re-read that message since it has a good > summary of arguments (including a link to a request from a corporate > security group to TortoiseSVN to avoid storing a password in plaintext in > memory). > > For me the route taken by OpenBSD seems reasonable: > - Enable plaintext passwords in the compile time defaults > - Disable plaintext passwords in the default runtime configuration > - Let the users re-enable it in their configuration if they want to > > Pros: > * It would not change the default behaviour. > * It would enable users to enable plaintext passwords in configuration > without having to recompile. > > Cons: > * Potentially some security group would argue about the possibility to > enable plaintext passwords at all. As someone who supported the original change to disable this feature at compile-time, I backtracked a bit when I saw the consequences on OpenBSD servers where unattended operation of svn in scripts is relatively common. But I still think that Brane's concerns are warranted. In particular (from #svn-dev IRC just now): 09:30 <@brane> the only issue i have with that is that users rarely look at ~/.subversion/config and may not even be aware that the option is enabled. A potential attack would be Alice leaving her desktop unlocked, and Eve using this chance to enable the option in Alice's config. Eve would also clear the password cache with svn auth --remove and disable the plaintext password prompt by setting the appropriate option in ~/.subversion/servers. Now Alice comes back and uses SVN as usual, unaware that her password is being cached in plaintext, perhaps assuming it is being cached in encrypted storage as she would reasonably expect. When Alice leaves her desktop unlocked another time Eve collects Alice's SVN password from plaintext storage. The above may seem ridiculous to some (after all, Alice should not have left her desktop defenseless!) but this is indeed a threat scenario which is considered in some deployments. The TortoiseSVN discussion linked earlier is based on a similar threat model where an unlocked Windows desktop is abused to spy out passwords cached by TortoiseSVN, which will reveal encrypted passwords in plaintext when asked to do so. To protect Alice from this attack, writing plaintext passwords must remain disabled during regular usage of SVN. We could provide a special mechanism to add a plaintext password under a set of conditions: - The command to run is not a regularly used SVN command. 'svn auth' would be a good candidate since its sole purpose is to inspect and manage the cached credentials store. - The user provides the password and authentication with this password against the server succeeds. - If a non-plaintext storage backend is available, that backend is used instead of storing the password in plaintext (but perhaps the plaintext backend could be forced via a command line switch). - The user gives consent to the password being stored in plaintext by answering 'yes' to the plaintext password prompt, in a way that cannot be overridden by configuration files (i.e. the value of the store-plaintext-passwords option in the servers configuration file would be ignored by this command). We could have 'svn auth add https://svn.example.com/svn/foo' as a one-shot operation that satisfies the above constraints, while leaving all other code paths compiled out which would otherwise store passwords in plaintext. A regular 'svn update' still won't cache a password in plaintext, unless --enable-plaintext-passwords was passed at compile-time. Now Alice can store a plaintext password (and will be aware of its existence), but Eve cannot fool Alice into doing so unless Subversion was compiled with the --enable-plaintext-passwords option. Would this work? Regards, Stefan
Re: A strong WTF on compiling out plaintext password support by default?!
Den mån 23 aug. 2021 kl 12:15 skrev Johan Corveleyn : > Anyway, concerning package maintainers, for Solaris, I'm getting even > more depressed ... > * We were using Collab.net's distro, but apparently their Solaris > build is no longer maintained: > https://www.collab.net/downloads/subversion > * Wandisco then? Nope: > https://www.wandisco.com/source-code-management/subversion#solaris ... > only Windows, Linux and MacOS. > * Fortunately, there is still a relatively recent build on OpenCSW: > https://www.opencsw.org/packages/subversion/ > > (-> Wandisco's link should be removed from > http://subversion.apache.org/packages.html#solaris -- making that > section empty ... or should we add a link to opencsw then?) > I agree, thanks for the suggestion! How about r1892550 ( http://subversion-staging.apache.org/packages.html#solaris)? Kind regards, Daniel Sahlberg
Re: A strong WTF on compiling out plaintext password support by default?!
Den mån 23 aug. 2021 kl 13:50 skrev Nathan Hartman : > On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn wrote: > >> I know the decision to disable plaintext pwd storage by default was >> briefly discussed on this very list [1], but sadly I didn't pay >> attention back then. I have a lot of respect for all people involved >> here, but I think this was a mistake, especially WRT server machines >> which don't have a GUI, no X11 etc. Or even if they have it installed, >> why force additional work on users / sysadmins that have been running >> these machines for years, and now have to jump through additional >> hoops, even if they decided before (through explicit configuration) >> that they were OK with plaintext password storage (= their decision / >> responsability). >> > [...] [1] >> https://lists.apache.org/thread.html/6751582f2d8eda885722933f935a3c90d1b0adb0f9c9dbe536a5c2d7%40%3Cdev.subversion.apache.org%3E >> >> -- >> Johan >> > > > Given the amount of complaints/trouble this change has led to, perhaps we > should rethink it and consider an approach where plaintext saving is always > compiled in but off until enabled by runtime config or something. > Has there been any complaints about Subversion's ability to store passwords in plaintext? (I tried to search the mailing list but didn't come up with anything, possibly because of a lack of imagination on proper keywords). Maybe these complaints would have gone to the different distributions? For reference, here is the e-mail where Stefan Sperling mentions the change in OpenBSD to re-enable support for plaintext passwords in OpenBSD: [2] I would encourage everyone to re-read that message since it has a good summary of arguments (including a link to a request from a corporate security group to TortoiseSVN to avoid storing a password in plaintext in memory). For me the route taken by OpenBSD seems reasonable: - Enable plaintext passwords in the compile time defaults - Disable plaintext passwords in the default runtime configuration - Let the users re-enable it in their configuration if they want to Pros: * It would not change the default behaviour. * It would enable users to enable plaintext passwords in configuration without having to recompile. Cons: * Potentially some security group would argue about the possibility to enable plaintext passwords at all. Kind regards, Daniel Sahlberg [2] http://mail-archives.apache.org/mod_mbox/subversion-dev/202008.mbox/%3C20200807083932.GU55188%40ted.stsp.name%3E
Re: A strong WTF on compiling out plaintext password support by default?!
Johan Corveleyn wrote on Mon, 23 Aug 2021 10:15 +00:00: > So I guess my best shot is contacting the maintainer of the openCSW > package, and asking him to add the --enable-plaintext-password-storage > configure flag and make a new build then. > > Building it ourselves is not an option. Write a wrapper tool that runs svn(1) in a pty and answers password prompts. ASF Infra did this once, complete with the wrapper prompting the user to enter a new password when the old one isn't accepted, but the code isn't public, AFAIK.
Re: A strong WTF on compiling out plaintext password support by default?!
On Mon, Aug 23, 2021 at 1:50 PM Nathan Hartman wrote: > > On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn wrote: >> >> On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak wrote: >> > >> > 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. >> > (https://stackoverflow.com/questions/2899209/how-to-save-password-when-using-subversion-from-the-console) >> > 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. >> > >> > Best, >> > Robby >> >> Late to te party, but I have to agree with Robby here. I'm only >> running into this now, since we'd like to upgrade the 1.9 client on >> our Solaris build machine to a more recent version ... sigh. >> >> I know the decision to disable plaintext pwd storage by default was >> briefly discussed on this very list [1], but sadly I didn't pay >> attention back then. I have a lot of respect for all people involved >> here, but I think this was a mistake, especially WRT server machines >> which don't have a GUI, no X11 etc. Or even if they have it installed, >> why force additional work on users / sysadmins that have been running >> these machines for years, and now have to jump through additional >> hoops, even if they decided before (through explicit configuration) >> that they were OK with plaintext password storage (= their decision / >> responsability). >> >> I have been defending Subversion at my company for a long time, >> highlighting its stability, simplicity and care for *backwards >> compatibility*. Unfortunately, backwards compatibility is broken here >> (I understand security can trump backwards compatibility, but to me >> this feels more like a "let's make this even more inconvenient" kind >> of security; not plugging a glaring security hole). So there goes one >> of my most important arguments pro SVN :-(. >> >> I know Stefan Sperling suggested in a reply to convince package >> maintainers, if necessary, to re-enable it
Re: A strong WTF on compiling out plaintext password support by default?!
On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn wrote: > On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak > wrote: > > > > 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. ( > https://stackoverflow.com/questions/2899209/how-to-save-password-when-using-subversion-from-the-console) > 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. > > > > Best, > > Robby > > Late to te party, but I have to agree with Robby here. I'm only > running into this now, since we'd like to upgrade the 1.9 client on > our Solaris build machine to a more recent version ... sigh. > > I know the decision to disable plaintext pwd storage by default was > briefly discussed on this very list [1], but sadly I didn't pay > attention back then. I have a lot of respect for all people involved > here, but I think this was a mistake, especially WRT server machines > which don't have a GUI, no X11 etc. Or even if they have it installed, > why force additional work on users / sysadmins that have been running > these machines for years, and now have to jump through additional > hoops, even if they decided before (through explicit configuration) > that they were OK with plaintext password storage (= their decision / > responsability). > > I have been defending Subversion at my company for a long time, > highlighting its stability, simplicity and care for *backwards > compatibility*. Unfortunately, backwards compatibility is broken here > (I understand security can trump backwards compatibility, but to me > this feels more like a "let's make this even more inconvenient" kind > of security; not plugging a glaring security hole). So there goes one > of my most important arguments pro SVN :-(. > > I know Stefan Sperling suggested in a reply to convince package > maintainers, if necessary, to re-enable it with a configure flag (as > he did for OpenBSD). But isn't that world upside down? Should every > packager now explicitly enable it? Why not leave the default as it > was, and tell package maintainers to disable it if they feel sensitive > about this
Re: A strong WTF on compiling out plaintext password support by default?!
On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak wrote: > > 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. > (https://stackoverflow.com/questions/2899209/how-to-save-password-when-using-subversion-from-the-console) > 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. > > Best, > Robby Late to te party, but I have to agree with Robby here. I'm only running into this now, since we'd like to upgrade the 1.9 client on our Solaris build machine to a more recent version ... sigh. I know the decision to disable plaintext pwd storage by default was briefly discussed on this very list [1], but sadly I didn't pay attention back then. I have a lot of respect for all people involved here, but I think this was a mistake, especially WRT server machines which don't have a GUI, no X11 etc. Or even if they have it installed, why force additional work on users / sysadmins that have been running these machines for years, and now have to jump through additional hoops, even if they decided before (through explicit configuration) that they were OK with plaintext password storage (= their decision / responsability). I have been defending Subversion at my company for a long time, highlighting its stability, simplicity and care for *backwards compatibility*. Unfortunately, backwards compatibility is broken here (I understand security can trump backwards compatibility, but to me this feels more like a "let's make this even more inconvenient" kind of security; not plugging a glaring security hole). So there goes one of my most important arguments pro SVN :-(. I know Stefan Sperling suggested in a reply to convince package maintainers, if necessary, to re-enable it with a configure flag (as he did for OpenBSD). But isn't that world upside down? Should every packager now explicitly enable it? Why not leave the default as it was, and tell package maintainers to disable it if they feel sensitive about this? Anyway, concerning package maintainers, for Solaris, I'm getting even more depressed ... * We were using Collab.net's distro, but
Re: A strong WTF on compiling out plaintext password support by default?!
Daniel Sahlberg wrote on Sat, 15 Aug 2020 11:28 +0200:
> Den fre 14 aug. 2020 23:44Daniel Shahaf skrev:
>
> > Daniel Sahlberg wrote on Fri, 14 Aug 2020 23:01 +0200:
> > > Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf > >:
> > >
> > > > It successfully adds a password to the storage, in the sense that
> > > > after running it, a subsequent `svn auth --show-passwords` shows the
> > > > password. Still, a subsequent `svn info` doesn't use the password.
> > > > Why? By source inspection, SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE
> > > > affects svn_auth__simple_creds_cache_set() but not
> > > > svn_auth__simple_creds_cache_get(),
> > > > so why doesn't the latter use the password?
> > > >
> > >
> > > It seems you also need to set passtype = simple for
> > > svn_auth__simple_creds_cache_get() to accept the password.
> > >
> >
> > Good catch.
> >
> > > Updated script, I changed to use /usr/bin/env to find zsh
> > > and explicitly set LANG to make sure svn auth return the expected
> > > text (normally I'm running sv_SE.UTF-8).
> >
> > Another good catch. Further improvements: it should set LC_ALL rather
> > than LANG, and the setting can be pushed into the $(…) subshell.
> > Furthermore, since this doesn't even try to be a POSIX script, the
> > «autoload -Uz _comp_locale; … $(_comp_locale; …)» idiom is also available.
> >
>
> That was way above my shell script comfort zone..
For completeness, I'm attaching the script again with that (trivial)
change made.
FWIW, I wouldn't usually have used zsh for code to be posted to this
list, since that language is spoken by few people here and isn't always
self-explanatory. That's one reason I described this script as
a "prototype". It should be easy to port this script to any other
language; what it does is:
1. Run `svn auth` with "LC_ALL=C" in the environment.
2. Split the output on empty lines ("\n\n"). This produces an array.
3. Remove the last element of the array (by pattern matching, but that's
the effect).
4. Prompt the user to choose an element of the array. This selects
a specific authn realm.
5. Prompt the user for the corresponding password.
6. Compute the md5 of the realm string, without a trailing newline.
7. Insert two key-value pairs to the serialized hash [see
svn_hash_write2()] in ~/.subversion/auth/ for the realm in question.
That uses ed(1) because the file format has a fixed trailer string.
This design means the script is only able to cache passwords for realms
for which a username is already cached.
Cheers,
Daniel
[[[
#!/usr/bin/env -S zsh -f
# Prompt for a realm and a password, then cache that password for that realm,
in plaintext.
PS3="Enter the number of the selected option: "
creds=( "${(ps.\n\n.)"$(LC_ALL=C svn auth)"}" )
creds=( ${(M)creds:#-*} )
select m in $creds
do
realm=${(M)${(f)m}:#Authentication realm: *}
realm=${realm#*: }
IFS= read -s -r pw"?Password: "
md5=${"$(printf %s "$realm" | openssl md5)"##*= }
print -rC1 \
\$ i \
"K 8" passtype "V 6" simple \
"K 8" password "V ${#pw}" "$pw" \
"." \
"w" \
"q" \
| ed -s ~/.subversion/auth/svn.simple/$md5
echo edited $_
break
done
]]]
Re: A strong WTF on compiling out plaintext password support by default?!
Den fre 14 aug. 2020 23:44Daniel Shahaf skrev: > Daniel Sahlberg wrote on Fri, 14 Aug 2020 23:01 +0200: > > Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf >: > > > > > It successfully adds a password to the storage, in the sense that > > > after running it, a subsequent `svn auth --show-passwords` shows the > > > password. Still, a subsequent `svn info` doesn't use the password. > > > Why? By source inspection, SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE > > > affects svn_auth__simple_creds_cache_set() but not > > > svn_auth__simple_creds_cache_get(), > > > so why doesn't the latter use the password? > > > > > > > It seems you also need to set passtype = simple for > > svn_auth__simple_creds_cache_get() to accept the password. > > > > Good catch. > > > Updated script, I changed to use /usr/bin/env to find zsh > > and explicitly set LANG to make sure svn auth return the expected > > text (normally I'm running sv_SE.UTF-8). > > Another good catch. Further improvements: it should set LC_ALL rather > than LANG, and the setting can be pushed into the $(…) subshell. > Furthermore, since this doesn't even try to be a POSIX script, the > «autoload -Uz _comp_locale; … $(_comp_locale; …)» idiom is also available. > That was way above my shell script comfort zone.. > I even think [SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE] could > > prevent reading an already stored password. > > So what would be done with the already-stored password? > > - Deleting it would be data loss. > > - Keeping it but not using it would needlessly increase the attack > surface: Mallory might find the plaintext password, but since svn > itself won't use it, it won't show up in audits' syscall traces and > so on. > > - [There may very well be a third option, but I haven't the time to > think one up right now.] > Good point and I agree with your analysis. No perfect solution there. Thanks for the bugfixes! > > Daniel >
Re: A strong WTF on compiling out plaintext password support by default?!
Daniel Sahlberg wrote on Fri, 14 Aug 2020 23:01 +0200: > Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf : > > > It successfully adds a password to the storage, in the sense that > > after running it, a subsequent `svn auth --show-passwords` shows the > > password. Still, a subsequent `svn info` doesn't use the password. > > Why? By source inspection, SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE > > affects svn_auth__simple_creds_cache_set() but not > > svn_auth__simple_creds_cache_get(), > > so why doesn't the latter use the password? > > > > It seems you also need to set passtype = simple for > svn_auth__simple_creds_cache_get() to accept the password. > Good catch. > Updated script, I changed to use /usr/bin/env to find zsh > and explicitly set LANG to make sure svn auth return the expected > text (normally I'm running sv_SE.UTF-8). Another good catch. Further improvements: it should set LC_ALL rather than LANG, and the setting can be pushed into the $(…) subshell. Furthermore, since this doesn't even try to be a POSIX script, the «autoload -Uz _comp_locale; … $(_comp_locale; …)» idiom is also available. > I even think [SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE] could > prevent reading an already stored password. So what would be done with the already-stored password? - Deleting it would be data loss. - Keeping it but not using it would needlessly increase the attack surface: Mallory might find the plaintext password, but since svn itself won't use it, it won't show up in audits' syscall traces and so on. - [There may very well be a third option, but I haven't the time to think one up right now.] Thanks for the bugfixes! Daniel
Re: A strong WTF on compiling out plaintext password support by default?!
Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf :
> It successfully adds a password to the storage, in the sense that
> after running it, a subsequent `svn auth --show-passwords` shows the
> password. Still, a subsequent `svn info` doesn't use the password.
> Why? By source inspection, SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE
> affects svn_auth__simple_creds_cache_set() but not
> svn_auth__simple_creds_cache_get(),
> so why doesn't the latter use the password?
>
It seems you also need to set passtype = simple for
svn_auth__simple_creds_cache_get() to accept the password.
Updated script, I changed to use /usr/bin/env to find zsh and explicitly
set LANG to make sure svn auth return the expected text (normally I'm
running sv_SE.UTF-8).
[[[
#!/usr/bin/env -S zsh -f
# Prompt for a realm and a password, then cache that password for that
realm, in plaintext.
LANG=en_US.UTF-8
PS3="Enter the number of the selected option: "
creds=( "${(ps.\n\n.)"$(svn auth)"}" )
creds=( ${(M)creds:#-*} )
select m in $creds
do
realm=${(M)${(f)m}:#Authentication realm: *}
realm=${realm#*: }
IFS= read -s -r pw"?Password: "
md5=${"$(printf %s "$realm" | openssl md5)"##*= }
print -rC1 \
\$ i "K 8" passtype "V 6" simple "K 8" password "V ${#pw}"
"$pw" "." "w" "q" \
| ed -s ~/.subversion/auth/svn.simple/$md5
echo edited $_
break
done
]]]
A proper svn store-password command would be nice to better support non-X11
automated environments in case of "stupid" compile time options. But that
moots the point of SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE and I understand
the need for it in certain (corporate) environments, I even think it could
prevent reading an already stored password. Better to convince
your favorite distribution to take the approach of OpenBSD (as detailed by
Stefan Sperling elsewhere in the thread).
Kind regards,
Daniel
Re: A strong WTF on compiling out plaintext password support by default?!
Dr. Thomas Orgis wrote on Fri, 07 Aug 2020 09:41 +0200:
> Am Fri, 7 Aug 2020 05:53:24 +
> schrieb Daniel Shahaf :
>
> > > > 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
I'm attaching a prototype standalone script implementing this
functionality.
It successfully adds a password to the storage, in the sense that
after running it, a subsequent `svn auth --show-passwords` shows the
password. Still, a subsequent `svn info` doesn't use the password.
Why? By source inspection, SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE
affects svn_auth__simple_creds_cache_set() but not
svn_auth__simple_creds_cache_get(),
so why doesn't the latter use the password?
Cheers,
Daniel
[[[
#!/usr/local/bin/zsh -f
# Prompt for a realm and a password, then cache that password for that realm,
in plaintext.
PS3="Enter the number of the selected option: "
creds=( "${(ps.\n\n.)"$(svn auth)"}" )
creds=( ${(M)creds:#-*} )
select m in $creds
do
realm=${(M)${(f)m}:#Authentication realm: *}
realm=${realm#*: }
IFS= read -s -r pw"?Password: "
md5=${"$(printf %s "$realm" | openssl md5)"##*= }
print -rC1 \
\$ i "K 8" password "V ${#pw}" "$pw" "." "w" "q" \
| ed -s ~/.subversion/auth/svn.simple/$md5
echo edited $_
break
done
]]]
Re: A strong WTF on compiling out plaintext password support by default?!
On Thu, Aug 06, 2020 at 06:56:55PM -0700, Robby Zinchak wrote: > 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 5) Convince Ubuntu packagers to enable this feature. Package maintainers can very easily re-enable this at compile-time. It's a single extra flag to pass to during the 'configure' step. I did exactly this on OpenBSD last year (commit shown below). The real problem is that whatever Subversion's upstream default is, one group of people is going to be unhappy. Everybody seems to expect their own use case to work out of the box, failing to recognize that contradictory requirements exist. There really isn't a one-size fits all solution to this. We provide all the options, but packagers need to choose and take the necessary steps to get the behaviour they want to provide to their users. A recent example in a related project (TortoiseSVN) where people want the exact opposite of what you want: https://groups.google.com/forum/#!topic/tortoisesvn/V3rLLYZgeRA In this case, the problem is that allowing people to easily sniff passwords is considered a big no-no in a particular deployment, and means SVN might get banned there. The behaviour was not changed; it is TortoiseSVN's choice as the packager of these particular SVN binaries, and this needs to be respected. Do you know if Ubuntu made a decision to disallow plaintext passwords? Perhaps they just missed the news that it has become a compile-time option? Regards, Stefan https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/subversion/Makefile CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2019/12/19 12:43:14 Modified files: devel/subversion: Makefile Log message: Re-enable support for storing plaintext passwords in Subversion. Subversion has disabled saving of plaintext passwords by default and a compile-time option is now required to enable this feature. OpenBSD has always disabled this feature at run-time in /etc/subversion and left users the choice to enable it in their configuration files. Unfortunately, the alternative password stores, gnome-keyring and KDE wallet, do not work in non-X11 environments. And the gpg-agent password store is not persistent. So there is no better solution for unattended SVN password authentication in non-X11 environments on OpenBSD, or pretty much any UNIX-like system for that matter. ok sthen@
Re: A strong WTF on compiling out plaintext password support by default?!
Am Fri, 7 Aug 2020 05:53:24 + schrieb Daniel Shahaf : > > > 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
Re: A strong WTF on compiling out plaintext password support by default?!
Robby Zinchak wrote on Thu, 06 Aug 2020 18:56 -0700: > I would love to hear what the expected workaround is for users running > automated subversion clients on server VMs [...]. > As I wrote on SVN-4861 recently: > > Also, if I'm reading the code correctly, simply adding the password > > to the md5sum(realm)-named file in ~/.subversion/auth/svn.simple/ > > should work: the compile-time knob prevents passwords from being > > _written_, but doesn't prevent passwords already there from being > > read.
A strong WTF on compiling out plaintext password support by default?!
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. ( https://stackoverflow.com/questions/2899209/how-to-save-password-when-using-subversion-from-the-console) 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. Best, Robby
