and was optional. The protocol did not require validation and as a result some protocol compliant implementations were vulnerable.
If a protocol compliant impl is vulnerable, and the fix is to update the protocol, the protocol is broken.
Yes without html you couldn't build this gadget, but we don't blame machine code for making gadgets possible, we blame insecure c for having buffer overflows.
But in use for all the clients that the EFAIL people tested. That was not the problem. The problem was that there were email clients that were loading image URLs from HTML emails. There was nothing to fix in the case of GPG2. It was entirely a problem with the way that certain email clients handled HTML emails ... a problem, might I add, that still exists today. They just prevented the one type of attack. There will undoubtedly be others that may or may not involve encrypted emails.
> However, we found that several clients only gave a warning to the user for invalid MDCs, but still displayed the modified plaintext. This allowed the CFB gadget attack despite the MDC
No, the problem was that clients would render a plaintext known to have been tampered with. This was exacerbated by a zero click gadget, but would still have been an issue if images weren't loaded and a malicious link was clicked.
You're right that Gpg wasn't shown to be broken, but pgp was. (This is the CBC attack, not the direct attacks on clients which are just client bugs, which themselves aren't direct evidence that a protocol is broken)
Indeed, which makes it ironic that ProtonMail (a webmail provider) was not affected by the vulnerability:
https://protonmail.com/blog/pgp-efail-statement/
If an issue with handling HTML is grounds for abandoning PGP, then it should also be grounds for abandoning Signal:
https://news.ycombinator.com/item?id=17050754