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

My point is not speed of forking, but memory pressure. We have problems with
Nix package manager forking any apps, unless it uses vfork() (either
directly, or indirectly via posix_spawn).

If zombies are the only reason for double forking, there are other ways
around, e. g. ignoring SIGCHLD.

And speaking of bugs, don't we have tests? :-)

That would be a large change which for sure would introduce a lot of new bugs.
In comparison to other operations required for gpg startup the pissible speedup
between fork and vfork will be minor. In any case vfork is an ugly hack which
is not required on modern OSes with MMU. Using posix_spawn is not possible
because we do double forking.

If you have a real problem with the performance, we should first evaluate the
problem and then find a solution. Thus: Please describe the use case and why
you think that the process creation is the performance hog. GPGME has been
designed to overcome such performance problems by eventually introducing
co-porcesses so to fork gpg only once for many operations. We do this with
gpgsm already but have not yet seen an urgent need to also also change this for
gpg. However, if there is a real need for it we can do that.

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.

Old plain fork is expensive, even on Linux, maybe because of garbage
collector.

https://github.com/zalora/defnix/commit/987a49aa77be5596ec2a352c1c758bce532b
5818
https://github.com/zalora/nix-
exec/commit/ea6eb396f0fa67df6568e1bf5dada41fb70a6ca2

Can you give a reason why you need this?

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.

Can you please downgrade to libgpg-error version 1.12 and try again?
I assume that there is a conflict between Pth and the Pthread mutexes from
libgpg-error > 1.12.

You may also consider to update to GnuPG 2.1.3 which does not use Pth anymore.

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.

Please show us the version of your gpg-agent and its configuration
(~/.gnupg/gpg-agent.conf).
The version of gpg-agent is usually expected to be same one of gnupg, and the
invocation is:

/opt/freeware/bin/gpg-agent --daemon /bin/<SOMESHELL> # to invoke subshell
or
/opt/freeware/bin/gpg-agent --daemon # to be background

GnuPG invokes gpg-agent with --use-standard-socket-p to check if gpg-agent exists,
but it seems your GnuPG failed here waiting finish of gpg-agent.

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

The version of GnuPG is old. I suggest to first update to the latest gpg4win
version (2.2.4).

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

Here is error in dirmngr:

2015-04-22 09:23:41 dirmngr[3108.0] critical certificate extension 2.5.29.36 is
not supported
2015-04-22 09:23:41 dirmngr[3108.0] critical certificate extension 2.5.29.54 is
not supported
2015-04-22 09:23:41 dirmngr[3108.0] error checking validity of CRL issuer
certificate: Unsupported certificate
2015-04-22 09:23:41 dirmngr[3108.0] crl_parse_insert failed: Unsupported certificate
2015-04-22 09:23:41 dirmngr[3108.0] crl_cache_insert via DP failed: Unsupported
certificate
2015-04-22 09:23:41 dirmngr[3108.0] command 'ISVALID' failed: Unsupported
certificate
2015-04-22 09:23:41 dirmngr[3108.0] DBG: chan_0 -> ERR 167772263 Unsupported
certificate <Dirmngr>
2015-04-22 09:23:41 dirmngr[3108.0] DBG: chan_0 <- [eof]

Confirmed.
I imported Scott-Perry.p7b by gpgsm, which worked fine.
Then, invoking 'gpgsm --debug-all -r 0x085c2a5c --encrypt some.txt', it said:

gpgsm: certificate #08278A9EBB6B91E8587386AF2C312F99/CN=RAPIDGate PIV-I Agency
CA,O=Eid Passport\, Inc.,C=US
gpgsm: checking the CRL failed: Unsupported certificate
gpgsm: validation model used: shell
gpgsm: can't encrypt to '0x085c2a5c': Unsupported certificate

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.

Do you mean GnuPG doesn't detect second card change?
Currently, GnuPG doesn't support multiple readers and multiple cards.

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?

Well, it is only a warning and we should not remove the -Wstrict-prototypes
because it is in general very helpful. I suggest to use something similar to

#if JNLIB_GCC_HAVE_PUSH_PRAGMA

1. pragma GCC push_options
2. pragma GCC optimize ("no-strict-overflow")

#endif
....
pragma pop... but with the diagnostics pragmas.

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

sevan@NetBSD.org just reported that it is needed on Solaris 10, otherwise
linking libgcrypt.so fails with:

Undefined first referenced

symbol in file

__udiv_qrnnd ./.libs/libgcrypt.so

ld: fatal: symbol referencing errors. No output written to .libs/mpicalc

collect2: ld returned 1 exit status

So please apply the change after all.

Just pushed commit 9d2d8b6 which is the patch with some modification to avoid
gcc warnings. Will go into 0.9.2

Thanks.

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

This is still an issue with pinentry 0.9.1

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

I can confirm that this is resolved in 2.1.3:

0 dkg@alice:~$ gpgconf --launch dirmngr
gpgconf: error running '/usr/bin/gpg-connect-agent': exit status 1
gpgconf: error running '/usr/bin/gpg-connect-agent --dirmngr NOP': General error
1 dkg@alice:~$

the error message isn't particularly helpful at directing the user to the source
of the problem (a bad dirmngr.conf), but at least it does return a non-zero
error code.

Or, SCardControl default timeout is too short. GnuPG doesn't specify the
timeout, but uses 0x00 for bTimeOut, which means using default.
I don't know how we can change default timeout on Windows.

The error value is 0x79, which means ERROR_SEM_TIMEOUT on Windows.
It seems for me that there was another application which tried to access the
smartcard and the reader, which interfered.
Did you use solely GnuPG?

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 should be fixed in 5cde5bf. I tested building with LDAP and without. I
also ran some basic queries in the LDAP case and everything seemed ok. If I
don't hear about any further issues, I'll close this in the next few days.

LDAP has not been made a hard requirement; this is a bug.

The attached callgraph for g10/gpg2 --homedir /tmp/gnupg1 --list-sigs $keyID4

Of course it should be g10/gpg2 --homedir /tmp/gnupg2 --list-sigs $keyID4.
(/tmp/gnupg1 doesn't contain a keybox.) Sorry for the confusion.