BUG, I think: fails with -seat

[Matthew Skala]

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:

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

0CEjY3JlYXRlZCBieSBHTlVQRyB2MC4yLjE1IChMaW51eCmjAnicAQoC9f2EzgNZiBmbpv/UHRAC
/057WNIzmwx3GdjpFbejVCyds23tIi1h76XlNTo/BuupJjrAUYJZ+CRgKrhKMSFfq8gXm/+WCgT8
Mzm3IJaPSPzonVR8vr9BCGt0cGcv4JLDPL2RPcVUJMWx4zbNk6RCwgL+KxAymQ2x02pVKOgIngIY
JKWyDRhR6O+G1G0wU6AxrqfVmo9AGgpUI5c3yJu8IMGLeoiTT3rkSSF5AbZJqijvsbLZFsdDWpDT
96A0KOU9vX0Evcg9y6ScRST5ZGzU0PgCpwE1hrLfdQEl6yfqsLHRWajCLFylUatqQMOy4OIfoVFq
VFzdABWOGe87y6LDklwk+J2kGPI0pxTLITaEUdksvRIF1QXXtgIv5Q7NA/tgE8oNpCoRFhijkvG7
SPNImX8mkM8mxtmeUC0rJlxuMHKyEhXI1KRbfcXmXi9nJ+6yzXUCdTmP7MfrgHunp3gdpx4w6nC4
TerFQMiFxOo2n+nnKBDRXDdqfVSGbnryE1tKsMv+zCE3eNoALzT0zRZDTLka7jbiV8TVsH6zL/H3
kcdZHUEs0OnjcBBmstKoONEjAHOZx8ryA73wwAAGKOMZWQGzKhC3nhFwhqR3Pc32uvxmRiyYqxeK
6kmtsWgwNmGg2ucr9h6uMcn8mUFEK6bnOF2umWm7DyLJJimpnF2BMPmbpkUVTNWUd6dpAAB+Xfx4

=TBl+
-----END PGP MESSAGE-----

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