How much time would it take to migrate to QT5?

Thanks, fixed in 2.1.2. (I had to run --edit-key and --check-trustdb first.)

Can you please try with 2.1.2 ?

Fixed with commit 0c3d764.
Should be backported to 1.4.

We already have that "confirm" flag for ssh and thus adding code to use it for
the extra-socket feature should be easy. The open question is how to disable
this feature on a per key base. A ~/.gnupg/confirmcontrol or similar file could
be used to record those keys which do not need confirmation or if persistance is
not required a checkbox in pinentry could be used to show the confirmation
dialog only once per session.

D283: 555_0001-dirmngr-Clean-up-spawned-dirmngr_ldap-processes.patch

This problem is due to ldap_wrapper creating processes with gnupg_spawn_process
but while gnupg_spawn_process states that you have to call gnupg_wait_process
and gnupg_release_process afterwards this is not done in the ldap_wrapper.

Sometimes release is called but never wait to get the exit status of the spawned
process and remove the zombie.

If release is not called this will also leak a handle on Windows.

Attached Patch moves the process cleanup in it's own function and calls that
function from where the process should be terminated and cleaned up.

My test for this:
export GNUPGHOME=$(mktemp -d)
echo "11:B9:1B:31:EE:09:E0:84:4D:25:4E:58:7A:65:CE:51:84:F3:6B:70 S" >
$GNUPGHOME/trustlist.txt
gpgsm --verify signed-smime-test.asc

D284: 554_avoid-crash-with-zero-length-DIR.txt

Here is a screen shot of the error message.

Here is a screen shot of the certificate chain.

Back ported to 2.0 (commit 2b2adb85948ce2c7db727ebc0c99e8ad2c29bf5f)

To reproduce using version 2.0.26 (on Windows):

1. Set your keyserver to something invalid (ie. put the following line in your

gpg.conf, without any other keyserver entries:

keyserver hkp://invalid.gnupg.net

2. Try to retrieve the key 82058954 (from john doe) from the server: gpg --recv-keys 82058954

This should report that no key has been found. What it *should* report is that
there was a communication problem with the servier.

3. Revert to a vali keyserver destination in your gpg.conf

keyserver hkp://keys.gnupg.net

4. Perform the recv operation again, it should successfully load the key gpg --recv-keys 82058954

5. Reset your server to an invali value and perform the following operation: gpg --send-keys 82058954

The application will with the message that it is sending the key to
invalid.gnupg.net, wnen in fact it is not

Good point. I added your suggestion to master.

This will eventually be done but not right now. I keep this bug report as a
reminder.

I granted you permissions to edit other bug reports. However, this patch is not
required.

I just changed the remaining http references to gnupg.org to https (on master).
Thanks.
Changing them in coments and in the outdated FAQ does not make sense.

Nope. See my comments at
https://lists.gnupg.org/pipermail/gnupg-users/2015-February/052401.html

master (2.1) already has limits for such cases and would thus return better
error message. Those will be backported to 1.4 and 2.0. However, for 2.1 your
test case does not work because PGP-2 formats are not anymore supported in 2.1.

I can't repeat that with the current version from the GIT repositories. Can you
please give an example best using --recv-key.

Thanks for the new test vector. This has already been fixed in master and those
fixes will be ported back to 2.0 and 1.4.

In general I would suggest to use at least the latest released version or even
better the respective GIT HEAD for fuzzing work.

D282: 546_0001-Use-https-for-links-in-documentation.patch

Here is the latter half of the output of --card-status in it's entirety...

The URL is listed, as for the signature key, that is the crux of the
problem... it shouldn't care about what the fingerprint of the signature key
when retrieving the public key when the signature key is a subkey as you
can't retrieve just the public key of the subkey, you need to retrieve the
public key of the master key that contains that subkey.

Note below how key 757C0180 is the master key and in the error message in
the op it is looking for AEB99527 which is the signing subkey.

Name of cardholder: John Tennyson
Language prefs ...: en
Sex ..............: male
URL of public key :
https://gist.githubusercontent.com/aelana/0cde322d66206ea5fb90/raw/1cc31e99f
bdb5a75e4104fe597794ec3dccd6bc4/gistfile1.txt
Login data .......: elfindreams
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: 85D5 A0DA 4EC2 B038 128F 9D88 4791 2162 AEB9 9527

created ....: 2015-02-03 21:18:19

Encryption key....: 3AD4 1BA6 47B9 1AA3 89CD C29E A6CF 5D5D CADC 0F35

created ....: 2015-02-03 21:18:48

Authentication key: D61E 29B6 9784 15A9 CEFE 08F4 6AD2 1E6C C40C A003

created ....: 2015-02-03 21:19:08

General key info..: pub 2048R/AEB99527 2015-02-03 Elvish Wanderer
<aelana@elfindreams.com>
sec# 4096R/757C0180 created: 2015-02-03 expires: 2015-11-30
ssb> 2048R/AEB99527 created: 2015-02-03 expires: 2015-11-30

card-no: 0006 03362156

ssb> 2048R/CADC0F35 created: 2015-02-03 expires: 2015-11-30

card-no: 0006 03362156

ssb> 2048R/C40CA003 created: 2015-02-03 expires: 2015-11-30

card-no: 0006 03362156

What did you put into the URL field of your card and what is the first
fingerprint:

gpg --card-status | grep ^URL
gpg --card-status | grep '^Signature key'

Fixed with commit d8eea25

Fixed for 2.1 with 382ba4b.Should be backported to 2.0 and 1.4.

Jason Donenfeld has a patch for this:

http://thread.gmane.org/gmane.comp.encryption.gpg.devel/19654