Alternatively the revokers could be listed in a separate tab in the details dialog.

There could be several designated revokers, and it's a direct key signature.
So it's like a certification, but not linked to a user ID, but to the key.
Therefor it can't be stored in one field.

In future, when spawn function API is used by libassuan (and stable), we can support gpgme with no gpgme-w32-spawn.exe.
(And it will be simpler, just using native functions in libassuan, instead of replacing ones by assuan_system_hooks.)

This is related to T6818

I guess the status should be set to Testing?

In D545#6468, @sandro wrote:

Is supporting Python 2.7 such a high priority? That version of python is super duper EOL and this might be a good opportunity to drop support for it.

The unexpected behavior of the MAPI store needs to be tested and handled. I had indeed forgotten about POP Mail in my concerns not to leak decrypted mails back to storage.

Recall that on windows you have a current working directory per drive. Thus only LETTER:\foo is a full patch - or an UNC (\\SERVER\foo).

The executable is on Z: drive (Z:\home\gniibe\build\mingw-i686\gnupg\agent\gpg-agent.exe) in the emulated environment.
Perhaps, when the path is absolute path with /, it is interpreted as on the drive Z:.

An update FYI

fwiw, i've just shipped a patch to correct this change in behavior in the 2.2 branch debian. Many thanks to @gniibe , on whose work in the 2.4 branch this is based, and to @ametzler1, who did the backporting to 2.2. I've also written a test which tries to tickle this bug. It fails with unpatched 2.2.43 as emacs times out signing and encrypting mail as epg.el deadlocks with gpg.

Thanks for your answer, @werner

Do not use the pcscd but the integrated CCID driver. This is actually the default form Unix. Or are you on Windows?

All fine. I just noticed it while checking the patch. All applied and more fun with cherry picking in the future ;-)

Hello all. I think I am affected by this problem (I get asked for the yubikey PIV pin every time I make a git commit).
Is there a known workaround?

that looks like it was a problem in the original text, not something i introduced. If you find anything else that needs fixing, please go ahead and fix it to! no need to wait for me.

It seems too late to reject on import, given that people might already have such a secret key in their ~/.gnupg/private-keys-v1.d/ They might have had it for years without knowing it, because the failure is so intermittent. They might just think that they did something wrong, and when they try again it works. It would be great to be more robust than that.

Is supporting Python 2.7 such a high priority? That version of python is super duper EOL and this might be a good opportunity to drop support for it.

In more than 25 years of OpenPGP we only had a few new implementations which got it wrong. I see no need to fix it here - maybe import could indeed reject such a key, though.

I have merged the changes for using setuptools if distutils isn't available. This fixes the immediate problem that the bindings couldn't be built for Python 3.12. I did not merge most of the changes in lang/python/Makefile.am because of the reasons mentioned above. Maybe we can address the open changes in another patch. In any case, thanks a lot for your patch! And sorry that it took so long to get some of it merged.

Maybe there's a 4th possible option that's better than the three i identified?

So i see a range of ways that any OpenPGP software could deal with this:

I don't think this UI makes much sense. From the user's perspective (and from the gpgme API), designated rekovers are not related to certifications at all. Shouldn't we rather just show this as a field in the list of metadata above the tabs in the certificate details dialog?

I left review comments in gitlab.

Right away the first patch:

Backported to 2.4 and relevant parts also to 2.2