Comitted in a958ffd.

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.

Fixed in 6897bbf.

$ gpg2 --multifile --sign --encrypt-files /tmp/foo /tmp/bar
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: --sign --encrypt does not yet work with --multifile

Committed in de9b234.

Committed in e16d716.

I tried running:

  echo | gpg -s -a

in two terminal. In the first terminal, I got a pinentry prompt (I'm using
pinentry-tty) and in the second, gpg2 appeared to freeze. Once I entered my
passphrase correctly in the first terminal, the first gpg2 process split out the
signed message and less than a second later, the second did as well.

The code also suggests that this is fixed (agent/findkey.c)

      /* If the pinentry is currently in use, we wait up to 60 seconds
         for it to close and check the cache again.  This solves a common
         situation where several requests for unprotecting a key have
         been made but the user is still entering the passphrase for
         the first request.  Because all requests to agent_askpin are
         serialized they would then pop up one after the other to
         request the passphrase - despite that the user has already
         entered it and is then available in the cache.  This
         implementation is not race free but in the worst case the
         user has to enter the passphrase only once more. */

Interestingly, this comment is from 2006 (commit: df52700f), which predates this
bug report.

As such, I'm changing this bug's status to needs-eg. Perhaps Werner can shed
some more light on this issue.

I've confirmed that this is still a problem.

We don't ship gtksecmementry any more so that is definitely no longer relevant.
Closing.

Current URL was reported in 1495. Closing this issue and leaving that one open.

Duplicate of T1495

This is still the case.

This now works. Closing.

This is still the case.

This support request appears to be resolved. Closing.

This support request appears to have been resolved. Closing.

This bug is still relevant: there are no links for any of the 2.1.x releases,
for instance.

GtkSecureEntry has been removed from pinentry.

As far as I can tell, http://gnupg.org/documentation/manpage.en.html is no
longer linked from
http://gnupg.org/documentation/guides.en.html. Closing.

I'm assuming that this issue was resolved since Eric didn't reply.

The attached patch builds on the patch in #806. It provides a
--encrypt-to-default-key. One could imagine adding an
--hidden-encrypt-to-default-key as well. Werner: is this acceptable?

D44: 706_0001-gpg-Add-encrypt-to-default-key.patch

I implemented this as follows: it is possible to specify --default-key multiple
times. The last specified key for which a secret key is available is taken. If
multiple such keys are available, the others are simply ignored. The patch is a
bit noisy, because we need to pass the ctrl structure around. But, I've tested
it as follows:

  gpg2 -a -s --default-key 58859975EE37CF96 --default-key 58859975EE37CF95

and it correctly takes the 96 key, which is available (95 is not).

Werner: thoughts?

D43: 705_0001-gpg-Allow-multiple-default-key-options.-Take-the-las.patch

Fix in ea99f88.

According to Kristian, there are currently two main keyservers.

The most widely used keyserver is SKS. It's homepage is here:
https://bitbucket.org/skskeyserver/sks-keyserver/overview

A new keyserver being developed in go is hockeypuck:
https://github.com/hockeypuck/hockeypuck

Werner: Is adding these under https://www.gnupg.org/related_software/tools.html
appropriate?

Really closing.

The new URL is now also an old URL.

I've implemented a new db format. It's still incomplete and experimental, but
it's available from the neal/next branch. Importing
/usr/share/keyrings/debian-keyring.gpg, which contains 751 keys is much faster
using this format:

$ rm pubring.kdb; time gpg2 --no-default-keyring --primary-keyring
gnupg-kdb:pubring.kdb --import debian-keyring.gpg >/dev/null
gpg: Total number processed: 751
gpg: imported: 751

real 0m7.729s
user 0m5.404s
sys 0m0.332s
$ rm pubring.kdx; time gpg2 --no-default-keyring --primary-keyring
gnupg-kbx:pubring.kdx --import debian-keyring.gpg >/dev/null
gpg: Total number processed: 751
gpg: imported: 751
gpg: public key of ultimately trusted key 2183839A not found
gpg: public key of ultimately trusted key BC15C85A not found
gpg: public key of ultimately trusted key EE37CF96 not found

real 1m52.560s
user 0m6.268s
sys 0m31.604s

Running --check-trustdb is almost an order of magnitude faster:

$ time gpg2 --no-default-keyring --primary-keyring gnupg-kdb:pubring.kdb
--check-trustdb
real 0m0.158s
user 0m0.004s
sys 0m0.004s
$ time gpg2 --no-default-keyring --primary-keyring gnupg-kbx:pubring.kbx
--check-trustdb
real 0m0.975s
user 0m0.012s
sys 0m0.032s

Doing a sequential read is a bit slower:

$ time gpg2 --no-default-keyring --primary-keyring gnupg-kdb:pubring.kdb -k |
grep ^pub | wc -l
751

real 0m2.515s
user 0m2.432s
sys 0m0.088s
$ time gpg2 --no-default-keyring --primary-keyring gnupg-kbx:pubring.kdx -k |
grep ^pub | wc -l
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!
751

real 0m1.245s
user 0m1.168s
sys 0m0.076s

This is because the interface for doing a full scan of the DB is unsuitable. If
we decide to use the new format, it shouldn't be hard to improve this.

I'd be interested in any feedback and perhaps some more measurements in real
conditions.

Thanks,

Neal

We don't maintain a PHP wrapper. I'd recommend that you report this problem to
the maintainers of that package. When doing so, you'll probably want to include
the public key that you are trying to import and indicate what version of GnuPG
and the GnuPG PHP wrapper that you have installed.

ciil: Thanks for the update!

All of the pinentry's use the same metric, which is very naive. From
agent/call-pinentry.c:

/* Estimate the quality of the passphrase PW and return a value in the

range 0..100.  */

static int
estimate_passphrase_quality (const char *pw)
{

  int goodlength = opt.min_passphrase_len + opt.min_passphrase_len/3;
  int length;
  const char *s;

  if (goodlength < 1)
    return 0;

  for (length = 0, s = pw; *s; s++)
    if (!spacep (s))
      length ++;

  if (length > goodlength)
    return 100;
  return ((length*10) / goodlength)*10;

}

Kristian Fiskerstrand pointed out that there is more information about this bug
at: https://bugs.gentoo.org/show_bug.cgi?id=560158

Based on aheinecke's comments I'm closing this.

Applied in 60bc5186.

D325: 675_0001-cache-test.patch

I've attached a patched that demonstrates the problem. This uses a single
keyring. Here is the output using the cache consistency fix:

  $ gpg2
  : keydb_search: preparing cache
  : keydb_search: preparing cache
  : keydb_get_keyblock: enter (cache state: 1).
  : keydb_get_keyblock: filling cache.
  : keydb_get_keyblock: enter (cache state: 1).
  : keydb_get_keyblock: filling cache.
  : desc1: Werner Koch (ha ha test) <wk@gnupg.org>
  : desc2: Werner Koch <wk@g10code.com>
  : Looks good.

And here is the output when the patch is not applied:

  $ gpg2
  : keydb_search: preparing cache
  : keydb_search: preparing cache
  : keydb_get_keyblock: enter (cache state: 1).
  : keydb_get_keyblock: filling cache.
  : keydb_get_keyblock: enter (cache state: 2).
  : keydb_get_keyblock: returning data from cache.
  : desc1: Werner Koch <wk@g10code.com>
  : desc2: Werner Koch <wk@g10code.com>
  : Same name (fail)!

As you can see, the second time keydb_get_block is called, it sees a filled
cache and simply returns the contents. However, the contents are for a
different search. I hope you now agree that fixing this bug is not really
problematic, that the problem has nothing to do with multiple keyrings and this
bug doesn't relate to the 15 year old discussion.

Just to be clear: this bug has nothing to do with multiple keyrings; it will
continue to occur even if we decide to use just a single keyring. The problem
has to do with multiple handles.

Why do you think fixing this is problematic? My simple patch ensures cache
consistency. What's the problem with it?

D326: 672_0001-g10-Make-the-keyblock-cache-per-handle-rather-than-g.patch

agent/findkey.c:unprotect (for instance) imposes a password limit of 99 bytes
(pi->max_length = 100). I've raised this limit to 255 bytes in commit 348a6eb.
I'd appreciate it if you could test this and confirm that this fix is
sufficient. Note: we are not going to raise the limit about 256 bytes.

If you can't manage to fit 128-bits of entropy in 256 bytes, then you need to
fix your passphrase generation scheme.