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
