Possible clearsign problem

Werner Koch wk at gnupg.org
Wed Sep 15 09:38:13 CEST 1999


Bob Luckin <bob at dal.asp.ti.com> writes:

> I have installed GPG 1.0 on an HP-UX 10.20 system, and been playing with it.
> (I used HP's ANSI C compiler and --disable-dynload to build it; I couldn't
> get it to work with dynamic loading.)

Ohh, I thought that I add support for shl_load() or whatever these
functions are called.  I probabyl check it the next time I have access
to such a machine (and some spare time).

> I've seen a couple of issues when clearsigning text :-

Ohh, once I thought all the problems are now fixed :-)


> So the question is whether GPG or PGP 5.0 is compliant with the RFC ?

Guess my answer ;-)

> If GPG is compliant, then it still has a problem with case (b), because it
> adds a newline when signing and then does not remove it subsequently.  (Yet
> it must add a newline, because the '-----BEGIN PGP SIGNATURE-----' must be
> on a line of it's own, yes ?)

I had a lot of trouble with this issue and I now believe that the
current code does it best regarding compatibilty to PGP 5 and PGP 2.

It is not a perfect solution.

> Either way, it would be a good idea to modify the RFC to make it clear which
> of the two cases applies :-
>  i) A newline is supposed to be added and subsequently removed

This is the far easiest way to define it.  However, PGP 2 and 5 don't
work this way.  I will throw that into the OpenPGP discussion.

> ii) The cleartext is to be unchanged, but the final newline is to be gnored
>     purely for the purposes of calculating the signature.  (In which case

I think that is what we are doing.

>     you need to specify how to cope with the case when the cleartext does not
>     end in a newline.)

Or what to do with a message of size 0 (someone complained about
this).

Anyway, clearsigned text is supposed to be used for reading by humans
and not my machines.  Such a message does not change it's sense by
adding blank lines or trailing spaces (what is another problem with
the PGP implemenations - gpg calculates two different hashs to cope
with this in some cases)

  
  Werner


-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013



More information about the Gnupg-devel mailing list