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

You have the problem only if hidden recipients are used. With 2.1 you
may use this option:

  --try-secret-key name

    For hidden recipients GPG needs to know the keys to use for trial
    decryption.  The key set with --default-key is always tried first,
    but this is often not sufficient.  This option allows to set more
    keys to be used for trial decryption.  Although any valid user-id
    specifica- tion may be used for name it makes sense to use at
    least the long keyid to avoid ambiguities.  Note that gpg-agent
    might pop up a pinentry for a lot keys to do the trial decryption.
    If you want to stop all further trial decryption you may use
    close-window button instead of the cancel button.

This won't be backported to 2.0.

This is not a bug. You need to install a Pinentry and adjust for the changes in
2.1. Please check with ArchLinux or ask at gnupg-users.

Can you please lookup the description or the symbol for the ERRNO value 141 ?
find /usr/include -name errno.h | xargs grep 141
might reveal it.

But the secret subkeys are not used. Or well, the keyflags should be taken from
the public key. That might not always be the case - in particular not if you
re-create the public key from the secret key.

You can of course repair it using 2.1 because there --export-secret-key takes
the public key and only adds the secret parameters.

What's not clear to me if it is possible to recover a private key that is
damaged this way? If you change expiration with 1.4, the self-signatures are
lost and some key flags are changed. Is it possible to recover from that? That
is the problem I'm concerned with -- if it isn't possible to recover, it seems
people end up with damaged secret subkeys after changing expiration date on a
subkey with gnupg 1.4/2.0.

I just verified that it is not a problem in 2.1.

I am not sure whether it makes sense to fix it in 1.4 given that it is easier to
change it with 2.1, export and import it then to 1.4. I feel it is better to
use my time to fix some missing export options in 2.1

Should be fixed by commit 017c6f8fba9ae141a46084d6961ba60c4230f97a
on 2014-06-24.

Backported to 2.0: commit 2424028.

All release tags are signed.

Signed commits are a bit cumbersome becuase I would have to insert the smartcard
for all commits. Signing with my on-disk standard key would be possible, though.

Ok, I'll give it a try with 09e8f35d3808d6e49f891360c341aae3869e8650 this weekend.

Regarding https: Yes, this is more security, even though only slightly as you will have
to trust CAs. Without it, an attacker could just give you a different repo and you'd
never notice if you don't compare commit checksums with someone else. Then again, that
someone else could also get the wrong repo, because your government decided that
everybody should get a backdoor'd GPG. With https, you also need to get a valid
certificate that's in the CAs. That's not helping against a government wanting to
backdoor GPG, but it at least helps against script kiddies and the like.

Speaking about signed commits and tags: Why not do that? I tried it with git and it
works great.

Fixed with commit 071ed43. Will go into 0.9.8.

Sorry for delaying it for so long.

Works for me now. Thanks again. -> resolved.

Okay, that took long :-(: commit da4db172 - will go into 2.1.2.

    I added options shown with --help but missing in the man page.
    However, --help won't show everything listed in the man age and
    frankly there are even more options not listed anywhere (to see them
    use --dump-options).

I also kept one British translation ;-)
Thanks for the report.

s/GPG-2/PGP-2/ of course

Tt is not really corrupted. There are just GPG-2 keys at the wrong place.

Well, some keys are duplicated but I do not think that this created the test case.
The reason for the duplication might be 1.4.12 which may not include the latest
locking code.

Regarding git: An https:// access is not in any way safer - it only hides what
you are doing on the remote repo. The security from git is due to the chain of
hashes. Thus if you see a full commit id you can be sure that we are talking
about the very same code.

Right, I could have given the full commit id, but that won't help either because
you should not trust this bug tracker. The only reliabale task is by starting
from a signed commit or tag and review all code up to there.
Fortunately any tmapering with git.gnupg.org would soon trigger a lot of
complains from people pulling updates and checking commit ids.

Okay, I was able to replicate your test case with an older gpg version. I am not
sure which version that was, though. I would need to bisect to find it.

However, with the latest version (commit 09e8f35d3808d6e49f891360c341aae3869e8650)
the problem has gone.