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 <danielsh_at_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 <charles_at_dyfis.net>
> > > To: dev_at_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.)
>
Received on 2013-04-27 23:22:08 CEST