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.

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: