A strong WTF on compiling out plaintext password support by default?!

[Robby Zinchak <si...@editingarchive.com>]

 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

Re: A strong WTF on compiling out plaintext password support by default?!

[Stefan Sperling <st...@elego.de>]

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:	stsp@cvs.openbsd.org	2019/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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

Daniel Sahlberg wrote on Sat, 15 Aug 2020 11:28 +0200:
> Den fre 14 aug. 2020 23:44Daniel Shahaf <d....@daniel.shahaf.name> skrev:
> 
> > Daniel Sahlberg wrote on Fri, 14 Aug 2020 23:01 +0200:  
> > > Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf <d.s@daniel.shahaf.name
> > >:
> > >  
> > > > 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?!

[Daniel Sahlberg <da...@gmail.com>]

Den fre 14 aug. 2020 23:44Daniel Shahaf <d....@daniel.shahaf.name> skrev:

> Daniel Sahlberg wrote on Fri, 14 Aug 2020 23:01 +0200:
> > Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf <d.s@daniel.shahaf.name
> >:
> >
> > > 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 Shahaf <d....@daniel.shahaf.name>]

Daniel Sahlberg wrote on Fri, 14 Aug 2020 23:01 +0200:
> Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf <d....@daniel.shahaf.name>:
> 
> > 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?!

[Daniel Sahlberg <da...@gmail.com>]

Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf <d....@daniel.shahaf.name>:

> 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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

Dr. Thomas Orgis wrote on Fri, 07 Aug 2020 09:41 +0200:
> Am Fri, 7 Aug 2020 05:53:24 +0000
> schrieb Daniel Shahaf <d....@daniel.shahaf.name>: 
> 
> > > > 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?!

["Dr. Thomas Orgis" <th...@uni-hamburg.de>]

Am Fri, 7 Aug 2020 05:53:24 +0000
schrieb Daniel Shahaf <d....@daniel.shahaf.name>: 

> > > 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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

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.

Re: A strong WTF on compiling out plaintext password support by default?!

[Stefan Sperling <st...@elego.de>]

On Fri, Aug 27, 2021 at 12:02:58PM +0000, 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?!

[Martin Edgar Furter Rathod <mf...@apache.org>]

On 30.08.21 03:38, Barry wrote:
> 
> 
>> On 26 Aug 2021, at 11:30, Stefan Sperling <st...@elego.de> 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?!

[Barry <ba...@barrys-emacs.org>]

> On 26 Aug 2021, at 11:30, Stefan Sperling <st...@elego.de> 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?!

[Stefan Sperling <st...@elego.de>]

On Thu, Aug 26, 2021 at 12:15:39PM +0000, 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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

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?!

[Stefan Sperling <st...@elego.de>]

On Thu, Aug 26, 2021 at 04:08:34PM -0400, Nathan Hartman wrote:
> On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling <st...@elego.de> 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?!

[Nathan Hartman <ha...@gmail.com>]

On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling <st...@elego.de> 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?!

[Stefan Sperling <st...@elego.de>]

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?!

[Mark Phippard <ma...@gmail.com>]

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
<da...@gmail.com> 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?!

[Nathan Hartman <ha...@gmail.com>]

On Sun, Oct 3, 2021 at 7:17 PM Johan Corveleyn <jc...@gmail.com> wrote:
>
> On Sun, Oct 3, 2021 at 12:39 PM Daniel Sahlberg <da...@gmail.com> wrote:
> >
> > Hi,
> >
> > I would like to reboot this thread once again. I have read through all messages and I have tried to make a summary of the important points. The date/time references are as seen in https://mail-archives.apache.org/mod_mbox/subversion-dev/.
> >

(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?!

[Johan Corveleyn <jc...@gmail.com>]

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

Thank you for picking this up again, Daniel.

It's tempting to think consensus is within reach, and we've not really
heard that many complaints of subversion's plaintext storage feature (as
Daniel Sahlberg's search did not find any). However, before we proceed any
further, and potentially shoot ourselves in the foot again, I think it's
important to have a good enough picture of both sides of the argument.

Now, I do remember one particularly vocal participant on users@ who
regularly brought up the issue: Nico Kadel-Garcia. If you search the users@
archives for posts from Nico, in combination with "plaintext" or "clear
text" or some similar keyword, I'm sure you'll find several interesting
posts (regardless whether or not you agree with them).

(sidenote: unfortunately, it's pretty hard to search the entirety of our
archives this way -- somehow the different archives find different matches,
but none find all of them -- searching my own gmail archive worked best,
but obviously that's not portable)

I've quickly selected a couple of them:

https://svn.haxx.se/users/archive-2006-07/0591.shtml
https://svn.haxx.se/users/archive-2006-08/1006.shtml

"In fact, I'd *love* to be able to compile Subversion so that it's svn
client
refuses to store such passwords. If I wrote in such a compile-time option as
a patch, could I get support for it? I'd definitely prefer to see the
clients compiled this paranoid way. "

https://svn.haxx.se/users/archive-2010-07/0179.shtml
https://svn.haxx.se/users/archive-2010-08/0000.shtml
https://svn.haxx.se/users/archive-2010-10/0133.shtml
https://svn.haxx.se/users/archive-2011-12/0161.shtml

"The other, and more powerful reason, is that Linux and
UNIX clients for Subversion store the passwords, by default, as
plain-text in a well-known location in your home directory. It's
possible to set up more clever password storage schemes, such as Gnome
or KDE "wallets", but they remain awkward and difficult to use for
unattended behavior such as nightly auto-build systems.

So wherever feasible, I use svn+ssh. I've also seen reports that
Kerberized access can work well, ..."

https://svn.haxx.se/users/archive-2012-06/0311.shtml

"It's also unreliable, since *any* arbitrary client can and will store
the plain-text password for HTTP or HTTPS access *unless* you can
control the client setups enough to block the feature."

https://svn.haxx.se/users/archive-2012-12/0058.shtml
https://mail-archives.apache.org/mod_mbox/subversion-users/202102.mbox/%3CCAOCN9rzwh2Dht8%2BU2siK3x-srAuD%3DKvXE0ype8Tu%2Bo7eTt8juw%40mail.gmail.com%3E


Also, we seem to have a wiki page about our options (and possible future
avenues) for (encrypted) password storage:
https://cwiki.apache.org/confluence/display/SVN/EncryptedPasswordStorage

Now, I know it's not easy to rehash old arguments and look back at
discussions from years ago. Nonetheless, I think it's important that we
don't ignore them, and do what we can to analyse and understand the issue
from all sides.

I have copied Nico here in cc, so he might clarify / summarize / offer more
suggestions / ... himself, if he wants to. Nico, I hope you don't mind that
I've singled out your posts :-), but they are good examples of complaints
about the plaintext password storage. Feel free to add more to this thread,
or simply ignore it if you prefer.

-- 
Johan

Re: A strong WTF on compiling out plaintext password support by default?!

[Daniel Sahlberg <da...@gmail.com>]

Hi,

I would like to reboot this thread once again. I have read through all
messages and I have tried to make a summary of the important points. The
date/time references are as seen in
https://mail-archives.apache.org/mod_mbox/subversion-dev/.

There are numerous descriptions of problems with the different keyrings. I
think the most important are:
- Some requiring GUI boxes to unlock, even showing GUI boxes on the local
display while running over SSH
- No easy way to work with the keyrings non-interactive

The original request was to find some way to store credentials in the
plaintext cache.

Two different solutions have been presented:
- Reverting the compile time default to enable the plaintext password
store, while setting runtime configuration options to disable it, following
the example set by OpenBSD.
Four persons seem to have expressed support for this idea (Mark Phippard,
Johan Corveleyn, myself (2021-08-26 13:34 to 2021-08-27 07:56) and Martin
Edgar Furter Rathod (2021-08-31 12:46)). The former three prefering it over
the svn auth, but accepting the idea of svn auth. Martin suggested to move
the plaintext support to a separate library that could be installed
separately (or removed after installation), no-one picked up this idea.

- Adding an svn auth add command
One person seem to have expressed support for this (Stefan Sperling
(2021-08-24 08:27 and again 2021-08-27 12:40)). The first message is the
earliest suggestion of svn auth add that I can find. In the latter message,
Stefan clarifies that he belives svn auth add is the better design but
wouldn't stand in the way of consensus. He also wrote he had been willing
to invest time in writing the code for svn auth add but not for switching
the default compile-time behaviour.
Regarding the need to validate the credentials with the server, it seems
this was based on pseudocode by Johan Corveleyn (2021-08-24 14:25) doing
svn ls, and then asking for a new password if svn ls failed. It was
mentioned by Daniel Shahaf that svn ls might succeed even if the
credentials were incorrect (as with svn.apache.org offering anonymous
access) or that the check only verified "r" access and later code might
require "w" access.
It seems to be a general agreement that it is currently not possible to
validate if some credentials have a certain level of access to a certain
path, in a general case. It was suggested to add RA API calls, but these
would only work with new versions of both the server and the client.
There has been a significant discussion whether to verify the credentials
and whose responsibility it is to store correct credentials (with
appropriate access).

---- This is the end of the summary. Below are my personal reflections

I have ignored the discussion regarding rethorics since I hope we can
continue without it. If someone feels hurt because of the discussion I hope
it can be worked out without affecting the future discussion in this
thread. I think all contributors have come with valuable input on the
design questions so far.

It seems most messages are concerning the svn auth add solution. To add
this command without contacting the server seems to be quite a bit of code
but not impossible. It would also be a client-side only solution not
requiring any specific server version. To add support on the server side
might be difficult, especially considering that (part of) the
authentication/authorization might be done outside of the Subversion code.

The decision to change the compile time default was made in 2018-10-31
within less than 12 hours and without much debate. It was committed less
than 19 hours after the initial message.
I'm assume the impact of an incorrect password in the store is application
dependant but a password can grow stale even if it was correct at the time
of writing so the administrator would have to manage this anyhow. From my
point of view, verifying the credentials is nice but not necessary to solve
the initial use case.

Until we completely remove the possibility to read the plaintext store
security conscious organisation might have issues. Having svn auth add as
an official command makes it more obvious that this possibility exists -
instead of users running unofficial scripts or even manually editing the
config files. Anyone who feel it should not even read the plaintext
password store could convince their vendor to remove it or roll their own.

---- Below is  my understanding of the decision tree and my proposal:

The first point where we must reach agreement is whether or not to do
anything at all:
 * There has been several complaints from several different users over
   the last years who's workflow has been interrupted. There may be users
   or organisations who disprove of storing passwords in the plaintext
   stores. Whatever we choose there will be someone who feels we make
   the wrong choice.
 * If we decide it is a reasonable use case store passwords in plaintext
   and that we should support writing this store we need to decide which
   solution to use:
    * Revert r1845377 and enable plaintext password store by default. I
      have not been able to find any complaints in the public archives
      about subversion's ability to store passwords in plaintext. As
      pointed out by Stefan Sperling (2021-08-24 08:27) there was a FAQ
      entry based on the nature of complaints received, some that might
      have gone directly to the companies involved in Subversion
      development.
    * Create an svn auth add command. This option has the advantage that
      one person has expressed interest to invest time to write the code.
    * Script in contrib. The least visible option and several people
      have expressed that it will be difficult for them to maintain a
      local copy of the script. Only advantage is that it gives us
      plausible deniability: "Subversion doesn't store passwords but
      we can't prevent your users from downloading a script and using".
 * If we go for svn auth add we must decide how important it is to
   verify that the credentials have the correct access.

Based on the reasoning above I'm proposing:
- Adding an svn auth add command that more or less does what the scripts
are already doing. It should require typing the password in a loop until
repeated correctly but not do anything to verify that the password is
correct. Anyone requiring to validate the password can do it with an
appropriate svn command based on their authn/authz setup and their
requirements.
- Adding this in SVN 1.15.0.

I don't have much time to contribute but I will help as much as I can in
testing.

Kind regards
Daniel Sahlberg

Re: A strong WTF on compiling out plaintext password support by default?!

[Nathan Hartman <ha...@gmail.com>]

On Fri, Aug 27, 2021 at 9:26 AM Johan Corveleyn <jc...@gmail.com> wrote:
>
> On Fri, Aug 27, 2021 at 2:03 PM Daniel Shahaf <d....@daniel.shahaf.name> 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?!

[Johan Corveleyn <jc...@gmail.com>]

On Fri, Aug 27, 2021 at 2:03 PM Daniel Shahaf <d....@daniel.shahaf.name> 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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

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?!

[Daniel Sahlberg <da...@gmail.com>]

Den fre 27 aug. 2021 kl 09:15 skrev Johan Corveleyn <jc...@gmail.com>:

> On Thu, Aug 26, 2021 at 3:44 PM Mark Phippard <ma...@gmail.com> wrote:
> >
> > On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling <st...@elego.de> 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?!

[Johan Corveleyn <jc...@gmail.com>]

On Thu, Aug 26, 2021 at 3:44 PM Mark Phippard <ma...@gmail.com> wrote:
>
> On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling <st...@elego.de> 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?!

[Mark Phippard <ma...@gmail.com>]

On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling <st...@elego.de> 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?!

[Stefan Sperling <st...@elego.de>]

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 <jc...@gmail.com> 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?!

[Stefan Sperling <st...@elego.de>]

On Thu, Aug 26, 2021 at 04:17:16PM +0200, Daniel Sahlberg wrote:
> Den tors 26 aug. 2021 kl 16:10 skrev Stefan Sperling <st...@elego.de>:
> 
> > 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?!

[Daniel Sahlberg <da...@gmail.com>]

Den tors 26 aug. 2021 kl 16:10 skrev Stefan Sperling <st...@elego.de>:

> 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?!

[Stefan Sperling <st...@elego.de>]

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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

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?!

[Branko Čibej <br...@apache.org>]

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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

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?!

[Branko Čibej <br...@apache.org>]

On 25.08.2021 21:01, Mark Phippard wrote:
> On Wed, Aug 25, 2021 at 3:16 AM Johan Corveleyn <jc...@gmail.com> 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?!

[Mark Phippard <ma...@gmail.com>]

On Wed, Aug 25, 2021 at 3:16 AM Johan Corveleyn <jc...@gmail.com> 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?!

[Stefan Sperling <st...@elego.de>]

On Fri, Aug 27, 2021 at 11:38:57AM +0000, 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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

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?!

[Johan Corveleyn <jc...@gmail.com>]

On Thu, Aug 26, 2021 at 4:31 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Johan Corveleyn wrote on Thu, 26 Aug 2021 12:41 +00:00:
> > On Wed, Aug 25, 2021 at 8:52 PM Daniel Shahaf <d....@daniel.shahaf.name> 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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

Johan Corveleyn wrote on Thu, 26 Aug 2021 12:41 +00:00:
> On Wed, Aug 25, 2021 at 8:52 PM Daniel Shahaf <d....@daniel.shahaf.name> 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?!

[Johan Corveleyn <jc...@gmail.com>]

On Wed, Aug 25, 2021 at 8:52 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Wed, 25 Aug 2021 07:16 +00:00:
> > On Tue, Aug 24, 2021 at 7:03 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > > Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> > > > On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf <d....@daniel.shahaf.name> 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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

Johan Corveleyn wrote on Wed, 25 Aug 2021 07:16 +00:00:
> On Tue, Aug 24, 2021 at 7:03 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> > > On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf <d....@daniel.shahaf.name> 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?!

[Johan Corveleyn <jc...@gmail.com>]

On Tue, Aug 24, 2021 at 7:03 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> > On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf <d....@daniel.shahaf.name> 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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf <d....@daniel.shahaf.name> 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?!

[Johan Corveleyn <jc...@gmail.com>]

On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf <d....@daniel.shahaf.name> 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 E000042 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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

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 E000042 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?!

[Johan Corveleyn <jc...@gmail.com>]

On Tue, Aug 24, 2021 at 1:24 PM Stefan Sperling <st...@elego.de> 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?!

[Stefan Sperling <st...@elego.de>]

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?!

[Johan Corveleyn <jc...@gmail.com>]

[ 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 <st...@elego.de> 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?!

[Stefan Sperling <st...@elego.de>]

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?!

[Johan Corveleyn <jc...@gmail.com>]

On Mon, Aug 23, 2021 at 1:50 PM Nathan Hartman <ha...@gmail.com> wrote:
>
> On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn <jc...@gmail.com> wrote:
>>
>> On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak <si...@editingarchive.com> 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 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?)
>> (-> this abandoning of packagers / maintainers makes me feel our
>> ecosystem is breaking down)
>>
>> 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.
>>
>> [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.
>
> In the meantime, even with plaintext support compiled out, SVN always supports using passwords that are already stored.

Yes, I know. But with passwords being changed regularly, that's not
going to help for long.

> So, as a workaround, is it an option to use either Daniel Shahaf's zsh script or Daniel Sahlberg's python script (both upthread I think) to store the needed passwords?

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. I don't want to explain to
them how to run an additional script when the password has been
changed (and how / where do I manage the "canonical version" of such a
script etc). I also don't want to write the additional plumbing in our
buildscripts to automate this (capture a pwd failure from svn; propose
to the user "hey, maybe the password was changed, want to type in a
new one?"; run external script and handling its possible errors; all
transparent to the user / dev that really doesn't want to know about
all this ...).

Maybe I should take a closer look at gnome-keyring or one of the
alternatives, but ... first have to gather some energy to climb that
hill.

-- 
Johan

Re: A strong WTF on compiling out plaintext password support by default?!

[Karl Fogel <kf...@red-bean.com>]

On 20 Jan 2022, Dr. Thomas Orgis wrote:
>Am Wed, 19 Jan 2022 20:08:06 -0600
>schrieb Karl Fogel <kf...@red-bean.com>: 
>
>> 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?!

["Dr. Thomas Orgis" <th...@uni-hamburg.de>]

Am Wed, 19 Jan 2022 20:08:06 -0600
schrieb Karl Fogel <kf...@red-bean.com>: 

> 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?!

[Karl Fogel <kf...@red-bean.com>]

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?!

[Stefan Sperling <st...@elego.de>]

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: [PROPOSAL] Allow plaintext passwords again. (was: Re: A strong WTF on compiling out plaintext password support by default?!)

[Nathan Hartman <ha...@gmail.com>]

On Fri, Jan 21, 2022 at 7:35 AM Mark Phippard <ma...@gmail.com> wrote:

> On Thu, Jan 20, 2022 at 11:50 PM Karl Fogel <kf...@red-bean.com> 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: [VOTE] Reverting r1845377 (Was: [PROPOSAL] Allow plaintext passwords again.)

[Mark Phippard <ma...@gmail.com>]

On Sat, Apr 22, 2023 at 4:30 AM Branko Čibej <br...@apache.org> wrote:
>
> On 22.04.2023 10:27, Branko Čibej wrote:
>
> On 21.04.2023 16:43, Johan Corveleyn wrote:
>
>
> My plan is to revert r1845377 during next weekend. For the first bulletpoint nothing has to be done, but if consensus changes during the week, I can do the work to to implement option 1. For the second bullet point I'd like to reach consensus (on the short- and long term plan) by the same time, then if we decide on 2/3 we will put it on the wish list for a future release.
>
> Great!

+1. great to see progress on this. Getting the change reverted should
be the priority. If someone volunteers to take up some of the
additional ideas even better but we do not need to block on them.


> There was one additional suggestion: obfuscate plaintext passwords, or
> encrypt them with a key embedded in the code (or even with a key
> supplied at compile-time).
>
>
> There's actually a branch for that, but the feature never made it to trunk.
>
>
> I'll just add that the intent of that branch is to properly encrypt passwords at least on Linux, not to obfuscate them or embed a key in the code. The latter is worse than storing in plain text, because the effect is the same but it adds a veneer of false sense of security.

Feedback we had from users did not agree with this. They would have
seen something as simple as Base64 encoding the string as an
improvement. I believe there is a way to implement this without
creating the impression that the string is cryptographically secure.
For starters, you could just name the property in the file something
like "obfuscatedPassword" or "base64Password" to make it clear.
Kubernetes has used the term "Opaque" for its Base64 encoded but
otherwise plaintext "secrets".

Even if we did use encryption and stored the key in the same file it
would still be better than having a plain text string.

I would agree that we should not suggest that the password is "secure"
if we do this but we have let this argument be the enemy of making
progress for nearly 2 decades when lots of users have said this would
be an improvement for them.

Mark

Re: [VOTE] Reverting r1845377 (Was: [PROPOSAL] Allow plaintext passwords again.)

[Daniel Sahlberg <da...@gmail.com>]

Den lör 22 apr. 2023 kl 10:30 skrev Branko Čibej <br...@apache.org>:

> On 22.04.2023 10:27, Branko Čibej wrote:
>
> On 21.04.2023 16:43, Johan Corveleyn wrote:
>
>
> My plan is to revert r1845377 during next weekend. For the first bulletpoint nothing has to be done, but if consensus changes during the week, I can do the work to to implement option 1. For the second bullet point I'd like to reach consensus (on the short- and long term plan) by the same time, then if we decide on 2/3 we will put it on the wish list for a future release.
>
> Great!
>
> There was one additional suggestion: obfuscate plaintext passwords, or
> encrypt them with a key embedded in the code (or even with a key
> supplied at compile-time).
>
>
> There's actually a branch for that, but the feature never made it to trunk.
>
>
> I'll just add that the intent of that branch is to properly encrypt
> passwords at least on Linux, not to obfuscate them or embed a key in the
> code. The latter is worse than storing in plain text, because the effect is
> the same but it adds a veneer of false sense of security.
>

I assume you are referring to the master-password branch? That will not
help with the use case some users are having - ie unattended svn actions -
since the user will have to enter the master password instead of the
password. (The use case "not remembering a lot of different passwords while
not storing passwords in clear" is of course solved by a master password).

--- thread reply ---
As you have probably seen, I've committed the revert as r1909351.

I have not made up my mind regarding the other points, but as pointed out
by several others, let's start with reverting and then take it from there.
I will read through all e-mails once more and see if i can sumarize the
discussion somewhat. So far I couldn't see any clear direction.

Kind regards,
Daniel

Re: [VOTE] Reverting r1845377 (Was: [PROPOSAL] Allow plaintext passwords again.)

[Branko Čibej <br...@apache.org>]

On 22.04.2023 10:27, Branko Čibej wrote:
> On 21.04.2023 16:43, Johan Corveleyn wrote:
>>
>>> My plan is to revert r1845377 during next weekend. For the first bulletpoint nothing has to be done, but if consensus changes during the week, I can do the work to to implement option 1. For the second bullet point I'd like to reach consensus (on the short- and long term plan) by the same time, then if we decide on 2/3 we will put it on the wish list for a future release.
>> Great!
>>
>> There was one additional suggestion: obfuscate plaintext passwords, or
>> encrypt them with a key embedded in the code (or even with a key
>> supplied at compile-time).
>
> There's actually a branch for that, but the feature never made it to 
> trunk.

I'll just add that the intent of that branch is to properly encrypt 
passwords at least on Linux, not to obfuscate them or embed a key in the 
code. The latter is worse than storing in plain text, because the effect 
is the same but it adds a veneer of false sense of security.

-- Brane

Re: [VOTE] Reverting r1845377 (Was: [PROPOSAL] Allow plaintext passwords again.)

[Branko Čibej <br...@apache.org>]

On 21.04.2023 16:43, Johan Corveleyn wrote:
>
>> My plan is to revert r1845377 during next weekend. For the first bulletpoint nothing has to be done, but if consensus changes during the week, I can do the work to to implement option 1. For the second bullet point I'd like to reach consensus (on the short- and long term plan) by the same time, then if we decide on 2/3 we will put it on the wish list for a future release.
> Great!
>
> There was one additional suggestion: obfuscate plaintext passwords, or
> encrypt them with a key embedded in the code (or even with a key
> supplied at compile-time).

There's actually a branch for that, but the feature never made it to trunk.

Re: [VOTE] Reverting r1845377 (Was: [PROPOSAL] Allow plaintext passwords again.)

[Johan Corveleyn <jc...@gmail.com>]

On Sun, Apr 16, 2023 at 11:19 PM Daniel Sahlberg
<da...@gmail.com> wrote:
>
> The dicussion died again, but this time I intend make sure we complete it once and for all. I've marked the subject as VOTE to hopefully get some attention, although I believe votes have already been cast.

Thanks for picking it up once again :-). Let's hope we can land this now ...

> In my mind, it seems we have consensus to revert r1845377 (+1 from Nathan Hartman, Evgeny Kotkov, Johan Corveleyn, myself, I'm also considering Karl Fogel to have voted for this by making the initial proposition and volunteering to do it. No objections).

Indeed, +1 from me.

> Then we have a two other suggestions:
>
> * Changing the default value of store-plaintext-passwords
> Option 1 - set the default value of store-plaintext-passwords to no. For a non-edited servers config file, this will put the behaviour of 1.15 in line with 1.12-1.14.
> Option 2 - keep store-plaintext-passwords = ask. For a non-edited servers config file, the behaviour of 1.15 will be in line with pre-1.12.
>
> I have previously expressed support (but no formal vote, and I will not stand in the way of consensus) for option 1, since I was under the impression that it was a longterm goal go disable the plaintext password store (I have previously commented on how quickly r1845377 was discussed and implemented). Nathan has argued that it might give a bad user experience if credentials are not stored even though plaintext storage is enabled in the build options. We can improve on this by updating the svn --version output to explicitly say if plaintext cache is build but runtime disabled.
>
> If I'm counting correctly, Nathan, Evgeny and Johan has expressed +1 for option 2.
>
> Considering this, I conclude we have consensus for option 2.
>
>
> * Changing handling of already stored plaintext passwords
> This was discussed in 2022 and there were some suggestions that Subversion should not even use plaintext passwords even if they were found in the plaintext password store (initially suggested by Mark Phippard as a way to soften the impact of reverting r1845377). I'm proposing we choose amoung one of the following three options:
>
> Option 1 - do nothing. Keep using the stored passwords.
> Option 2 - add a new runtime config option dont-use-plaintext-passwords [default no] global overrides local.
> Option 3 - new compile time option to disable reading/using plaintext passwords.

Why a new compile-time option for disabling reading? Why not keep it
simple, and disable the reading of plaintext passwords if the
compile-time option that will be re-introduced by reverting r1845377
is supplied (--disable-plaintext-password-storage)? I think that is
what Mark was suggesting, and I still like it because it's simple and
doesn't add more knobs than necessary.

So maybe:
Option 4 - disable reading/using plaintext passwords if compile-time
/storing/ of plaintext-passwords is configured
(--disable-plaintext-password-storage).

>
> Options 2 and 3 should probably imply disabling storing plaintext passwords as well. I think they should also warn if the code finds a stored password and suggest the user to delete it using svn auth --remove. (It was hinted previously that we would disable the code that searches for the files storing the password, however the same files also store the username and we read them as an apr_hash_t so we don't really have the option to "not read the password").
>
> With option 2 or 3 we let a security consious organisation configure their system to their liking. I would love to have them, but I can't avoid the feeling that it is security theater: As far as I can tell it is not possible to avoid that a user can upload their own version of the svn binary and then all bets are off anyway. (On Windows and MacOS it is possible to only allow execution of signed binaries, and they don't even store the passwords in plaintext anyway).
>
> If we go with either 2 or 3, then I'm perfering option 2 since it will allow the administrators to set this without compiling their own version (which seems to be a major obstacle, considering the reaction to r1845377). I believe Karl Fogel and Mark was also leaning towards doing something during the discussion in 2022.
>
> Johan seems to believe option 1 is fine ("these additional \"mitigations\" are not absolutely required").
>
> In my mind, it is perfectly acceptable to vote +1 on both option 1 AND one of option 2/3. I would interpret that as "do nothing in the short term, but do X in the long term".

Agreed. So option 1 follows automatically from reverting r1845377; and
option 2, 3 or 4 can be done later.

>
> My plan is to revert r1845377 during next weekend. For the first bulletpoint nothing has to be done, but if consensus changes during the week, I can do the work to to implement option 1. For the second bullet point I'd like to reach consensus (on the short- and long term plan) by the same time, then if we decide on 2/3 we will put it on the wish list for a future release.

Great!

There was one additional suggestion: obfuscate plaintext passwords, or
encrypt them with a key embedded in the code (or even with a key
supplied at compile-time). Though that'd be nice, it might not be as
trivial as it seems at first sight (keeping in mind that old and new
clients might be mixed on someone's system, so we can't just put an
obfuscated password in the "simple" passtype). I wouldn't want this to
block the simple revert of r1845377.

-- 
Johan

[VOTE] Reverting r1845377 (Was: [PROPOSAL] Allow plaintext passwords again.)

[Daniel Sahlberg <da...@gmail.com>]

The dicussion died again, but this time I intend make sure we complete it
once and for all. I've marked the subject as VOTE to hopefully get some
attention, although I believe votes have already been cast.


In my mind, it seems we have consensus to revert r1845377 (+1 from Nathan
Hartman, Evgeny Kotkov, Johan Corveleyn, myself, I'm also considering Karl
Fogel to have voted for this by making the initial proposition and
volunteering to do it. No objections).


Then we have a two other suggestions:

* Changing the default value of store-plaintext-passwords
Option 1 - set the default value of store-plaintext-passwords to no. For a
non-edited servers config file, this will put the behaviour of 1.15 in line
with 1.12-1.14.
Option 2 - keep store-plaintext-passwords = ask. For a non-edited servers
config file, the behaviour of 1.15 will be in line with pre-1.12.

I have previously expressed support (but no formal vote, and I will not
stand in the way of consensus) for option 1, since I was under the
impression that it was a longterm goal go disable the plaintext password
store (I have previously commented on how quickly r1845377 was discussed
and implemented). Nathan has argued that it might give a bad user
experience if credentials are not stored even though plaintext storage is
enabled in the build options. We can improve on this by updating the svn
--version output to explicitly say if plaintext cache is build but runtime
disabled.

If I'm counting correctly, Nathan, Evgeny and Johan has expressed +1 for
option 2.

Considering this, I conclude we have consensus for option 2.


* Changing handling of already stored plaintext passwords
This was discussed in 2022 and there were some suggestions that Subversion
should not even use plaintext passwords even if they were found in the
plaintext password store (initially suggested by Mark Phippard as a way to
soften the impact of reverting r1845377). I'm proposing we choose amoung
one of the following three options:

Option 1 - do nothing. Keep using the stored passwords.
Option 2 - add a new runtime config option dont-use-plaintext-passwords
[default no] global overrides local.
Option 3 - new compile time option to disable reading/using plaintext
passwords.

Options 2 and 3 should probably imply disabling storing plaintext passwords
as well. I think they should also warn if the code finds a stored password
and suggest the user to delete it using svn auth --remove. (It was hinted
previously that we would disable the code that searches for the files
storing the password, however the same files also store the username and we
read them as an apr_hash_t so we don't really have the option to "not read
the password").

With option 2 or 3 we let a security consious organisation configure their
system to their liking. I would love to have them, but I can't avoid the
feeling that it is security theater: As far as I can tell it is not
possible to avoid that a user can upload their own version of the svn
binary and then all bets are off anyway. (On Windows and MacOS it is
possible to only allow execution of signed binaries, and they don't even
store the passwords in plaintext anyway).

If we go with either 2 or 3, then I'm perfering option 2 since it will
allow the administrators to set this without compiling their own version
(which seems to be a major obstacle, considering the reaction to r1845377).
I believe Karl Fogel and Mark was also leaning towards doing something
during the discussion in 2022.

Johan seems to believe option 1 is fine ("these additional \"mitigations\"
are not absolutely required").

In my mind, it is perfectly acceptable to vote +1 on both option 1 AND one
of option 2/3. I would interpret that as "do nothing in the short term, but
do X in the long term".


My plan is to revert r1845377 during next weekend. For the first
bulletpoint nothing has to be done, but if consensus changes during the
week, I can do the work to to implement option 1. For the second bullet
point I'd like to reach consensus (on the short- and long term plan) by the
same time, then if we decide on 2/3 we will put it on the wish list for a
future release.

Kind regards,
Daniel Sahlberg

Re: [PROPOSAL] Allow plaintext passwords again.

[Nathan Hartman <ha...@gmail.com>]

On Thu, Mar 30, 2023 at 8:39 AM Johan Corveleyn <jc...@gmail.com> wrote:
> Basically this would correspond to kfogel's proposal earlier in this
> thread [1] (and the one most participants agreed with):
>
> "I think it's just a matter of reverting r1845377, right?  (And
> updating CHANGES, etc.)"
>
> For completeness, I want to quickly summarize two additional
> suggestions made by Mark Phippard [2][3]:
>
> - If plaintext-pwd-caching support is compiled out (by explicitly
> giving the compile-time flag for this), also stop reading already
> cached ones. This would render Daniel's python script useless in these
> environments. It might satisfy some security sensitive people who
> would regard the script as a way to "circumvent" the
> plaintext-disablement. It would make the "plaintext-disabling" more of
> a complete feature. Additionally, it was suggested that svn could warn
> or erase such legacy plaintext-cached passwords (instead of just
> ignoring them), as yet another mitigation improvement.

If the plaintext cache is explicitly disabled, I think it is
appropriate to stop reading plaintext passwords already cached AND
warn about the presence of previously cached passwords.

Both of those things should go together; in other words, if we no
longer can read previously cached plaintext passwords, then we should
warn users if they exist to avoid unknowingly keeping them around.

I don't think we should automatically erase passwords; IMO that should
remain the user's decision.

To be clear, I'm describing the scenario where the plaintext cache was
explicitly disabled at compile time. Otherwise, the plaintext cache is
fully functional and we don't issue the warning.

> - Apply some obfuscation or encryption with a key hidden in the code
> (or even supplied by a compile time option) to the plaintext
> passwords. This helps against non-malicious exposure, and makes it a
> tad harder for simple scripts to extract the password (which might
> appease some part of our user base). This might break legitimate
> scripts that explicitly (mis-)use the cached password for other
> purposes, though we could regard such uses as hacks that we are
> allowed to break.

I like this idea because it provides a simple self-contained middle
ground between "no caching without strong encryption ever" and "but
that prevents automated tasks, usage through ssh, etc".

As you pointed out earlier, the first suggestion renders DSahlberg's
python script useless in environments where the plaintext cache is
disabled. Perhaps, then, it could be modified to convert password
caches from plaintext to the new obfuscated format. There could be a
command line option to delete the original plaintext ones if
conversion succeeded. (Also, it should retain the ability to store in
plaintext, since 1.12 through 1.14 clients will still need this.)

(It doesn't escape me that people could use the code in the script as
an example of how to read the obfuscated cache but then they could use
the code in Subversion itself for that. Also, if a custom key can be
provided at compile time, that avoids much of the trouble.)

> IMHO these additional "mitigations" are not absolutely required (I
> mainly would like to see r1845377 reverted), but if some people feel
> strongly about them ... sure, why not (though in that case we'd need
> someone to put in the work too).

Although that is a challenge, it does help to know exactly what we
want as a project before anyone puts in that work. :-)

Cheers,
Nathan

Re: [PROPOSAL] Allow plaintext passwords again.

[Johan Corveleyn <jc...@gmail.com>]

On Thu, Mar 30, 2023 at 12:15 AM Nathan Hartman
<ha...@gmail.com> wrote:
>
> On Wed, Mar 29, 2023 at 6:02 PM Evgeny Kotkov
> <ev...@visualsvn.com> wrote:
> >
> > Nathan Hartman <ha...@gmail.com> writes:
> >
> > > I think a good middle ground is:
> > >
> > > * Build with --enable-plaintext-password-storage by default; users who
> > >   want to harden their system can do so, but will need to build their
> > >   own client.
> >
> > +1.

+1

> > > * Set the default run-time config to store-plaintext-passwords = no
> > >   (if it isn't already; haven't checked) and instruct users on how to
> > >   change it. This makes the decision to store in plaintext an explicit
> > >   one that the user can opt into. (I appreciate that this could be
> > >   changed without the user's knowledge; perhaps the systemwide config
> > >   should always take precedence over the user-controlled one for this
> > >   setting?)
> >
> > So, apparently, the current default is "ask".
> >
> > I haven't checked all the details, but I think that defaulting to "ask"
> > already makes the user decision explicit and allows it to happen naturally,
> > without requiring any additional instructions or knowledge.
> >
> > If we change the default to "no", this part of the experience could be worse,
> > because for the end users it might look like the credentials aren't being
> > stored for unknown reasons / a bug in the software.
>
> Ah, this makes sense. In that case, I'm +1 to leave it as "ask" (no change).

+1

Basically this would correspond to kfogel's proposal earlier in this
thread [1] (and the one most participants agreed with):

"I think it's just a matter of reverting r1845377, right?  (And
updating CHANGES, etc.)"

For completeness, I want to quickly summarize two additional
suggestions made by Mark Phippard [2][3]:

- If plaintext-pwd-caching support is compiled out (by explicitly
giving the compile-time flag for this), also stop reading already
cached ones. This would render Daniel's python script useless in these
environments. It might satisfy some security sensitive people who
would regard the script as a way to "circumvent" the
plaintext-disablement. It would make the "plaintext-disabling" more of
a complete feature. Additionally, it was suggested that svn could warn
or erase such legacy plaintext-cached passwords (instead of just
ignoring them), as yet another mitigation improvement.

- Apply some obfuscation or encryption with a key hidden in the code
(or even supplied by a compile time option) to the plaintext
passwords. This helps against non-malicious exposure, and makes it a
tad harder for simple scripts to extract the password (which might
appease some part of our user base). This might break legitimate
scripts that explicitly (mis-)use the cached password for other
purposes, though we could regard such uses as hacks that we are
allowed to break.


IMHO these additional "mitigations" are not absolutely required (I
mainly would like to see r1845377 reverted), but if some people feel
strongly about them ... sure, why not (though in that case we'd need
someone to put in the work too).

[1] https://lists.apache.org/thread/shzxh04l493qnj8pdt8vl0x4gkjrkvcy
[2] https://lists.apache.org/thread/1tfny40nokqf6p6nll30p06t8or2c8hm
[3] https://lists.apache.org/thread/p2vn6foj8qz3lfvdl70bs62vg5krcgr7

-- 
Johan

Re: [PROPOSAL] Allow plaintext passwords again.

[Nathan Hartman <ha...@gmail.com>]

On Wed, Mar 29, 2023 at 6:02 PM Evgeny Kotkov
<ev...@visualsvn.com> wrote:
>
> Nathan Hartman <ha...@gmail.com> writes:
>
> > I think a good middle ground is:
> >
> > * Build with --enable-plaintext-password-storage by default; users who
> >   want to harden their system can do so, but will need to build their
> >   own client.
>
> +1.
>
> > * Set the default run-time config to store-plaintext-passwords = no
> >   (if it isn't already; haven't checked) and instruct users on how to
> >   change it. This makes the decision to store in plaintext an explicit
> >   one that the user can opt into. (I appreciate that this could be
> >   changed without the user's knowledge; perhaps the systemwide config
> >   should always take precedence over the user-controlled one for this
> >   setting?)
>
> So, apparently, the current default is "ask".
>
> I haven't checked all the details, but I think that defaulting to "ask"
> already makes the user decision explicit and allows it to happen naturally,
> without requiring any additional instructions or knowledge.
>
> If we change the default to "no", this part of the experience could be worse,
> because for the end users it might look like the credentials aren't being
> stored for unknown reasons / a bug in the software.

Ah, this makes sense. In that case, I'm +1 to leave it as "ask" (no change).

Cheers,
Nathan

Re: [PROPOSAL] Allow plaintext passwords again.

[Evgeny Kotkov via dev <de...@subversion.apache.org>]

Nathan Hartman <ha...@gmail.com> writes:

> I think a good middle ground is:
>
> * Build with --enable-plaintext-password-storage by default; users who
>   want to harden their system can do so, but will need to build their
>   own client.

+1.

> * Set the default run-time config to store-plaintext-passwords = no
>   (if it isn't already; haven't checked) and instruct users on how to
>   change it. This makes the decision to store in plaintext an explicit
>   one that the user can opt into. (I appreciate that this could be
>   changed without the user's knowledge; perhaps the systemwide config
>   should always take precedence over the user-controlled one for this
>   setting?)

So, apparently, the current default is "ask".

I haven't checked all the details, but I think that defaulting to "ask"
already makes the user decision explicit and allows it to happen naturally,
without requiring any additional instructions or knowledge.

If we change the default to "no", this part of the experience could be worse,
because for the end users it might look like the credentials aren't being
stored for unknown reasons / a bug in the software.


Thanks,
Evgeny Kotkov

Re: [PROPOSAL] Allow plaintext passwords again.

[Daniel Sahlberg <da...@gmail.com>]

Den tis 28 mars 2023 kl 18:56 skrev Nathan Hartman <hartman.nathan@gmail.com
>:

> On Tue, Mar 28, 2023 at 10:35 AM Daniel Sahlberg
> <da...@gmail.com> wrote:
> > [...] reverting the previous change and changing the default config. I
> don't know (didn't check, no time) what the default config is right now and
> if it can be interpreted as "don't cache passwords" for old clients being
> updated.
>

[...]

* Set the default run-time config to store-plaintext-passwords = no
>   (if it isn't already; haven't checked) and instruct users on how to
>   change it. This makes the decision to store in plaintext an explicit
>   one that the user can opt into. (I appreciate that this could be
>   changed without the user's knowledge; perhaps the systemwide config
>   should always take precedence over the user-controlled one for this
>   setting?)
>

If I read the code correctly (subversion/libsvn_subr/auth.c) this is
controlled by store-plaintext-passwords in the servers file. The default is
SVN_CONFIG_DEFAULT_OPTION_STORE_PLAINTEXT_PASSWORDS, defined
in subversion/include/svn_config.h to SVN_CONFIG_ASK.

In the default servers file (see svn_config_ensure in
subversion/libsvn_subr/config.c), the default config file has never had a
setting for store-plaintext-passwords. If the user has not edited the
servers file, we can change the default to no (probably FALSE, in
svn_config.h) and have the same behaviour in 1.15 as in 1.12 to 1.14 even
if we enable storing plaintext passwords compile-time.

If someone has edited the servers file, I believe we have three cases (for
default compile-time options):
store-plaintext-passwords=yes: In pre-1.12: storing passwords without
asking, 1.12 to 1.14: not storing/not asking, 1.15-later: storing passwords
without asking.
store-plaintext-passwords=no: In all versions: not storing/not asking.
store-plaintext-passwords=ask: In pre-1.12: asking about storing passwords,
1.12 to 1.14: not storing/not asking, 1.15-later: asking about storing
passwords.

Disadvantages to making the above reversal: The FAQ entry will become
> more complicated; possible complaints from those who prefer that the
> client not support plaintext cache writing at all.
>

I'm sure we can come up with some cleaver wording in the FAQ, but good
thing you brought this up so we don't forget.

I would argue that since Subversion is open source, it is very easy for a
user to compile their own version of Subversion and run it, so the
administrators have very little options to control this anyway (unless it
is possible to limit the executables that are possible to run on a machine
- in Windows it would be possible with a group policy but I don't know what
can be done in SELinux, much less in the different Unix flavours).

As argued by Danielsh in the other threads, it is easy to pass the password
on the command line or to write scripts to automatically answer the
password prompt. So any administrator efforts to limit this will have
little effect anyway.

 Kind regards,
Daniel

Re: [PROPOSAL] Allow plaintext passwords again.

[Nathan Hartman <ha...@gmail.com>]

On Tue, Mar 28, 2023 at 10:35 AM Daniel Sahlberg
<da...@gmail.com> wrote:
>
> Den tis 28 mars 2023 kl 14:41 skrev Johan Corveleyn <jc...@gmail.com>:
>>
>> On Mon, Jan 24, 2022 at 5:02 PM Mark Phippard <ma...@gmail.com> wrote:
>> >
>> > On Mon, Jan 24, 2022 at 10:44 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> >
>> > > > > >I return to my "two camps" argument. The people that do not want
>> > > > > >plaintext passwords to be cached ... do not want them being
>> > > > > >cached.
>> > > > >
>> > > > > I see what you mean.
>> > > > >
>> > > > > If svn is compiled to not cache passwords, but a legacy cached
>> > > > > password exists on disk for a given repository, should svn not
>> > > > > only not read it but actually warn the user that the cached
>> > > > > password exists?
>> > > >
>> > > > IMO, it is not necessary and if a compiler option disables the code
>> > > > then I would envision we do not even have any code running that is
>> > > > looking for those files to give the warning.
>> > >
>> > > Plaintext passwords are saved in the "password" element of the
>> > > serialized hash in ~/.subversion/auth/svn.simple/.
>> > >
>> > > Those are the same files that cache the username when the username is
>> > > cached without its password.
>> > >
>> > > We can't know whether a file contains a password or not until we have
>> > > opened, read, and parsed it.
>> > >
>> > > So, "not even have any code running that is looking for those files"
>> > > isn't an option (unless we're willing to throw away cached usernames
>> > > even if they were cached without a password)
>> > >
>> > > So, what should we do if we have parsed one of those files and the
>> > > resulting apr_hash_t contains a "password" key?
>> > >
>> > > Ignore it?  Erase it (memset() it to zero)?  Warn about it?  Use it?
>> >
>> > Good points and excellent questions. If we would already be
>> > discovering this file then I suppose we could do something. I would be
>> > fine with just ignoring the cached password but some kind of other
>> > option would also be good.
>> >
>> >
>> > > And for that matter, should there be a configure option that disables
>> > > the --password command-line option?  It, too, can be used insecurely
>> > > (see above about filesystem-level encryption).
>> >
>> > Also a good question. A configure option to disable this might be
>> > appreciated by some users.
>>
>> Is this issue on someone's radar? It seems the discussion died out
>> here, and I can't find anything further. Maybe worth taking another
>> look now that we're getting closer to 1.15?
>>
>> We seemed to get stuck "finding consensus on desired behaviour".
>> Various proposals were made, but none got over the "bar of
>> objections", and we ran out of steam. Which leaves us with the status
>> quo, however imperfect it is :-(.
>>
>> (This recently came up in my company, when we were looking at
>> upgrading the svn client on a unix build machine -- oops can't upgrade
>> past SVN 1.12 or so, because of the compiled-out plain-text pwd
>> caching support)
>>
>> For some background (warning long read):
>>
>> https://lists.apache.org/thread/b6g2hx2m3s117wcmno08opl874ons3q8
>> https://lists.apache.org/thread/shzxh04l493qnj8pdt8vl0x4gkjrkvcy
>
>
> One outcome was that I wrote a script (based on suggestions by danielsh) to store plaintext passwords. It is linked from the website:
> https://subversion.apache.org/faq.html#plaintext-passwords

I was going to point that out as well: the Python script might provide
a reasonable workaround. Especially if we re-enable the plaintext
cache in the default build for 1.15+, the workaround would be needed
only temporarily.

More below:

> And the script can be found here:
> https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/store-plaintext-password.py
>
> Hopefully the script will help you at least some part of the way.
>
> Stefan Sperling has previously described how OpenBSD explicitly compile SVN /with/ support for caching plaintext passwords but disable it in the global runtime config. That sounds like a good option to me - reverting the previous change and changing the default config. I don't know (didn't check, no time) what the default config is right now and if it can be interpreted as "don't cache passwords" for old clients being updated. One downside is that it might be difficult for administrators to enforce a policy (ie, "don't allow users to store a password") but since SVN uses existing passwords, such policy is easily circumvented (create the auth cache file on another machine and copy it manually).

Or they could use the above-mentioned script.

We have gotten many complaints about this change causing problems for
users, especially with automation or when accessing a remote SVN
client over SSH (the auth GUI dialog box appears on the remote
machine, inaccessible to the user).

I appreciate that if we reverse the change, we may get complaints from
the other camp.

I think a good middle ground is:

* Build with --enable-plaintext-password-storage by default; users who
  want to harden their system can do so, but will need to build their
  own client.

* Set the default run-time config to store-plaintext-passwords = no
  (if it isn't already; haven't checked) and instruct users on how to
  change it. This makes the decision to store in plaintext an explicit
  one that the user can opt into. (I appreciate that this could be
  changed without the user's knowledge; perhaps the systemwide config
  should always take precedence over the user-controlled one for this
  setting?)

* (For extra credit) Encourage packagers to create a second package
  without plaintext support, so users can choose which to install and
  avoid a custom build. For some consistency across package managers,
  we could suggest a name for the package if we can come up with one.

Disadvantages to making the above reversal: The FAQ entry will become
more complicated; possible complaints from those who prefer that the
client not support plaintext cache writing at all.

Just for completeness, I'll note that this not an issue on Windows or
macOS; both have OS facilities for caching passwords. It affects only
Unix; in case of desktop Unix machines that have GNOME Keyring and/or
KWallet (with support in the SVN client), this change should have
minimal impact for users, since those will receive priority over the
plaintext cache.

Nathan

Re: [PROPOSAL] Allow plaintext passwords again.

[Daniel Sahlberg <da...@gmail.com>]

Den tis 28 mars 2023 kl 14:41 skrev Johan Corveleyn <jc...@gmail.com>:

> On Mon, Jan 24, 2022 at 5:02 PM Mark Phippard <ma...@gmail.com> wrote:
> >
> > On Mon, Jan 24, 2022 at 10:44 AM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
> >
> > > > > >I return to my "two camps" argument. The people that do not want
> > > > > >plaintext passwords to be cached ... do not want them being
> > > > > >cached.
> > > > >
> > > > > I see what you mean.
> > > > >
> > > > > If svn is compiled to not cache passwords, but a legacy cached
> > > > > password exists on disk for a given repository, should svn not
> > > > > only not read it but actually warn the user that the cached
> > > > > password exists?
> > > >
> > > > IMO, it is not necessary and if a compiler option disables the code
> > > > then I would envision we do not even have any code running that is
> > > > looking for those files to give the warning.
> > >
> > > Plaintext passwords are saved in the "password" element of the
> > > serialized hash in ~/.subversion/auth/svn.simple/.
> > >
> > > Those are the same files that cache the username when the username is
> > > cached without its password.
> > >
> > > We can't know whether a file contains a password or not until we have
> > > opened, read, and parsed it.
> > >
> > > So, "not even have any code running that is looking for those files"
> > > isn't an option (unless we're willing to throw away cached usernames
> > > even if they were cached without a password)
> > >
> > > So, what should we do if we have parsed one of those files and the
> > > resulting apr_hash_t contains a "password" key?
> > >
> > > Ignore it?  Erase it (memset() it to zero)?  Warn about it?  Use it?
> >
> > Good points and excellent questions. If we would already be
> > discovering this file then I suppose we could do something. I would be
> > fine with just ignoring the cached password but some kind of other
> > option would also be good.
> >
> >
> > > And for that matter, should there be a configure option that disables
> > > the --password command-line option?  It, too, can be used insecurely
> > > (see above about filesystem-level encryption).
> >
> > Also a good question. A configure option to disable this might be
> > appreciated by some users.
>
> Is this issue on someone's radar? It seems the discussion died out
> here, and I can't find anything further. Maybe worth taking another
> look now that we're getting closer to 1.15?
>
> We seemed to get stuck "finding consensus on desired behaviour".
> Various proposals were made, but none got over the "bar of
> objections", and we ran out of steam. Which leaves us with the status
> quo, however imperfect it is :-(.
>
> (This recently came up in my company, when we were looking at
> upgrading the svn client on a unix build machine -- oops can't upgrade
> past SVN 1.12 or so, because of the compiled-out plain-text pwd
> caching support)
>
> For some background (warning long read):
>
> https://lists.apache.org/thread/b6g2hx2m3s117wcmno08opl874ons3q8
> https://lists.apache.org/thread/shzxh04l493qnj8pdt8vl0x4gkjrkvcy
>

One outcome was that I wrote a script (based on suggestions by danielsh) to
store plaintext passwords. It is linked from the website:
https://subversion.apache.org/faq.html#plaintext-passwords

And the script can be found here:
https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/store-plaintext-password.py

Hopefully the script will help you at least some part of the way.

Stefan Sperling has previously described how OpenBSD explicitly compile SVN
/with/ support for caching plaintext passwords but disable it in the global
runtime config. That sounds like a good option to me - reverting the
previous change and changing the default config. I don't know (didn't
check, no time) what the default config is right now and if it can be
interpreted as "don't cache passwords" for old clients being updated. One
downside is that it might be difficult for administrators to enforce a
policy (ie, "don't allow users to store a password") but since SVN uses
existing passwords, such policy is easily circumvented (create the auth
cache file on another machine and copy it manually).

Kind regards,
Daniel

Re: [PROPOSAL] Allow plaintext passwords again.

[Johan Corveleyn <jc...@gmail.com>]

On Mon, Jan 24, 2022 at 5:02 PM Mark Phippard <ma...@gmail.com> wrote:
>
> On Mon, Jan 24, 2022 at 10:44 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> > > > >I return to my "two camps" argument. The people that do not want
> > > > >plaintext passwords to be cached ... do not want them being
> > > > >cached.
> > > >
> > > > I see what you mean.
> > > >
> > > > If svn is compiled to not cache passwords, but a legacy cached
> > > > password exists on disk for a given repository, should svn not
> > > > only not read it but actually warn the user that the cached
> > > > password exists?
> > >
> > > IMO, it is not necessary and if a compiler option disables the code
> > > then I would envision we do not even have any code running that is
> > > looking for those files to give the warning.
> >
> > Plaintext passwords are saved in the "password" element of the
> > serialized hash in ~/.subversion/auth/svn.simple/.
> >
> > Those are the same files that cache the username when the username is
> > cached without its password.
> >
> > We can't know whether a file contains a password or not until we have
> > opened, read, and parsed it.
> >
> > So, "not even have any code running that is looking for those files"
> > isn't an option (unless we're willing to throw away cached usernames
> > even if they were cached without a password)
> >
> > So, what should we do if we have parsed one of those files and the
> > resulting apr_hash_t contains a "password" key?
> >
> > Ignore it?  Erase it (memset() it to zero)?  Warn about it?  Use it?
>
> Good points and excellent questions. If we would already be
> discovering this file then I suppose we could do something. I would be
> fine with just ignoring the cached password but some kind of other
> option would also be good.
>
>
> > And for that matter, should there be a configure option that disables
> > the --password command-line option?  It, too, can be used insecurely
> > (see above about filesystem-level encryption).
>
> Also a good question. A configure option to disable this might be
> appreciated by some users.

Is this issue on someone's radar? It seems the discussion died out
here, and I can't find anything further. Maybe worth taking another
look now that we're getting closer to 1.15?

We seemed to get stuck "finding consensus on desired behaviour".
Various proposals were made, but none got over the "bar of
objections", and we ran out of steam. Which leaves us with the status
quo, however imperfect it is :-(.

(This recently came up in my company, when we were looking at
upgrading the svn client on a unix build machine -- oops can't upgrade
past SVN 1.12 or so, because of the compiled-out plain-text pwd
caching support)

For some background (warning long read):

https://lists.apache.org/thread/b6g2hx2m3s117wcmno08opl874ons3q8
https://lists.apache.org/thread/shzxh04l493qnj8pdt8vl0x4gkjrkvcy

-- 
Johan

Re: [PROPOSAL] Allow plaintext passwords again.

[Mark Phippard <ma...@gmail.com>]

On Mon, Jan 24, 2022 at 10:44 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:

> > > >I return to my "two camps" argument. The people that do not want
> > > >plaintext passwords to be cached ... do not want them being
> > > >cached.
> > >
> > > I see what you mean.
> > >
> > > If svn is compiled to not cache passwords, but a legacy cached
> > > password exists on disk for a given repository, should svn not
> > > only not read it but actually warn the user that the cached
> > > password exists?
> >
> > IMO, it is not necessary and if a compiler option disables the code
> > then I would envision we do not even have any code running that is
> > looking for those files to give the warning.
>
> Plaintext passwords are saved in the "password" element of the
> serialized hash in ~/.subversion/auth/svn.simple/.
>
> Those are the same files that cache the username when the username is
> cached without its password.
>
> We can't know whether a file contains a password or not until we have
> opened, read, and parsed it.
>
> So, "not even have any code running that is looking for those files"
> isn't an option (unless we're willing to throw away cached usernames
> even if they were cached without a password)
>
> So, what should we do if we have parsed one of those files and the
> resulting apr_hash_t contains a "password" key?
>
> Ignore it?  Erase it (memset() it to zero)?  Warn about it?  Use it?

Good points and excellent questions. If we would already be
discovering this file then I suppose we could do something. I would be
fine with just ignoring the cached password but some kind of other
option would also be good.


> And for that matter, should there be a configure option that disables
> the --password command-line option?  It, too, can be used insecurely
> (see above about filesystem-level encryption).

Also a good question. A configure option to disable this might be
appreciated by some users.

Mark

Re: [PROPOSAL] Allow plaintext passwords again.

[Daniel Shahaf <d....@daniel.shahaf.name>]

Mark Phippard wrote on Fri, Jan 21, 2022 at 20:29:21 -0500:
> On Fri, Jan 21, 2022 at 7:22 PM Karl Fogel <kf...@red-bean.com> wrote:
> >
> > On 21 Jan 2022, Mark Phippard wrote:
> > >One aspect of the previous thread that came up is that someone
> > >demonstrated a simple script to create a cached password (as a
> > >workaround for current users). That is what led to the idea of
> > >formalizing this using the svn auth command to create this file.
> > >
> > >I am the only one calling this a backdoor. I am saying that if I am
> > >an admin that does not want plaintext passwords being cached and
> > >you then create a simple way to do exactly that, then that is a
> > >backdoor around the policy I wanted.

There's any number of other ways to auto-answer password prompts:

- Build a custom client
  [It's easy, especially considering that many of our users happen to be
  programmers.]

- Use the --password option
  [which would be visible in ps(1) output without needing local root,
  unlike the content of ~/.subversion/auth/]

- Use wrapper tools that will run $SHELL in a pty and auto-answer
  password prompts
  [They exist]

- Map some key or mouse button to one's password
  [and then forget to chmod one's ~/.xmodmaprc restrictively]

- Run 1.14
  [can be prevented server-side by checking the User-Agent string]

- Set the password to adjacent home row keys, so it's easy to type
  [can be prevented by the admin]

- Use kwallet/gnome-keyring with an empty or easy-to-guess master password

And conversely, there might be encryption at or below the OS filesystem
level, in which case plaintext password caching is pretty much comparable
to the alternative caching options.

> > >Maybe it is not the right term to use here.

I'd say "circumvent".  "Backdoor" specifically refers to bypassing
authz.

> > >I am just saying if we are going to make someone compile their own
> > >binaries we might as well at least give them what they want.

There'll always be ways to feed passwords to svn(1) automatically.  The
question is just how difficult it would be to do so.

More below.

> > >I return to my "two camps" argument. The people that do not want
> > >plaintext passwords to be cached ... do not want them being
> > >cached.
> >
> > I see what you mean.
> >
> > If svn is compiled to not cache passwords, but a legacy cached
> > password exists on disk for a given repository, should svn not
> > only not read it but actually warn the user that the cached
> > password exists?
> 
> IMO, it is not necessary and if a compiler option disables the code
> then I would envision we do not even have any code running that is
> looking for those files to give the warning.

Plaintext passwords are saved in the "password" element of the
serialized hash in ~/.subversion/auth/svn.simple/.

Those are the same files that cache the username when the username is
cached without its password.

We can't know whether a file contains a password or not until we have
opened, read, and parsed it.

So, "not even have any code running that is looking for those files"
isn't an option (unless we're willing to throw away cached usernames
even if they were cached without a password)

So, what should we do if we have parsed one of those files and the
resulting apr_hash_t contains a "password" key?

Ignore it?  Erase it (memset() it to zero)?  Warn about it?  Use it?

And for that matter, should there be a configure option that disables
the --password command-line option?  It, too, can be used insecurely
(see above about filesystem-level encryption).

> 
> That said, I do not have a strong opinion on this one.

Neither do I :)

Cheers,

Daniel

Re: [PROPOSAL] Allow plaintext passwords again.

[Mark Phippard <ma...@gmail.com>]

On Fri, Jan 21, 2022 at 7:22 PM Karl Fogel <kf...@red-bean.com> wrote:
>
> On 21 Jan 2022, Mark Phippard wrote:
> >One aspect of the previous thread that came up is that someone
> >demonstrated a simple script to create a cached password (as a
> >workaround for current users). That is what led to the idea of
> >formalizing this using the svn auth command to create this file.
> >
> >I am the only one calling this a backdoor. I am saying that if I
> >am an
> >admin that does not want plaintext passwords being cached and you
> >then
> >create a simple way to do exactly that, then that is a backdoor
> >around
> >the policy I wanted. Maybe it is not the right term to use
> >here. I am
> >just saying if we are going to make someone compile their own
> >binaries
> >we might as well at least give them what they want.
> >
> >I return to my "two camps" argument. The people that do not want
> >plaintext passwords to be cached ... do not want them being
> >cached.
>
> I see what you mean.
>
> If svn is compiled to not cache passwords, but a legacy cached
> password exists on disk for a given repository, should svn not
> only not read it but actually warn the user that the cached
> password exists?

IMO, it is not necessary and if a compiler option disables the code
then I would envision we do not even have any code running that is
looking for those files to give the warning.

That said, I do not have a strong opinion on this one.

Mark

Re: [PROPOSAL] Allow plaintext passwords again.

[Karl Fogel <kf...@red-bean.com>]

On 21 Jan 2022, Mark Phippard wrote:
>One aspect of the previous thread that came up is that someone
>demonstrated a simple script to create a cached password (as a
>workaround for current users). That is what led to the idea of
>formalizing this using the svn auth command to create this file.
>
>I am the only one calling this a backdoor. I am saying that if I 
>am an
>admin that does not want plaintext passwords being cached and you 
>then
>create a simple way to do exactly that, then that is a backdoor 
>around
>the policy I wanted. Maybe it is not the right term to use 
>here. I am
>just saying if we are going to make someone compile their own 
>binaries
>we might as well at least give them what they want.
>
>I return to my "two camps" argument. The people that do not want
>plaintext passwords to be cached ... do not want them being 
>cached.

I see what you mean.

If svn is compiled to not cache passwords, but a legacy cached 
password exists on disk for a given repository, should svn not 
only not read it but actually warn the user that the cached 
password exists?

Best regards,
-Karl

Re: [PROPOSAL] Allow plaintext passwords again.

[Mark Phippard <ma...@gmail.com>]

On Fri, Jan 21, 2022 at 6:39 PM Karl Fogel <kf...@red-bean.com> wrote:

> >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.
>
> That was a deliberate compatibility move, and I'm not sure we
> should change it.  Can you describe the harm that would come from
> keeping that behavior vs changing it as you describe above?  I
> guess I don't see how it's a "backdoor".

One aspect of the previous thread that came up is that someone
demonstrated a simple script to create a cached password (as a
workaround for current users). That is what led to the idea of
formalizing this using the svn auth command to create this file.

I am the only one calling this a backdoor. I am saying that if I am an
admin that does not want plaintext passwords being cached and you then
create a simple way to do exactly that, then that is a backdoor around
the policy I wanted. Maybe it is not the right term to use here. I am
just saying if we are going to make someone compile their own binaries
we might as well at least give them what they want.

I return to my "two camps" argument. The people that do not want
plaintext passwords to be cached ... do not want them being cached.

Mark

Re: [PROPOSAL] Allow plaintext passwords again.

[Karl Fogel <kf...@red-bean.com>]

On 21 Jan 2022, Mark Phippard wrote:
>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.

Well:

  ------------------------------------------------------------------------ 
  r1845377 | brane | 2018-10-31 14:40:21 -0500 (Wed, 31 Oct 2018) 
  | 6 lines Changed paths: 
     M /subversion/trunk/configure.ac 
   
  Disable plaintext password storage by default. It can still be 
  enabled at configure time.   * configure.ac: Invert the default 
  of the plaintext-password-storage 
     option and update its help text. 
   
  ------------------------------------------------------------------------

:-)

>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?

As Nathan Hartman pointed out in his reply, we already do this (I 
wasn't aware of it either until Nathan's mail, by the way!).

>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.

That was a deliberate compatibility move, and I'm not sure we 
should change it.  Can you describe the harm that would come from 
keeping that behavior vs changing it as you describe above?  I 
guess I don't see how it's a "backdoor".

Best regards,
-Karl

Re: [PROPOSAL] Allow plaintext passwords again. (was: Re: A strong WTF on compiling out plaintext password support by default?!)

[Mark Phippard <ma...@gmail.com>]

On Thu, Jan 20, 2022 at 11:50 PM Karl Fogel <kf...@red-bean.com> 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?!)

[Karl Fogel <kf...@red-bean.com>]

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?!

[Mark Phippard <ma...@gmail.com>]

On Thu, Jan 20, 2022 at 4:06 PM Karl Fogel <kf...@red-bean.com> 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?!

[Karl Fogel <kf...@red-bean.com>]

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?!

[Karl Fogel <kf...@red-bean.com>]

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?!

[Bernard Boudet <ac...@2020.boudet.uk>]

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: A strong WTF on compiling out plaintext password support by default?!

[Mark Phippard <ma...@gmail.com>]

On Wed, Jan 19, 2022 at 9:08 PM Karl Fogel <kf...@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

Re: A strong WTF on compiling out plaintext password support by default?!

[Karl Fogel <kf...@red-bean.com>]

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 :) 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?!

[Stefan Sperling <st...@elego.de>]

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?!

[Robby Zinchak <si...@editingarchive.com>]

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 <st...@elego.de> 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 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?!

[Stefan Sperling <st...@elego.de>]

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?!

[Daniel Sahlberg <da...@gmail.com>]

Den mån 23 aug. 2021 kl 13:50 skrev Nathan Hartman <hartman.nathan@gmail.com
>:

> On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn <jc...@gmail.com> 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?!

[Nathan Hartman <ha...@gmail.com>]

On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn <jc...@gmail.com> wrote:

> On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak <si...@editingarchive.com>
> 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 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?)
> (-> this abandoning of packagers / maintainers makes me feel our
> ecosystem is breaking down)
>
> 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.
>
> [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.

In the meantime, even with plaintext support compiled out, SVN always
supports using passwords that are already stored.

So, as a workaround, is it an option to use either Daniel Shahaf's zsh
script or Daniel Sahlberg's python script (both upthread I think) to store
the needed passwords?

Nathan

Re: A strong WTF on compiling out plaintext password support by default?!

[Daniel Sahlberg <da...@gmail.com>]

Den mån 23 aug. 2021 kl 12:15 skrev Johan Corveleyn <jc...@gmail.com>:

> 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: Subversion on Solaris (was Re: A strong WTF on compiling out plaintext password support by default?!)

[Johan Corveleyn <jc...@gmail.com>]

On Thu, Sep 2, 2021 at 7:29 AM Daniel Sahlberg
<da...@gmail.com> wrote:
>
> Den mån 23 aug. 2021 kl 12:15 skrev Johan Corveleyn <jc...@gmail.com>:
>>
>> 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?!)

[Daniel Sahlberg <da...@gmail.com>]

Den mån 23 aug. 2021 kl 12:15 skrev Johan Corveleyn <jc...@gmail.com>:

> 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?!

[Daniel Shahaf <d....@daniel.shahaf.name>]

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?!

[Johan Corveleyn <jc...@gmail.com>]

On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak <si...@editingarchive.com> 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 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?)
(-> this abandoning of packagers / maintainers makes me feel our
ecosystem is breaking down)

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.

[1] https://lists.apache.org/thread.html/6751582f2d8eda885722933f935a3c90d1b0adb0f9c9dbe536a5c2d7%40%3Cdev.subversion.apache.org%3E

--
Johan