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

I use several key of near all types: ed25519, rsa, dsa, ecdsa. All of them have
stopped working.

Duplicate of T2096

Are you using an Ed25519 key? There was a regression in 2.1.8 which has
meanwhile be fixed in the repo. See also T2096.

Solution (c) will be used for 2.1.8.

Won't fix in 1.4 because that version is mostly useful on old systems and those
don't have proper utf-8 supoort anyway.

Originally dirmngr was a system wide daemon. Thus a limit made a lot of sense
so that users could not oincrease the memory usage of dirmngr. As a user daemon
this is not too problematic anymore but (in contrast to GNU policy), having
limits is still good to avoid DoS. The packet parser also employs certain
limits, like 2K for a user ID or 16M for an attribute packet.

I assume keyservers also have some limit - or at least they should have one to
help against misuse as cheap storage provider. What about using this limit?

can you explain why the limit is useful? e.g. does it increase efficiency in
some metric? defend against certain classes of attack? something else? sorry
that i don't understand the tradeoff fully.

a runtime configuration would be better than a hard fail, but in either case it
seems like we're asking the user to fiddle with things that they shouldn't have
to think about or understand. is there a way that we can automatically detect
the reason for the failure and make things Just Work for normal users without
opening up the tooling to more problems?

To clarify werners comment. The revert is part of the 2.0 branch. I've
confoirmed the fix works so -> resolved) But awaiting a package / downstream
deployment.
The default for 2.0 won't be changed away from SHA-1.

This will be part of the next gpg4win release.

(Btw. Good to see you here sandro ;-) )

The limit set by dirmngr is in general useful. Shall we make the limit
configurable at runtime?

Oh well, the hang is indeed a libassuan bug. The assuan_inquire fucntion
stopped reading as soon as a supplied limit was reached and returned to the
caller. The caller (dirmngr), printed an error and sends back an ERR line.
Hwoever, the client kept on sending the remaining lines and thus messed uo the
protocol.

Just fixed it in libassuan (5a52404) by reading up the extra lines before
returing from assuan_inquire.

Re-assigning to gnupg. libassuan works correctly, afaics.
When trying to send back Zack's key I had the same problem last week and
increased the limit in dirmngr (84f4c8811fc5bdd78693c4dc289389a8337cc257).
I also mentioned that in a comment to another Debian bug report.

However, their should not be a hang but a proper error diagnostic; it is on my list.

with 2.1.7, i see no hang, but i do see failure with certain large certificates,
like 0xB27B944E34884E85:

0 dkg@alice:~$ gpg2 --send 0xB27B944E34884E85
gpg: sending key 0xB27B944E34884E85 to hkps server hkps.pool.sks-keyservers.net
gpg: keyserver send failed: Too much data for IPC layer
gpg: keyserver send failed: Too much data for IPC layer
2 dkg@alice:~$

maybe the boundary is 500KiB? I don't have this problem with my own OpenPGP cert:

0 dkg@alice:~$ gpg2 --export 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 | wc

3126   11384  481051

0 dkg@alice:~$ gpg2 --export 0xB27B944E34884E85 | wc

4310   13779  541937

0 dkg@alice:~$

This is a regression in 2.0.28. The fix is
commit 35d3ced4fda90a5410a579850ca92ea6a356b402
which reverts to use SHA-1 for a CSR.

It works fine in 2.1 but backporting the changes is not planned.

i prefer solution (c): we should assume utf8, if we are going to assume anything
at all.

if the user doesn't provide UTF8 *and* doesn't have the proper locale set, then
we should exit with a meaningful message.

that way, things break for people that don't have a properly configured locale
*and* try to input non-UTF8 as opposed to just fail if locale is *not
configured*, which is a pretty common scenario.

hm, common/utf8conv.c says this:

  /* Note that we silently assume that plain ASCII is actually meant
     as Latin-1.  This makes sense because many Unix system don't have
     their locale set up properly and thus would get annoying error
     messages and we have to handle all the "bug" reports. Latin-1 has
     always been the character set used for 8 bit characters on Unix
     systems. */

I wonder if this is still the best choice. In my experience, far more machines
have text in some UTF-8 encoding today than in Latin-1. this is especially true
for systems that deal with OpenPGP User IDs, where UTF-8 is the canonical
representation.

If the user's environment claims that it's plain ASCII and we're seeing 8-bit
characters, gpg does have to make a decision about what to do. i see four options:

a) report an error and fail.

b) pretend that the 8-bit characters are Latin-1 (this is "OK" because any
bytestring is a valid Latin-1 string)

c) pretend that the 8-bit characters are UTF-8

d) do some sort of autodetection on the bytestring (e.g. if it is a valid UTF-8
byte sequence then treat as UTF-8, otherwise treat as Latin-1)

option (a) is annoying and likely a cause of spurious complaints, as the comment
notes. GnuPG is currently going with option (b). Option (c) seems more
reasonable to me because of OpenPGP's relationship with UTF-8, but introduces
some error cases (what do we do where the bytestring is not valid UTF-8?).
Option (d) avoids error cases but might be a bit more delicate to implement.

What do you think?

I think werner means --utf8-strings instead of --utf-strings.

I did a couple of tests but I do not understand what is going on.
There is also an older key of Antoine 231A87628530E205 which encodes
his name in Latin-1 (wrong charset during creation or PGP was used).

Using

  gpg -vvv ....

shows the character set used by gpg. Maybe this gives some insights.
If you know that the command line is UTF-8 you may use the option
--utf-strings to avoid any conversion.

FWIW, gpg uses LC_ALL, LC_LANG, LANG in that order to determine the
locale. Antoine's original report shows

  Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)

and thus UTF-8 should be used due do LC_CTYPE. gpg converts command
line arguments back and forth as needed but passes them as utf-8 to
the keyserver (which is the reason that the "searching for =..."
message renders it differently.

Hi Brian,

I tried it in PuTTY without screen and it was not skewed. The line draw
characters looked funny (which I'm assuming is a Unicode thing), but they
were in a rectangle.

bjmgeek: ping

Done with commit 25331bb for 2.1.5.
Won't be backported to 2.0 or 1.4.

This also changes the publication date to the date of the last commit for one of
the texi files. This was the original intention of the version.texi file but
that did not worked in a git world.

Won't be done for 2.0 but I will try to implement that for 2.1

I've now applied the patch.

ah, right! the other option is to pass mb->size instead of size in the memset call.

We should really synchronize secmem.c between libgcrypt:src/secmem.c,
pinentry:secmem/secmem.c, and gpg-STABLE-BRANCH-1-4:util/secmem.c :/

D305: 627_0001-secmem-When-clearing-memory-don-t-clear-beyond-the-e.patch

Well, that's embarrassing. It looks like it was my bug. The attached patch
seems to fix the problem.

I've been debugging this issue for about an hour and I tentatively came to the
same conclusion.

OK, something is definitely wrong with the secmem allocators.

I applied this patch:

diff --git a/secmem/secmem.c b/secmem/secmem.c
index 9a478cf..bf97a2a 100644

• a/secmem/secmem.c

+++ b/secmem/secmem.c
@@ -381,11 +381,16 @@ secmem_realloc( void *p, size_t newsize )

mb = (MEMBLOCK*)((char*)p - ((size_t) &((MEMBLOCK*)0)->u.aligned.c));
size = mb->size;

+ printf("A: %d\n", mb->size);

    if( newsize < size )
	return p; /* it is easier not to shrink the memory */

+ printf("B: %d\n", mb->size);

a = secmem_malloc( newsize );

+ printf("C: %d\n", mb->size);

memcpy(a, p, size);

+ printf("D: %d\n", mb->size);

memset((char*)a+size, 0, newsize-size);

+ printf("E: %d\n", mb->size);

secmem_free(p);
return a;

}

and ran pinentry-gtk-2 with "getpin" as an input and typed in 32 characters for
the dialog box. at character 16, it printed:

A: 32
B: 32
C: 32
D: 32
E: 32

and at character 32 it printed:

A: 0
B: 0
C: 0
D: 0
E: 0

I'm beginning to suspect that this allocator never worked quite right, and that
1d3583a2562e83496ac515276e9bd63a7f1abbc7 just exposes a flaw in the addressing.

Tracking this down further, it appears to be caused by
1d3583a2562e83496ac515276e9bd63a7f1abbc7.

If i revert that commit, the problem goes away.

This makes me think something is wrong with secmem_realloc or secmem_malloc.

OK, I'll try that too.