On Tue, Jul 26, 2011 at 03:56:17PM +0300, Daniel Shahaf wrote:
> stsp_at_apache.org wrote on Tue, Jul 26, 2011 at 12:11:06 -0000:
> > Author: stsp
> > Date: Tue Jul 26 12:11:05 2011
> > New Revision: 1151069
> >
> > URL: http://svn.apache.org/viewvc?rev=1151069&view=rev
> > Log:
> > * subversion/libsvn_subr/gpg_agent.c: Add a comment that explains how this
> > auth cache provider operates, including security considerations.
> >
> > Modified:
> > subversion/trunk/subversion/libsvn_subr/gpg_agent.c
> >
> > Modified: subversion/trunk/subversion/libsvn_subr/gpg_agent.c
> > URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/gpg_agent.c?rev=1151069&r1=1151068&r2=1151069&view=diff
> > ==============================================================================
> > --- subversion/trunk/subversion/libsvn_subr/gpg_agent.c (original)
> > +++ subversion/trunk/subversion/libsvn_subr/gpg_agent.c Tue Jul 26 12:11:05 2011
> > @@ -23,6 +23,36 @@
> >
> > /* ==================================================================== */
> >
> > +[four paragraphs of documentation comment]
>
> Looks good :)
>
> > + * Therefore, while the gpg-agent is running and has the password cached,
> > + * this provider is no more secure than a file storing the password in
> > + * plaintext.
>
> Should the gpg-agent provider implement a "plaintext prompt" password
> that explains this and asks the user's permission to do so?
I was thinking about that, too.
The key difference between the plaintext password store and the
gpg-agent store is that the user must already have a running gpg-agent.
The plaintext password store is always used and is not guarded by
any such precondition.
I think that if someone is already running gpg-agent, they are probably
storing their PGP passphrase in it, which IMO is a secret of much higher
value than a Subversion password.
So if someone has the agent running then svn might as well just use it.
If the user does not want Subversion to use it it can be turned off in
the config file (password-stores option).
Received on 2011-07-26 15:34:20 CEST