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.

gniibe/t6606 patches are all pushed into master.

Good idea.

Use the is_qualified flag to figure out QES certificates. This is more than just a capability flag.

NonRepudiation is not a well defined term. It is used by X.509 but often used similar to a digital signature. Thus this does not make sense. The is_qualified flag is what we need for QeS and it seems we already got this in gpgme.

gpgme puts digitalSignature and norRepudiation into canSign. We need them separated at the sources (maybe exposing keyUsage directly in gpgme. That would also make the code in poppler better and more accurate. I'm trying to reconstruct the keyUsages from the canSign&friends functions.

But shouldn't we then rather rename the shortcut of Kleopatra to: GnuPG VS-Desktop - Kleopatra ? That would make it discoverable under both names.

Our sales team gets the support calls and they have to explain that really often.

All the patch related to this are now merged

werner I strongly disagree here. There is no need for this for our software on Windows and that is definitely not the Windows way, esp. with our current feature set. Do you really think a user wants to start "GnuPG VS-Desktop" to then have a selection between Okular, Outlook, and Kleopatra? That is not how this works at all. Definitely not High priority for us if you think Kleopatra is too hard to discover then we could add another start menu entry for Kleopatra called "GnuPG VS-Desktop" but a starter that only offers to switch between Okular and Kleopatra currently does _not_ have high priority, For windows this is solved with the windows registry, If you want to make Okular - GnuPG Edition your default PDF reader you can, similarly for Kleopatra and please also keep in mind that a user wants to "Encrypt" or "Decrypt" a file. And does not necessarily care about Kleopatra.

I do not find this that important because while users tend to repeat actions to ensure that they are _really_ done (e.g. my nephew always saves games twice to ensure that it really was saved) no real harm is done here.

without understanding more of your setup, which user starts it with which rights and when and so on we cannot really help you here. This is a classical support question. You might want to check the permissions on the lock file. Maybe they are created by a user with higher privileges e.g. to interactively manage the keys, and then the batch user comes along and does not have the permission to obtain or create the lock file. My suggestion would indeed be to use the --homedir parameter in the batch script and ensure that the user has full access rights to that folder and no "Adminstrator" messes with the files / permissions in there.

FWIW, we also need this for Windows. ppl often ask what to do after they installed VSD because they can't find a program. Thus a menu ala Kontact is the way to go. It would be linked directly from a GnUPG Desktop entry from Windows. We can even keep the old Kleopatra becuase it does not harm. Whether the "menu" is a container window or a detached windows can be decided by the user, like GIMP and other tools do this.

I suppose you have read https://docs.appimage.org/user-guide/run-appimages.html#integrating-appimages-into-the-desktop, even though I think those two helpers don't do what you want and, on top, they are Linux-specific.

While the DBus problem is interesting and I want to further investigate this, I think the real question or feature we need to have here is to attach multiple "UI Processes" to an AppImage environment. So that you can have an Okular, KMail and Kleopatra running in your VSD environment without going through the console.

I am pretty sure what I want to do here. There is no way around .desktop files if we want to have proper linux integration. Otherwise you cannot for example have okular gnupg in the "start with" menu. It is something like the Windows registry integration. Or make KMail with GnuPG Desktop your default Mail client etc.

The Task from the description is solved in gpg4win 4.2.0. See follow up tickets for anything else.