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

[Dan Engel <da...@sourceharvest.com>]

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

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

["C. Michael Pilato" <cm...@collab.net>]

On 12/01/2010 06:29 PM, Dan Engel wrote:
> From a purely personal point of view, I'd be happy with ANY disk or
> memory password cache for Subversion on Linux that is safe
> (security-wise) and doesn't rely on the presence of any GUI libraries or
> capabilities. The gpg-agent path was just the easiest one for me to
> implement directly.

FWIW, I appreciate that you're taking a look at this, Dan.  I know that many
corporate customers of Subversion desperately want additional encrypted
password caching options that, as you say, don't rely on GUI libraries.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

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

[Stefan Sperling <st...@elego.de>]

On Wed, Dec 01, 2010 at 06:29:06PM -0500, Dan Engel wrote:
> On Wed, 2010-12-01 at 14:08 +0100, Stefan Sperling wrote:
> > 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!") 
> 
> 
> Yes, the agent protocol provides for customized prompts, and the patch
> itself refers to the Subversion repository server (or something like
> that) in that prompt.

If we can control the prompt, then let's just make the prompt
clear enough so that people who read it don't accidentally enter
their pgp passphrase. That will make the mistake much less likely.
If people don't read the prompt, well, then we cannot help them either.

Thanks for pointing out how gpg-agent really works.

Stefan

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

[Dan Engel <da...@sourceharvest.com>]

On Wed, 2010-12-01 at 14:08 +0100, Stefan Sperling wrote:
> 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!") 


Yes, the agent protocol provides for customized prompts, and the patch
itself refers to the Subversion repository server (or something like
that) in that prompt.

I have no emotional investment in the gpg-agent idea (aside from the
"don't re-invent the wheel argument"), but here's my $0.02:

I think most people who know enough to use gpg agent (it's a bit more
involved to set up, etc. than things like gnome-keyring) probably
understand what it does well enough to not make that mistake.

Also, in most corporate or enterprise environments (where the stakes are
really high) Subversion will be installed and set up by administrators
(who *better* know what they're doing) and used by users who may not
even know that gpg-agent is running in the background. All they get is a
prompt for their subversion password.

I know those lines get a little more blurred in Linux-land than in
Windows-land, but I think the point is still a valid one.

>From a purely personal point of view, I'd be happy with ANY disk or
memory password cache for Subversion on Linux that is safe
(security-wise) and doesn't rely on the presence of any GUI libraries or
capabilities. The gpg-agent path was just the easiest one for me to
implement directly.

Thanks,
-Dan

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

[Dan Engel <da...@sourceharvest.com>]

On Wed, 2010-12-01 at 14:08 +0100, Stefan Sperling wrote:
> 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!") 


Yes, the agent protocol provides for customized prompts, and the patch
itself refers to the Subversion repository server (or something like
that) in that prompt.

I have no emotional investment in the gpg-agent idea (aside from the
"don't re-invent the wheel argument"), but here's my $0.02:

I think most people who know enough to use gpg agent (it's a bit more
involved to set up, etc. than things like gnome-keyring) probably
understand what it does well enough to not make that mistake.

Also, in most corporate or enterprise environments (where the stakes are
really high) Subversion will be installed and set up by administrators
(who *better* know what they're doing) and used by users who may not
even know that gpg-agent is running in the background. All they get is a
prompt for their subversion password.

I know those lines get a little more blurred in Linux-land than in
Windows-land, but I think the point is still a valid one.

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

[Stefan Sperling <st...@elego.de>]

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