Note that with gnupg 2.2 that file produces a BAD signature error due to internal changes in the armor parsing. You would need to spoof it a bit different with 2.2

On Linux, Kleopatra (master) with GnuPG 2.5 (master) shows a BAD signature. It shows the same output as running gpg --verify --output bla.txt in Konsole and pasting the file content (by maybe the copy paste changes some control characters). If I run gpg --verify --output bla.txt <payload.spoofed.asc then bla.txt also contains the same data.

I don't understand what you mean by "only the verified part must be shown". Please clarify. Note that Kleopatra doesn't do any parsing. If gpgme identifies the content of the notepad as signed data then Kleopatra passes the content of the notepad verbatim to gpg --verify --output ....

I originally uploaded a wrong copy of the file. Now fixed; the correct checksum is 8d830a2dd7e1e14ecbc47b8cdc61d393e9d3f62c

I think we are all wrong here. We were tricked by the fact that regardless of the outcome of the signature verification the signed content is shown. That is surprising for a cleartext signature because that one can be viewed anyway. Thus I propose to not update the clipboard unless the signature checks out.

It turns out that Kleopatra's notepad converts the CR characters of the spoofed file to LF characters when pasting the text so that Kleopatra doesn't really verify the content of the spoofed file but different content. And this results in a bad signature. The confusing bit is that Kleopatra also says "Successfully verified the notepad" and that it shows the claimed-to-be-signed text although the signature is bad which could lead an inattentive user to the assumption that the signature of the displayed text was actually good (because "Successfully verified").

I have verified (by looking at QTextEdit's code) that, on paste, QTextEdit splits the text for the internal representation into lines and discards any CR and LF characters.