[BUG] "--rfc1991" + "-t" = faulty packet header
dshaw at jabberwocky.com
Wed Mar 3 12:20:26 CET 2004
On Fri, Feb 27, 2004 at 09:18:56PM +0100, abognupg at redtenbacher.de wrote:
> In GnuPG 1.2.4, the combining of the options "--rfc1991" (use old
> style packet headers) and "-t" (textmode) produces faulty packets.
> This can be easily verified by a command like:
> gpg --rfc1991 -t -z 0 -o mail.lit --store mail.txt
> The resulting (uncompressed) packet can be visually inspected and
> shows that after the packet tag byte (CHR(175) = old style packet with
> tag type "11" [literal packet] and length-type "3" [indeterminate
> length]) there are 2 length bytes before the "t"/"b" format byte,
> which should not be there according to RFC 2440, section 4.2.1. In
> addition, at the end of the packet, there are 2 CHR(0)'s that should
> not be there, either.
Believe it or not, that's not a bug. It is a piece of backwards
compatibility dating from a pre-RFC2440 GnuPG. A very old version of
GnuPG used a special encoding scheme for indeterminate length packets.
This is no longer used, and the backwards compatibility code will not
be present in GnuPG 1.4.
> This bug has no effect when "--pgp2" is used (as this option has the
> undocumented side-effect of silently turning off any requested
This is documented under the --pgp2 section of the manual: "It also
disables --textmode when encrypting."
More information about the Gnupg-devel