BUG, I think: fails with -seat

Matthew Skala mskala at ansuz.sooke.bc.ca
Thu Apr 23 20:24:48 CEST 1998

When I attempt to sign, encrypt, and ASCII-armour some text, using a
command like:

gpg -o test2 -r 0xA6FFD41D -u 0xE5CC80B5 -seat test1

I get a message like this:

gpg: do_plaintext(): wrote 54 bytes but expected 47 bytes

and I get output like this:

Version: GNUPG v0.2.15 (Linux)
Comment: This is an alpha version!



which, when decrypted, produces the first 43 bytes of the 47-byte input
file, with the message:

gpg: [don't know]: invalid packet (ctb=65)

Note the extra blank line right before the checksum in the armoured file. 
I've also seen examples where there is NO newline between checksum and
body, so that the last line of the armoured block is too long.  Can
provide the test keys, input file, and passphrases used to generate this
example, on request.  This behaviour seems to be repeatable with more than
one input file and choice of sign/encrypt keys.  I've only observed it
when I specify all of "sign", "encrypt", "ascii armour", and "text mode".

I don't know exactly what is wrong here, but as a first guess, it looks
like the routine that's producing the message is reading bytes from a
buffer and counting them, and it also gets a number from somewhere else
that says how many bytes there should be.  But that number of bytes 
is the number of bytes in the input, and because of the "t" option,
it's going through a filter that adds carriage returns to the file, so
there are more bytes in the file-to-be-encrypted then there were in the
original input, and the numbers don't match.

"Let me lose so beautifully               http://www.islandnet.com/~mskala/
 Let me lick the dew from the money tree           Matthew Skala
 Have the moms of the world all care about me        Ansuz BBS
 At suppertime"                        - Odds     (250) 642-7820

More information about the Gnupg-devel mailing list