Is a guarantee provided that configuration files (as referenced via --config-dir) will only be read once (and thus may refer to a non-seekable socket)? If so, this may be adequate as-is (and I may end up submitting only a test case and documentation patch guaranteeing this as a forward-supported semantic).
Permitting a password to be read from a specified file descriptor is a more flexible superset of reading from stdin alone -- providing disambiguation (such that a wrapper need not be built to handle cases where inputs other than a password are required on the same FD) use in cases where other prompts are being displayed to the user interactively. On Tue, Apr 16, 2013 at 7:49 PM, Daniel Shahaf <danie...@elego.de> wrote: > Greg Stein wrote on Tue, Apr 16, 2013 at 19:01:23 -0400: > > Pulled from an accidental moderation rejection: > > > > ---------- Forwarded message ---------- > > > From: Charles Duffy <char...@dyfis.net> > > > To: dev@subversion.apache.org > > > Cc: > > > Date: Tue, 16 Apr 2013 10:09:22 -0500 > > > Subject: Feature proposal: SVN_USERNAME and SVN_PASSWORD environment > variables > > > Howdy -- > > > > > > At present, the easiest way to pass credentials into Subversion is on > the command line, which is supported across all bundled tools. > > > > > > Unfortunately, on UNIX, this is extremely insecure: The contents of > programs' argv array is visible to all users (as in ps). While a program > can overwrite its argv array, there is necessarily a window between startup > and the point when this operation occurs. > > > > > > A moderate improvement would be to allow credentials to be passed in > through the environment; on Unixlike systems following best-practices, this > protects them from being read by other non-root users on the same system. > (Some security-hardened systems have stronger controls available than > merely "same user", allowing a similar level of control to that exercised > over ptrace). > > > > > > A larger improvement would be to allow a file descriptor to be > specified which _only_ reads password data in an unambiguous form. This is > what GnuPG does with its --passphrase-fd option, and is an improvement over > reusing stdin in contexts where passwords are being provided automatically > as there is no need to track stdout for reprompting, alternate requests, > etc. > > > > > > My interest is in having something which can be safely used from shell > scripts in a reasonably secure manner, and with a level of implementation > difficulty compatible with my available schedule. Counterproposals, > objections, or alternate mechanisms would be greatly appreciated. > > > > > Additional options: > > - allow specifying a filename which contains the password. (This can be > done today, via --config-dir, if you know the realm.) > > - read a password from stdin. (Why? Because `man openssl | less -p > 'PASS PHRASE ARGUMENTS'` supports that. How does that interact with > 'svnrdump load' and 'svn ci -F -', which already consumed stdin? > Needs to be determined.) >
