When creating a clear-signed signature and then modifying the clear-signed
portion by appending spaces up to a newline, the --verify finds the integrity of
the file as valid. This appears to be minor for two reasons:

Only spaces that are appended appear to cause this issue
One can simply use a detached signature to avoid this issue

However, I find that due to the intent behind this feature, it is indeed a bug.

I expected the verification to fail since the integrity of the clear signed
message had been tampered with. According to GPG2(1), the clear signed portion
is the only portion validated and understandably so. In other words, I expected:
…
gpg: BAD signature from "Ray Daley [email blocked]"

Steps to re-create:

Create a sample file
$ echo Hello > foo.txt

Verify its SHA-1 hash
$ gpg --print-md sha1 < foo.txt 1D22 9271 928D
3F9E 2BB0 375B D6CE 5DB6 C6D3 48D9

Compare the previous against a 3rd party tool to ensure we arrive at a matching
SHA-1 hash (i.e., I used openssl)
$ cat foo.txt | openssl sha1
1d229271928d3f9e2bb0375bd6ce5db6c6d348d9

Generate a clear-signed representation
$ gpg --clearsign foo.txt

You need a passphrase to unlock the secret key for
user: "Ray Daley [email blocked]"
4096-bit RSA key, ID 8FF8A1FA, created 2010-02-02
...

Verify the integrity (no modification)
$ gpg --verify foo.txt.asc gpg: Signature made Mon May 12 20:10:05 2014 MST
using RSA key ID 8FF8A1FA
gpg: Good signature from "Ray Daley [email blocked]"

After appending one or more spaces to the original text
$ gpg --verify foo.txt.asc gpg: Signature made Mon May 12 20:12:22 2014 MST
using RSA key ID 8FF8A1FA
gpg: Good signature from "Ray Daley [email blocked]"

Note:

• Prepending any number of spaces produces expected results (i.e., bad

signature)

• Any other tested character seems to result in an expected failure (however, I

did not try every character due to time constraints)

• Workaround (and agreed best practice) is to use a detached signature