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.
