subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <>
Subject Re: gpg-agent branch treats PGP passphrase as repository password?
Date Mon, 06 Dec 2010 19:46:00 GMT
Greg Hudson wrote on Mon, Dec 06, 2010 at 10:31:05 -0500:
> On Mon, 2010-12-06 at 07:30 -0500, Daniel Shahaf wrote:
> > Ideally, Subversion won't know the PGP passphrase.  (If it does, then
> > a malicious libsvn_subr can compromise a private key.)
> I think you're trying to solve a different problem here.  The goal is to
> minimize typing of passwords without storing passwords in a fixed
> medium, not to protect keys against malicious or broken Subversion code.

Agreed, there are two different problems here:

P1.  Minimize typing of passwords.
S1a. Cache the password in gpg-agent.

P2.  Do not store passwords on disk in plaintext.
S2a. Encrypt the passwords with GPGME before storing them to disk.

I was commenting on Stefan's suggestion that Subversion should
explicitly know the passphrase of some PGP key.  (I'm assuming some
people will use for this purpose the same PGP key they use for email

> > For comparison, the ssh-agent protocol[1] only allows a client of the
> > agent to authenticate himself (using the agent) to a third party, but
> > does not have a "Retrieve secret key" option [2].  If we are to use PGP,
> > could we find a solution with similar properties?
> ssh-agent has special knowledge of the operations which will be
> performed using the keying material.  PGP probably doesn't have any
> interest in the operations Subversion needs to do with passwords.

I'm not sure I understand this comment.  Originally, I assumed that PGP
might implement a generic   lambda ctxt: decrypt(pgp_sk, ctxt)   interface.

> PKCS#11 is the most commonly used general API for operations where an
> application can use a key but isn't allowed to know what it is.  The
> most useful free software implementation of PKCS#11 is probably NSS.  I
> don't think we want to go there, though.

We only have the "Subversion isn't allowed to know the key" requirement
if that key is used by something other than Subversion.  Therefore, an
alternative is to require keys that are used only by Subversion (so
leaking the passphrases compromises nothing but ~/.subversion/auth/):

* we could store a secret gpg keyring under ~/.subversion/.gnupg/ :-)

* we could use symmetric passwords (as I suggested elsethread)


Thanks for your comments,


View raw message