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?

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.

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.)

Great.

FYI, the change for npth is committed.
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=npth.git;a=commitdiff;h=c2015a2bafa99fdab8f26af9b60e93f1d36ac166

The error "Ambiguous Name" is generated in "sm/certlist.c" in gpgsm_find_cert().

Arguments to this function are:

name:

"/1.2.840.113549.1.9.1=#636140756E692D6D75656E737465722E6465,CN=Zertifizierungsstelle
Universitaet Muenster - G02,O=Universitaet Muenster,C=DE"

keyid: NULL

Caller is the function inq_certificate() in "sm/call-dirmngr.c".
Argument to this function is:

line: "SENDCERT

/1.2.840.113549.1.9.1=#636140756E692D6D75656E737465722E6465,CN=Zertifizierungsstelle
Universitaet Muenster - G02,O=Universitaet Muenster,C=DE"
This is caused in function gpgsm_dirmngr_isvalid() in "sm/call-dirmngr.c" by
calling assuan_transact() with

  line: "ISVALID A52EFAEFBC86EF98C5E9AA92B3ECEC4101080F0A.1700BFBB98F74B"

When looking up the CRL, GnuPG assumes that there is only one certificate with
the Distinguished Name of the Certification Authority.
But that is not true: Distinguished Names distinguish identities, not
certificates. The same identity can hold multiple certificates at the same time.
So GnuPG must be fixed to allow multiple valid certificates with the same
Distinguished Name.
Wenn looking up a CRL, GnuPG may use any of these certificates.
My proposal: Perhaps you could implement and use a dirmngr function "SENDANYCERT"?

With 2.1.2, the bug still exists:

[/home/permail/RHEL5/devel/gpgfamily/bin/gpgsm] [--no-greeting] [--yes]
[--auto-issuer-key-retrieve] [--batch] [--no-tty] [--homedir]
[/home/p/perske/.perMail/gnupghome] [--base64] [--detach] [--local-user]
[&7CF2C58D823C0ED461ED6B1FD13F9E96B6F7C436] [--status-fd] [8] [--output]
[/index/permail/RHEL5/devel/sso/work/pgp.fe5316b600000e8a.out] [--sign]
[/index/permail/RHEL5/devel/sso/work/pgp.fe5316b600000e8a.dat]
(using a self-written pinentry replacement)

Output is now reduced, but basically unchanged:

gpgsm: Note: non-critical certificate policy not allowed
gpgsm: certificate not found: Ambiguous name
gpgsm: certificate
#1700BFBB98F74B/1.2.840.113549.1.9.1=#636140756E692D6D75656E737465722E6465,CN=Zertifizierungsstelle
Universitaet Muenster - G02,O=Universitaet Muenster,C=DE
gpgsm: checking the CRL failed: Not found
gpgsm: can't sign using '&7CF2C58D823C0ED461ED6B1FD13F9E96B6F7C436': Not found

Currently used versions:

gnupg-1.4.18.tar.bz2
gnupg-2.1.2.tar.bz2 (build process patched according to T1862)
libassuan-2.2.0.tar.bz2
libgcrypt-1.6.2.tar.bz2
libgpg-error-1.18.tar.bz2
libksba-1.3.2.tar.bz2
npth-1.1.tar.bz2
pinentry-0.9.0.tar.bz2
(my own) pinentry.c

I am using gpg-agent on a KDE system, compiled from gentoo sources on ~x64.
A couple of weeks ago it started that I get two error messages presented upon
every logon. One says an error occurred while scanning my keyring and then
presents something like that (I have used --checkdb here to recreate it on the
shell)

sm@hal9001 ~ $ gpg --check-trustdb
gpg: enabled debug flags: memstat
gpg: Oops: keyid_from_fingerprint: no pubkey
gpg: Oops: keyid_from_fingerprint: no pubkey
gpg: key 00000000 occurs more than once in the trustdb
gpg: Note: signatures using the MD5 algorithm are rejected
...

The next message says that it cannot start gpg-agent. However, when I check for
the agent then it appears to be running. Also, I seem to be able to sign mails.

The problem appears to be gpg doing something unexpected upon start.
I am using a keyring that is quite old. Been using it since the late 90s. Sadly,
this also means the trustdb is exceedingly large. --check-trustdb throws an
endless list of warnings of all kinds but the above seems to be the most severe.
I don't know if my speculations here are of any help. The warnings are like this:

gpg: public key 0BC39EB6 is 265359387 seconds newer than the signature
gpg: public key 0BC39EB6 is 263867739 seconds newer than the signature
gpg: public key 0BC39EB6 is 263867739 seconds newer than the signature
gpg: public key 0BC39EB6 is 452815208 seconds newer than the signature
gpg: public key 0BC39EB6 is 263867728 seconds newer than the signature
gpg: public key 0BC39EB6 is 263867728 seconds newer than the signature
gpg: public key 0BC39EB6 is 11229 seconds newer than the signature
gpg: public key 0BC39EB6 is 452815208 seconds newer than the signature
gpg: public key 0BC39EB6 is 452815208 seconds newer than the signature
gpg: public key 0BC39EB6 is 263867739 seconds newer than the signature
gpg: public key 0BC39EB6 is 11425 seconds newer than the signature
gpg: public key 0BC39EB6 is 11474 seconds newer than the signature
gpg: public key 0BC39EB6 is 11521 seconds newer than the signature
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: public key of ultimately trusted key 00000000 not found
gpg: public key of ultimately trusted key 87978569 not found
gpg: public key of ultimately trusted key 1F8C7C61 not found
...
and so on.

That's it! Setting

+ export LDFLAGS=-lrt

and then running the build process as described in my original report and in
msg6216, compilation is successful.

Thank you very, very much!

Thanks. No, you don't need to create another issue, since it's known simple issue.

Old system has clock_gettime function in librt. Please link with -lrt.
It would be good for npth's configure script to detect this for its build time.
I'll consider about that.

A big step forward :-)

With the command sequence

+ [... for building prerequisites see original bug report ...]
+ tar jvxf ../gnupg-2.1.2.tar.bz2
+ cd gnupg-2.1.2
+ /bin/cp -i common/Makefile.am common/Makefile.am.orig </dev/null || true
+ /bin/cp -i common/Makefile.in common/Makefile.in.orig </dev/null || true
+ s1='s|^t_jnlib_src = t-support\.c t-support\.h$|t_jnlib_src = t-support.h|'
+ s2='s|^amobjects_18 = t-support\.\$(OBJEXT)$|amobjects_18 =|'
+ /bin/sed "$s1" <common/Makefile.am.orig >common/Makefile.am
+ /bin/sed "$s1;$s2" <common/Makefile.in.orig >common/Makefile.in
+ ./configure --prefix=/PREFIX --with-gpg-error-prefix=/PREFIX
--with-npth-prefix=/PREFIX --with-libassuan-prefix=/PREFIX
--with-libgcrypt-prefix=/PREFIX --with-ksba-prefix=/PREFIX
--with-pinentry-pgm=/PREFIX/bin/pinentrywrapper
+ make

the build process fails later:

[...]
make[2]: Leaving directory `/root/devel/rpgpg/work/gnupg-2.1.2/sm'
Making all in agent
make[2]: Entering directory `/root/devel/rpgpg/work/gnupg-2.1.2/agent'
[...]
gcc -I/PREFIX/include -I/PREFIX/include -I/PREFIX/include -I/PREFIX/include -g
-O2 -Wall -Wno-pointer-sign -Wpointer-arith -o gpg-agent gpg_agent-gpg-agent.o
gpg_agent-command.o gpg_agent-command-ssh.o gpg_agent-call-pinentry.o
gpg_agent-cache.o gpg_agent-trans.o gpg_agent-findkey.o gpg_agent-pksign.o
gpg_agent-pkdecrypt.o gpg_agent-genkey.o gpg_agent-protect.o
gpg_agent-trustlist.o gpg_agent-divert-scd.o gpg_agent-cvt-openpgp.o
gpg_agent-call-scd.o gpg_agent-learncard.o ../common/libcommonpth.a
-L/PREFIX/lib -lgcrypt -lgpg-error -lassuan -L/PREFIX/lib -lgpg-error
-L/PREFIX/lib -lnpth -lpthread -L/PREFIX/lib -lgpg-error
/PREFIX/lib/libnpth.a(npth.o): In function `npth_clock_gettime':
/root/devel/rpgpg/work/npth-1.1/src/npth.c:699: undefined reference to
`clock_gettime'
collect2: ld returned 1 exit status
make[2]: * [gpg-agent] Error 1
make[2]: Leaving directory `/root/devel/rpgpg/work/gnupg-2.1.2/agent'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory `/root/devel/rpgpg/work/gnupg-2.1.2'
make: *** [all] Error 2

Shall we keep in this issue or open a new one?

I mean, when you manually edit common/Makefile.in, you need to edit the variable
am__objects_18, so that it won't include the object generated by t-support.c.

See the description of my build steps in my original report: After

+ tar jvxf ../gnupg-2.1.2.tar.bz2
+ cd gnupg-2.1.2

I manually changed both common/Makefile.am and common/Makefile.in and then
continued with

+ ./configure --prefix=/PREFIX --with-gpg-error-prefix=/PREFIX
--with-npth-prefix=/PREFIX --with-libassuan-prefix=/PREFIX
--with-libgcrypt-prefix=/PREFIX --with-ksba-prefix=/PREFIX
--with-pinentry-pgm=/PREFIX/bin/pinentrywrapper
+ make

On 04/23/2015 05:20 PM, Rainer Perske via BTS wrote:

no change: I had already tried installing from scratch working in an empty
directory.

no change: I had already tried installing from scratch working in an empty
directory.

Umm... Could you try 'make distclean', then 'configure && make'? t-support.o is
not the target to build any more by the patch,
so, it should not be linked to t-stringhelp.
When you change common/Makefile.am and common/Makefile.in, common/Makefile
should be generated again,
but it would not be generated, perhaps.

Thank you, but I regret, the patch does not change anything.
(I have made the corresponding change in common/Makefile.in, too,
with same result.)

That is not a bug but due to non-supported certificate policy constraints.

If you want to ignore them as a workaround you may modify the function
unknown_criticals which you find in
gnupg/dirmngr/validate.c and gnupg/sm/validate.c. Add to the
"known" array the strings "2.5.29.36" and "2.5.29.54".

Please try a patch:
http://lists.gnupg.org/pipermail/gnupg-devel/2015-April/029739.html

c3po: There is no need to sighup gpg-agent.
gpgconf --reload (or --kill) dirmngr is sufficent

I pushed a few commits which should solve that bug. This is the strategy:

1. gpg --keyserver-option http-proxy=HOST:PORT overrides all other
2. dirmngr --http-proxy=HOST:PORT overrides
3. envvar http_proxy but only if dirmngr's --honor-http-proxy is set

HOST:PORT
http://HOST:PORT
socks4://HOST:PORT

are valid ways to specify a proxy. I plan to add socks5h as well.

I would also like to see this.

Maybe --refresh-keys without arguments for "the entire keyring" should also ask
for a confirmation "This will leak your entire keyring to the keyserver and
possibly an attacker. Do you really want to do this? (y/N)", or "--yes".

Please see T1930. And if you have time, please
test it for PC/SC.
For GnuPG's internal CCID driver, you can use reader-port=1 for the case of a).
I don't know if partial match will be useful for internal CCID driver.

D291: 599_gpg2-scd-issue-1930-patch.diff

Thank you for your patch. I think that it is more useful.
Well, it will change the semantics of "reader-port" option slightly (exact match
to partial match).
In this case, isn't it more useful for users to allow default reader when no
match (my patch attached)?

Please let me know your name so that I can acknowledge your name as original
patch author.
Please test my patch.

Sorry. Message was "Passphrase too long" as in agent/call-pinentry.c.

2.0.26-r3 is just release 2.0.26 with some gentoo specific patches.

I'm just wondering, because the problem can be fixed if I downgrade only gnupg.
I'm not touching any other package.

What about gnupg? Is it intended for "big" passphrases? sm/minip12.c checks for
a length of 63/2 (don't know if that check has anyhting to do with the passphrase.

Do you think it makes sense to file a bug in gnome-keyring or anything similar?

I don't know version 2.0.26-r3 - it must be a modified version of your
distribution. I have also not found the string "Password too long" in any
GnuPG source.

Did you fixed gnome-keyring; which modifies gnupg at runtime? See
https://wiki.gnupg.org/GnomeKeyring

...for PGP keyservers.

This is quite obvious in the code:

  err = http_open (&http,
                   post_cb? HTTP_REQ_POST : HTTP_REQ_GET,
                   request,
                   httphost,
                   /* fixme: AUTH */ NULL,
                   httpflags,
                   /* fixme: proxy*/ NULL,
                   session,
                   NULL,
                   /*FIXME curl->srvtag*/NULL);

thanks for opening this bug.

The original reporter was on 2.1.0.

It looks like I can confirm this on 2.1.3.

Well, I commited a change to gnupg and for documentation reasons also to pinentry.

When calling pinentry with a known key (but not for PIN or during key creation)
the internal cache id is converted to a keyinfo string and send to Pinentry.
example:

  SETKEYINFO n/FD692BD59D6640A84C8422573D469F84F3B98E53

That string identifies a key. It is prefixed with a letter with a secret
meaning (actually n = normal key, s = used for ssh). Pinnetries should not
interpret the string but take it as opaque data.

It is possible to backport this to 2.0 if there is an interest in this.

I can confirm that this is resolved in 2.1.3 with .kbx files. Thanks for the fix!

Fix committed as 971d558e862db878a7310e06ed7116dbe36886ab.

I would like to see this happen. It would be great if dirmngr could make
parcimonie obsolete, for example.

(should this be "category: dirmngr" instead of just adding it as a topic?)

This will mostly be fixed in 2.1.3 however one bug still persists: You need to
enter the emprty passphrase twice. This annoys me too and it will be fixed
after 2.1.3.

Here's the lsusb output:

Bus 001 Device 002: ID 058f:9540 Alcor Micro Corp.
Device Descriptor:

bLength                18
bDescriptorType         1
bcdUSB               2.01
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0 
bDeviceProtocol         0 
bMaxPacketSize0         8
idVendor           0x058f Alcor Micro Corp.
idProduct          0x9540 
bcdDevice            1.20
iManufacturer           1 Generic
iProduct                2 EMV Smartcard Reader
iSerial                 0 
bNumConfigurations      1
Configuration Descriptor:
  bLength                 9
  bDescriptorType         2
  wTotalLength           93
  bNumInterfaces          1
  bConfigurationValue     1
  iConfiguration          0 
  bmAttributes         0xa0
    (Bus Powered)
    Remote Wakeup
  MaxPower               50mA
  Interface Descriptor:
    bLength                 9
    bDescriptorType         4
    bInterfaceNumber        0
    bAlternateSetting       0
    bNumEndpoints           3
    bInterfaceClass        11 Chip/SmartCard
    bInterfaceSubClass      0 
    bInterfaceProtocol      0 
    iInterface              0 
    ChipCard Interface Descriptor:
      bLength                54
      bDescriptorType        33
      bcdCCID              1.10  (Warning: Only accurate for version 1.0)
      nMaxSlotIndex           0
      bVoltageSupport         7  5.0V 3.0V 1.8V 
      dwProtocols             3  T=0 T=1
      dwDefaultClock       3700
      dwMaxiumumClock     12000
      bNumClockSupported      3
      dwDataRate           9946 bps
      dwMaxDataRate      688172 bps
      bNumDataRatesSupp.    138
      dwMaxIFSD             254
      dwSyncProtocols  00000007  2-wire 3-wire I2C
      dwMechanical     00000000 
      dwFeatures       000404BE
        Auto configuration based on ATR
        Auto activation on insert
        Auto voltage selection
        Auto clock change
        Auto baud rate change
        Auto PPS made by CCID
        Auto IFSD exchange
        Short and extended APDU level exchange
      dwMaxCCIDMsgLen       272
      bClassGetResponse    echo
      bClassEnvelope       echo
      wlcdLayout           none
      bPINSupport             0 
      bMaxCCIDBusySlots       1
    Endpoint Descriptor:
      bLength                 7
      bDescriptorType         5
      bEndpointAddress     0x81  EP 1 IN
      bmAttributes            3
        Transfer Type            Interrupt
        Synch Type               None
        Usage Type               Data
      wMaxPacketSize     0x0004  1x 4 bytes
      bInterval               1
    Endpoint Descriptor:
      bLength                 7
      bDescriptorType         5
      bEndpointAddress     0x02  EP 2 OUT
      bmAttributes            2
        Transfer Type            Bulk
        Synch Type               None
        Usage Type               Data
      wMaxPacketSize     0x0010  1x 16 bytes
      bInterval               0
    Endpoint Descriptor:
      bLength                 7
      bDescriptorType         5
      bEndpointAddress     0x83  EP 3 IN
      bmAttributes            2
        Transfer Type            Bulk
        Synch Type               None
        Usage Type               Data
      wMaxPacketSize     0x0010  1x 16 bytes
      bInterval               0

Binary Object Store Descriptor:

bLength                 5
bDescriptorType        15
wTotalLength           12
bNumDeviceCaps          1
USB 2.0 Extension Device Capability:
  bLength                 7
  bDescriptorType        16
  bDevCapabilityType      2
  bmAttributes   0x00000002
    Link Power Management (LPM) Supported

Device Status: 0x0000

  (Bus Powered)

For the scdaemon log, do you need it:

• with pcscd running or with GnuPG direct ccid implementation?
• in “working” condition (for example doing a gpg --card-status or gpg --sign)?
• during the “breakage” (doing a gpg --decrypt)
• in “broken” condition (after doing a gpg --decrypt).

Sorry if my report wasn't so clear. The broken behavior only appears:

• when using GnuPG ccid implementation (instead of pcscd);
• when doing a decrypt operation (maybe also an encrypt, I didn't check yet, but I'd be surprised since the smartcard hardly do any job here)

After trying a decrypt operation, the USB reader is in a non working condition, and I can only restore working condition by doing a reboot (I'v
tried to cut power to the USB bus but that doesn't seem enough).

Please give me the output of lsusb -v -d 058f:9540
and debug log of scdaemon.
Do you mean --card-status works bug --decrypt fails?

Not yet.

For a regular private key wie have such an indentifier. We don't have it for
symmetric passphrases but they are very rarely used. There is also no need to
have any cache for a smart card PIN.

The OpenPGP information as conveyed with SETDESC ist not a stable idnetification
but I think I can add something else. Not for 2.1.3 but soon after it.

Done in c238340:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=c2383407bba5eefea486464a31e02846124c9da5

This was fixed by:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=6619ead2cfd2abcb95b66dc70622fdeef624fb8a

using the test described in T1921 (aheinecke on Mar 10 2015, 06:13 PM / Roundup) there are no longer duplicated certificates
shown after the verify command.

Thanks!

I can't reproduce this problem neither in our company setup nor on a vanilla debian.

I've placed the .der files in the correct directories
/var/lib/dirmngr/extra-certs and /etc/dirmngr/trusted-certs

gpgsm --import aheinecke.der

Dirmngr output shows that the LOOKUP Issuer and Intermediate -Cert are not not
found in the dirmngr cache and they are not imported into the keyring.

This is probably another bug that hid this issue in the past.