On Tue, Aug 24, 2021 at 1:24 PM Stefan Sperling <s...@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
