I think you should simply use gpgv for verifying signatures. gpgv exists for exactly this use case. You don't even have to import anything because you can directly pass a keyring to gpgv.

Sorry, I haven't been able to get any more information so far. I'll try to read up on the code a bit during my upcoming vacation, perhaps I can identify something. While I couldn't confirm that it's about the loader lock, but also couldn't rule it out.

I have the website repo now filtered and ready to be pushed but the write access to repos only hosted on phabricator does not work. We probably need repos on playfair.gnupg.org and only then mirror them here. Since werner is currently busy and I need him for that I will do that tomorrow or wednesday. As tomorrow I am on the road.

I have created the repo now. https://dev.gnupg.org/source/gpg4win-compendium/

That was not me. I would much prefer to have the website in its own repo with its own contributors and so on. Maybe we could also do this then.

I am not sure what autoconf -o does though?

Ok cool, I think then you can mostly use git-filter-repo to filter out the history of the manual subfolder into a new git empty repo. Just give the word and I can create one here on dev.gnupg.org where you can then push to.
I am not sure what autoconf -o does though? How are the replacements handled which were defined in confiugure.ac etc?

What I tried so far (after checking out de40f2fe3336c63e5f73cce93402a73029779fd3, the commit before you removed the compendium):

I am reopening this at least for testing as we have reports that another client is facing the issue with recent versions and also with verified mails .

I spent my afternoon with git-filter-repo and while that worked nicely I failed to come up with a new build system for the compendium that worked, I tried to do the full autotools shebang but in the evening I realized that a simple static Makefile would probably be better like with the website branch. But I leave that to someone else. I will now tag gpg4win-4.2.0 as "the-last-compendium" and include the pdfs from that version from now on and just remove the compendium from master.

@aheinecke Backport to gpg4win/23.07?

@aheinecke Backport to gpg4win/23.07?

Works for me.

The poppler API exposes key usage extensions, and I'm trying to reconstruct them from the canX flags, which of course is highly inaccurate.

Technically, the canX are already checking a flag internally because _gpgme_key stores the can_X values as single bits. There are still 17 unused bits in _gpgme_key, i.e. there's plenty of space for more flags like can_haz_cheezeburger.

Pushed the change into master of libassuan (to be 3.0).

OK, still the whole usage stuff screams for a flag style api IMO. With all the canX then reduced to checking for the according flags internally.
@werner I am assigning this to you for triage. Basically set it to wontfix or whishlist if you think it would be worthwhile or not for future canHazCheezeburger things

npth_t is untouched for Windows 64-bit.

npth_connect and npth_accept should deprecated (since it's not consistent with 64-bit Windows). In gnupg master, there is no use.

In libassuan 3.0, we distinguish the integer identifier for process and the HANDLE (by T6487).
This was problem was solved.

assuan_sock_accept approach is taken in gnupg master.