Re: gpg-preset-passphrase and extra agent socket

[xeyrion--- via Gnupg-users]

On Mon, Mar 27, 2023 at 5:58 AM Werner Koch  wrote:

> You are right.  I forgot about this.
>
> You need to wait for the next version or apply the attached patch and
> run gpg-preset-passphrase with the option --restricted to address the
> other cache.
>

Great, thanks for confirming and the patch!
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase and extra agent socket

[Werner Koch via Gnupg-users]

On Sat, 25 Mar 2023 18:56, xeyrion--- said:

> The difference seems to be that normal socket uses ".0" as cache key while
> extra socket uses ".1" and therefore misses?

You are right.  I forgot about this.

You need to wait for the next version or apply the attached patch and
run gpg-preset-passphrase with the option --restricted to address the
other cache.


Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
From ab35d756d86438db124fa68aa633fe528ff8be50 Mon Sep 17 00:00:00 2001
From: Werner Koch 
Date: Mon, 27 Mar 2023 11:37:49 +0200
Subject: [PATCH GnuPG] agent: New option --restricted for PRESET_PASSPHRASE.

* agent/command.c (cmd_preset_passphrase): Add option.

* agent/preset-passphrase.c (oRestricted): New.
(opts): Add option --restricted.
(main): Set option.
(preset_passphrase): Use option.
--

We use a different cache for connections from the extra-socket.
However, with gpg-preset-passphrase is only able to preset a
passphrase into the regular cache.  Further, a restricted connection
may not use PRESET_PASSPHRASE.  To solve this we add an new option to
preset the passphrase into the "restricted" cache.  For the
gpg-preset-passphrase tool we also add the option --restricted.

Note that this does not yet work with gpg-preset-passphrase --forget.
---
 agent/command.c   | 13 +++--
 agent/preset-passphrase.c |  9 -
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/agent/command.c b/agent/command.c
index 2e996d096..9481f47c3 100644
--- a/agent/command.c
+++ b/agent/command.c
@@ -2491,14 +2491,17 @@ cmd_passwd (assuan_context_t ctx, char *line)
 
 
 static const char hlp_preset_passphrase[] =
-  "PRESET_PASSPHRASE [--inquire]   []\n"
+  "PRESET_PASSPHRASE [--inquire] [--restricted] \\\n"
+  "[]\n"
   "\n"
   "Set the cached passphrase/PIN for the key identified by the keygrip\n"
   "to passwd for the given time, where -1 means infinite and 0 means\n"
   "the default (currently only a timeout of -1 is allowed, which means\n"
   "to never expire it).  If passwd is not provided, ask for it via the\n"
   "pinentry module unless --inquire is passed in which case the passphrase\n"
-  "is retrieved from the client via a server inquire.\n";
+  "is retrieved from the client via a server inquire.  The option\n"
+  "--restricted can be used to put the passphrase into the cache used\n"
+  "by restricted connections.";
 static gpg_error_t
 cmd_preset_passphrase (assuan_context_t ctx, char *line)
 {
@@ -2509,6 +2512,7 @@ cmd_preset_passphrase (assuan_context_t ctx, char *line)
   int ttl;
   size_t len;
   int opt_inquire;
+  int opt_restricted;
 
   if (ctrl->restricted)
 return leave_cmd (ctx, gpg_error (GPG_ERR_FORBIDDEN));
@@ -2517,6 +2521,7 @@ cmd_preset_passphrase (assuan_context_t ctx, char *line)
 return set_error (GPG_ERR_NOT_SUPPORTED, "no --allow-preset-passphrase");
 
   opt_inquire = has_option (line, "--inquire");
+  opt_restricted = has_option (line, "--restricted");
   line = skip_options (line);
   grip_clear = line;
   while (*line && (*line != ' ' && *line != '\t'))
@@ -2579,7 +2584,11 @@ cmd_preset_passphrase (assuan_context_t ctx, char *line)
 
   if (!rc)
 {
+  int save_restricted = ctrl->restricted;
+  if (opt_restricted)
+ctrl->restricted = 1;
   rc = agent_put_cache (ctrl, grip_clear, CACHE_MODE_ANY, passphrase, ttl);
+  ctrl->restricted = save_restricted;
   if (opt_inquire)
 {
 	  wipememory (passphrase, len);
diff --git a/agent/preset-passphrase.c b/agent/preset-passphrase.c
index df6da00e3..4cf624462 100644
--- a/agent/preset-passphrase.c
+++ b/agent/preset-passphrase.c
@@ -63,11 +63,13 @@ enum cmd_and_opt_values
   oNoVerbose = 500,
 
   oHomedir,
+  oRestricted,
 
 aTest };
 
 
 static const char *opt_passphrase;
+static int opt_restricted;
 
 static gpgrt_opt_t opts[] = {
 
@@ -79,6 +81,7 @@ static gpgrt_opt_t opts[] = {
   { oForget,  "forget",  256, "forget passphrase"},
 
   { oHomedir, "homedir", 2, "@" },
+  { oRestricted,  "restricted", 0, "put into the restricted cache"},
 
   ARGPARSE_end ()
 };
@@ -156,7 +159,9 @@ preset_passphrase (const char *keygrip)
   return;
 }
 
-  rc = asprintf (&line, "PRESET_PASSPHRASE %s -1 %s\n", keygrip,
+  rc = asprintf (&line, "PRESET_PASSPHRASE %s%s -1 %s\n",
+ opt_restricted? "--restricted ":"",
+ keygrip,
 		 passphrase_esc);
   wipememory (passphrase_esc, strlen (passphrase_esc));
   xfree (passphrase_esc);
@@ -232,6 +237,8 @@ main (int argc, char **argv)
 case 

Re: gpg-preset-passphrase and extra agent socket

[xeyrion--- via Gnupg-users]

On Fri, Mar 24, 2023 at 5:20 AM Werner Koch  wrote:

> On Wed, 22 Mar 2023 16:16, xeyrion--- said:
>
> > Forwarding normal socket (instead of extra socket) makes the prompt go
> > away. Is there a way to preset passphrase for extra socket as well?
>
> The caching behavior does not depend on the connection type.  Thus this
> should not be an issue.  I assume you are using 2.4.0 which has a couple
> of fixes for remote use.
>
> I am almost always using the extra-socket with cards and thus I unloch
> the card before I start working (using "gpg-card" and its "verify"
> command).
>
> I would suggest to add
>
>   debug ipc,cache
>   log-file /foo/somefile
>
> to your local gpg-agent.conf (or use watchgnupg and "socket://" as file
> for live watching) to see what's going on.  You should see some error
> message "Forbidden" when the remote site issues certain commands.
>

Thanks for the debugging tips. I collected more info using those. Caching
behavior does indeed seem to depend on connection type based on what I am
seeing in the logs:

Call to gpg-preset-passphrase for :

DBG: chan_8 <- PRESET_PASSPHRASE  -1 
DBG: agent_put_cache ''.0 (mode 1) requested ttl=-1
DBG: chan_8 -> OK

Asking to decrypt using normal socket:

DBG: chan_8 <- PKDECRYPT
DBG: chan_8 -> S INQUIRE_MAXLEN 4096
DBG: chan_8 -> INQUIRE CIPHERTEXT
DBG: chan_8 <- [ 00 00 00 ...(105 byte(s) skipped) ]
DBG: chan_8 <- END
DBG: agent_get_cache ''.0 (mode 2) ...
DBG: ... hit

Asking to decrypt using extra socket:

DBG: chan_8 <- PKDECRYPT
DBG: chan_8 -> S INQUIRE_MAXLEN 4096
DBG: chan_8 -> INQUIRE CIPHERTEXT
DBG: chan_8 <- [ 00 00 00 ...(105 byte(s) skipped) ]
DBG: chan_8 <- END
DBG: agent_get_cache ''.1 (mode 2) ...
DBG: ... miss
DBG: agent_get_cache ''.1 (mode 2) (stored cache key) ...
DBG: ... miss
starting a new PIN Entry


The difference seems to be that normal socket uses ".0" as cache key while
extra socket uses ".1" and therefore misses?

This is using GnuPG 2.4.0 both on local and remote.

Ideas? Is this a designed behavior? Or do I have something misconfigured?

Thank you.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase and extra agent socket

[Werner Koch via Gnupg-users]

On Wed, 22 Mar 2023 16:16, xeyrion--- said:

> Forwarding normal socket (instead of extra socket) makes the prompt go
> away. Is there a way to preset passphrase for extra socket as well?

The caching behavior does not depend on the connection type.  Thus this
should not be an issue.  I assume you are using 2.4.0 which has a couple
of fixes for remote use.

I am almost always using the extra-socket with cards and thus I unloch
the card before I start working (using "gpg-card" and its "verify"
command).

I would suggest to add

  debug ipc,cache
  log-file /foo/somefile

to your local gpg-agent.conf (or use watchgnupg and "socket://" as file
for live watching) to see what's going on.  You should see some error
message "Forbidden" when the remote site issues certain commands.

> If not, what are the implications of forwarding the normal socket? The wiki
> page just says "extra socket is more restricted" without going into any

For example the remote site can't list the keys on the local site.  This
is sometimes required and thus you can allow this on per private key
base by adding

  Remote-list: true

to the private key file (which you figure out using gpg -K
--with-keygrip).  But that might not be your problem.


Shalom-Salam,

   Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein


openpgp-digital-signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg-preset-passphrase and extra agent socket

[xeyrion--- via Gnupg-users]

Hello,

I am trying to set up agent forwarding as per
https://wiki.gnupg.org/AgentForwarding. Everything is generally working,
but the remote gpg is prompting for passphrases
despite gpg-preset-passphrase having been used against local agent.

Forwarding normal socket (instead of extra socket) makes the prompt go
away. Is there a way to preset passphrase for extra socket as well?

If not, what are the implications of forwarding the normal socket? The wiki
page just says "extra socket is more restricted" without going into any
details.

Thank you.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg-preset-passphrase and extra agent socket

[xeyrion--- via Gnupg-users]

I am trying to set up agent forwarding as per
https://wiki.gnupg.org/AgentForwarding. Everything is generally working,
but the remote gpg is prompting for passphrases
despite gpg-preset-passphrase having been used against local gpg agent.

Forwarding normal socket (instead of extra socket) makes the prompt go
away. Is there a way to preset passphrase for extra socket as well?

If not, what are the implications of forwarding the normal socket? The wiki
page just says "extra socket is more restricted" without going into any
details.

Thank you.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Confusion about gpg-preset-passphrase

[Efe İzbudak via Gnupg-users]

On 23/03/03 03:09PM, Ingo Klöcker wrote:
> On Freitag, 3. März 2023 13:09:09 CET efeizbudak via Gnupg-users wrote:
> > So I'm trying to use gpg-preset-passphrase but for some reason I keep
> > having to enter the passphrase all the same. I run
> > 
> > /usr/libexec/gpg-preset-passphrase --preset $KEYGRIP
> 
> Works for me (with the current development version). I did the following 
> (after adding `allow-preset-passphrase` to gpg-agent.conf and restarting
> gpg-agent):
> 
> $ gpg -K --with-keygrip A151BC5817C228CF
> sec   ed25519 2021-02-26 [SC]
>   69C701A436FDD496FAE5580AA151BC5817C228CF
>   Keygrip = 382BC7C2C4E13EF7D40870B7EB9CDE4AE0232B4E
> uid   [ultimate] f...@example.net
> ssb   cv25519 2021-02-26 [E]
>   Keygrip = B9386D3E742597E532C6BD0978192517A09B41C3
> 
> $ echo bla | gpg --armor --encrypt -r A151BC5817C228CF | gpg --decrypt
> -> pinentry pops up; I click Cancel
> gpg: encrypted with cv25519 key, ID 14AC6E5C812B91E1, created 2021-02-26
>   "f...@example.net"
> gpg: public key decryption failed: Operation cancelled
> gpg: decryption failed: Operation cancelled
> 
> $ /opt/gnupg/master/libexec/gpg-preset-passphrase --preset \ 
> B9386D3E742597E532C6BD0978192517A09B41C3
> test
> 
> $ echo bla | gpg --armor --encrypt -r A151BC5817C228CF | gpg --decrypt
> -> no pinentry pops up
> gpg: encrypted with cv25519 key, ID 14AC6E5C812B91E1, created 2021-02-26
>   "f...@example.net"
> bla
> 
> Are you sure that you used the keygrip of the encryption subkey and not its 
> fingerprint? Does caching work if you enter the passphrase in pinentry? (I'm 
> asking because I'm wondering whether your max-cache-ttl could be the problem.)
> 
> Regards,
> Ingo

After seeing your example, I thought, why don't I test this with a
simpler password and it turns out that the problem was with my very
complicated auto-generated password which I believe have contained some
characters that were "illegal." Everything works fine with the simpler
password. Thank you for spending time on this. Sorry for not noticing it
earlier.

-- 
All the best,
Efe

The funny quote of this email is trivial and left as an exercise.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Confusion about gpg-preset-passphrase

[Ingo Klöcker]

On Freitag, 3. März 2023 13:09:09 CET efeizbudak via Gnupg-users wrote:
> So I'm trying to use gpg-preset-passphrase but for some reason I keep
> having to enter the passphrase all the same. I run
> 
> /usr/libexec/gpg-preset-passphrase --preset $KEYGRIP

Works for me (with the current development version). I did the following 
(after adding `allow-preset-passphrase` to gpg-agent.conf and restarting
gpg-agent):

$ gpg -K --with-keygrip A151BC5817C228CF
sec   ed25519 2021-02-26 [SC]
  69C701A436FDD496FAE5580AA151BC5817C228CF
  Keygrip = 382BC7C2C4E13EF7D40870B7EB9CDE4AE0232B4E
uid   [ultimate] f...@example.net
ssb   cv25519 2021-02-26 [E]
  Keygrip = B9386D3E742597E532C6BD0978192517A09B41C3

$ echo bla | gpg --armor --encrypt -r A151BC5817C228CF | gpg --decrypt
-> pinentry pops up; I click Cancel
gpg: encrypted with cv25519 key, ID 14AC6E5C812B91E1, created 2021-02-26
  "f...@example.net"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: Operation cancelled

$ /opt/gnupg/master/libexec/gpg-preset-passphrase --preset \ 
B9386D3E742597E532C6BD0978192517A09B41C3
test

$ echo bla | gpg --armor --encrypt -r A151BC5817C228CF | gpg --decrypt
-> no pinentry pops up
gpg: encrypted with cv25519 key, ID 14AC6E5C812B91E1, created 2021-02-26
  "f...@example.net"
bla

Are you sure that you used the keygrip of the encryption subkey and not its 
fingerprint? Does caching work if you enter the passphrase in pinentry? (I'm 
asking because I'm wondering whether your max-cache-ttl could be the problem.)

Regards,
Ingo

signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Confusion about gpg-preset-passphrase

[efeizbudak via Gnupg-users]

Hi all,

So I'm trying to use gpg-preset-passphrase but for some reason I keep
having to enter the passphrase all the same. I run

/usr/libexec/gpg-preset-passphrase --preset $KEYGRIP

and then paste the passphrase (I've also tried this with the keygrip for
the [E] subkey as opposed to the [SC]). But then when I try to  decrypt
a file encrypted for this key I still face pinentry. I also tried
running the decryption command with the 

--pinentry loopback --batch

which just fails with 

gpg: Sorry, we are in batchmode - can't get input

And I already have in my gpg-agent.conf the following:

allow-preset-passphrase
max-cache-ttl 2147483647

Am I misunderstanding something here? Can someone please point me in the
right direction?

Thank you!

-- 
All the best,
Efe

The funny quote of this email is trivial and left as an exercise.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Have gpg-preset-passphrase always required a keygrip? (was: Newbie question.)

[raf via Gnupg-users]

Dmitry Alexandrov wrote:

> Peter Lebbing  wrote:
> > You can actually unlock keys the way GnuPG intends to do that with:
> >
> > $ my-unlocker | /usr/lib/gnupg/gpg-preset-passphrase --preset 
> >
> > You can find the keygrip for your keys with:
> >
> > $ gpg --with-keygrip --list-secret-keys
> >
> > You do need it for every subkey you want to use like this separately,
> 
> Hm...
> 
> Did not gpg-preset-passphrase(1) worked perfectly on any NAMEs (IDs,
> UIDs) as well some time ago?  Or is that me, who have some false
> memories?

For gpg-agent 2.0.x I needed to use gpg --fingerprint --fingerprint xxx@xxx
to get the cache id to use with gpg-preset-passphrase --preset.
Since then, I need gpg2 --fingerprint --with-keygrip xxx@xxx.
So it probably changed from fingerprint to keygrip with 2.1
(but I don't know exactly when).

cheers,
raf


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Have gpg-preset-passphrase always required a keygrip? (was: Newbie question.)

[Dmitry Alexandrov]

Peter Lebbing  wrote:
> You can actually unlock keys the way GnuPG intends to do that with:
>
> $ my-unlocker | /usr/lib/gnupg/gpg-preset-passphrase --preset 
>
> You can find the keygrip for your keys with:
>
> $ gpg --with-keygrip --list-secret-keys
>
> You do need it for every subkey you want to use like this separately,

Hm...

Did not gpg-preset-passphrase(1) worked perfectly on any NAMEs (IDs, UIDs) as 
well some time ago?  Or is that me, who have some false memories?


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase installation and usage

[gnupg]

Walia, Gaurav (333G) via Gnupg-users wrote:

> Ok.  Did some googling came up with the following.  Could someone confirm 
> that I’m doing this correctly?
> 
> Objective: To save passphrase in cache to an unattended machine so that it 
> doesn’t time out the credentials.  Specifically, using 
> https://github.com/docker/docker-credential-helpers, with setup 
> https://github.com/docker/docker-credential-helpers/issues/102#issuecomment-388634452.
> 
> Steps:
> use gpg-preset-passphrase
> Current Setup
> 
>   *   ~/.gnupg/gpg-agent.conf
>  *   pinentry-program /usr/bin/pinentry-curses
>  *   max-cache-ttl 6048
>  *   default-cache-ttl 6048
>  *   allow-preset-passphrase
> 
>   *   gpg --version
>  *   gpg (GnuPG) 2.0.22
>  *   libgcrypt 1.5.3
>  *   Copyright (C) 2013 Free Software Foundation, Inc.
>  *   License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
>  *   This is free software: you are free to change and redistribute it.
>  *   There is NO WARRANTY, to the extent permitted by law.
>  *
>  *   Home: ~/.gnupg
>  *   Supported algorithms:
>  *   Pubkey: RSA, ?, ?, ELG, DSA
>  *   Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
>  *   CAMELLIA128, CAMELLIA192, CAMELLIA256
>  *   Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
>  *   Compression: Uncompressed, ZIP, ZLIB, BZIP2
>   *   gpg2 --fingerprint --fingerprint n...@domain.com
>  *   pub   2048R/12312312 2019-03-23
>  * Key fingerprint = 4567 4567 4567 4567 4567  4567 4567 4567 
> 4567 4567
>  *   uid  Name 
>  *   sub   2048R/11121314 2019-03-23
>  * Key fingerprint = 8910 8910 8910 8910 8910  8910 8910 8910 
> 8910 8910
> 
> Updated Setup using gpg-preset-passphrase only
> 
>   *   ~/.gnupg/gpg-agent.conf
>  *   We should be able to remove the first 3 line items since we are only 
> using gpg-preset-passphrase
>  *   Final file contents
> *   allow-preset-passphrase
>   *   Reload gpa-agent.conf file
>  *   gpg-connect-agent reloadagent /bye
>   *   Setup gpg-preset-passphrase
>  *   gpg-preset-passphrase --preset 
> 8910891089108910891089108910891089108910
>   *   Now when you login to that key and enter the passphrase It should cache 
> it until you issue the following command to remove it.
>  *   gpg-preset-passphrase —forget 
> 8910891089108910891089108910891089108910
> 
> Question:
> 
>   1.  Is the updated setup correct in my assumption for the setup?
> 
> Thank you in advance for taking the time to help, it is greatly appreciated.
> 
> Gaurav

hi,

the best thing to do is test it. :-)
but it looks promising.

however, be warned that 2.0.22 is old and things have
changed a lot since then. especially on systems with
systemd, and especially when the subsequent uses of gpg
are from a different systemd user session to the one
that preset the passphrase.

when i used 2.0.x, i ran gpg-agent in --daemon mode with
the --write-env-file option so that the subsequent uses
of gpg knew where to find gpg-agent (since they weren't
child processes with access to the environment variables).
that option disappears in later versions.

also, in later versions you'll need to change:

  gpg2 --fingerprint --fingerprint n...@domain.com

to:

  gpg2 --fingerprint --with-keygrip n...@domain.com

cheers,
raf


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase installation and usage

[Peter Lebbing]

On 13/04/2019 14:34, Peter Lebbing wrote:
> Either reload the agent (this will make it forget all passphrases)

Of course I should have made that explicit. You reload the agent by:

$ gpgconf --reload gpg-agent

I should mention this before you start figuring out a way to send it
SIGHUP (which btw would also work fine, it's just that you need a PID
then).

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase installation and usage

[Peter Lebbing]

Hello!

On 13/04/2019 12:42, Walia, Gaurav (333G) via Gnupg-users wrote:
>   * gpg --version
>   o gpg (GnuPG) 2.0.22

This version is a full six years old. Not only is 2.0.22 unsupported,
the whole 2.0 branch has been end-of-life for a good bit more than a
year now.

How come you're using something ancient that upstream doesn't support
and which has known defects? Is this a distribution-supported version?
If there is no security support from any party, I think you should
switch to a supported version.

>   * Setup gpg-preset-passphrase
>   o gpg-preset-passphrase --preset 
> 8910891089108910891089108910891089108910
>   * Now when you login to that key and enter the passphrase It should cache 
> it until you issue the following command to remove it.
>   o gpg-preset-passphrase —forget 8910891089108910891089108910891089108910

No, that's not how gpg-preset-passphrase works. You supply the
passphrase on the invocation of gpg-preset-passphrase. And you use the
keygrip, not the fingerprint. You can find the keygrip with the
--with-keygrip option when listing the key.

You would supply the passphrase on stdin of gpg-preset-passphrase,
probably from some utility that got it from the operator. Or with the -P
command line option directly, but this makes it visible for any user on
the system through the process list.

There is no feedback if either keygrip or passphrase is wrong. The net
result is simply you'll get a pinentry pop up when you try to use the
key.

And it will only cache it up to max-cache-ttl as mentioned in the man
page for gpg-preset-passphrase, so you probably want to not remove that
option from gpg-agent.conf.

Alternatively, you could just set default-cache-ttl to whatever value
you desire and completely forego gpg-preset-passphrase. Because it
sounds like you are okay with just supplying the passphrase on the first
invocation, it seems?

gpgconf tells us that the data type of the TTL options is uint32, so you
can make a TTL of 136 years. I notice you use a NASA e-mail address.
This TTL might be a problem on an unmanned spacecraft, but somehow I'll
expect your use case is covered ;-). (Plus, max-cache-ttl always limits
it to the 136 years anyway)

If you did not use gpg-preset-passphrase to preset the passphrase, you
can't use gpg-preset-passphrase --forget to clear it again. Either
reload the agent (this will make it forget all passphrases), or issue:

$ gpg-connect-agent 'clear_passphrase --mode=normal KEYGRIP' /bye

I'm not sure whether that last method is future-proof or might change in
some new version. In other words, I don't know if it's part of the API
or an implementation detail.

I did these things on the distribution-provided GnuPG on Debian
stretch/stable. So it's possible that it works differently on different
versions.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase installation and usage

[Walia, Gaurav (333G) via Gnupg-users]

Ok.  Did some googling came up with the following.  Could someone confirm that 
I’m doing this correctly?

Objective: To save passphrase in cache to an unattended machine so that it 
doesn’t time out the credentials.  Specifically, using 
https://github.com/docker/docker-credential-helpers, with setup 
https://github.com/docker/docker-credential-helpers/issues/102#issuecomment-388634452.

Steps:
use gpg-preset-passphrase
Current Setup

  *   ~/.gnupg/gpg-agent.conf
 *   pinentry-program /usr/bin/pinentry-curses
 *   max-cache-ttl 6048
 *   default-cache-ttl 6048
 *   allow-preset-passphrase

  *   gpg --version
 *   gpg (GnuPG) 2.0.22
 *   libgcrypt 1.5.3
 *   Copyright (C) 2013 Free Software Foundation, Inc.
 *   License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
 *   This is free software: you are free to change and redistribute it.
 *   There is NO WARRANTY, to the extent permitted by law.
 *
 *   Home: ~/.gnupg
 *   Supported algorithms:
 *   Pubkey: RSA, ?, ?, ELG, DSA
 *   Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
 *   CAMELLIA128, CAMELLIA192, CAMELLIA256
 *   Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
 *   Compression: Uncompressed, ZIP, ZLIB, BZIP2
  *   gpg2 --fingerprint --fingerprint n...@domain.com
 *   pub   2048R/12312312 2019-03-23
 * Key fingerprint = 4567 4567 4567 4567 4567  4567 4567 4567 4567 
4567
 *   uid  Name 
 *   sub   2048R/11121314 2019-03-23
 * Key fingerprint = 8910 8910 8910 8910 8910  8910 8910 8910 8910 
8910

Updated Setup using gpg-preset-passphrase only

  *   ~/.gnupg/gpg-agent.conf
 *   We should be able to remove the first 3 line items since we are only 
using gpg-preset-passphrase
 *   Final file contents
*   allow-preset-passphrase
  *   Reload gpa-agent.conf file
 *   gpg-connect-agent reloadagent /bye
  *   Setup gpg-preset-passphrase
     *   gpg-preset-passphrase --preset 8910891089108910891089108910891089108910
  *   Now when you login to that key and enter the passphrase It should cache 
it until you issue the following command to remove it.
     *   gpg-preset-passphrase —forget 8910891089108910891089108910891089108910

Question:

  1.  Is the updated setup correct in my assumption for the setup?

Thank you in advance for taking the time to help, it is greatly appreciated.

Gaurav

From: Gaurav walia mailto:gaurav.wa...@jpl.nasa.gov>>
Date: Friday, April 12, 2019 at 3:09 PM
To: "gnupg-users@gnupg.org<mailto:gnupg-users@gnupg.org>" 
mailto:gnupg-users@gnupg.org>>
Subject: gpg-preset-passphrase installation and usage

Hello,

Very new to gpg.   I’m attempting to use gpg-preset-passphrase.  But uncertain 
how to go about enabling it for usage.  Could someone direct me or provide me 
some instructions in how to go about enabling gpg-preset-passphrase?

I have the following version installed:
gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


Gaurav
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg-preset-passphrase installation and usage

[Walia, Gaurav (333G) via Gnupg-users]

Hello,

Very new to gpg.   I’m attempting to use gpg-preset-passphrase.  But uncertain 
how to go about enabling it for usage.  Could someone direct me or provide me 
some instructions in how to go about enabling gpg-preset-passphrase?

I have the following version installed:
gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


Gaurav
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg-preset-passphrase installation and usage

[Walia, Gaurav (333G) via Gnupg-users]

Hello,

Very new to gpg.   I’m attempting to use gpg-preset-passphrase.  But uncertain 
how to go about enabling it for usage.  Could someone direct me or provide me 
some instructions in how to go about enabling gpg-preset-passphrase?

I have the following version installed:
gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


Gaurav
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Unable to get gpg-preset-passphrase working with gpg2 + gpg-agent in Ubuntu Xenial

[Austin Witt]

It really was that simple! Thank you! I must have spent too many hours
staring at it to be able to see such a simple issue.

gpg-preset-passphrase is happy with a keygrip and works exactly as I want
it to.

Cheers!

On Thu, Aug 16, 2018 at 11:34 AM, Peter Lebbing 
wrote:

> On 16/08/18 18:31, Peter Lebbing wrote:
> > By the way, the GnuPG 2.1 in Ubuntu 16.04 hasn't been updated in almost
> > two years. I don't feel comfortable with it, and I would consider
> > alternatives.
>
> s/two years/two and a half years/
>
> It hasn't been updated since release. For a moment I was thinking about
> the .10 releases.
>
> Peter.
>
> --
> I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> You can send me encrypted mail if you want some privacy.
> My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Unable to get gpg-preset-passphrase working with gpg2 + gpg-agent in Ubuntu Xenial

[Peter Lebbing]

On 16/08/18 18:31, Peter Lebbing wrote:
> By the way, the GnuPG 2.1 in Ubuntu 16.04 hasn't been updated in almost 
> two years. I don't feel comfortable with it, and I would consider 
> alternatives.

s/two years/two and a half years/

It hasn't been updated since release. For a moment I was thinking about
the .10 releases.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Unable to get gpg-preset-passphrase working with gpg2 + gpg-agent in Ubuntu Xenial

[Peter Lebbing]

gpg-preset-passphrase wants a keygrip, not a key fingerprint. To get the 
keygrip for a specific key, use f.e.:

--8<---cut here---start->8---
$ gpg --with-keygrip -k 211601B877A3395Apub   rsa1024 2012-03-17 [SC] [expires: 
2018-08-23]
  825472F37172B95ADC7349BE98B67DE4DCDFDFA4
  Keygrip = 2F677680CA15F6F7B963AF35822E8EC01FBF840A
uid   [  full  ] Test Teststra 
uid   [  full  ] Test Teststra (Koning van Wezel) 
sub   rsa1024 2012-03-17 [E]
  Keygrip = 15CB764B81D542CF921978CA89910C69D53F4E2D
sub   rsa2048 2016-01-12 [A]
  Keygrip = 3D88DC9D60F791821AF8D537EEAC3C8DF7720D63
--8<---cut here---end--->8---

Or for machine-parseable output, f.e.:

--8<---cut here---start->8---
$ gpg --batch --with-colons --with-keygrip -k 
211601B877A3395Atru::7:1534436270:1537177125
pub:f:1024:1:98B67DE4DCDFDFA4:1331982780:1535041047::n:::scESCA:::
fpr:825472F37172B95ADC7349BE98B67DE4DCDFDFA4:
grp:2F677680CA15F6F7B963AF35822E8EC01FBF840A:
uid:f1534436249::A57955B7E1CD67534EBEB1E2F56C1FA882CDDE44::Test Teststra 
:
uid:f1534436247::B56114536967B4C81D29D6942712F43E831224A5::Test Teststra 
(Koning van Wezel) :
sub:f:1024:1:211601B877A3395A:1331982780::e::
fpr:9A40F128868A76CF92320458211601B877A3395A:
grp:15CB764B81D542CF921978CA89910C69D53F4E2D:
sub:f:2048:1:0BF68DE438EF7410:1452622346::a::
fpr:029CE2AB6B2E28D10BF9E7140BF68DE438EF7410:
grp:3D88DC9D60F791821AF8D537EEAC3C8DF7720D63:
sub:e:1024:1:24FE6FCFC9685297:1490208195:1490812995:s::
fpr:39F1AE29CE8B6C313CEE723E24FE6FCFC9685297:
grp:B93CA4F1A44FAD92D45DC836DEC653769421E703:
--8<---cut here---end--->8---

Scan lines up to the signing subkey, and take the grp-record that 
follows the signing subkey. See doc/DETAILS for details about the 
format.

preset-passphrase works on individual keys, if you need to preset both 
encryption and signature keys, use it once for each keygrip.

By the way, the GnuPG 2.1 in Ubuntu 16.04 hasn't been updated in almost 
two years. I don't feel comfortable with it, and I would consider 
alternatives.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Unable to get gpg-preset-passphrase working with gpg2 + gpg-agent in Ubuntu Xenial

[Austin Witt]

I want:

To be able to configure an Ubuntu Xenial machine with passphrase-protected
gpg2 keys on disk, and have a running gpg-agent with a passphrase for the
keys pre-loaded by a script. "Users" of this environment should never see a
gpg passphrase prompt: the script will have been run and will have
populated the gpg-agent with the passphrase for the keys before they run a
single command.

I'd settle for getting it working with vanilla gpg2, but ultimately I want
git to be able to sign commits.

I've had a hard time tracking down online documentation that speaks
specifically to gpg 2.1+; most of what I've found (on the stackexchange
sites, forums, and mailing lists, etc) reference older versions of gpg,
especially where gpg-agent is concerned.

I execute gpg-preset-passphrase to the best of my understanding, but all
GPG tools still prompt me for a passphrase. After entering the passphrase,
the gpg-agent correctly saves it and I avoid any future prompts.

I suspect that one of the following is true:

1. I don't know how to use gpg-preset-passphrase 2.1.11
2. gpg-preset-passphrase 2.1.11 doesn't work with gpg-agent 2.1.11
3. gpg-preset-passphrase 2.1.11 doesn't work in Ubuntu Xenial

To aid in debugging, I have created a git repository that builds an Ubuntu
Xenial Docker image that reproduces the issue. Really it just does what I
am trying to do, in the environment I was trying to do it in, and fails the
same way.

So, while I'll quickly tell you some relevant things about my environment,
e.g.

1. OS: Ubuntu 16.04.5 LTS
2. gpg2 version: gpg (GnuPG) 2.1.11
3. gpg-agent version: gpg-agent (GnuPG) 2.1.11
4. gpg-preset-passphrase version: gpg-preset-passphrase (GnuPG) 2.1.11

You can (if you have "docker" installed), visit & clone
https://github.com/Gengar003/linux-gpg2-agent-preset to reproduce & explore
my situation in my exact environment with my exact commands.

My actual questions are:

1. Am I using gpg-agent correctly for gpg 2.1+?
2. Am I using gpg-preset-passphrase correctly for gpg 2.1+?
3. Should gpg-preset-passphrase work with gpg 2.1+?
4. Does anyone know of a working example of a preset passphrase with
gpg-agent in gpg 2.1+?

Thank you for your time.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Workaround for missing pinentry support in gpg-preset-passphrase? (was: How to avoid Passphrase prompt)

[Peter Lebbing]

On 02/02/18 12:23, Peter Lebbing wrote:
> Do this every time after starting the server/starting gpg-agent, to unlock 
> the key:
> 
> gpg-preset-passphrase --preset 15CB764B81D542CF921978CA89910C69D53F4E2D
> 
> (Type in the password. Currently no pinentry support.)

It is a pity gpg-preset-passphrase currently has no pinentry support.

While doing the dishes, I thought: can't we work around that for a bit? 
:-)

I'd like to know what people think of this hack:

--8<---cut here---start->8---
gpg-connect-agent -q '/datafile -' 'get_passphrase --data workaround:pass + 
Enter+passphrase: +' 'clear_passphrase workaround:pass' /bye | 
/usr/lib/gnupg2/gpg-preset-passphrase --preset 
15CB764B81D542CF921978CA89910C69D53F4E2D
--8<---cut here---end--->8---

As far as I can tell, the first part neatly echoes a pinentry-obtained 
passphrase on stdout. This is then passed to gpg-preset-passphrase.

A neat work-around? Or an ugly hack that leads to system compromise, 
uncontrolled nuclear fusion in the processor and a new world war?

(By the way, I didn't know how to pass an empty string, and all the 
prompts are not optional despite what "help" says. So I passed single 
spaces for the text.)

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase not working with 2.1

[Justus Winter]

Hello :)

David Matthews  writes:

> I can't get gpg-preset-passphrase to work with GnuPG 2.1.7. The
> command appears to work successfully but the passphase is not found by
> GET_PASSPHRASE. I've included details of my simple test below plus the
> output from running it on Centos 7.2 (where it works using 2.0.22) and
> Fedora 23 (where it fails using 2.1.7).

Thanks for the report.

> Searching through the issue tracker I found
> https://bugs.gnupg.org/gnupg/issue2015. The title of this issue is
> "GET_PASSPHRASE with --no-ask always return error in gnupg 2.1.5" but,
> based on the discussion in the issue, I think the title should really be
> "gpg-preset-passphrase does not work". Have I understood that
> correctly?

I haven't looked deeply into the issue, but gpg-preset-passphrase does
work, we use it in our test suite.  Feel free to add relevant
information, but please don't retitle the bug.  I have approved your bug
tracker account.

> If so I assume I will see the same issue with the latest release?

Yes.  The issue is not closed, so it should be still present.


Cheers,
Justus


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase not working with 2.1

[David Matthews]

On 14 July 2016 at 07:29, David Matthews  wrote:
> On 13 July 2016 at 13:13, Daniel Kahn Gillmor  wrote:
>> Hi David--
>>
>> On Tue 2016-07-12 16:46:53 +0200, David Matthews wrote:
>>> I can't get gpg-preset-passphrase to work with GnuPG 2.1.7.
>>
>> there have been significant changes to GnuPG between 2.1.7 and 2.1.13.
>>
>> can you try upgrading to 2.1.13?
>
> I've compiled 2.1.13 on Fedora 23 and get the same result (test output below).
>
> According to issue 2015 this was caused by a change that went into
> release 2.1.5.

Could someone with the necessary permissions please add a comment to
https://bugs.gnupg.org/gnupg/issue2015 to indicate that this bug still exists at
2.1.13 and also update the title? I only have permission to create a new bug
and I don't want to create a duplicate.

Thanks,
David

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase not working with 2.1

[David Matthews]

On 13 July 2016 at 13:13, Daniel Kahn Gillmor  wrote:
> Hi David--
>
> On Tue 2016-07-12 16:46:53 +0200, David Matthews wrote:
>> I can't get gpg-preset-passphrase to work with GnuPG 2.1.7.
>
> there have been significant changes to GnuPG between 2.1.7 and 2.1.13.
>
> can you try upgrading to 2.1.13?

I've compiled 2.1.13 on Fedora 23 and get the same result (test output below).

According to issue 2015 this was caused by a change that went into
release 2.1.5.

Thanks,
David

++ gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9
gpg-agent[12163]: enabled debug flags: command mpi crypto memory cache
memstat ipc
gpg-agent[12163]: listening on socket '/run/user/1000/gnupg/S.gpg-agent'
gpg-agent[12164]: gpg-agent (GnuPG) 2.1.13 started
+ eval ''
+ /usr/local/libexec/gpg-preset-passphrase -vv --preset -P test myid
gpg-agent[12164]: handler 0x7fc9c028a700 for fd 4 started
gpg-agent[12164]: DBG: chan_4 -> OK Pleased to meet you, process 12165
gpg-agent[12164]: DBG: chan_4 <- OPTION ttyname=/dev/pts/0
gpg-agent[12164]: DBG: chan_4 -> OK
gpg-agent[12164]: DBG: chan_4 <- OPTION ttytype=xterm
gpg-agent[12164]: DBG: chan_4 -> OK
gpg-agent[12164]: DBG: chan_4 <- OPTION lc-ctype=en_US.UTF-8
gpg-agent[12164]: DBG: chan_4 -> OK
gpg-agent[12164]: DBG: chan_4 <- OPTION lc-messages=en_US.UTF-8
gpg-agent[12164]: DBG: chan_4 -> OK
gpg-agent[12164]: DBG: chan_4 <- PRESET_PASSPHRASE myid -1 74657374
gpg-agent[12164]: DBG: agent_put_cache 'myid' (mode 1) requested ttl=-1
gpg-agent[12164]: DBG: chan_4 -> S PROGRESS need_entropy X 60 120
gpg-agent[12164]: DBG: chan_4 -> S PROGRESS need_entropy X 120 120
 Removed lots of repeated lines 
gpg-agent[12164]: DBG: chan_4 -> S PROGRESS need_entropy X 60 120
gpg-agent[12164]: DBG: chan_4 -> S PROGRESS need_entropy X 120 120
gpg-agent[12164]: DBG: chan_4 -> OK
gpg-agent[12164]: DBG: chan_4 <- [eof]
gpg-agent[12164]: handler 0x7fc9c028a700 for fd 4 terminated
+ echo 'GET_PASSPHRASE --no-ask myid Err Pmt Des'
+ gpg-connect-agent -vv
gpg-agent[12164]: handler 0x7fc9c028a700 for fd 4 started
gpg-agent[12164]: DBG: chan_4 -> OK Pleased to meet you, process 12168
gpg-agent[12164]: DBG: chan_4 <- RESET
gpg-agent[12164]: DBG: chan_4 -> OK
gpg-agent[12164]: DBG: chan_4 <- OPTION ttytype=xterm
gpg-agent[12164]: DBG: chan_4 -> OK
gpg-agent[12164]: DBG: chan_4 <- GET_PASSPHRASE --no-ask myid Err Pmt Des
gpg-agent[12164]: DBG: agent_get_cache 'myid' (mode 3) ...
gpg-agent[12164]: DBG: ... miss
gpg-agent[12164]: command 'GET_PASSPHRASE' failed: No data
gpg-agent[12164]: DBG: chan_4 -> ERR 67108922 No data 
gpg-connect-agent: closing connection to agent
ERR 67108922 No data 
gpg-agent[12164]: DBG: chan_4 <- [eof]
gpg-agent[12164]: handler 0x7fc9c028a700 for fd 4 terminated

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg-preset-passphrase not working with 2.1

[David Matthews]

I can't get gpg-preset-passphrase to work with GnuPG 2.1.7. The
command appears to work successfully but the passphase is not found by
GET_PASSPHRASE. I've included details of my simple test below plus the
output from running it on Centos 7.2 (where it works using 2.0.22) and
Fedora 23 (where it fails using 2.1.7).

Searching through the issue tracker I found
https://bugs.gnupg.org/gnupg/issue2015. The title of this issue is
"GET_PASSPHRASE with --no-ask always return error in gnupg 2.1.5" but,
based on the discussion in the issue, I think the title is now wrong
and should really be "gpg-preset-passphrase does not work". Have I
understood that correctly? If so I assume I will see the same issue
with the latest release?

Any advice much appreciated.

Thanks

## Test script

#!/bin/bash
set -x
eval "$(gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9)"
/usr/libexec/gpg-preset-passphrase -vv --preset -P test myid
echo "GET_PASSPHRASE --no-ask myid Err Pmt Des" | gpg-connect-agent -vv

## Centos 7.2 output

++ gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9
gpg-agent[3239]: enabled debug flags: command mpi crypto memory cache
memstat assuan
gpg-agent[3239]: listening on socket `/home/vagrant/.gnupg/S.gpg-agent'
gpg-agent[3240]: gpg-agent (GnuPG) 2.0.22 started
+ eval 'GPG_AGENT_INFO=/home/vagrant/.gnupg/S.gpg-agent:3240:1; export
GPG_AGENT_INFO;'
++ GPG_AGENT_INFO=/home/vagrant/.gnupg/S.gpg-agent:3240:1
++ export GPG_AGENT_INFO
+ /usr/libexec/gpg-preset-passphrase -vv --preset -P test myid
gpg-agent[3240]: handler 0xcfcb70 for fd 7 started
gpg-agent[3240]: chan_7 -> OK Pleased to meet you, process 3241
gpg-agent[3240]: chan_7 <- OPTION display=localhost:10.0
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- OPTION ttyname=/dev/pts/1
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- OPTION ttytype=dumb
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- OPTION lc-ctype=en_US.UTF-8
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- OPTION lc-messages=en_US.UTF-8
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- PRESET_PASSPHRASE myid -1 74657374
gpg-agent[3240]: DBG: agent_put_cache `myid' requested ttl=-1 mode=1
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- [eof]
gpg-agent[3240]: handler 0xcfcb70 for fd 7 terminated
+ echo 'GET_PASSPHRASE --no-ask myid Err Pmt Des'
+ gpg-connect-agent -vv
gpg-agent[3240]: handler 0xcfe550 for fd 7 started
gpg-agent[3240]: chan_7 -> OK Pleased to meet you, process 3243
gpg-connect-agent: connection to agent established
gpg-agent[3240]: chan_7 <- RESET
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- OPTION ttytype=dumb
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- OPTION display=localhost:10.0
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- GET_PASSPHRASE --no-ask myid Err Pmt Des
gpg-agent[3240]: DBG: agent_get_cache `myid'...
gpg-agent[3240]: DBG: ... hit
gpg-agent[3240]: chan_7 -> [[Confidential data not shown]]
OK 74657374
gpg-connect-agent: closing connection to agent

## Fedora 23 output

++ gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9
gpg-agent[1420]: enabled debug flags: command mpi crypto memory cache
memstat ipc
gpg-agent[1420]: listening on socket '/home/vagrant/.gnupg/S.gpg-agent'
gpg-agent[1421]: gpg-agent (GnuPG) 2.1.7 started
+ eval ''
+ /usr/libexec/gpg-preset-passphrase -vv --preset -P test myid
gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 started
gpg-agent[1421]: DBG: chan_4 -> OK Pleased to meet you, process 1422
gpg-agent[1421]: DBG: chan_4 <- OPTION ttyname=/dev/pts/1
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- OPTION ttytype=dumb
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- OPTION lc-ctype=en_US.UTF-8
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- OPTION lc-messages=en_US.UTF-8
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- PRESET_PASSPHRASE myid -1 74657374
gpg-agent[1421]: DBG: agent_put_cache 'myid' (mode 1) requested ttl=-1
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- [eof]
gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 terminated
+ echo 'GET_PASSPHRASE --no-ask myid Err Pmt Des'
+ gpg-connect-agent -vv
gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 started
gpg-agent[1421]: DBG: chan_4 -> OK Pleased to meet you, process 1425
gpg-agent[1421]: DBG: chan_4 <- RESET
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- OPTION ttytype=dumb
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- OPTION putenv=INSIDE_EMACS=24.5.1,comint
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- GET_PASSPHRASE --no-ask myid Err Pmt Des
gpg-agent

Re: gpg-preset-passphrase not working with 2.1

[Daniel Kahn Gillmor]

Hi David--

On Tue 2016-07-12 16:46:53 +0200, David Matthews wrote:
> I can't get gpg-preset-passphrase to work with GnuPG 2.1.7.

there have been significant changes to GnuPG between 2.1.7 and 2.1.13.

can you try upgrading to 2.1.13?

--dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg-preset-passphrase not working with 2.1

[David Matthews]

I can't get gpg-preset-passphrase to work with GnuPG 2.1.7. The
command appears to work successfully but the passphase is not found by
GET_PASSPHRASE. I've included details of my simple test below plus the
output from running it on Centos 7.2 (where it works using 2.0.22) and
Fedora 23 (where it fails using 2.1.7).

Searching through the issue tracker I found
https://bugs.gnupg.org/gnupg/issue2015. The title of this issue is
"GET_PASSPHRASE with --no-ask always return error in gnupg 2.1.5" but,
based on the discussion in the issue, I think the title should really be
"gpg-preset-passphrase does not work". Have I understood that correctly?
If so I assume I will see the same issue with the latest release?

Any advice much appreciated. My setup relies on using
gpg-preset-passphrase so I'll need to install 2.0 for the moment unless
I can get this working.

Thanks,
David

## Test script

#!/bin/bash
set -x
eval "$(gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9)"
/usr/libexec/gpg-preset-passphrase -vv --preset -P test myid
echo "GET_PASSPHRASE --no-ask myid Err Pmt Des" | gpg-connect-agent -vv

## Centos 7.2 output

++ gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9
gpg-agent[3239]: enabled debug flags: command mpi crypto memory cache
memstat assuan
gpg-agent[3239]: listening on socket `/home/vagrant/.gnupg/S.gpg-agent'
gpg-agent[3240]: gpg-agent (GnuPG) 2.0.22 started
+ eval 'GPG_AGENT_INFO=/home/vagrant/.gnupg/S.gpg-agent:3240:1; export
GPG_AGENT_INFO;'
++ GPG_AGENT_INFO=/home/vagrant/.gnupg/S.gpg-agent:3240:1
++ export GPG_AGENT_INFO
+ /usr/libexec/gpg-preset-passphrase -vv --preset -P test myid
gpg-agent[3240]: handler 0xcfcb70 for fd 7 started
gpg-agent[3240]: chan_7 -> OK Pleased to meet you, process 3241
gpg-agent[3240]: chan_7 <- OPTION display=localhost:10.0
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- OPTION ttyname=/dev/pts/1
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- OPTION ttytype=dumb
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- OPTION lc-ctype=en_US.UTF-8
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- OPTION lc-messages=en_US.UTF-8
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- PRESET_PASSPHRASE myid -1 74657374
gpg-agent[3240]: DBG: agent_put_cache `myid' requested ttl=-1 mode=1
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- [eof]
gpg-agent[3240]: handler 0xcfcb70 for fd 7 terminated
+ echo 'GET_PASSPHRASE --no-ask myid Err Pmt Des'
+ gpg-connect-agent -vv
gpg-agent[3240]: handler 0xcfe550 for fd 7 started
gpg-agent[3240]: chan_7 -> OK Pleased to meet you, process 3243
gpg-connect-agent: connection to agent established
gpg-agent[3240]: chan_7 <- RESET
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- OPTION ttytype=dumb
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- OPTION display=localhost:10.0
gpg-agent[3240]: chan_7 -> OK
gpg-agent[3240]: chan_7 <- GET_PASSPHRASE --no-ask myid Err Pmt Des
gpg-agent[3240]: DBG: agent_get_cache `myid'...
gpg-agent[3240]: DBG: ... hit
gpg-agent[3240]: chan_7 -> [[Confidential data not shown]]
OK 74657374
gpg-connect-agent: closing connection to agent

## Fedora 23 output

++ gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9
gpg-agent[1420]: enabled debug flags: command mpi crypto memory cache
memstat ipc
gpg-agent[1420]: listening on socket '/home/vagrant/.gnupg/S.gpg-agent'
gpg-agent[1421]: gpg-agent (GnuPG) 2.1.7 started
+ eval ''
+ /usr/libexec/gpg-preset-passphrase -vv --preset -P test myid
gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 started
gpg-agent[1421]: DBG: chan_4 -> OK Pleased to meet you, process 1422
gpg-agent[1421]: DBG: chan_4 <- OPTION ttyname=/dev/pts/1
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- OPTION ttytype=dumb
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- OPTION lc-ctype=en_US.UTF-8
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- OPTION lc-messages=en_US.UTF-8
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- PRESET_PASSPHRASE myid -1 74657374
gpg-agent[1421]: DBG: agent_put_cache 'myid' (mode 1) requested ttl=-1
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- [eof]
gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 terminated
+ echo 'GET_PASSPHRASE --no-ask myid Err Pmt Des'
+ gpg-connect-agent -vv
gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 started
gpg-agent[1421]: DBG: chan_4 -> OK Pleased to meet you, process 1425
gpg-agent[1421]: DBG: chan_4 <- RESET
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- OPTION ttytype=dumb
gpg-agent[1421]: DBG: chan_4 -> OK
gpg-agent[1421]: DBG: chan_4 <- OPTION putenv=INSIDE_EMACS=24.5.1,comint
gpg-a

gpg-preset-passphrase: problem setting the gpg-agent options [caused by empty $DISPLAY]

[gnupg]

Hi,

ubuntu-14.04.3 LTS
gnupg-1.4.16-1ubuntu2.3
gnupg2-2.0.22-3ubuntu1.3
gnupg-agent-2.0.22-3ubuntu1.3

I've just started using gpg-agent and gpg-preset-passphrase to store a
passphrase briefly.

Yesterday, this was working fine on two hosts.
Today, it stopped working on one of them.

The gpg-agent command looks like:

  $ /usr/bin/screen -- \
  > /usr/bin/sudo -u thing --set-home -- \
  > /usr/bin/gpg-agent \
  > --homedir /etc/thing/.gnupg \
  > --write-env-file /etc/thing/run/.gpg-agent-info \
  > --allow-preset-passphrase \
  > --daemon -- \
  > /bin/bash --login

And the gpg-preset-passphrase command looks like:

  $ gpg_cache_id="`/usr/bin/gpg --homedir /etc/thing/.gnupg --fingerprint 
--fingerprint th...@example.com | grep 'Key fingerprint' | tail -1 | sed -e 
's/^[^=]\+=//' -e 's/ //g'`"
  $ my-ask-password 'Enter the GPG passphrase:' | 
/usr/lib/gnupg2/gpg-preset-passphrase --preset "$gpg_cache_id"
  
The gpg-preset-passphrase command is executed from within the .bash_login
script that is executed by bash that is run by gpg-agent in the first
command above.

So yesterday, this worked perfectly. Today, when I try it, I get:

  Enter the GPG passphrase:
  gpg-preset-passphrase: problem setting the gpg-agent options
  gpg-preset-passphrase: caching passphrase failed: Invalid response

Is there any way to find out what the problem was? I couldn't find any
log messages with more information and adding the -v option to
gpg-preset-passphrase didn't add anything.

There's nothing wrong with the cache id. It hasn't changed since yesterday.

Hang on, I've found out what caused it:

  $ DISPLAY=

Yesterday, I was logged into the problem host from the same LAN so I had
$DISPLAY set. Today, I'm logged in from further way and cleared $DISPLAY to
prevent slow X11 traffic.

When I turn off X11, I do it by setting DISPLAY to the empty string. That has
always worked for all other programs but it seems that gpg-preset-passphrase
is assuming that if $DISPLAY exists, then it must contain something useful
and, if not, it runs into problems. At least that's what it seems like.

If I do the following instead:

  $ unset DISPLAY

Then gpg-preset-passphrase works fine.

It seems to me to be a buglet in gpg-preset-passphrase because it's the only
program I've encountered that doesn't treat an empty $DISPLAY the same as an
absent $DISPLAY.

This also applies to:

debian-8
gnupg-1.4.18-7
gnupg2-2.0.26-6
gnupg-agent-2.0.26-6

But at least I know now what not to do to keep it working. :-)

cheers,
raf


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase: cache id

[Werner Koch]

On Mon, 27 May 2013 14:02, mailinglis...@hauke-laging.de said:

> How is a passphrase with a cache id like foo:12346 used? Is it tried for all 
> keys which do not have a keygrip entry?

No.  It is used with the commands 

  GET_PASSPHRASE [--data] [--check] [--no-ask] [--repeat[=N]]
 [--qualitybar] 
 [  ]
 
and 

  CLEAR_PASSPHRASE [--mode=normal] 

which both take care of the cache-id.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg-preset-passphrase: cache id

[Hauke Laging]

Hello,

I quote from the man page:

###
gpg-preset-passphrase [options] [command] cacheid

cacheid is either a 40 character keygrip of hexadecimal characters identifying 
the key for which the passphrase should be set or cleared. [...] Alternatively 
an arbitrary string may be used to identify a passphrase; it is suggested that 
such a string is prefixed with the name of the application (e.g foo:12346).
###

How is a passphrase with a cache id like foo:12346 used? Is it tried for all 
keys which do not have a keygrip entry?


Hauke
-- 
☺
PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04)
http://www.openpgp-courses.org/


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase

[kkaputa]

I have a patch for fixing the 'forget' option.  I hope this is of some help.   
http://old.nabble.com/file/p27817136/clear_passphrase.patch
clear_passphrase.patch 

It would be nice to have a more complete tool for administering passphrases,
or a simpler interface to pinentry :)

/K


Daniel Eggleston-2 wrote:
> 
> I'm looking for some help explaining the behavior of
> gpg-preset-passphrase.
> 
> First, the manpage states:
> 
>Passphrases set with this utility  don't  expire  unless  the
> --forget
>option is used to explicitly clear them from the cache --- or
> gpg-agent
>is either restarted or reloaded (by sending a SIGHUP  to  it).   It
> is
> 
> But it looks like gpg-preset-passphrase cached passphrases are still
> subject
> to the --max-cache-ttl option in gpg-agent ... this behavior is hardly
> "Don't expire". Is there a way to change this behavior?
> 
> Second, the manpage also states:
> 
>--forget
>   Flush the passphrase for the given cache ID from the cache.
> 
> The implication (to me) is that if I cache a passphrase with
> gpg-preset-passphrase, then run gpg-preset-passphrase with the same key
> fingerprint and the --forget option, that gpg-agent will no longer cache
> that entry.  When this didn't pan out, I thought maybe the forget command
> simply makes the cached passphrase obey the --default-cache-ttl option,
> but
> no dice.
> 
> So, basically the --preset command is subject to --max-cache-ttl (although
> the documentation implies otherwise), and the --forget command doesn't
> appear to change anything at all.  Am I doing it wrong?
> 
> Any help is appreciated,
> 
> -- 
> 
>   Daniel
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
> 

-- 
View this message in context: 
http://old.nabble.com/gpg-preset-passphrase-tp27812444p27817136.html
Sent from the GnuPG - User mailing list archive at Nabble.com.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg-preset-passphrase

[Daniel Eggleston]

I'm looking for some help explaining the behavior of gpg-preset-passphrase.

First, the manpage states:

   Passphrases set with this utility  don't  expire  unless  the
--forget
   option is used to explicitly clear them from the cache --- or
gpg-agent
   is either restarted or reloaded (by sending a SIGHUP  to  it).   It
is

But it looks like gpg-preset-passphrase cached passphrases are still subject
to the --max-cache-ttl option in gpg-agent ... this behavior is hardly
"Don't expire". Is there a way to change this behavior?

Second, the manpage also states:

   --forget
  Flush the passphrase for the given cache ID from the cache.

The implication (to me) is that if I cache a passphrase with
gpg-preset-passphrase, then run gpg-preset-passphrase with the same key
fingerprint and the --forget option, that gpg-agent will no longer cache
that entry.  When this didn't pan out, I thought maybe the forget command
simply makes the cached passphrase obey the --default-cache-ttl option, but
no dice.

So, basically the --preset command is subject to --max-cache-ttl (although
the documentation implies otherwise), and the --forget command doesn't
appear to change anything at all.  Am I doing it wrong?

Any help is appreciated,

-- 

  Daniel
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

seeding agent cache with gpg-preset-passphrase does not seem to work

[Andrew Thompson]

Greetings gnupg-users,

I'm trying to seed gnupg-agent using the not-so-majikal 
gpg-preset-passphrase tool. Emphasis on *trying* - it's not working atm 
(yet?) All the gory details follow bellow, but in a nutshell, this is 
what I think is happening:
* use of gpg-preset-passphrase results in a successful PRESET_PASSPHRASE 
message that includes the hexified passphrase (and successful 
agent_put_cache call according to the log)
* then attempting a decryption results in a "hit" for the 
agent_get_cache call ("hit" implying that the cached passphrase was 
found, right?) But I can only assume that this passphrase isn't in the 
correct format, or has been truncated, or somehting, as the cache for 
that key is cleared and a second GET_PASSPHRASE occurs with the 
pin-entry message "Invalid passphrase; please try again etc..."

* caching of passphrases entered through pin-entries works as expected

Could this be a regression related to this: 
http://lists.gnupg.org/pipermail/gnupg-devel/2008-August/024559.html ??


Anyway, here's the -v version.

Firstly, I fire up the agent for debugging like so:
 $ eval `gpg-agent --daemon --write-env-file $HOME/.gpg-agent-info 
--enable-ssh-support --debug-all --allow-preset-passphrase --verbose 
--log-file $HOME/gpg-agent-verbose.log`
 gpg-agent[1994]: NOTE: no default option file 
`/home/andrew/.gnupg/gpg-agent.conf'


And yes, I make sure GPG_TTY is exported too:
 $ GPG_TTY=$(tty);export GPG_TTY;

The log so far:
 2009-09-24 16:54:43 gpg-agent[1994] listening on socket 
`/tmp/gpg-LLlkyo/S.gpg-agent'
 2009-09-24 16:54:43 gpg-agent[1994] listening on socket 
`/tmp/gpg-H7nzb6/S.gpg-agent.ssh'


Now for the passphrase presetting (yes, I know the passphrase is visible 
- this is a test run for you people):
 $ /usr/lib/gnupg2/gpg-preset-passphrase --preset 
C778704A03AED6F241BBBEA001D190DE22248DEB

 12341234

Side Note: The only way I could figure out how to get that darn keygrip 
is to pull it out of a running agent's debug log - is there another way, 
similar to gpgsm's --dump-secret-keys or something?? Anyway, on with the 
show...


The preset passphrase log:
 2009-09-24 16:57:55 gpg-agent[1995] handler 0x1847f90 for fd 7 started
 gpg-agent[1995.7] DBG: -> OK Pleased to meet you
 gpg-agent[1995.7] DBG: <- OPTION display=:0.0
 gpg-agent[1995.7] DBG: -> OK
 gpg-agent[1995.7] DBG: <- OPTION ttyname=/dev/pts/16
 gpg-agent[1995.7] DBG: -> OK
 gpg-agent[1995.7] DBG: <- OPTION ttytype=xterm
 gpg-agent[1995.7] DBG: -> OK
 gpg-agent[1995.7] DBG: <- OPTION lc-ctype=en_GB.UTF-8
 gpg-agent[1995.7] DBG: -> OK
 gpg-agent[1995.7] DBG: <- OPTION lc-messages=en_GB.UTF-8
 gpg-agent[1995.7] DBG: -> OK
 gpg-agent[1995.7] DBG: <- OPTION xauthority=/tmp/.gdmKJ11XU
 gpg-agent[1995.7] DBG: -> OK
 gpg-agent[1995.7] DBG: <- PRESET_PASSPHRASE 
C778704A03AED6F241BBBEA001D190DE22248DEB -1 3132333431323334
 2009-09-24 16:57:55 gpg-agent[1995] DBG: agent_put_cache 
`C778704A03AED6F241BBBEA001D190DE22248DEB' requested ttl=-1 mode=1

 gpg-agent[1995.7] DBG: -> OK
 gpg-agent[1995.7] DBG: <- [EOF]
 2009-09-24 16:57:55 gpg-agent[1995] handler 0x1847f90 for fd 7 terminated

Note that the hexified passphrase is correct:
 $ echo -n "12341234" | xxd -c 256 -ps
 3132333431323334

Now, encrypt something:
 $ gpg -e -r t...@test.test encrypt_this.txt

Then decrypt:
 $ gpg -d encrypt_this.txt.gpg

 You need a passphrase to unlock the secret key for
 user: "Test Test (Testing 123) "
 2048-bit ELG-E key, ID 22248DEB, created 2009-09-24 (main key ID 8CAC7B50)

 gpg: encrypted with 2048-bit ELG-E key, ID 22248DEB, created 2009-09-24
 "Test Test (Testing 123) "
 Some text to encrypt.

Obviously, the above requires pin-entry, the log shows the preset cached 
passphrase rejection I think:

 2009-09-24 17:21:10 gpg-agent[2397] handler 0x1aafb00 for fd 7 started
 gpg-agent[2397.7] DBG: -> OK Pleased to meet you
 gpg-agent[2397.7] DBG: <- OPTION display=:0.0
 gpg-agent[2397.7] DBG: -> OK
 gpg-agent[2397.7] DBG: <- OPTION ttyname=/dev/pts/16
 gpg-agent[2397.7] DBG: -> OK
 gpg-agent[2397.7] DBG: <- OPTION ttytype=xterm
 gpg-agent[2397.7] DBG: -> OK
 gpg-agent[2397.7] DBG: <- OPTION lc-ctype=en_GB.UTF-8
 gpg-agent[2397.7] DBG: -> OK
 gpg-agent[2397.7] DBG: <- OPTION lc-messages=en_GB.UTF-8
 gpg-agent[2397.7] DBG: -> OK
 gpg-agent[2397.7] DBG: <- GET_PASSPHRASE 
C778704A03AED6F241BBBEA001D190DE22248DEB X X 
You+need+a+passphrase+to+unlock+the+secret+key+for+user:%0A"Test+Test+(Testing+123)+"%0A2048-bit+ELG-E+key,+ID+22248DEB,+created+2009-09-24+(main+key+ID+8CAC7B50)%0A
 2009-09-24 17:21:10 gpg-agent[2397] DBG: agent_get_cache 
`C778704A03AED6F241BBBEA001D190DE22248DEB'...

 2009-09-24 17:21:10 gpg-agent[2397] DBG: ... hit
 gpg-agent[2397.7] DBG: -> [Confidential data not shown]
 gpg-agent[2397.7] DBG: <- BYE
 gp