Is that still a problem with the latest Pinentry (0.9.1 or 0.9.2)?

Probably, T1936 will a duplicate of this issue.
Create a new issue so I could not comment on the issue...

D299: 603_bug494740.patch

Fixed in master with commit 64e809b Will go into 2.1.4.

Missed to explain that this does not happen when using gnupg 2.0.* and this occured
on Windows. I did not try this on *nix.

So maybe there is another correct way to say user that he must type passphrase?
It is need for QCA gnupg plugin. qca-gnupg plugins uses pipes to send/recieve
data with gpg. It was many time ago when I tried to fix problem. So now I can't
remember particularity problem. Seems it was gpg2 related.

I wrote this in my QCA TODO

• New plugin qca-gpgme to replace current qca-gnupg. qca-gnupg requires to have gpg binary which can be any 1.4.x or 2.x. Them behaviour is different. gpg2 requires gpg-agent to ask user for passphrase. No correct way to check that key requires passphrase.

Although the output timing of NEED_PASSPHRASE is different (than your

expectation), it is emitted after gpg reads passphrase string and it needs the
passphrase for signing.

It is nonsense. In this case status is such log file. Such behaviour is no
obviously and documentation says nothing about ths.
And user can't know must or no he provides passphrase.

2.0.12 is very old (close to 6 years). Please try to replicate that with a
current version (best would be 2.0.27). We also need to know your OS.

I checked the code and the behavior. It is confirmed that the default of
gpg-agent disables loopback-pinentry mode and user needs to enable it.

Now, we need some fixes/improvements:
(1) gpg should automatically work with gpg-agent with the option of --passphrase
(-file, -fd).
In GnuPG 2.1.x, the secret keys are under control of gpg-agent and gpg frontend
should pass the passphrase to gpg-agent in some way.
When --passphrase (-file, -fd) option is supplied, gpg frontend could use
gpg-agent feature of either loopback-pinentry mode _OR_ preset_passphrase .
The latter requires specific key identification, so, loopback-pinentry mode
would be the solution for general.
(2) Both of loopback-pinentry mode and preset_passphrase are disabled as
default. We need to fix this default of gpg-agent _AND_ we need to fix gpg
frontend error handling of this case of disabled feature of gpg-agent. Well, I
don't know the reason this features need to be disabled...
(3) When it is gpg frontend which invokes gpg-agent, it would be natural to
enable loopback-pinentry (or preset_passphrase). But, there will be existing
gpg-agent even with --batch option. I don't know how it should work in this case.

Thanks for your further experiment. I didn't read well about the part of
'mkfifo' in your first message.
I think that you expect some interactive behavior; gpg emits NEED_PASSPHRASE
when its needed, and your program writes to the fifo.

No, gpg doesn't work like that with --passphrase-file or --passphrase-fd.
gpg will read the passphrase string from a file or an fd at the start.

Although the output timing of NEED_PASSPHRASE is different (than your
expectation), it is emitted after gpg reads passphrase string and it needs the
passphrase for signing.

I just now tested it on my Fedora 20 with gpg 1.4.19 and 2.0.27. I tried to use
--no-use-agent no password request again.

Background information:

With GnuPG 2.1, my webmailer does no longer work.

In principle, I use the following procedure e. g. for signing an e-mail:

1. My GnuPG 2.0 is compiled with the option

--with-pinentry-pgm=/path/to/pinentrywrapper

2. The user enters text and passphrase into the HTML form.

3. I encrypt the passphrase with symmetric cryptography

4. I set the environment variable PINENTRY_USER_DATA to the encrypted password

(see also T799)

5. I set the environment variable GPG_TTY to "PINENTRY/pinentry-permail"

6. I also set the environment variables HOME and GNUPGHOME.

7. I launch /path/to/gpg-agent --daemon --sh --no-allow-mark-trusted

8. I parse the output GPG_AGENT_INFO=/path/to/socket:process_number:version_number

9. Then I sign, encrypt, decrypt, verify or whatever the user wants by
   • putting GPG_AGENT_INFO and all other needed variables into the environment
   • starting /path/to/gpgsm with all needed options for the respective transaction

10. Then gpgsm contacts the just started gpg-agent which calls my

/path/to/pinentrywrapper which detects the "magic" GPG_TTY setting and does not
try to start a dialog on the (non-existent) terminal or desktop, but simply
responds with the decrypted content of PINENTRY_USER_DATA whenever a passphrase
input is requested.

11. Finally I kill the gpg-agent using the process_number extracted above.

This procedure does no longer work with GnuPG 2.1 because I cannot start a new
agent for every transaction: gpg-agent of 2.1 uses the default socket, not a new
one, and does not write its process_number into GPG_AGENT_INFO, and, most
important, gpgsm disregards GPG_AGENT_INFO so that I cannot tell gpgsm which
running gpg-agent to contact. (There can be multiple transactions at the same
time; I trust in gpg-agent to properly lock files where necessary.)

As long as there is no way of passing the entered passphrase from my webmailer
to gpg-agent in any other way than by writing it into the environment when
starting gpg-agent and using a special pinentry that reads this environment, I
have to start a new gpg-agent for every transaction because different
transactions may need different passphrases.

That, of course, is only an ugly, ugly circumvention of a limitation of gpgsm.

gpg2 knows options --pinentry-mode loopback --passphrase-fd file_number, and
gpg-agent offers all support for using these options. Only gpgsm does not
support it.

If gpgsm would also offer these options, the whole hack with a magic GPG_TTY,
with the encrypted PINENTRY_USER_DATA, with using a pinentry wrapper, and with
using special options when compiling GnuPG 2.0 would be completely unnecessary.

So please please please copy the code that implements --pinentry-mode loopback
--passphrase-fd file_number from gpg2 to gpgsm.

Thank you very much!

It seems that the gpg-agent needs to be started with --allow-loopback-pinentry
for this to work.
Because I let gpg autostart the daemon for me, this does not get passed to
gpg-agent and therefore does not work when setting --pinentry-mode=loopback in gpg.

I don't know what is to do here.
Should gpg with --pinentry-mode=loopback autostart the gpg-agent with
--allow-loopback-pinentry ?
Or should I just add some documentation to the manpages to describe what is
necessary for --pinentry-mode=loopback and --passphrase-file to work?

It doesn't reproducible for me with 2.0.26 in Debian.
For 1.4, you need --no-use-agent when you have use-agent option in your
configuration.

It seems that your gpg-agent doesn't support loopback mode.
Either, your gpg-agent is from 2.0 or the socket is hijacked by gnome-keyring.
For the latter, please see http://wiki.gnupg.org/GnomeKeyring

It can be specified by scdaemon's option. Now in 2.0.x and 2.1.x, it does
partial match for PC/SC.
So, this issue is now closed.

It's fixed in 2.0.18 (as the T1203 was closed).

Confirmed that this is fixed in GnuPG in 2.0.25. In the external reference (the
bugzilla at RedHat), it's also closed already.
In the SCM (http://pkgs.fedoraproject.org/cgit/gnupg2.git), it's
1f6281e091d124170238821e7b9150ab56ff1195 which
removed the patch.

In 1.6.3, libgcrypt now work with automake >= 1.14.

See the commit: c123e313e90a6ffb14c9be3ddaab3ad44a44f2b6

The patch is a work for problem somewhere in the PC/SC implementaion. I am also
not sure whether a pthread_cancel for a buggy PC/SC library is a good idea.
Terminating the process seems to be a better solution.

If gpgtools wants to apply this pacth, they might of course do so but I don't
want to apply it upstream in particular not to an older version (2.1 is current).

Hi Werner,

I am running Fedora 20 and here is some information regarding the the installed
packages

Name : gnupg
Arch : x86_64
Version : 1.4.19
Release : 2.fc20

Name : openldap
Arch : x86_64
Version : 2.4.39
Release : 4.fc20

I didn't compile any of them from source. I downgraded gnupg but for some reason
it went to 1.4.15

Name : gnupg
Arch : x86_64
Version : 1.4.15
Release : 1.fc20

This version works without a problem. Then upgrading again causes the problem to
come back.

Regarding the ldap setup, I followed the approach given in

http://justinmattock.blogspot.com/2013/03/openldap-gpg-keyserver-private.html

Please let me know if you need any further information.

Thanks

D298: 602_pcsc-wrapper.patch

Note that when using the --export option you are asked whether you want to add
another signature. This can be used as a workaround until the problem has been
fixed.

dkg and Neal fixed a couple of things recently. @neal: I think supporting C-W
in curses would a good idea.

That would require to send this string to all pinentries.

We need a bit more information. What OS, how has 1.4.19 been build (attach
config.h) and what LDAP server you are using. Can you replicate the same after
downgrading to 1.4.18?

I changed that to a feature but I agree that the subkey selection mechanism
should take smartcards into account.

It would be surpising that suddendly a different subkey will be used for signing
if a smartcard is not available. Right, most users with several subkeys are
experts and know what they are going but nevertheless this is a change in behaviour.

Fixed in:

commit 189ab07e94dc2d4103c1edf00e15e0156df89297
Author: Neal H. Walfield <neal@gnu.org>
Date: Fri May 1 20:35:59 2015 +0200

When reading the pin, correctly handle backspace.

* tty/pinentry-tty.c (read_password): Handle backspace.

--

When I try the following under gnupg 2.1.3 with arch linux:

$ gpg --homedir <gpg-dir> --batch --pinentry-mode=loopback --passphrase-file
<passfile> --decrypt myfile.gpg

I get the following error:

gpg: setting pinentry mode 'loopback' failed: Not supported
...
gpg: decryption failed: No secret key

Is the gnupg version of arch just missing some compile-time flag to support
--passphrase-file without manual pinentry? If this is the case, I could report
this back to the arch maintainer to get it fixed downstream.
Or is there still some work to be done on gnupg?

I think this needs to be a bit clearer:

In pinentry-tty.c:confirm, only the "ok" button's text is shown and it is
suffixed by a fixed string: "[y/N]", which should be internationalized.

In GnuPG 2.1.x, secret key is under control of gpg-agent. You can use
--pinentry-mode=loopback.
But, I think that --batch should imply --pinentry-mode=loopback.

I propose to implement a partly solution as a start: Add a 4th parameter
"allow_ambiguous" to gpgsm_find_cert() in "sm/certlist.c".

When called from "sm/gpgsm.c" or "sm/server.c" or anywhere else, set this
parameter to 0. Then gpgsm_find_cert() will behave like before.

When called by inq_certificate() in "sm/call-dirmngr.c", set this parameter to

1. Then gpgsm_find_cert() will not bail out an ambiguous certificates, but

return the newest one of the matching certificates (according to
validity.notBefore).

(I am not sure what to pass when called by run_command_inq_cb() in
"sm/call-dirmngr.c" because I did not yet understand in which situation this
callback is used.)

As far as I can see, this change never hurts, but it helps when there are
multiple certificates for intermediate CAs with identical subject and identical
key by allowing to use "gpgsm" without "--disable-crl-checs --disable-dirmngr".

See attached patch.

(A complete solution probably requires call-dirmngr to return all matching
certificates and dirmngr to try each of the returned certificates in a loop.)

D199: 601_gnupg.diff

I confirmed that it's in 2.0.x, too.
My patch is here:
http://lists.gnupg.org/pipermail/gnupg-devel/2015-April/029752.html

Thank you for the reproducible case.
This would be the cause my key becoming too big in someone's keyring.
I'm going to investigate in detail, for 1.4.x and 2.0.x.

Sorry, I don't understand why you have a ENOMEM problem there. You are using
Linux and thus you have copy-on-write which should not lead to such problem.
Right there are some corner cases but I doubt that they kick in here.

What kind garbage collector are you using? Can you check with the guix folks
whether they have a similar problem? IIRC, Guile also uses gpgme

You can't use SIGCHLD in a library.

Great. Thanks for your work!
(With these fixes, I am now able to test whether T1644 is solved in 2.1.2,
unfortunately it is not.)