Daniel Shahaf wrote on Sun, Apr 28, 2013 at 01:13:22 +0300: > Charles Duffy wrote on Sat, Apr 27, 2013 at 11:42:58 -0500: > > 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). > > > > I don't think that's guaranteed, but it might well be what the cmdline > client does already (not in order to support fifos, but because it's > inefficient to read the same file twice). > > Other clients are longer-lived so might construct multiple auth batons, > client ctxs, etc, and thus open/read the file more than once. >
I'm specifically talking about svn_client_ctx_t, which includes an svn_auth_baton_t and an config hash. Daniel > Daniel > > > 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.) > > >
