Given that 2.1 will remove the helpers, I doubt that it makes sense to
put a lot of work into a new detection feature. What do you think of
this change:

• a/configure.ac

+++ b/configure.ac
@@ -157,8 +157,9 @@ if test -z "$GPG"; then
fi

dnl Find the keyserver plugins. Assume that gpgkeys_ldap is always available
-AC_PATH_PROG(GPGKEYS_LDAP, gpgkeys_ldap, [${libexecdir}/gnupg/gpgkeys_ldap],

• [$PATH:/usr/libexec/gnupg/:/usr/lib/gnupg/])

+AC_PATH_PROGS(GPGKEYS_LDAP, gpg2keys_ldap gpgkeys_ldap,
+ [${libexecdir}/gnupg/gpg2keys_ldap],
+ [$PATH:/usr/libexec/gnupg:/usr/lib/gnupg2:/usr/lib/gnupg])
KEYSERVER_HELPERS_DIR=dirname $GPGKEYS_LDAP
if test -z "$KEYSERVER_HELPERS_DIR"; then

        AC_MSG_ERROR([[

That is we check for gpg2keys_ldap first and also put the Debian
directory into the PATH.

Done. Thanks.

Right. Commit e7aeaeb.

I have another work item for gpgme and plan to do a new release next week.

In general I don't like pkg-config because it adds an extra dependecy above the
required libraries and introduces other problems. However, for GPA we already
have lot of dependencies and thus I would accept a patch.

My fix is for gpa (44b6bdf6) and gpgme (9f081da7).

It would be possible to do fix this only in GPA but the fix in gpgme makes gpgme
also more robust.

Applied to master (fb738b2). Thanks.

D155: 350_fix_segfault_filehandler.patch

Doesn't occur in 0.9.2. Closing as 'resolved' myself.

I will stay prepared for any testing or debugging that might be requested by
anyone of you guys (but it might take a week, as the reader belongs to someone
else), such a warning could have saved lots of time for each one of us.

And, only for your files, I made a mistake in the first E-Mail I wrote Ludovic:
It's not a Cherry ST-1044U, but a Cherry XX44 smartcard reader (ST-1044U seems
to be the USB-Descriptor)

Ludovic noticed that this reader does not support extended APDUs (Log says
"Short APDU level exchange"). Thus there is no way to use this reader for 2k keys.

He also suggested to print a warning for such readers. That is a good idea.

That is the same error as in your first report. It is either a
problem of the reader or of pcscd. Please stop pcscd and try with the
internal driver.

Ludovic: Using an extend APDU with a 3 byte Lc is not strange - even
if the value of Lc is only 2. This is Case 4E in 7816-4.

We need to use an extended APDU because we need to specify the
expected return length Le as larger than 256. We use 2048 here
(0x0800) because that is the maximum length of response data for this
specific card. Although we don't expect a 2048 byte response, we
expect one that is larger than 256 and thus we need to request an
Extended Length APDU. The 2048 is required for other commands and
thus the reader need to support it anyway.

The debug-output of scdaemon can be found here:

http://pastebin.kruton.de/21/src

And I do have write permission on the device.

The CMD 0x47 is an ISO7816-8 command (Generate keypair). I suggest to enable
debugging in scdaemon: Put this into ~/.gnupg/scdaemon.conf

log-file /foo/bar/mylog
debug 1024
debug 2048
debug-ccid-driver

kill scdaemon and try again. It is possible that the reader fails due to the
genrate key command. Another option is a problem in pcscd. Stop pcscd, make
sure you have write permissions to the reader's device under /dev/bus/usb, and
tru again. This will use scdaemons internal driver.

We need some more information. You ,ay want to start gpg thi way:

  gpg -v --debug 1024 --gen-key

Has the agent been started? Try

  gpg-connect-agent 'getinfo version' /bye

If gpg still fails, the easiest way to track it down is by running it under a
debugger, or check the core file. Also try GnuPG 2.0.19 which have fixed the
problem

It seems that my patch does actually break gcc... i'm not sure how to handle
this correctly anyway. It seems that the problem is actually unsolvable, and
there's no correct way to mix inline functions and external assembly definitions.

D154: 346_0001-Fix-use-of-inline-to-avoid-multiple-declarations.patch

Hello Werner.

Do you need more information, or you can confirm and reproduce bug with given
description?

Sure, a "make clean" will delete the keyring and thus you see a message:
“imported" - if you run it a second time you see “not changed". That is all okay.

But please tell us the info I requested.

The first time I did run the test, the armor.test.log file was as
follows:

linux is a bit unspecific. Debian, Suse, Fedora, Ubuntu, Genttoo, Arch ?
I also need to see the log file - if you hesitate to post it to this BTS, feel
free to send it by PM to me (wk@gnupg.org) - Not HTML parts, you may want to
_gzip_ the log file.

On Tue, 2012-05-08 at 14:47 +0000, Werner Koch via BTS wrote:

Werner Koch <wk@gnupg.org> added the comment:

What OS and what shell are you using? Please also attach the file armor.test.log.

What OS and what shell are you using? Please also attach the file armor.test.log.

I assume you meant audit-codes.h and status-codes.h.
Right they were listed under CLEANFILES; which is wrong. I am currently fixing
this. Thanks.

That seems to be an old Outlook version without proper MIME support (OL 2000?).
For OL2003 please make sure to install the latest service pack.

Fixed in master will go into 1.3.2. Thanks.

Fixed. Will eventually go into 1.4.13.

By the way, --quiet does suppress other stderr messages, at least this one:

"gpg: keyring `/home/blah/.gnupgtmp/pubring.gpg' created"

Is it just me, or are both of my messages truncated to a single line?!

This is in no way specific to Kleopatra (the KDE certificate manager), gpgsm --

KDE's Kontact has been developed along with GnuPG, thus I wonder why you have
this problem. Can you please explain the problem a bit more detailed?

D153: 344_gnupg-2.0.18-protect-tool-env.patch

Would be great to have included if 2.1 is the ecc release.

I would love to just have 1 agent for everything.

There is no ECC support for the agent, yet. The ssh protocol is different from
the OpenPGP Protocol. It should be easy to add support, though.

Make sure that you paste a complete message. Use the command line if in doubt.
This is very likely a user error; ask on gnupg-users at gnupg.org for help

I'm using Linux Mint 12 Lisa, and I've tested on built-in 1.4.11 and on custom
built latest revision in repository - d64aa7.

1. I've created key with Primary key (P0), and 3 subkeys (S1, S2, S3). Export

this key for further tests.

2. Change expiration date of first subkey (S1). Everything seems OK.
3. Export whole key, remove it from gpg, import again - Everything is OK.
4. Back to step 2 - remove key, import original one.
5. Change expiration date of second or third subkey (S2, S3). Everything seems

OK again.

7. Export whole key, remove it from gpg, import again - we've missed S1 subkey,

and expiration date of changed subkey left as in step 1.

I've analyzed changes on each step via gpgsplit. My conclusion: GPG always edit
S1 subkey signature. Editing non-first subkey (S2, S3, S4…) edits (breaks) S1
signature. S2¸ S3… signatures leaved unchanged. GPG checks subkey signature
only at import. User doesn't know about subkeys breakage until he reexport it.

Please explain in detail (step by step), what you did. What OS are you using?
Thanks.

Done for master (f1e1387).