gpg --decrypt strips space (but not CR) from clearsigned text

[David Shaw]

On Jul 11, 2008, at 2:39 AM, Brian Candler wrote:

> On Thu, Jul 10, 2008 at 08:22:09PM -0400, David Shaw wrote:
>> This is correct, and is as per the standard.  Section 7 of RFC-4880:
>> "Note that this framework is not intended to be reversible."
>
> True - but I'd argue it's still inconsistent that --clearsign  
> doesn't change
> the cleartext, but --decrypt does.

Why?  --cleartext is an 'encode' operation.  --decrypt is a 'decode'.   
Not reversible is not reversible.  It doesn't matter much where that  
happens.

> RFC-4880 also says "any trailing whitespace ... is removed when the
> cleartext signature is generated". gpg --clearsign doesn't modify  
> the text
> body in this way, although it does do it to the version of text body  
> which
> goes into the hash calculation of course.

Yes.  Any trailing whitespace is, in fact, removed when the cleartext  
signature is generated.  The *signature*.  The standard says nothing  
about removing it from the body of the message.  Mind you, it would be  
legal to remove it, just as it would be legal to add more of it (say,  
for a system with fixed-width transmission).  It's even legal (though  
silly) if GPG arbitrarily added a secret mesage in morse code to each  
line using space as 'dot' and tab as 'dash'.  All that is required is  
that the signature contains the correct information.

>> Note that the trailing CR is not actually retained.  Rather, the end-
>> of-line marker is made to be correct for your platform.  Depending on
>> that platform it might be a CR, a LF, or a CRLF.
>
> That's not the behaviour I observe. For each incoming line, if it  
> ends with
> CRLF it is passed through as CRLF; but if it ends with LF only then  
> it is
> passed through as LF only.

Sorry, my mistake.  I was thinking of textmode signatures.  There is  
no need to fix clearsigned end-of-line markers since (by definition)  
they started as a text file on your local platform.

David