werner: What is your call to action? Should pinentry always be shutdown or is
the status quo acceptable? Thanks.

dkg: I've now applied your backport to the 1.4 branch. Sorry for not doing this
sooner. I believe that this now completely rectifies this issue. As such, I'm
marking this issue as resolve. Thanks.

It seems this now works. In fact the code suggests that it should have detected
this condition since at least 2013 so I don't know what the actual issue was.

$ echo | gpg2 --pinentry-mode=loopback -s -a
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: setting pinentry mode 'loopback' failed: Not supported

Werner notes:

There is a comment in mainproc that we need to sort the list of keys and try
them in an order to get a decryption key early. The other thing is about the
meta data for keys. It would be possible to add a priority to the private keys
and use them to prioritise the list of keys to try.

The error has change in 2.1 to:

  gpg: secret key "foo.gpg" not found: Not found

(i.e., it doesn't say Unknown system error any more.)

The fundamental issue is that the argument to --gen-revoke is not a filename,
but a user id (e.g., the key id). I've accordingly change the error message in
46e128d as follows:

$ gpg2 --output revoke.asc --gen-revoke foo.gpg

gpg: no secret key matches the search term "foo.gpg"

gp_ast: have you gotten a chance to try this?

I'm closing this as Werner think it is a problem with Fedora and the original
reporter hasn't suggested this is not the case.

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

Fixed in eb54fca.

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

This tool has now been marked as deprecated in the documentation.

Based on Werner's comment, this issue has been addressed. As such, I'm closing
this bug report.

I now see I misunderstood the problem description.

The point is that a user has a message that is encrypted to key X. After
receiving the message, he wants to allow another key (say Y) to decrypt the
message by adding a symmetrically encrypted data packet to the message for Y,
i.e., without reencrypting the whole thing.

The reporter wasn't to specify the secret key to use. Werner indicated that
--try-secret-key does what the reporter wants in 2.1, but that this won't be
backported to 2.0. As such, I'm marking this issue as resolved.

I reviewed this issue. I've identified three issues that the reporter is
complaining about:

• Can't create a key with a passphrase (this works)
• Can't import a key that is not protected by a passphrase (this works)
• Can't export a key without protecting it with a passphrase (this is not allowed)

I also moved my mouse between screens in my multi-head setup and gpg did not crash.

I'm marking this issue as resolved.

At least with 2.1.9, it is possible to create a key without a passphrase:

$ gpg2 --gen-key
gpg (GnuPG) 2.1.10-beta132; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Note: Use "gpg2 --full-gen-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Empty
Email address: empty@testing.org
You selected this USER-ID:

    "Empty <empty@testing.org>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
Please enter the passphrase to
protect your new key
Passphrase:
Repeat:
You have not entered a passphrase - this is in general a bad idea!
Please confirm that you do not want to have any protection on your key.

Yes, protection is not needed
Enter new passphrase

[ye]? y

gpg: key BC364B3A marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, TOFU+PGP trust model
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2015-11-18
pub rsa2048/BC364B3A 2015-11-18

Key fingerprint = 6766 A52A 3E04 F09B E6F7  F80C 920C 9361 BC36 4B3A

uid [ultimate] Empty <empty@testing.org>
sub rsa2048/906F39F0 2015-11-18

It is also possible to import a secret key that doesn't have a passphrase:

$ gpg --no-options --gen-key
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:

(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)

Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 1024
Requested keysize is 1024 bits
Please specify how long the key should be valid.

   0 = key does not expire
<n>  = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years

Key is valid for? (0) 10
Key expires at Sat 28 Nov 2015 01:21:43 PM CET
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:

    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: Empty Passphrase
Email address:
Comment:
You selected this USER-ID:

    "Empty Passphrase"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.

You don't want a passphrase - this is probably a *bad* idea!
I will do it anyway. You can change your passphrase at any time,
using this program with the option "--edit-key".

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 201 more bytes)
...+++++
..+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
.............+++++
.+++++
gpg: unable to use unknown trust model (7) - assuming PGP trust model
gpg: key 4240CFD8 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: public key of ultimately trusted key BC364B3A not found
gpg: public key of ultimately trusted key 41A7057B not found
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 3 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: next trustdb check due at 2015-11-28
pub 1024R/4240CFD8 2015-11-18 [expires: 2015-11-28]

Key fingerprint = 4E0D 8EED 3567 4228 7F44  C7D7 92BE 30B6 4240 CFD8

uid Empty Passphrase
sub 1024R/D6CF583D 2015-11-18 [expires: 2015-11-28]

$ gpg --no-options --export-secret-key 4240CFD8 > 4240CFD8.sec
$ gpg2 --import 4240CFD8.sec
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 4240CFD8: public key "Empty Passphrase" imported
gpg: key 4240CFD8: secret key imported
gpg: Total number processed: 3
gpg: imported: 1
gpg: secret keys read: 3
gpg: secret keys imported: 2
gpg: 3 marginal(s) needed, 1 complete(s) needed, TOFU+PGP trust model
gpg: depth: 0 valid: 3 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: next trustdb check due at 2015-11-18
$ gpg2 -K 4240CFD8
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
sec rsa1024/4240CFD8 2015-11-18 [expires: 2015-11-28]
uid [ultimate] Empty Passphrase
ssb rsa1024/D6CF583D 2015-11-18 [expires: 2015-11-28]

I'm going to close this. The right forum to address these issues is the OpenPGP
working group.

As I understand the problem, a key appeared in multiple keyrings and this was
causing confusion. I don't think there is a bug here so I'm marking this issue
as resolved.

Fixed in 1e3dbb15.

cd2d685 fixes the assert. I don't see the utility of checking keyid (gpg will
do that). Closing.

Based on Werner's comment, I'm changing this to nobug and marking the issue as
resolved.

Based on Werner's comment, I'm marking this bug as resolved.

(At least) 2.1.9 should support version 3 (see dirmngr/ks-engine-ldap.c:492).
If this is still not working, please reopen this bug. Thanks.

Fixed in 84ebf15. Thanks!

Fixed in 84ebf15. Thanks!

This seems to work with 2.1.9. As such, I'm marking this issue as resolved.

$ gpg2 --list-options no-show-unusable-subkeys -k 4F43C989
pub rsa1024/4F43C989 2015-11-17
uid [ unknown] Testing <testing@testing.com>
sub rsa1024/3CAD33EE 2015-11-17
sub rsa1024/FE39BBA1 2015-11-17

$ gpg2 --list-options show-unusable-subkeys -k 4F43C989
pub rsa1024/4F43C989 2015-11-17
uid [ unknown] Testing <testing@testing.com>
sub rsa1024/3CAD33EE 2015-11-17
sub rsa1024/FE39BBA1 2015-11-17
sub elg1024/A10351BD 2015-11-17 [revoked: 2015-11-17]

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>

For what it is worth, this does not appear to be an issue for GnuPG 2.1.x. If
the specified home directory does not exist, GnuPG quickly fails:

$ gpg2 --homedir /tmp/gpg-temp --gen-key
gpg (GnuPG) 2.1.10-beta132; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keyblock resource '/tmp/gpg-temp/pubring.kbx': No such file or directory
Note: Use "gpg2 --full-gen-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Foo
Name must be at least 5 characters long
Real name: Foobar
Email address:
You selected this USER-ID:

    "Foobar"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: failed to create temporary file
'/tmp/gpg-temp/.#lk0x00000000017158f0.grit.10925': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: agent_genkey failed: No agent running
Key generation failed: No agent running

I just tried following the steps using gpg2 (2.1.9) and I can't reproduce the
problem. It would be good if we had an exact sequence of commands that
reproduced the problem.

Fixed in ad9befa.

Note: to reproduce:

gpg2 --no-options --no-default-keyring --keyring pubring.gpg -k

I've disabled the automatic keylisting while an import job is running in
Kleopatra as this is a good idea anyway.

Still this should be fixed although we might want to give it a try with 2.1
instead as it is no longer a hard issue for gpg4win with the workarond in kleo
in place.

The import with 2.0.29 is also very slow on Windows. Over two minutes to import
650 keys while the same import with 2.1.9 on GNU/Linux only takes 20seconds.

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

This would add a lot of complexity because some users will soon request
configurable colors and attributes as well as different output formatting.

I suggest to write a wrapper to do this or resort to one of the GUI tools.

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.

For the record Rolf Eike Beer still maintains KGpg (I was not aware of this when
i wrote T2048 (aheinecke on Aug 28 2015, 10:54 PM / Roundup))
And he is planning to port it to Qt5.
See: https://mail.kde.org/pipermail/kde-community/2015q3/001651.html

Please leave this issue closed here. This bug either belongs in the Fedora
Bugtracker or in KDE's bugtracker.

(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

Yep, that was it.

Thanks Niibe.

Sorry for your trouble. I believe that your key includes ed25519.

Once, we introduced a bug and it was fixed in 2.1.9. For a key registered by
old GnuPG by ssh-add, it should be removed and to be add again.

On 6 November, there was finally some movement on the 22 July Bug I filed at:

https://bugzilla.redhat.com/show_bug.cgi?id=1245732

Rex Dieter provided the underlying explanation of the KGpg autostart failure on
Fedora 22 (or newer) systems:

He stated:

"Simple reason is that plasma5 doesn't support kde4 apps' use of
X-KDE-Autostart-condition"

Note: Rex is also developing/testing a patch to address this plasma5
shortcoming for Fed 22 systems.

Importantly, and as I had suspected and alluded to, this plasma5 lack of support
explains why the KGpp failure to autostart occured *only* on my Fed 22 systems,
and did not impact any of the other KDE operating systems I use.

I have upgraded all my Fed 22 systems to Fed 23, where the KGpg autostart
currently continues to persist. I have documented the workaround in the Bug
report linked above for anyone impacted. This workaround also works in Fed 23.

Hopefully, this issue will be fully resolved in the next Fedora-approved release
of KGpg.

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

This seems to still be a problem:

$ gpg2 --keyserver hkp://keyring.debian.org --search-keys dkg
gpg: error searching keyserver: No data
gpg: keyserver search failed: No data

This bug report is very old and 2.0.17 is no longer supported. The right way
forward is to rerun the test suite with the latest version on a modern OS.
However, I expect that if these failures were still a problem, we'd have heard
about them. As such, I'm closing this bug.