On Wed, Dec 01, 2010 at 06:50:35AM -0500, Dan Engel wrote:
> 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, this makes sense. I was expecting a scheme that would persist
the password on disk. Using gpg-agent as a mere runtime password cache
as you describe is certainly fine and, if used right, does not expose
the private key passphase.
However, I still see a potential risk here because the name "gpg-agent"
is very misleading. It violates the principle of least surprise.
How can we prevent users misunderstanding what "Subversion's gpg-agent
feature" does from entering their private pgp key passphrase (which will
then be sent to the server)? Can we control the prompt printed by
gpg-agent? ("Enter your Subversion password, NOT your secret PGP passphrase!")
Remember that people may want to use Subversion password caches even for
publicly accessible servers which are password "protected" with a commonly
known user/password combination. Any such server could potentially receive
PGP passphrases in clear text if the gpg-agent feature is misused.
Because of this concern, I'd rather have a new tool called 'svn-agent'
for this purpose, licensed under Apache License v2 and distributed
along with Subversion. jIn that case users would not make a mental
association with PGP and are very unlikely to enter their PGP passphrase.
This would also avoid introducing a dependency on an external tool.
It would not be very hard to write such a tool, using a protocol similar
to the one used in gpg-agent.
I would also support a scheme that uses PGP in the way I described,
persisting passwords on disk encrypted with a PGP private key.
Thanks,
Stefan
Received on 2010-12-01 14:09:28 CET