The argument here seems to be that when GnuPG's implementation, or the original standard, has flaws, those flaws should be seen as inherent limitations of the use-case, rather than flaws in the implementation and standard. And with GnuPG, that argument seems to be used to justify having it behave the same way it always has, which leads to dangerous situations.
That PGP handles armor, escaping, and comments badly, and clients handle display of the signed text badly, do not seem like they mean that the concept of cleartext signatures are inherently flawed.
derleyici [3 hidden]5 mins ago
Fair point. Calling the concept inherently flawed is doing a lot of work to excuse 30 years of implementation bugs.
That PGP handles armor, escaping, and comments badly, and clients handle display of the signed text badly, do not seem like they mean that the concept of cleartext signatures are inherently flawed.
Really? To me it seems that what’s really harmful is assuming a long string of high entropy hex bytes is a valid signature.
Both detached signatures and cleartext need to be run through verify, so what gives?
Does gpg not error when the post-verification output file doesn’t match the cleartext? That sounds like a bug in gpg