( Apart from the part that was moved out to T3895 )

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released.

Werner it would be great if you could look into this. This is currently my most annoying 2.1. regression. Especially with auto-key-locate it is unintuitive when the Firewall question pops up and appears to come out of nowhere (e.g. adding recipients in GpgOL or in Kleopatra).

I think you are running in the infamous T3459 "As long as the decrypted content of a crypto mail is loaded a mail can't be moved" You have to unselect the mail and then move it without opening it. E.g. by right clicking it. I know this is horrible and it's a major problem but I don't see how we can fix it in our architecture. As we replace the mail content with the decrypted stuff we have to prevent "Write" Events by Outlook. For Move if you block a write event, the move fails. But we don't have any idea in our addon when a write comes from a move. I spent a lot of time on this and have not yet found a good solution. But I think the workaround is kinda ok.

The Bug is here that the Error is not shown properly. In the log:

With the changes in 3.1.0 I think this is acceptable enough that we can move further improvements to this to a lower priority.
We only support PGP/Inline (no-mime), warn if an attachment is also added. A user could send attachments encrypted on a file basis.

All subtasks are in testing.

I've opened T3895 for a permanent decryption / permanent removal of attachments. Maybe something for 3.2.0 ;-)

When an attachment of a crypto mail is removed it now leads to a warning.

In my tests it does work nicely now. We detect the "Send Again" state and correctly handle it. Sign / Encrypt is preselected depending on the state of the original mail. Even works with attachments.

Never seen the crash again.

New version of GnuPG is now packaged.

Accidentally mixed up the ticket number. The correct commits for this ticket are:

Oops. I confused the ticket numbers rO34f6bb73882e: Implement send again for crypto mails. Would be the correct commit for this ticket.

Workaround is implemented in 2.2.6.

I'll go for a warning / error for now and see if I can fix the renumbering.

In fact, renumbering of attachments happens also by just viewing them repeatedly. This likely causes multiple copies somewhere, reducing disk space.

Thanks for the report and the spelling fixes :-)

This problem should be gone with Gpg4win-3.1.0-beta48. While I could not reproduce it I've tried to fix it and changed the hard error to a debug log in case something is unexpected here. I believe that this is safe.

I tried to reproduce this again, using S/MIME Mails, installing gpg4win 2.x etc. It did not crash for me :-/

In T3864#112250, @aheinecke wrote:

• Resetting the GnuPG Profile back to default in Kleopatra does not work.

I doubt that I will be able to fix this. The problem is that for Outlook we build the signed mail structure, which is a multipart MIME message. If you receive such a mail with a non crypto client you see the plain text and a pgp-signature attachment. That is why Outlook shows it as "attachment".

Normal prio as I don't think that this is a regression.

Thanks for trying out the beta. I was about to open an issue about this as someone in the forum reported the same thing. https://wald.intevation.org/forum/message.php?msg_id=5759

• Aborting the keyresolver results in error code 5 in GpgOL
• Resetting the GnuPG Profile back to default in Kleopatra does not work.
• Add uid in Kleopatra results in General Error.

I can verify the problem will be solved with 3.1.0, this can be closed.

fixed with rev. 4fbbd134b865b1203b1914eb1623fa65aab8cb75

Mr. Heinecke, to make sure, please note that despite the thread title these crashes happened with 3.1.0. beta 38. It would be sad if you do all of the tests and checks with 3.0.3

Apologies for not replying to your mail directly. I've marked it in my INBOX to do the test with 3.0.3 first but have not gotten around to it.

Funny thing, it worked for some time, now it's reproducably crashing again. This might be the better log file.

So, this is tested with 3.1.0 beta 38, reproducable crash

I answered by mail in this fashion:

Fixed with: https://commits.kde.org/libkleo/5b93bddf468b6c067fe062131aee726ed4aa6928