On Sun, 2010-10-17 at 16:03 +0200, Stefan Sperling wrote:
> If my understanding is correct, it seems the current code on the gpg-agent
> branch essentially uses the gpg-agent as a glorified password prompt.
>
> Here's what the code seems to be doing:
>
> Storing a password:
> Nothing happens.
>
> Retreiving a password:
> Step 1: svn contacts the gpg-agent to find out the passphrase for the private
> PGP key the agent is managing
I have not reviewed the "current code" on the gpg-agent branch, but was
the original submitter for the gpg-agent support patch. I've wanted to
return to it, but have not had the time. However, I would like to take a
moment and address this concern.
The name of the program (gpg-agent) may be misleading in this, but all
gpg-agent does is to safely (securely, without swapping, etc.) cache
secrets indexed by a domain. The domain is whatever the client provides
and the secret is the password that the user types in. So what happens
is:
Step 1: svn contacts gpg-agent, providing the username and repository
URL as the domain.
Step 2: gpg-agent checks to see whether there is a password associated
with that domain. If not, it prompts for one. Here, the user enters
their subversion password, NOT their pgp private key passphrase.
Step 3: gpg-agent associates the password with the provided domain and
stores that in the memory cache in protected memory. There is typically
a timeout (one hour, 24 hours, whatever).
Step 4: svn receives the password and sends it to the server.
Step 5: Later, the user invokes svn again (in a way that needs the
server). Normally, this would be the point at which svn would prompt for
another password. Instead...
Step 6: svn contacts the gpg-agent, providing the same domain (username
+ repository URL) as before.
Step 7: gpg-agent checks to see whether there is a password associated
with that domain, and this time there is, because of step 3 before. Now,
gpg-agent just returns this password instead of prompting for a new one.
Step 8: svn receives the password and sends it to the server...
So, you see, in spite of the name (gpg-agent) there's no inherent
interaction between gpg-agent and the pgp private key store, and at no
time is the user prompted for their private pgp key.
The purpose of the gpg-agent patch is to make it so that a user who
doesn't have one of the GUI wallets available (gnome-keyring or kwallet)
doesn't have to type in their subversion password EVERY time they invoke
a command against the repository. The gpg program uses gpg-agent (when
so configured) for exactly the same purpose--to keep the user from
having to re-type that passphrase more than once every X hours. But the
agent itself is generic enough to serve a broad range of password
caching needs.
gpg-agent allows the user to configure how long passwords persist in
protected memory. If the timeout has passed, then in step 7, the
gpg-agent would request the password again since it would no longer be
in the memory cache.
Does that all make sense?
Thanks,
-Dan
> Step 2: svn treats this passphrase as the repository password, and sends
> it to the server.
>
> This is very wrong, if not outright dangerous.
> Nobody should use their PGP passphrase as a Subversion password.
> The passphrase is sacred, and svn should not ever send it to the server.
> It could be easily leaked in case someone is using http:// to connect
> to a repository, for instance. This behaviour of svn can lead to the private
> PGP key being compromised.
>
> Here's what I think should happen instead:
>
> Storing a password:
> Step 1: svn encrypts the password using the user's public PGP key and
> stores the encrypted form somewhere in the ~/.subversion/auth area
>
> Retreiving a password:
> Step 1: svn contacts the gpg-agent to find out the passphrase for the
> private pgp key the agent is managing. If the agent cannot be
> contacted svn asks the user for the passphrase.
> Step 2: svn uses this passphrase to decrypt the user's PGP private key
> Step 3: svn uses this private key to decrypt the password stored
> inside the ~/.subversion/auth area
> Step 4: svn sends the decrypted password to the server
>
> The GPGME library will probably help with these steps:
> http://www.gnupg.org/gpgme.html
> I haven't checked, but it's possible that this library will talk to
> the GPG agent on behalf of Subversion.
>
> Also, it could happen that the block of memory containing the passphrase
> is swapped out to disk. This should be prevented if at all possible,
> e.g. by using mlock(). The passphrase should be overwritten with random
> data right after it has been used.
>
> The feature could be renamed from "gpg-agent password store" to
> "gpgme password store" or "pgp-encrypted password store", to take
> account of the fact that the gpg-agent itself doesn't provide encryption
> services.
>
> I'm strongly -1 on merging the branch to trunk in its current form.
> I'm sorry I didn't see this problem during my initial review of the code.
>
> Thanks,
> Stefan
Received on 2010-12-01 12:51:15 CET