On Wed, Jan 19, 2022 at 9:08 PM Karl Fogel <kfo...@red-bean.com> 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 1 if they must go that route.
Anyway ... maybe the idea I sent to the list could be another approach
that satisfies both? Unfortunately, other than reading and responding
to messages on the list I probably do not have time to otherwise
contribute to this project anymore.
Thanks
Mark
