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.

Oh wait. That shows a Problem in our side. We should include the full chain in our signature. I am renaming your task and will at least investigate if we do or if that maybe changed the last time we updated the certificate. Which might have been after 4.0.3

I agree that "Delete All" should use the same list of attachments as "Save All". Additionally, we should make sure that in both cases the list of attachments that are saved/deleted is identical to the list of attachments that is displayed as attachments in the viewer. Hopefully, KMime::Message::attachments() is also used for this.

There's also https://bugs.kde.org/show_bug.cgi?id=351426 that argues for a full GUI to allow the user to individually select attachments to delete. I can think of such a GUI but I think the amount of work needed to implement it would not be justified by the rather niche use-case.

PRs:
https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/67
https://invent.kde.org/pim/eventviews/-/merge_requests/88
https://invent.kde.org/pim/korganizer/-/merge_requests/103

OK, had to install the intermediary CA certificate from https://support.globalsign.com/ca-certificates/intermediate-certificates/code-signing-standard-ev-intermediate-certificates . For some reason it was missing from my system.
After installing things look good.

The setting which I understood to be the workaround:

Should be fixed.

Phew! This bug has been with us for more than 20 years unless gpg's behaviour has changed only later.

Using -o signedtext.txt fixes the problem. Unfortunately, gpgme does

      err = add_arg (gpg, "--output");
      if (!err)
	err = add_arg (gpg, "-");
[...]
      if (!err)
	err = add_data (gpg, plaintext, 1, 1);

i.e. it tells gpg to write the output to stdout and then reads everything from stdout as plaintext.

In the group dialog I can not cycle forward with Tab endlessly through the not-greyed-out buttons of the window because the focus gets stuck in the bottom row. There "Revert" is included in the cycling, which is not correct, since it is greyed out. With Shift+Tab, cycling backwards works as expected.

On windows the main window looks ok with high contrast mode black. But with dark backgrounds some items in other windows are not readable:

The error was changed to "Bad data" which should be more appropriate.