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 <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:16:53 CEST