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.
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 <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-28 00:13:58 CEST