You can implemnnt something like this using 2.1 and the --extra-socket feature.
Give the extra socket appropriate permissions/ACLs

FWIW, 2.1.4 will also bring a

gpg --quick-adduid USER_ID NEW_USER_ID

I close this bug because the new features won't be backported to 1.4 or 2.0.

All updated in the meantime.

Actually "make distcheck" does such a check and thus I wonder how this can
aheppn. Well (make distcheck and me) we are always doint out-of-source builds
so this might be the reason.

This bug report is quite old and a lot of code has been improved. Thus please
re-open it if it persists with 2.1.3.

This won't happen in 2.1 anymore. We can't do much about it in 1.4. sorry.

Thanks.

Can you please try with the latest version (2.1.4 will be released tomorrow)

When updating a key gpg uses the keyring where it was found in the first place
and only this. Thus it is better to have only one copy.

I am not sure whether this patch is the best for all platforms.

For now I install a fix that detects INT32_MAX and returns 256 then. May it be
that AIX does not use a fixed size structure? In this case it would be usable
to know whether there is a way to get information on the highest fd currently in
use.

This report was for which version of GnuPG?

Implement that for export.

1793 has been fixed thus we can close this.

May I assume this problem has been fixed?

(BTW, I sign my commits now)

Please try 2.1.3 or the soon to be released 2.1.4

I have fixed it for the gca functions percent and percent+ but won't do it in
the generic percent_exacpe C function. Changing the latter may introduce
regressions.

Fixed for 2.0 and 2.1.

You need to use --pem:

  dirmngr-client -v --pem ~/tmp/google.pem

There is no auto-detection in dirmngr-client. If you think this is useful
please change Priority to "feature " and adjust the title.

We fixed some things related to this in 2.1.3.
(2.1.4 will be released tomorrow)

This looks more like a problem with the way that versionnhas been build in
Fedora. I suggest to take this problem to Fedora or the gnupg-users mailing list.

Okay that can be done. It won't be in 2.1., though.

During deployment of gnupg 2.1.3 this bug was still noticed and I can still
reproduce it with git master. -> back to chatting

I must have messed up the test in T1921 (aheinecke on Apr 08 2015, 04:36 PM / Roundup). Probably by using a different
sysconfig dir for that test. Apologies for that.

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.

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.

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

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.

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.