GNUPG 0.3.2 encryption bug

[Brian Warner]

wk at isil.d.shuttle.de (Werner Koch) writes:
> Werner Koch <wk at isil.d.shuttle.de> writes:
> 
> > I think I have introduced a bug in the buffer logic - the interanl
> > buffers are 8k so ...
> 
> Okay, I found the bug.  I has to do with the new 4 byte length
> headers.  Fixed.
> 
> BTW: This might be the reason why pgp 5 can not decrypt some messages:
> The 4 byte length headers are OpenPGP but to new for pgp5 - Can
> someone please check, which version of pgp knows about it?

pgp50i looks like it doesn't understand the 4-byte length headers.
src/lib/pgp/pgpPktByte.h suggests that it understands two cases for the
length bytes of "terminating subpackets":

 length < 192:  one byte '0sssssss' or '10ssssss'
 192 <= length < 8384: two bytes '110sssss ssssssss'

src/lib/pgp/pipe/parser/pgpPrsBin.c has a comment that mentions the original
PGP packet format (1/2/4/0 bytes of length field specified by the ctb byte)
and the "one-pass PGP 3 format" with multiple non-final subpackets, each with
2^s bytes (s is [0 .. 32]) and a final subpacket with s <= 8383 bytes.  There
isn't mention of a format in which the 1/2/4(5) bytes of length are indicated
by the upper-order bits of the first length byte (which is what I believe GPG
and the OpenPGP draft use). (is it just me, or is this length representation
inspired by drugs? Use an 8-byte field and never think about it again. Ever).

pgp55pi seems to be the same way.

I don't have a copy of pgp60, but I hear that it's available in england
somewhere :).

 -Brian