Here is a sequence of operations/commands that permits to setup or update KDF-DO and align PIN codes accordingly:

Please add

Please dee the commit for a description of this fix.

Not for export, there's a few traps in there, but if you want to take a second swing at import, I'd probably accept that instead.

I don't think this is an error in Debian. Debian Squeeze is packed with libgpg-error 1.26 in the latest stable release [1].
According to the list of changes, gpgrt.h is addes as an alias for gpg-error.h in 1.27 [2].
I think a quick (and correct) fix is to increase the NEED_GPG_ERROR_VERSION in configure.ac to at least 1.27 [3], so the build will fail nicely in the configure-step with a correct error.

That makes sense. If you don't have any other patches floating around for this, would you mind if I took a crack at rewriting export?

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

Okay, the import is pretty much a match for what I have tucked away elsewhere, to that will probably get merged as is, more or less.

Actually op_import and op_export do work, but they're the underlying SWIG bindings, not the more pythonic layer Justus added a couple of years ago. I'd been planning on fixing that this month (part of the work is in one of the ben/howto-update branches), but not merged with master until it could be documented since there's something potentially hazardous in there (exporting secret keys).

Thanks. Yes, I think that's it. Here's a video just in case.

Ok You could notice it because if the year changes there was no "blue" selected date in the current page.

Had a bit trouble reproducing it. It worked for me.

It's nice. Although for now I've only added a message in the legacy_cipher_nomdc case:

I've noticed during testing that GpgOL would not send valid PGP/Inline signed only messages and also failed to verify such messages itself when special characters were in the mix.

Oops. The commits added here belong to T3975

Thanks for your report, but as JJworx already said this is sadly one of the known issues to which we don't yet have a good idea how to fix it. In T3459 there is an animation what is meant by "unselecting" the mails.

Yes, this is actually pretty high on the wishlist but AFAIK there was not yet a task for this.

I justed commited some gadgets to gpgme which might be helpful But please show warnings etc before you use that new option.

There won't be anything without MDC in 2.2.8 anymore.

In addition GnuPG master and 2.2.8 now always create MDC messages (except with option --rfc2440) and always fail for messages without an MDC. For old algorithms a hint is printed:

gpg: WARNING: message was not integrity protected
gpg: Hint: If this message was created before the year 2003 it is
     likely that this message is legitimate.  This is because back
     then integrity protection was not widely used.
gpg: Use the option '--ignore-mdc-error' to decrypt anyway.
gpg: decryption forced to fail!

I need to revise my statement (partly because fixing gpgme would be quite complicated). Marcus is right in that using the the literals_seen counter is the straightforward way to get this right. And it will fix it also for non-GPGME applications.

[We do things in the public unless explicitly requested by a bug reporter writing to security.]

I have changed visibility of the bug, as I think you can do a lot more with this than Marcus imagined.

Do you have a need for doing a new release immediately?

@gouttegd Thank you very much!

Following in-person discussion with @werner last week, I have now added this EFL pinentry to the master branch of pinentry (commit 948105b).

The set of information returned by gpg is too large to be mapped on an exit code. Thus we have status codes and the gpgv tool.

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!

Can you help me understand what the impact of this is? AFAIK Back in 2007 the problem was that it could be faked that data looked like it was signed.

Oh dear, adding new keywords which have not been reserved in the past was a bad idea by C11. This will eventually require fixes at lot of places because the noreturn attribute is widely used ( other common headers may include the noreturn header as well).