@werner @ikloecker I tend to agree with the original reporter that this is an issue. Not a Bug, but an issue that causes problems for our Users. At least we should have some way in Kleopatra to disable "Advanced Features". Then users could be pointed to some screenshots how to disable AEAD.

This works now with the fix in pinentry that uses the same code to bring the smartcard insertion dialog to the front as we use in the password entry dialog.
Before I was able to reproduce the issue, now it works as expected:

We have changes for this in master; I need to see whether it is possible to backport them.

Here is an example on how to remove the AEAD preference from a key using GnuPG 2.3:

As an alternative you may change the preferences on the key to adjust them to your changed/downgraded version.

Observations:

• TestKey1 (gpg 2.3) is an ECC-key (ed25519/cv25519) while TestKey3 (OpenKeyChain) is an RSA-key (rsa3072). I assume that OpenKeyChain supports ed25519/cv25519.
• TestKey1 (gpg 2.3) states that it supports some advanced OpenPGP features: features: 07 (= 0x04 + 0x02 + 0x01).
• TestKey3 (OpenKeyChain) states that it only supports one advanced OpenPGP feature: features: 01

Some details about TestKey3:

$ gpg --show-keys backup_2022-08-11.sec
pub   rsa3072/BBF1585AFE6385A9 2022-08-12 [SC]
      4AFA1B0808A82E3EF941B067BBF1585AFE6385A9
uid                            TestKey3 <TestKey3@Email>
sub   rsa3072/F3E9DFE37D777AEF 2022-08-12 [E]

Some details about TestKey1_0x31B038AA:

$ gpg --show-keys --verbose TestKey1_0x31B038AA_public.asc 
pub   ed25519/CD1E530031B038AA 2022-08-12 [SC] [expires: 2024-08-11]
      A438C95B6CAA724BC9F3DEB9CD1E530031B038AA
uid                            TestKey1 <TestKey1@Email>
sub   cv25519/B390B84B58866C6A 2022-08-12 [E] [expires: 2024-08-11]

Here are two keys that I created on OpenKeyChain. They are in an encrypted backup file:

Here are two test keys I created with gpg4win 4.0.3 after reinstalling.

Please don't yell at us!

All issues were "fixed" by getting rid of the dialog for T6115: Kleopatra: On "revoke certification" do not offer keys which did not certify that certificate.

Depending on what the user selected (key, one or more user IDs, a single certification) all certifications that the user can revoke are determined and, after confirmation, are revoked one after the other.

Apologies for the delay here, but the particular user claimed it was no longer an issue and it fell off my radar. However I now have a new individual with the same problem.

While playing with your scripts I figured that it would be useful to enhance the KEYINFO command. With
rG989eae648c8f3d2196517e8fc9cce247b21f9629 we could now

FWIW, the man pages do not carry all the info we have. However, I plan to chnage this and put everyting into man pages. It turned out that even me uses the man pages more than info(1) or gnupg/doc/*.

In T6129#161497, @werner wrote:

We are currently investigating another problem with a new feature. Thus things are delayed. Hopefully we get a new release this month (or at least a new gnupg 2.3 version to install on top of gpg4win).

We are currently investigating another problem with a new feature. Thus things are delayed. Hopefully we get a new release this month (or at least a new gnupg 2.3 version to install on top of gpg4win).

Is it possible to have a gpg4win ETA that fixes this bug? thank you

The option to flag a user ID as the primary user ID is now available in the Certificate Details dialog as button below the user ID table and as context menu entry of the user ID table.

I am adding the gpgcom tag as this causes support problems because we do not really know if it is an invalid object with the correct passphrase or if just the passphrase is incorrect.

Should go into 1.10 too

Indeed, you are right. The object created by with can be valid even after the context (when referenced by another object).

Not sure if that is the complete fix - if you do something like:

with gpg.Context(...) as context:
    ...
... cause an exception after the context has been closed ...

then context will still be a valid reference to the gpg.Context instance, and may cause segfaults when something tries to access things inside it (f.e. for serialisation).
I like your previous solution with the accessor checks, because that actually fixes the issue.
Stylistically, maybe __del__ should just be renamed to cleanup or free, and then make sure to call that function from both __exit__ and __del__.

I think the fix should be something like this:

diff --git a/lang/python/src/core.py b/lang/python/src/core.py
index 81f961d9..95fd0cba 100644
--- a/lang/python/src/core.py
+++ b/lang/python/src/core.py
@@ -1189,8 +1189,9 @@ class Context(GpgmeWrapper):
     def __enter__(self):
         return self

@jap Thank you.

Should be fixed. A copy of an older version of pinentry's source code that can be built with Q4 is now included and will result in a pinentry-qt4 executable. Note that while we won't break this pinentry intentionally we won't maintain it either.

Can confirm, we've been running into this as well, but never filed a bug report. Our solution is to have this in our codebase: