Mailing List Archive

"Roland E. Lipovits" <lipo@telekabel.at> writes:

> ´gpg -seat -r Recipient filename´ and then decrypt it with
> ´gpg < encr_file´ gpg says that all is ok, but the new plaintext
> file is one byte bigger than the old one (it ends with a double 0x0A).

Yes, I know that. That is the reason we have the tools/clean-sat.c
;-)

The reason is, that I'm not quit sure about the semantics of
clearsigned messages: the problem is that I found no way to
distinguish between a file ending with a LF and one without a LF as
the last character. The OpenPGP draft says that there must be exacly
one emtpty line but it does not talk about files which do not have a
LF as last character. As this is only used for plain text is should
not bother you. Due to the way it is coded this bugs occurs also if
you are doing an encryption with ascii armor.

As armoring is not the suggested method (you should use MIME), I
decided not to put too much time on this. I never realized for what
"-t" is good anyway - it is a matter of the mailer to bring a message
into a RFC format; I want a clean 8-bit encryption and not this silly
LF/CR or whatever replacement - we have other tools to that if there
is really a need for it.

If someone wants to fix it, I'm glad anyway.


Werner

"Roland E. Lipovits" <lipo@telekabel.at> writes:

> When I sign/encrypt a small text file (ending with a single 0x0A) with
> ´gpg -seat -r Recipient filename´ and then decrypt it with
> ´gpg < encr_file´ gpg says that all is ok, but the new plaintext

Okay, I have spend some time on it and checked the OpenPGP draft
(which does not state anymore the stuff Lutz wrote in his paper about
PGP enhancements).

It now works and I have added a new test script for it. The drawback
is that you might not be able to check old cleartext signatures - we
have to live with this, as it is now compatible with pgp 2 and 5 and
OpenPGP.

Will be in the next release.


Werner