[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    Re: Feature proposal: SVN_USERNAME and SVN_PASSWORD environment variables
From:       Daniel Shahaf <danielsh () elego ! de>
Date:       2013-04-27 22:16:18
Message-ID: 20130427221618.GV3055 () lp-shahaf ! local
[Download RAW message or body]

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@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@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.)
> > >

[prev in list] [next in list] [prev in thread] [next in thread]