Ok this looks nice already. My plan is the following:

Yes, signing failed: Bad Passphrase but that may be later.

In T3236#99865, @justus wrote:

The whole "GnuPG System" section?

I'm not sure if this is really a thing, maybe it would be enough to just disable showing the advanced options in Kleopatra again. I only recently enabled them.

Sorry. I looked at path_add and not at path_remove, see my garbled line numbers I started at 1062 and not 1162.

I don't see the bug. Please elaborate. path_new is is freed in line 1065 but if this condition does not match it's freed in line 1079.

C++ Part looks completely fine. Thanks.

*facepalm* Ooops. I see. Thanks for the report. I'll fix it.

Uhm I thought this was fixed with 2e661b9e1a9b50656a5c9646d7444a98477010c1 that should have been part of GPGME-1.9.0 are you sure that you are not seeing this with an older version?

Yes.

In T3059#98039, @justus wrote:

Afaics the document does not specify the following. OpenPGP messages can carry multiple signatures, and the session key can be encrypted by multiple keys. I will implement the following logic:

1. A verification operation is compliant if one of the signatures is compliant.
2. A decryption operation is compliant if all of the algorithms used to encrypt the session keys are compliant.

I don't see a way to make the intention work on Windows without mayor changes. As far as I can see it keeps the pubring open for the full gpg.exe run after a getkey is done and only closes it in gpg_deinit_default_ctrl so any modification to the pubring after it was accessed in the same process once will fail with a sharing violation. And I don't know how we can decide when callers will modify the pubring after a getkey.

I bisected this to: 5556eca5acd46983bff0b38a1ffbc2f07fbaba9f
GnuPG apparently keeps the keyring open in some situations and then fails trying to modify / rename the pubring.

We can close this. The current Master of GpgOL states that Outlook 2003 and 2007 Support is no longer maintained and we will remove support for this altogether in new versions. With current Master this issue also no longer occurs.

*restored the issue after spam edititing*

Works! :-) Thanks.

The commit resolved this.

Fixed with https://commits.kde.org/libkleo/aec263d7ff0ea727a730f657439e4945ba88b18a

Pushed with abe3a9043

I would also like to have attached differential included for Gpg4win if this is not too much.

Plan: Use the table only for X509 add an entry field above for OpenPGP Keyserver.

Found the problem and fixed it. The Problem is described in the commit. Basically glib always assumed it gets UTF-8 Encoded filenames even if they were provided in system locale through double click / open with / command line / drag & drop.

GpgEX is now also compiled with ASLR + DEP. I still have to check some other binaries of Gpg4win before I close this task but I no longer see it as blocking a 3.0 release where I wanted to have this included.

You can now install Gpg4win with /S /MINIMAL=1 command line switches to just get gnupg + pinentries. I think this is what enigmail needs.

Installation of Gpg4win is now possible without Administrator rights. GpgEX does not handle it yet but this is another issue. GpgOL / Kleo / GPA and GnuPG work. Including file extension handling.