On sparc64, powerpc64, and s390x (debian's three 64-bit big-endian
platforms), gpg is unable to create a new OpenPGP certificate from some
secret keys that it already knows about.
In particular, "gpg --batch --generate" from a Key-Grip: line that
refers to a key file in private-keys-v1.d/ that contains a comment
sublist will fail with "Invalid S-expression" on those platforms.
This is due to a buggy invocation of gcry_sexp_build_array that is only
tickled when int is smaller than size_t and the platform is big-endian,
which causes the comment string to be set to zero length, which itself
is interpreted as an error of GPG_ERR_SEXP_ZERO_PREFIX.
However, this failure causes necessary functionality for
"monkeysphere-host import-key" as of monkeysphere version 0.43-3 to
break on these platforms, making monkeysphere FTBFS because the failure
is caught by its test suite.
The attached patch resolves the issue when i test it on
zelenka.debian.org (s390x), and should also work on the other two
From e4a158faacd67e15e87183fb48e8bd0cc70f90a8 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <[hidden email]>
Date: Tue, 14 May 2019 00:05:42 -0400
Subject: [PATCH] agent: correct length for uri and comment on 64-bit
* agent/findkey.c (agent_public_key_from_file): pass size_t as int to
This is only a problem on big-endian systems where size_t is not the
same size as an int. It was causing failures on debian's s390x,
powerpc64, and sparc64 platforms.
There may well be other failures with %b on those platforms in the
codebase, and it probably needs an audit.
Once you have a key in private-keys-v1.d/$KEYGRIP.key with a comment
or a uri of reasonable length associated with it, this fix can be
gpg-agent --server <<<"READKEY $KEYGRIP"
On the failing platforms, the printed comment will be of length 0.
Bug#928963: [pkg-gnupg-maint] Bug#928963: fixed in gnupg2 2.2.13-2
On Sat 2019-06-22 20:51:00 +0200, Paul Gevers wrote:
> On Tue, 14 May 2019 06:18:31 +0000 Daniel Kahn Gillmor
> <[hidden email]> wrote:
>> gnupg2 (2.2.13-2) unstable; urgency=medium
>> * Correct gpg-wks-server manpage (Closes: #927431) Thanks, ju xor!
>> * Fix handling private keys with comments (Closes: #928963, #928964)
>> * clean up logcheck rules for gpg-agent (Closes: #918466)
>> * Update gpg-wks-client.1 (Closes: #918586)
>> * cherry-pick more patches from upstream STABLE-BRANCH-2-2
> Is there any reason that we shouldn't want to unblock this for buster
> (i.e. is there any reason why you didn't file an unblock bug request)?
Filing an unblock for gnupg2 version 2.2.13-2 for buster is on my stack
of things to do, but i'm quite far behind on other work. I do think it
would be useful to have, and i welcome any help in filing such an
This change includes several upstream cleanup changes beyond the
2.2.12-1 that is in buster right now, in particular (from upstream's
* gpg: Implement key lookup via keygrip (using the & prefix).
* gpg: Allow generating Ed25519 key from existing key.
* gpg: Emit an ERROR status line if no key was found with -k.
* gpg: Stop early when trying to create a primary Elgamal key. [#4329]
* gpgsm: Print the card's key algorithms along with their keygrips
in interactive key generation.
* agent: Clear bogus pinentry cache in the error case. [#4348]
* scd: Support "acknowledge button" feature.
* scd: Fix for USB INTERRUPT transfer. [#4308]
* wks: Do no use compression for the the encrypted challenge and
Since the gnupg2 source produces a udeb for gpgv, there are likely to be
additional hurdles to clearing the queue. :/