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:

Note to self: T6100: Kleopatra: Make revocation of certifications accessible may be obsolete when the improvements are completed because then the dialog will most likely be gone.

If the user cannot revoke any of the certifications of the selected key or user IDs, then we now inform the user about this instead of showing the dilaog.

Firefox nicely shows the 3 NIST certificates from my Telesec card but not the important Brainpool certificate for eIDAS. It turns out that Firefox does not support Brainpool, despite that a patch has been provided 8 years ago. See https://bugzilla.mozilla.org/show_bug.cgi?id=943639 . Thus there is currently no way to use LibreOffice or Okular to signe PDFs because they rely on NSS.

We now propose "<fingerprint>.rev" in the last used export directory as file name. This is the same file name as for the revocation certificates that gpg automatically writes to the openpgp-revocs.d folder when a new OpenPGP key is generated.