On 7/3/14 9:10 PM, Martin Furter wrote:
> 3) Allow the password to be supplied over stdin using the special value "-".
>
> Nobody will see the password. The only leak is that a password has been
> supplied using stdin. An attacker will have to convince the calling application
> to run something different than svn which logs the password to a file.
A lot of tools have options to provide passwords via a file. That's certainly
a better option for people who want to do automation and are concerned with the
leakage via the command line.
Just adding "-" as a special value for the existing --password option doesn't
necessarily help people doing automation since you're going to have to do
something to send that password over stdin, which might end up leaked via the
same mechanism (though usually things like echo are shell internals and don't
spawn processes).
I'd rather add a --password-file option and that can take the "-" special value
for STDIN if people want and that other values just read the password form the
path provided.
The question then becomes is it better to just leave --password with
documentation and maybe some sort of redaction or should we just remove it
entirely.
Yes it would take some minor effort for anyone upgrading that depends on
--password now, including our own test suite, but it ought to be rather trivial
to write the password to a file with proper permissions and just start passing
the name of the file on the command line.
To that end how about:
"--password-file ARG : specify a password stored in file ARG (secure provided
proper permissions are set on the file, interactive users may prefer the
interactive password prompts when credentials are needed)"
Deprecate --password in 1.9 but leave it with the following help text:
"(deprecated, insecure use --password-file instead)"
Remove --password support entirely in 1.10 and emit an error telling users to
use --password-file.
Received on 2014-07-04 08:00:25 CEST