[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: gpg-agent branch treats PGP passphrase as repository password?

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 6 Dec 2010 21:46:00 +0200

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,

Received on 2010-12-06 20:48:25 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.