[From nobody Thu Jul 16 16:20:07 2009
Received: (at submit) by bugs.debian.org; 28 Apr 2003 20:27:32 +0000
Return-path: <willy@www.linux.org.uk>
Received: from parcelfarce.linux.theplanet.co.uk (www.linux.org.uk)
	[195.92.249.252] 
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 19AFDm-0005G2-00; Mon, 28 Apr 2003 15:27:31 -0500
Received: from willy by www.linux.org.uk with local (Exim 4.14)
	id 19AFDk-0000Lf-VO
	for submit@bugs.debian.org; Mon, 28 Apr 2003 21:27:28 +0100
Date: Mon, 28 Apr 2003 21:27:28 +0100
From: Matthew Wilcox <willy@debian.org>
To: submit@bugs.debian.org
Subject: interoperability problem with pgp 2.6.3i
Message-ID: <20030428202728.GD22762@parcelfarce.linux.theplanet.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Sender: <willy@www.linux.org.uk>
Delivered-To: submit@bugs.debian.org
X-Spam-Status: No, hits=-12.3 required=4.0
	tests=BAYES_10,HAS_PACKAGE,USER_AGENT_MUTT
	autolearn=ham version=2.53
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp)


Package: gnupg
Version: 1.2.1-2
Severity: minor

PGP 2.6.3i has some stupid bugs where it doesn't check the type encoded
in the packet tag but checks the value of the byte directly.  For example:

#define CTB_CERT_PUBKEY CTB_BYTE(CTB_CERT_PUBKEY_TYPE,1)
        /* CTB_CERT_PUBKEY len16 timestamp userID mpi(n) mpi(e) crc16 */

and so it only accepts pubkey with 16-bit lengths.  gnupg is generating
a pubkey with 8-bit lengths in some circumstances.

It might be the case that this isn't relevant; I'm investigating adding
support for v4 keys to the pgp 2.6 codebase and it's a v4 key that's
using an 8-bit length.  Maybe gnupg is more careful when encoding a v3 key.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

]