There are a couple of ideas on how to use mail for key retrieval. We won't be
able to implement them for 2.2 but we should consider this for 2.3.

There won't be any changes for 1.4, though.

I pushed Ueno's patches for gpgme. In particular
dee56820cabde60c43c9bf8281b8d411cb2ad644

Oops; forgot to add the fix to 1.7.0

Fixed in the repo (commit 536c721)

gpg-agent does disable core dumps both in the stable and modern version.
Furthermore I have to agree with Werner here, if there is a process that can
ptrace your gpg-agent, then you have already lost anyway.

GnuPG 2.1.11 will print PROGRESS lines which allows in connection with
--exit-on-status-write-error to use that correctly. We should add that option
to gpg invocation of gpgme, though.

This was implemented for 2.1. We won't backport it to 1.4 or 2.0.

Sorry, I can't see any problem here.

The "priotr-old" key is actually the newer key because an expiration date was
added to that copy of the key (2012-07-09) and that key has meanwhile expired.
Thus you can't encrypt using this key.

When you import the "piotr" key that is actually the same key but w/o the update
with the expiration date. Thus gpg does not chnage the exiting in key because
the existing key has a newer self-signature (where the expiration date is
stored) than the new key. So nothing changes, which is correct.

If you delete the .gnupg directory you don't have the newer key and by importing
the key w/o the expiration date you can encrypt to that key.

Same behaviour with gpg-2.1.10 (Arch), libgcrypt 1.6.4.

1.4.12 is heavily outdated (from 2012). Please update to 1.4.20 or at least
1.4.19 and check again.

As I am not sure how to attach files to this report I have uploaded them here:
http://www.elstel.org/uploads/gnupg/

Err, fixed in 6ac57a48.

Fixed in

FWIW, with commit 19545e3a from 2015-09-09 I had bumped the limit up to 20MiB.
This should solve all current practical problems.

As an additional point, the client max body size in nginx defaults to 1 MiB[0].
Currently no checking is done for larger request bodies for inclusion in the
keyserver pools. Apache does not have such a limit by default.

Reference:
[0] http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

Kristian Fiskerstrand told me that the SKS keyservers currently have a 5 MB
limit for parsing incoming header, pre-merge.

It looks like this problem has been fixed in the meantime. As such, I'm marking
this bug as resolved. Thanks.

$ gpg2 --with-fingerprint 4F43C989.txt
pub rsa1024/4F43C989 2015-11-17

Key fingerprint = A8D8 E9B9 D25D 6AB8 9997  AEE4 3817 872D 4F43 C989

uid Testing <testing@testing.com>
sub rsa1024/3CAD33EE 2015-11-17
sub rsa1024/FE39BBA1 2015-11-17
sub elg1024/A10351BD 2015-11-17
$ gpg2 --fingerprint 4F43C989
pub rsa1024/4F43C989 2015-11-17

Key fingerprint = A8D8 E9B9 D25D 6AB8 9997  AEE4 3817 872D 4F43 C989

uid [ unknown] Testing <testing@testing.com>
sub rsa1024/3CAD33EE 2015-11-17
sub rsa1024/FE39BBA1 2015-11-17
sub elg1024/A10351BD 2015-11-17

I've fixed this with commit 0b86c74 by making it possible to select keys using
the key id. Consider:

gpg> key 4BFA08E4

pub rsa4096/D21739E9

created: 2007-06-02  expires: 2016-01-21  usage: SC  
validity: unknown

sub rsa4096/21484CFF

created: 2007-06-02  expired: 2015-02-26  usage: E

sub* rsa2048/4BFA08E4

created: 2008-06-19  expires: 2016-01-21  usage: A

sub rsa4096/1BFDFA5C

created: 2013-03-12  expires: 2016-01-21  usage: S

sub rsa2432/0CA757FB

created: 2013-09-11  expires: 2016-09-14  usage:

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

sub rsa4096/14D5DA70

created: 2015-01-21  expires: 2016-01-21  usage: E

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

[ unknown] (1). Daniel Kahn Gillmor <dkg@fifthhorseman.net>
[ unknown] (2) Daniel Kahn Gillmor <dkg@openflows.com>
[ revoked] (3) Daniel Kahn Gillmor <dkg@astro.columbia.edu>
[ revoked] (4) Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net>
[ unknown] (5) [jpeg image of size 3515]
[ unknown] (6) Daniel Kahn Gillmor <dkg@debian.org>
[ unknown] (7) Daniel Kahn Gillmor <dkg@aclu.org>

Oops. I used a plain old keyring and not a keybox. However the effect is the same.

That should go into the keylisting. Here is a listing of a revoked
key:

  pub   dsa1024/269E78D84738350A 1999-08-16 [revoked: 2011-02-15]
        Key fingerprint = 72A2 A242 8623 84A9 5910  C454 269E 78D8 4738 350A
        Keygrip = 2BBB5EF3D036022DD66EF4386680C194352A2EC2
  uid                 [ revoked] Florian Lohoff <flo@[...]>
  uid                 [ revoked] Florian Lohoff <flo@[...]>
  uid                 [ revoked] Florian Lohoff <flor[...]>

Another line after the Keygrip line could show key revocation
information. To show user id revocations a list option is anyway
required:

  $ gpg --list-options show-unusable-uids  \
     --with-fingerprint  --with-keygrip -k 6C7EE1B8621CC013
  pub   dsa1024/6C7EE1B8621CC013 1998-07-07 [expired: 2004-12-31]
        Key fingerprint = ECAF 7590 EB34 43B5 C7CF  3ACB 6C7E E1B8 621C C013
        Keygrip = E3003A38C3CCB63DFB39998A6C8A78EB9498E42A
  uid                 [ expired] Werner Koch <wk@gnupg.org>
  uid                 [ expired] Werner Koch <werner.koch@guug.de>
  uid                 [ expired] Werner Koch <wk@[...].com>
  uid                 [ revoked] Werner Koch <wk@openit.de>

A similar formatted revocation reason could be shown after the revoked
user id. It would be best to indent that to align with the [revoked]
string.

And of course we also need to come up with a --with-colon format for
both cases.

Iff we do this it should only go into 2.1 thus I changed the Version field.

My problem was a different one. Here is what I wrote to gnupg-devel:

$ ../g10/gpg2 -vsbau 0xE3FDFF218E45B72B </etc/motd >/dev/null

[...]

gpg: Error: the key specification '0xE3FDFF218E45B72B' is ambiguous.

gpg: (check argument of option '--local-user')

gpg: error reading key block for '0xE3FDFF218E45B72B': Unknown system error.

gpg: Error: the key specification '1E42B367' is ambiguous.

gpg: (check argument of option '--encrypt-to')

gpg: error reading key block for '1E42B367': Unknown system error.

gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a

fingerprint.

gpg: Error: the key specification '1E42B367' is ambiguous.
gpg: (check argument of option '--default-key')
gpg: error reading key block for '1E42B367': Unknown system error.
gpg: writing to stdout
gpg: EDDSA/SHA256 signature from: "E3FDFF218E45B72B Werner Koch (wheatstone

commit signing)"

  wk@wheatstone:~/b/gnupg/tmp$ echo $?
  2

Note that I have only specified a short key id because this is pretty
common and gpg prints only a warning. Okay.

The real problem is that there are several error messages - one is
sufficient to let gpg exit with a failure and git won't continue. There
are 2 different kinds of errors:

  gpg: Error: the key specification '0xE3FDFF218E45B72B' is ambiguous.

This is the keyid I specified on the command line. Let's check it:

$ ../g10/gpg2 -k 0xE3FDFF218E45B72B

[...]

gpg: Error: the key specification '1E42B367' is ambiguous.

gpg: (check argument of option '--encrypt-to')

gpg: error reading key block for '1E42B367': Unknown system error.

gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a

fingerprint.

  gpg: Error: the key specification '1E42B367' is ambiguous.
  gpg: (check argument of option '--default-key')
  gpg: error reading key block for '1E42B367': Unknown system error.
  gpg: please do a --check-trustdb
  pub   ed25519/E3FDFF218E45B72B 2015-02-18 [expires: 2025-02-15]
  uid                 [ultimate] Werner Koch (wheatstone commit signing)

(and -k shows the same result).
What is the ambiguity here?

The other two error messages are identical one for --encrypt-to and one
for --default-key:

  gpg: Error: the key specification '1E42B367' is ambiguous.

Let's check it:

$ ../g10/gpg2 -k 1E42B367

[...]

gpg: Error: the key specification '1E42B367' is ambiguous.

gpg: (check argument of option '--encrypt-to')

gpg: error reading key block for '1E42B367': Unknown system error.

gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a

fingerprint.

  gpg: Error: the key specification '1E42B367' is ambiguous.
  gpg: (check argument of option '--default-key')
  gpg: error reading key block for '1E42B367': Unknown system error.
  gpg: please do a --check-trustdb
  pub   dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31]
  uid                 [ unknown] Werner Koch <wk@gnupg.org>
  uid                 [ unknown] Werner Koch <wk@g10code.com>
  uid                 [ unknown] Werner Koch <werner@eifzilla.de>
  sub   dsa1024/4F0540D577F95F95 2011-11-02
  sub   rsa2048/1E0FE11D664D7444 2014-01-02 [expires: 2016-12-31]

Also not ambiguous.

So this new feature break existing installations. This is a complaint
as mentioned in T1128 (wk on Nov 06 2015, 10:57 AM / Roundup). Not due to performance but due to severe
breakage. This needs a lot more testing before we can release it.

I've fixed the problem that Niibe reported in 7546e81.

(commit e8c53fc was for master)

This introduces a regression. I had to revert this commit to be able to keep on
using gpg in my configuration. A description of the problem can be found at:
https://lists.gnupg.org/pipermail/gnupg-devel/2015-November/030549.html

In 2.1, these options are supported. They are not support in 1.4, but they are
in 1.4's manual.

Added the option --only-sign-text-ids in 28e1982

Fix in f99830b.

Where should this output be displayed? When doing gpg2 -K, revoked user ids are
not shown. Perhaps in --edit-key? Nevertheless, it would be nice to have a
command line option to get this information directly.

Checked in (e8c53fc).

With 'wait' I mean: Push, release, wait for complaints.

log_error (_("no such key corresponding to: %s\n"),t->d)
if (!opt.quiet)

  log_info ("(check argument of option '%s')\n", option);

However, we need to check all error messages to make sure they use a common
scheme. For example at some places we use

key 123445567: This is is not usable

• When you say let's wait, what do you mean? In particular, how are we going to

get a user response without checking the code in?

• Ok. I will return an error code.

• I already do this, e.g.:

log_error (_("no such key corresponding to %s (passed to %s)\n"),

t->d, option);

Some comments:

• Always checking this _might_ slow down things. Let's wait for user response.

• Please do not die in that function. We may want to use it a other places too (server mode). Better return an error (NULL) and let the caller decide what to do.

• The strings should be changed to ease translation: For example put the second part into its own message: log_info ("(check argument of option '%s')\n", "--local-user");

D106: 719_0001-gpg-Check-for-ambiguous-or-non-matching-key-specs.patch

The following patch adds checks for --default-key, --local-user and --remote-user.

Check that any user id specifications passed to --local-user
and --remote-user correspond to exactly 1 user. Check that any user
id specifications passed to --default-key correspond to at most 1
user. Warn if any user id specifications passed to --local-user or
--default-user are possible ambiguous (are not specified by long keyid
or fingerprint).

$ gpg2 -s -a -r testing
gpg: WARNING: recipients (-r) given without using public key encryption
gpg: Error: the key specification 'testing' is ambiguous (passed to --encrypt-to).
gpg: 'testing' matches at least: 362D3527F53AAD1971AAFDE658859975EE37CF96 and
439D954F18F79CC4F71BED91CACED996BC15C85A.
$ gpg2 -s -a --local-user testing
gpg: Warning: value 'testing' for --local-user should be a long keyid or a
fingerprint.
gpg: Error: the key specification 'testing' is ambiguous (passed to --local-user).
gpg: 'testing' matches at least: 362D3527F53AAD1971AAFDE658859975EE37CF96 and
439D954F18F79CC4F71BED91CACED996BC15C85A.
$ gpg2 -s -a --default-key testing
gpg: Warning: value 'testing' for --default-key should be a long keyid or a
fingerprint.
gpg: Error: the key specification 'testing' is ambiguous (passed to --default-key).
gpg: 'testing' matches at least: 362D3527F53AAD1971AAFDE658859975EE37CF96 and
439D954F18F79CC4F71BED91CACED996BC15C85A.

Committed (ec409e6).

Fix in cd2d685.

Verifying the unwrapped data also works:

$ gpg2 --decrypt --unwrap /tmp/a > /tmp/b
Please enter the passphrase to unlock the OpenPGP secret key:
"Testing (insecure!)"
1024-bit RSA key, ID 6EA74366,
created 2015-09-18 (main key ID EE37CF96).

Passphrase:
gpg: encrypted with 1024-bit RSA key, ID 6EA74366, created 2015-09-18

"Testing (insecure!)"

$ gpg2 --verify /tmp/b
gpg: Signature made Wed 04 Nov 2015 01:53:31 PM CET using RSA key ID EE37CF96
gpg: Good signature from "Testing (insecure!)" [full]
gpg: Verified 7 messages signed by "Testing (insecure!)" (key: 362D 3527 F53A
AD19 71AA FDE6 5885 9975 EE37 CF96, policy: good) in the past 1 day, 20 hours.
The most recent message was verified 22 hours, 40 minutes ago.

D89: 708_0002-gpg-Add-support-for-unwrapping-the-outer-level-of-en.patch

D90: 707_0001-common-Add-a-function-for-copying-data-from-one-iobu.patch

This implements the requested --unwrap feature. It strips the first level of
encryption and then dumps the data.

$ gpg2 --decrypt --unwrap /tmp/a | gpg2 --list-packets
Please enter the passphrase to unlock the OpenPGP secret key:
"Testing (insecure!)"
1024-bit RSA key, ID 6EA74366,
created 2015-09-18 (main key ID EE37CF96).

Passphrase:
gpg: encrypted with 1024-bit RSA key, ID 6EA74366, created 2015-09-18

"Testing (insecure!)"

off=0 ctb=a3 tag=8 hlen=1 plen=0 indeterminate

:compressed packet: algo=2

off=2 ctb=90 tag=4 hlen=2 plen=13

:onepass_sig packet: keyid 58859975EE37CF96
version 3, sigclass 0x00, digest 8, pubkey 1, last=1

off=17 ctb=cb tag=11 hlen=2 plen=13 new-ctb

:literal data packet:
mode b (62), created 1446641593, name="",
raw data: 7 bytes

off=32 ctb=88 tag=2 hlen=2 plen=156

:signature packet: algo 1, keyid 58859975EE37CF96
version 4, created 1446641611, md5len 0, sigclass 0x00
digest algo 8, begin of digest b7 8a
hashed subpkt 2 len 4 (sig created 2015-11-04)
subpkt 16 len 8 (issuer key ID 58859975EE37CF96)
data: [1023 bits]

Based on Werner's response, I believe that the underlying issue is resolved.
Thus, I'm going to close this.

Removing and readding key helped. Thanks. Seems to be solved in 2.1.9

Please remove your private key(s) of ed25519 and register it again.

Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798956#24

The same issue in 2.1.9

For no pinentry pop-up, I think that this is same cause described in the Issue 2112.
Please try the patch in T2112