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.
