gpg --decrypt strips space (but not CR) from clearsigned text
dshaw at jabberwocky.com
Fri Jul 11 14:21:52 CEST 2008
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
> 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
> 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.
More information about the Gnupg-devel