In T6328#166678, @aheinecke wrote:

@ikloecker the proper fix for this would be T5478 so you do not have to spend time looking for this, we will remove the Process Input / Outputs of Kleopatra altogether.

The first thing I noticed is that ProcessStdInOutput uses redirect_close<QProcess> as process class. redirect_close overrides QProcess::close, but it never calls the original close(). That's very dubious. Maybe it's not a problem, but there's no comment explaining why the original close() doesn't need to be called. Or maybe that's what is causing the hang in waitForFinished.

On Windows, a whitespace character followed by a number in parenthesis at the end of the file name is now stripped from the proposed output file name.

In T4505#166463, @aheinecke wrote:

I have an Idea. Can't we read all data into memory in Kleopatra (for Certificates this should be ok) and then give this to GPGME as a single data object. So that only one process imports multiple files?

I really don't want to bypass gpgme and then parse the import results and all other status output of gpgsm ourselves. I'll go for Andre's suggestion and serialize imports of multiple files.

@werner Do I understand correctly that by "It might be easier to bypass the gpgsm and run gpgsm directly" you mean using gpgsm in server mode? Or what do you mean with "bypass gpgsm and run gpgsm" (which seems contradictory).

Sure, we could do this. Shouldn't make the ImportCertificatesCommand much more complex than it already is.

Not working on this at the moment.

Finished for now. Not sure if there's much we can/should test ourselves. Maybe we should simply close it and open new tasks for the findings in the report of the next accessibility test.

Done. I verified that gpg4win still builds.

Thanks for the patches. I have completely rewritten FindAssuan2.cmake and have added a separate FindGpgError.cmake. We cannot assume that pkg-config is available everywhere. Therefore, we cannot use pkg_check_modules exclusively. I have verified that the Find*.cmake files work for gpg4win and for the AppImage.

Regarding armored files: Well the whole point of armoring is that there is only a plain 7-bit ASCII channel.

The debug output is

[2560] org.kde.pim.kleopatra: Checking Ui Server connectivity...
[2560] UI server not running, starting it
[2560] org.kde.pim.kleopatra: UiServer: client connect on fd  1528
[2560] org.kde.pim.kleopatra: UiServer: nonce check failed
[2560] org.kde.pim.libkleopatraclientcore: Could not find  "kleopatra"  in PATH.

which means that libkleopatraclientcore couldn't start kleopatra, but at the same time the UiServer seems to be running? Okay, maybe the lines are in wrong order and the connect doesn't fail because the server isn't running but because of the wrong nonce.

The problem with expired keys may still happen for GpgSignKeyEditInteractor, but Kleopatra doesn't allow certifying expired keys or user IDs. Therefore, I don't look into this.