works

Well, the picture given as example above looks exactly as before if I choose a key by clicking on it. But at least it changes after hitting return or switching to the next line, so it's an improvement.

I see no change in the reported behavior:

Testing gpg-auth : There are two different use cases

• test with xsecurelock for screen lock
• test with pam-autoproto for login / gdm / etc.

Here are pam_authproto.c with Makefile, so that you can compile it with libpam:

Lookup on server should no longer report any errors caused by a failed WKD lookup.

In T6111#160993, @ikloecker wrote:

Please give this a try on Windows.

Pushed the fix.
Note that non-in-tree build never been reliable (using the result of the configure, in tree).
So, I basically don't consider the use case of non-in-tree build.

works now

Pushed changes.

If the certificate details are opened from the Lookup on Server dialog for OpenPGP keys that are not already present in the local key ring, then all buttons and context menu entries that don't make sense should be disabled or hidden. Information that cannot
be determined for remote keys (e.g. the expiration date of keys looked up on keyservers) should be hidden or displayed as
"unknown".

The export/backup of the secret part of S/MIME certificates has been fixed with T6189: Secret key backup of S/MIME certificate creates bad result. An exported certificate should now be imported without problems.

Fixed.

Here is a PAM module, which interact a spawned process using authproto protocol of xsecurelock.

I can confirm the fix.

Should be fixed.

Thanks, I really appreciate having this fixed in gpgrt-config! I backported the commit to gentoo and can confirm that fixes the build issue with slibtool.

Push the change.

In the situation of a certificate about to be expired in the cache:

Thanks, @gniibe -- i agree that this change to put_cert should be helpful, when encountering a certificate that is already invalid.

This is in for so long we can mark it as resolved. I had tested it on Windows.

Fixed

I realized that some AEAD cipher (including GCM) allows arbitrary length for IV.
But it's not good for the API of setup_geniv and geniv.

rejecting an intermediate certificate too.

Pushed the change of mine to master, since I can confirm that it results validate_cert_chain working better, because of put_cert's rejecting an intermediate certificate too.

I think we can close this one. Note also that we now have --no-user-trustlist and --sys-trustlist-name. in 2.2.37 and 2.3.7 which allows to entirely ignore the user trustlist and to define a global one..

I pushed the change with documentation.

I pushed the changes. It also cares about the case for --cflags.

I'll flag it for re-testing with the next version.

Should be fixed.

exact v.2.3.8 is expected, generally I don't import Key on yubico I generate them directly from yubico itself in order to have the private Key created directly on yubico and not exportable.

Hi! I would like to add my experience about this issue.

what's new for a possible gnupg 2.3.8 or gpg4win 4.0.4 release?

I imported the public key using Kleopatra.

The information should now be updated automatically. F5 still won't change anything if the data on the smart card didn't change, but pressing F5 to update information about locally stored keys shouldn't be necessary in the first place.

All issues have been addressed except:

• No accessible feedback when checking/unchecking user ID

This is caused by a bug in Qt which doesn't report the checkable state to AT-SPI.

Push the change.

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.

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

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.

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.

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: