Importing the attached OpenPGP certificate with 2.1.12 results in:
gpg: Ohhhh jeeee: Can't encode length=294 in a 2 byte header!
AbortedThis also happens when imported from the keyservers with:
gpg --keyserver keys.gnupg.net --recv 0x109B5B0BEDAB644E
The certificate is importable (and exportable) with gnupg 1.4, though.
it seems like this might be related to T2307, except that it involves no
secret key material.
I don't know the reason, but User ID length is hardcoded.
diff --git a/g10/build-packet.c b/g10/build-packet.c
index 4bfc2ac..1353a86 100644
+++ b/g10/build-packet.c
@@ -329,7 +329,7 @@ do_user_id( IOBUF out, int ctb, PKT_user_id *uid )
}
else
{+ write_header2( out, ctb, uid->len, 0 );
rc = iobuf_write( out, uid->name, uid->len ); } return rc;
We need to look at the history of the patch which introduced the stricter
checks. The problem we have is that some packets are indeed malformed but must
be exported/re-packaged exactly in their original broekn format.
FWIW, I added the stricter check. Previously, we specified the header size, but
didn't check that it was respected. When discussing this with Werner, he said
that respecting the header size was important, which is why I chose to die
rather than silently change the header size.
fwiw, i first encountered this by doing a full-keyring refresh from the
keyservers. Dying rather than adjusting or accomodating the malformed header
meant that all keys after this one failed to refresh.
In general, dying outright seems likely to make an observed problem worse than
it needs to be.
The check what Neal introduced is somehow orthogonal to the change of mine.
The key in question, there is a User ID packet of length >= 256 (because he
include ssh key string in his User ID).
In the code of build-packet.c, gpg assumed the length of User ID is < 256 and it
is hard coded to have header length 2.
With the check (in gpg 2.1), it causes an error. I think that, in gpg 1.4 and
2.0, gpg creates malformed packet with incorrect length (LSB of the length).
In 1.4 and 2.0, --import just copies the block, so the bug doesn't hit. In 2.1,
when it tries to write to keybox, the bug hits.
It was fixed in db1ecc8212defdd183abbb6b1407fcc8d2dc9552 for 2.1.
In 2.1, HDRLEN=0 for all callers, so, there will be no same "Ohhhh jeeee" any more.
In 1.4 and 2.0, HDRLEN is used as a hint. There is no need to change 1.4 and
2.0. Detail is described in:
https://lists.gnupg.org/pipermail/gnupg-devel/2016-June/031178.html