On Wed, Jul 19, 2017 at 12:24 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Jul 18, 2017 at 08:58:26PM -0400, Nico Kadel-Garcia wrote:
>> The other blocking factor, for me, was the default behavior of the
>> Subversion client of storing the HTTP or HTTPS access passwords in
>> cleartext. It's gotten better orver time, notifying users better of
>> the risks, but the default behavior is still an issue.
> Nico, you have been repeating this point over and over again
> like a broken record. I expect every subscriber to this list
> is already very much aware of your opinion on this matter ;-)
Yup. I don't do it every week, or even every month. Frankly, as
Subversion has been falling in popularity, it's become less critical.
This subscriber is new, and having difficulty with Apache
configurations. Since that's so often been so awkward, and this is
*another* reason to migrate away from it, I made sure that *he*
thought about the functional, less complex to integrate, and by
default more secure svn+ssh.
Branko, some of the same risk occurs for SSH users who use passphrase
free SSH keys. The default of "ssh-keygen" to produce such keys, by
default, without a mandatory commandline option saying "yes, yes, I
really wanted no passphrase!" is a similar but not identical issue.
> The prompt (which I added years ago) was an improvement, yes.
> But I don't expect this default behaviour (prompt) to change, ever,
> and I see no reason to keep discussing this point. It's many years
> too late for that now.
Because there are occasionally new users and new admins. Admittedly,
most of the new admins are supporting legacy tools such as Subversion
in a legacy environment as they migrate to various more modern
distributed source control system. But every single new user
encounters this dangerous default unless their local client
environment has been hand-tweaked by someone with more security
I do appreciate that you updated the default to at least warn about
the risk. See my above note about SSH keys without passphrases. I'm
afraid that even with the warning, it's not always enough, but it at
least allows a typical admin or user installing software to say "I put
up a sign about that pool, it's your own !@#$ fault".
> The default behaviour can be adjusted globally by the system admin with
> a small config file in /etc/subversion. OpenBSD has been installing such
> a file for many years and there has never been any complaint.
> I recommend you do the same on systems you maintain, and move on.
"System admins" do not typically have control of user's local systems
to enforce such a change in the clients, and it's pretty useless on
the Subversion server unless they all log in there with shell access
and check out material into local working copies. Admins usually only
have such control over the servers. (Been there, done that, it pays my
salary for the last 29 years.) The success of such a default change in
OpenBSD's package installed client suggests that people would accept
it for other operating systems. Perhaps we could have a very separate
thread bout whether it's time to change that default, finally, for the
next major release? Is thee a 1.10, or a 2.0 in the planning stages?
Received on 2017-07-20 04:08:50 CEST