[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    Re: A strong WTF on compiling out plaintext password support by default?!
From:       Karl Fogel <kfogel () red-bean ! com>
Date:       2022-01-21 21:13:52
Message-ID: 874k5wzt9r.fsf () red-bean ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]