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.

On Linux it works in principle, you can generate a key.
I could not test this in windows with my setup, but as the external testers did not complain about this use case, I'd say this is resolved. For the rest see ticket T5901.

I want to add that the scrolling/moving windows around (on Linux) is made more annoying than it could be because windows do not adapt in size if hardly any content is shown. Therefore you might have to scroll quite a lot through an empty window before finding the OK button in the lower right corner.

The external a11y testers (working on windows) wrote:

Applied: rGb8c5d99406c9: gpg,agent,kbx,sm,scd,tpm2d,g13: Use assuan_control.

In T6606#173044, @gniibe wrote:

More care is needed to be perfect; There are places in GnuPG where assuan_sock_connect may be used before syscall clamp set up (after the first assuan_sock_bind failure).

I pushed the commit: rE64532db11fcd: build: New configure option --with-libtool-modification.

PRs with initial implementation - for now only in message list and message viewer context menu:

I don't have an idea where to start looking here.

This fix was pretty minimal and I could test:

Okay, will go into the next revision. Thanks.

Dear Werner, have you had any toughts about this ?

Sorry for misleading you and others, perhaps. That particular thing happens to me time and time again. So if there are no symbols the stack symbols will use an offset relative to the nearest exported symbol. So my initial jumps to a conclusion were uncalled for in regards to the meaning of the stack.

In T6623#173512, @aheinecke wrote:

I also see this from time to time, mostly when the keyring is empty or very small. But never was able to reproduce it. I thought this might be fixed with keyboxd but if you say that scdaemon might be the culprit then I might misunderstood the issue and it is not the keyring loading that is stuck but maybe rather our configuration initialization which queries the config of each component and is also part of the "Loading certificate cache.."

This works now for me and all the examples I have for the customer. With https://dev.gnupg.org/rO0fc4b87a946dd634d4b61d4e8cb0ad6164faa83c it looks to me in KMail like KMime might handle the transition between different encodings / languages not correctly in continued parameters.

Thanks for the reply!

The patch to the specs would be this:

        The three data items hashed for document signatures need to
-       mirror the values of the Literal Data packet.  For detached
-       and cleartext signatures 6 zero bytes are hashed instead.
+       mirror the values of the Literal Data packet.  Note that for a
+       detached signatures this means to hash 6 0x00 octets and for a
+       cleartext signature this means to hash a 't' followed by 5 0x00
+       octets.

Regading your first point: From gnupg (2.4) sign.c:hash_sigversion_to_magic

werner do you have any idea based on the information from the original report where we could start looking for this?

I also see this from time to time, mostly when the keyring is empty or very small. But never was able to reproduce it. I thought this might be fixed with keyboxd but if you say that scdaemon might be the culprit then I might misunderstood the issue and it is not the keyring loading that is stuck but maybe rather our configuration initialization which queries the config of each component and is also part of the "Loading certificate cache.."

Thank you. I think it is good that we have now the time to attack some of these more difficult problems :) I don't understand the code there so don't expect a review from me.