Nov 15 2022
Dec 5 2018
Jun 8 2018
Jun 2 2018
Yeah, that's not good enough. You also need to check if literals_seen is 0 before BEGIN_DECRYPTION to catch the case where the plaintext packet comes before the encrypted packet. See https://github.com/das-labor/neopg/commit/30623bcd436a35125f21fe6f29272a5fa7212d3f
May 30 2018
The impact is low to our current understanding, that's why I didn't report it as a security vulnerability. I tried to use this for signatures, but GnuPG has more verification for signatures, so it doesn't work there as far as I can see. So that's good.
If you allow for a BADMDC, you can easily downgrade the content of an encrypted data packet from, for example, compressed to private packet type, and then you don't even need the public key, just an encrypted message. The MDC will notice this, and since Efail the clients should have strict MDC checking, so I didn't include that variation in my report.
By the way, there are other clients I didn't test which are probably affected, such as kmail, claws, gpgtools.
I only have Outlook 2007 and no funds to buy software I don't use, as I am unemployed and using up my savings. So, next time I won't be able to do the testing, sorry!
May 29 2018
I would also recommend that GPGME does a sanity check on the status fd output for people with new GPGME but old GnuPG binary.