Mailing List Archive

Using loopback pin entry with GnuPG 2.1
I'm having trouble trying to get loopback pinentry working from my unit tests.

Environment: Ubuntu 16.04 (64-bit), GnuPG 2.1.11/libgcrypt 1.6.5

$ cat ~/.gnupg/gpg-agent.conf
allow-loopback-pinentry


After creating this file, I logged out and logged in again. When I run


gpg2 --pinentry-mode loopback --status-fd 2 --no-tty --homedir /home/vinay/projects/python-gnupg/keys --batch --passphrase-fd 0 --debug-quick-random --decrypt


from a test script, I get errors (the first line is just for context):

[GNUPG:] ENC_TO BCB77EF0C7648FEB 16 0
gpg: setting pinentry mode 'loopback' failed: Not supported
[GNUPG:] ERROR set_pinentry_mode 67108924


I checked the gpg-agent process:

$ ps -ef | grep gpg-agent | grep -v grep
vinay 21402 21284 0 17:37 ? 00:00:00 gpg-agent --homedir /home/vinay/.gnupg --use-standard-socket --daemon

I can't find any reference to the error code 67108924, nor can I see what I've done wrong in the setup. Can anyone enlighten me as to how to get my tests to run all the way through without popping up pinentry prompts or failing as above?

Thanks and regards,

Vinay Sajip

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Using loopback pin entry with GnuPG 2.1 [ In reply to ]
On Thu, 20 Oct 2016 18:56, vinay_sajip@yahoo.co.uk said:
> $ cat ~/.gnupg/gpg-agent.conf
> allow-loopback-pinentry
>
> After creating this file, I logged out and logged in again. When I run

Sending a HUP (or "gpgconf --reload gpg-agent") would be sufficient to
enable the option. Adn with 2.1.12 --allow-loopback-pinentry is anyway
the default.

> gpg: setting pinentry mode 'loopback' failed: Not supported
> [GNUPG:] ERROR set_pinentry_mode 67108924

$ gpg-error 67108924
67108924 = (4, 60) = (GPG_ERR_SOURCE_GPGAGENT, GPG_ERR_NOT_SUPPORTED) \
= (GPG Agent, Not supported)

gpg tells gpg-agent about the requested pinentry mode using an Assun
OPTION command. This command errors out with the above error. To see
what's going on, I suggest to enable logging for the agent. The best
way to do this is by running

watchgnupg --force /home/foo/.gnupg/S.log

in a second terminal and add this to gpg-agent.conf:

log-file socket:///home/foo/.gnupg/S.log
verbose
debug ipc

The kill the agent you will see all commands send to the agent in the
second terminal.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Using loopback pin entry with GnuPG 2.1 [ In reply to ]
Dear Werner,

Thanks for the suggestions. My comments are:

> $ gpg-error 67108924
> 67108924 = (4, 60) = (GPG_ERR_SOURCE_GPGAGENT, GPG_ERR_NOT_SUPPORTED) \
> = (GPG Agent, Not supported)

gpg-error is apparently not shipped with all distros - there's no sign of it on my Ubuntu system. Is there a list of error codes with meanings published somewhere (other than in gpg-error.h)?

I did the following:

> watchgnupg --force /home/foo/.gnupg/S.log

> in a second terminal and add this to gpg-agent.conf:

> log-file socket:///home/foo/.gnupg/S.log
> verbose
> debug ipc


The second window now shows traffic with the agent, e.g.:

[client at fd 4 connected (local)]
4 - 2016-11-04 10:04:10 started
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 -> OK Pleased to meet you, process 1897
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 <- OK Pleased to meet you, process 1897
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 -> GETINFO pid
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 <- GETINFO pid
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 -> D 1897
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 <- D 1897
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 -> OK
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 <- OK
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 -> BYE
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 <- BYE
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 -> OK closing connection
4 - 2016-11-04 10:04:10 gpg-agent[1897]: handler 0x7f960ce8b700 for fd 6 terminated


However, when I run the tests (and they fail as before, with the same error code), no further details are displayed by watchgnupg.

Do you have any further suggestions?

Thanks and regards,

Vinay Sajip

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Using loopback pin entry with GnuPG 2.1 [ In reply to ]
On 04/11/16 11:11, Vinay Sajip wrote:
> gpg-error is apparently not shipped with all distros - there's no
> sign of it on my Ubuntu system.

It's in the package libgpg-error-dev.

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>

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Using loopback pin entry with GnuPG 2.1 [ In reply to ]
On Fri, 4 Nov 2016 11:11, vinay_sajip@yahoo.co.uk said:

>
> The second window now shows traffic with the agent, e.g.:
>
> [client at fd 4 connected (local)]
> 4 - 2016-11-04 10:04:10 started
> 4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 -> OK Pleased to meet you, process 1897
> 4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 <- OK Pleased to meet you, process 1897
> 4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 -> GETINFO pid
> 4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 <- GETINFO pid
> 4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 -> D 1897
> 4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 <- D 1897

That is gpg-agent making a connection to itself to see whether its
socket is still connected to self. This is done once a minute.

It seems your gpg is not using that agent.

You can add "--debug ipc" to gpg to get gpg's site of the communication.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Using loopback pin entry with GnuPG 2.1 [ In reply to ]
Dear Werner,

> That is gpg-agent making a connection to itself to see whether its
> socket is still connected to self. This is done once a minute.

> It seems your gpg is not using that agent.

> You can add "--debug ipc" to gpg to get gpg's site of the communication.

I did that, with no difference. After running my failed tests, I did

$ ps -ef | grep gpg-agent | grep -v grep
vinay 1863 1734 0 19:06 ? 00:00:00 gpg-agent --homedir /home/vinay/.gnupg --use-standard-socket --daemon
vinay 2343 1734 23 19:08 ? 00:00:04 gpg-agent --homedir /home/vinay/projects/python-gnupg/keys --use-standard-socket --daemon
vinay 2368 1734 29 19:08 ? 00:00:04 gpg-agent --homedir /home/vinay/projects/python-gnupg/keys --use-standard-socket --daemon
vinay 2415 1734 43 19:08 ? 00:00:03 gpg-agent --homedir /home/vinay/projects/python-gnupg/keys --use-standard-socket --daemon


Only the first line was present before I ran the tests. After a while, only two lines appear:

$ ps -ef | grep gpg-agent | grep -v grep
vinay 1863 1734 0 19:06 ? 00:00:00 gpg-agent --homedir /home/vinay/.gnupg --use-standard-socket --daemon
vinay 2415 1734 1 19:08 ? 00:00:03 gpg-agent --homedir /home/vinay/projects/python-gnupg/keys --use-standard-socket --daemon


I don't understand what invokes the additional gpg-agent invocations. The watchgnupg program only connects to the first agent (process 1863 above).

I appreciate your help.

Regards,

Vinay Sajip

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Using loopback pin entry with GnuPG 2.1 [ In reply to ]
On Fri, 4 Nov 2016 20:14, vinay_sajip@yahoo.co.uk said:

> I did that, with no difference. After running my failed tests, I did

I am sorry, but I do not have enough information what you are doing. If
you need help, please describe exactly what you are doing (including the
version of the software and the OS). You might have given that in
another mail, but I can't remember.

> $ ps -ef | grep gpg-agent | grep -v grep

ps -ef | grep gpg-agen[t]

is easier ;-) or "pgrep -l gpg-agent" if the pids are sufficient

> I don't understand what invokes the additional gpg-agent
> invocations. The watchgnupg program only connects to the first agent
> (process 1863 above).

The agent connects to the socket watchgnupg is listening on. All agents
configured to use that socket will be showsn by watchgnupg. note tah if
you used

log-file socket://

the used socket depends on the current GNUPGHOME. To direct all log
messages to a single watchgnupg use something like

log-file socket:///tmp/S.my-gnupg-log

and run

watchgnupg --time-only --force /tmp/S.my-gnupg-log


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Using loopback pin entry with GnuPG 2.1 [ In reply to ]
Dear Werner,

> I am sorry, but I do not have enough information what you are doing. If
> you need help, please describe exactly what you are doing (including the
> version of the software and the OS). You might have given that in
> another mail, but I can't remember.

I am running on Ubuntu 16.04.1 (x86_64) with gpg 1.4.20 and gpg 2.1.11 installed using the distro package manager.

My ~/.gnupg/gpg-agent.conf is:

allow-loopback-pinentry
log-file socket:///tmp/S.my-gnupg-log
verbose
debug ipc

Just after reboot, there is only one agent running:


$ ps -ef | grep gpg-agen[t]
vinay 1836 1710 0 22:11 ? 00:00:00 gpg-agent --homedir /home/vinay/.gnupg --use-standard-socket --daemon

and watchgnupg connects to it:


$ watchgnupg --time-only --force /tmp/S.my-gnupg-log
[client at fd 4 connected (local)]
4 - 22:13:12 gpg-agent[1836]: handler 0x7efca342e700 for fd 5 started
4 - 22:13:12 gpg-agent[1836]: DBG: chan_5 -> OK Pleased to meet you, process 1836
4 - 22:13:12 gpg-agent[1836]: DBG: chan_4 <- OK Pleased to meet you, process 1836
4 - 22:13:12 gpg-agent[1836]: DBG: chan_4 -> GETINFO pid
4 - 22:13:12 gpg-agent[1836]: DBG: chan_5 <- GETINFO pid
4 - 22:13:12 gpg-agent[1836]: DBG: chan_5 -> D 1836
4 - 22:13:12 gpg-agent[1836]: DBG: chan_4 <- D 1836
4 - 22:13:12 gpg-agent[1836]: DBG: chan_5 -> OK
4 - 22:13:12 gpg-agent[1836]: DBG: chan_4 <- OK
4 - 22:13:12 gpg-agent[1836]: DBG: chan_4 -> BYE
4 - 22:13:12 gpg-agent[1836]: DBG: chan_5 <- BYE
4 - 22:13:12 gpg-agent[1836]: DBG: chan_5 -> OK closing connection
4 - 22:13:12 gpg-agent[1836]: handler 0x7efca342e700 for fd 5 terminated


Then I run a single test, which fails. After it, there are two agents:

$ ps -ef | grep gpg-agen[t]
vinay 1836 1710 0 22:11 ? 00:00:00 gpg-agent --homedir /home/vinay/.gnupg --use-standard-socket --daemon
vinay 2373 1710 48 22:12 ? 00:00:03 gpg-agent --homedir /home/vinay/projects/python-gnupg/keys --use-standard-socket --daemon


I have placed a copy of ~/.gnupg/gpg-agent.conf in /home/vinay/projects/python-gnupg/keys/gpg-agent.conf.

However, the watchgnupg output shows no reference to PID 2373, only the once-a-minute check with PID 1836.

The test creates two keys and encrypts and decrypts some data, and verifies that the decryption result matches what was encrypted. The test fails at the decryption stage, the relevant excerpt from the test log is as follows:

MainThread gpg2 --pinentry-mode loopback --status-fd 2 --no-tty --debug ipc --homedir /home/vinay/projects/python-gnupg/keys --batch --passphrase-fd 0 --debug-quick-random --decrypt
MainThread Wrote passphrase
MainThread data copier: <Thread(Thread-12, initial daemon)>, <_io.BytesIO object at 0x7f8d51b40410>, <open file '<fdopen>', mode 'wb' at 0x7f8d5207c9c0>
MainThread stderr reader: <Thread(Thread-13, initial daemon)>
Thread-12 closed output, 896 bytes sent
MainThread stdout reader: <Thread(Thread-14, initial daemon)>
Thread-13 gpg: Note: no default option file '/home/vinay/projects/python-gnupg/keys/gpg.conf'
Thread-13 gpg: enabled debug flags: ipc
Thread-13 [GNUPG:] ENC_TO 195194AD659FA047 16 0
Thread-13 gpg: DBG: chan_5 <- OK Pleased to meet you, process 2384
Thread-13 gpg: DBG: connection to agent established
Thread-13 gpg: DBG: chan_5 -> RESET
Thread-13 gpg: DBG: chan_5 <- OK
Thread-13 gpg: DBG: chan_5 -> OPTION ttytype=xterm-256color
Thread-13 gpg: DBG: chan_5 <- OK
Thread-13 gpg: DBG: chan_5 -> OPTION display=:0
Thread-13 gpg: DBG: chan_5 <- OK
Thread-13 gpg: DBG: chan_5 -> OPTION xauthority=/home/vinay/.Xauthority
Thread-13 gpg: DBG: chan_5 <- OK
Thread-13 gpg: DBG: chan_5 -> OPTION putenv=XMODIFIERS=@im=ibus
Thread-13 gpg: DBG: chan_5 <- OK
Thread-13 gpg: DBG: chan_5 -> OPTION putenv=GTK_IM_MODULE=ibus
Thread-13 gpg: DBG: chan_5 <- OK
Thread-13 gpg: DBG: chan_5 -> OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-qFEK77X1S3
Thread-13 gpg: DBG: chan_5 <- OK
Thread-13 gpg: DBG: chan_5 -> OPTION putenv=QT_IM_MODULE=ibus
Thread-13 gpg: DBG: chan_5 <- OK
Thread-13 gpg: DBG: chan_5 -> GETINFO version
Thread-13 gpg: DBG: chan_5 <- D 2.1.11
Thread-13 gpg: DBG: chan_5 <- OK
Thread-13 gpg: DBG: chan_5 -> OPTION allow-pinentry-notify
Thread-13 gpg: DBG: chan_5 <- OK
Thread-13 gpg: DBG: chan_5 -> OPTION agent-awareness=2.1.0
Thread-13 gpg: DBG: chan_5 <- OK
Thread-13 gpg: DBG: chan_5 -> OPTION pinentry-mode=loopback
Thread-13 gpg: DBG: chan_5 <- ERR 67108924 Not supported <GPG Agent>
Thread-13 gpg: setting pinentry mode 'loopback' failed: Not supported
Thread-13 [GNUPG:] ERROR set_pinentry_mode 67108924
Thread-13 gpg: DBG: chan_5 -> AGENT_ID
Thread-13 gpg: DBG: chan_5 <- ERR 67109139 Unknown IPC command <GPG Agent>
Thread-13 gpg: encrypted with 2048-bit ELG key, ID 659FA047, created 2016-11-04
Thread-13 "Barbara Brown (A test user (insecure!)) <barbara.brown@beta.com>"
Thread-13 [GNUPG:] NO_SECKEY 195194AD659FA047
Thread-13 [GNUPG:] BEGIN_DECRYPTION
Thread-13 [GNUPG:] DECRYPTION_FAILED
Thread-13 gpg: decryption failed: No secret key
Thread-13 [GNUPG:] END_DECRYPTION


In the above: the MainThread invokes gpg2 and writes the passphrase, Thread-12 writes the data to be decrypted to gpg2's stdin, and Thread-13 reads gpg2's stderr.

Does the above shed any additional light on what's going on? The identical test code works fine with gpg 1.4.20.

Regards,

Vinay Sajip

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Using loopback pin entry with GnuPG 2.1 [ In reply to ]
On Fri, 4 Nov 2016 23:42, vinay_sajip@yahoo.co.uk said:

> Thread-13 gpg: DBG: chan_5 -> GETINFO version
> Thread-13 gpg: DBG: chan_5 <- D 2.1.11

That is an old version of GnuPG.

> Thread-13 gpg: DBG: chan_5 -> OPTION pinentry-mode=loopback
> Thread-13 gpg: DBG: chan_5 <- ERR 67108924 Not supported <GPG Agent>
> Thread-13 gpg: setting pinentry mode 'loopback' failed: Not supported

For that old version you need to put

allow-loopback-pinentry

into gpg-agent.conf. However, I would strongly suggest to switch to
2.1.15.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Using loopback pin entry with GnuPG 2.1 [ In reply to ]
Dear Werner,


>> Thread-13 gpg: DBG: chan_5 <- D 2.1.11

> That is an old version of GnuPG.

Yes, I mentioned the version I was using at the top of my post.

> For that old version you need to put
> allow-loopback-pinentry
> into gpg-agent.conf. However, I would strongly suggest to switch to
> 2.1.15.

As I mentioned in my post, the allow-loopback-pinentry option has already been specified in gpg-agent.conf. As to the version of GnuPG used - unfortunately, many users will have to use whatever GnuPG version is bundled with their distro, which in this case is 2.1.11. I am trying to see how I can improve support for GnuPG 2.1 for my users, many of whom typically will not have the option to upgrade to a more recent GnuPG version.

Does 2.1.11 not support loopback pinentry?

Regards,

Vinay Sajip

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Using loopback pin entry with GnuPG 2.1 [ In reply to ]
On Sat, 5 Nov 2016 11:06, vinay_sajip@yahoo.co.uk said:

> As I mentioned in my post, the allow-loopback-pinentry option has
> already been specified in gpg-agent.conf. As to the version of GnuPG

Not in the version of the agent you are running. Look at the log
message:

> Thread-13 gpg: DBG: chan_5 -> OPTION pinentry-mode=loopback
> Thread-13 gpg: DBG: chan_5 <- ERR 67108924 Not supported <GPG Agent>

and the code producing this:

else if (!strcmp (key, "pinentry-mode"))
{
int tmp = parse_pinentry_mode (value);
if (tmp == -1)
err = gpg_error (GPG_ERR_INV_VALUE);
else if (tmp == PINENTRY_MODE_LOOPBACK && !opt.allow_loopback_pinentry)
err = gpg_error (GPG_ERR_NOT_SUPPORTED);
else
ctrl->pinentry_mode = tmp;
}
[...]
else
err = gpg_error (GPG_ERR_UNKNOWN_OPTION);

Thus you will see the error "Not supported" (GPG_ERR_NOT_SUPPORTED) only
if opt.allow_loopback_pinentry (this variable is set from the conf file)
is not set. I suggest to double check your setup.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Using loopback pin entry with GnuPG 2.1 [ In reply to ]
Dear Werner,


>> As I mentioned in my post, the allow-loopback-pinentry option has
>> already been specified in gpg-agent.conf. As to the version of GnuPG

> Not in the version of the agent you are running. Look at the log
> message:


$ gpg-agent --version
gpg-agent (GnuPG) 2.1.11
libgcrypt 1.6.5
Copyright (C) 2016 Free Software Foundation, Inc.


That's the version that's running, and gpg-agent.conf is in ~/.gnupg and /home/vinay/projects/python-gnupg/keys - which seem to be the only two relevant locations.

Is the code you posted from 2.1.11, or a more recent version?

Regards,

Vinay Sajip

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel