Thanks for your work. I applied it to Gpgex.

Will do. Thank you very much.

Edit: The text below was wrong. The error given below only occurs when the combined path+filenmae is to long on windows.
An emoticon in a file below the folder to be encrypted does not hinder encryption via GpgEX.

Not sure yes If I rather fix this or do: T6331

Note to self after spending some time searching again for the documentation I saw previously about this: https://learn.microsoft.com/en-us/windows/win32/shell/context-menu-handlers#suppressing-verbs-and-controlling-visibility

Fixed in gpgex 1.0.8

Patch has been applied to Kleopatra. See T5619: Kleopatra does not create the UI-Server socket in the socketdir.

Okay.

Alternative patch for Kleopatra:

diff --git a/src/uiserver/uiserver.cpp b/src/uiserver/uiserver.cpp
index d9746f0b..ab4d2ca7 100644
--- a/src/uiserver/uiserver.cpp
+++ b/src/uiserver/uiserver.cpp
@@ -23,6 +23,8 @@
 #include "kleopatra_debug.h"
 #include <KLocalizedString>

Not from understanding. libkleo adds high-level functionality that's useful for KDE applications, but out-of-scope for gpgme and its C++/Qt wrappers gpgme++ and qgpgme. I would use GpgME::dirInfo() directly in Kleopatra. It would make sense to add an overload of GpgME::dirInfo() that takes an enum, so that one does not have to use the low-level string names in Kleopatra. The downside is that a string-based interface can be extended easily. OTOH, deprecating values of a string-based interface is hard and after removing it the compiler won't complain.

We want to deprecate the whole UI-Server thing and thus I considered it better to provide the generic socket dir instead of adding support in libkleo for the uiserver socket. For the time being, doing this in Kleopatra sounds better to me. From my understanding. libkleo shall be an interface to gpgme++, right?

gpgme_get_dirinfo does already have support for "uiserver-socket" since about 7 years. I don't think a separate "socketdir" which requires a brand new gpgme makes much sense.

For Kleopatra this patch

It will be useful to have support in libkleo:

Thanks a lot.

Thanks Andre,

We have released 3.1.12 which updated all the GUI libraries Kleopatra uses and I got some feedback in related issues like T4689 that this might have helped.

I think this might be the issue with High DPI support problems. T4819 which is not yet released.

I see no reason to not allow decryption of an entire folder recursively. The user knows what they are doing by right-clicking a folder instead of a file. You can show a progress dialog with a cancel button.

Right. GpgEX is in serious need of polishing. I'm not sure if I'm in favor of processing all files recursively. But then the decrypt option should not even be shown.

3.1.11

Please let us know which version of Gpg4win you are using.

This should be normal priority as we continue to receive bug reports about UIServer and the usage in GpgEX of the UIServer protocol keeps us from removing it in Kleopatra.

I'll try to reproduce it.

We did not have more reports about this so I'm resolving it here.

fixed with rev. 4fbbd134b865b1203b1914eb1623fa65aab8cb75

Confirming this bug in Gpg4win version 3.0.3 (previous version was OK).

Sorry for the delay, been a busy busy couple of weeks..

Setting this to resolved until we get reports to the contrary.

As GpgEX only queries a UI Server (GPA or Kleopatra) this is a Kleopatra or GPA problem.
With Gpg4win-3.0 Kleopatra got the option "Encrypt with password" in the file encryption dialog, which does symmetric encryption. GPA does not offer this but as Kleopatra is our main UI for GpgEX I think this feature request is done.

The only way I can think of that this fails if that there are some old files from a gpg4win installation that was not cleanly removed lying around and failing to start.

Since there was no action for half a year, I think this task can be closed.

With the Release of Gpg4win 3.0.1 this error doesn't appear anymore for me while testing.

Multiple bugs fixed here:

Thanks for the report. This is indeed badly broken. I'll work on this now.
I can reproduce and also have a reproducable crash when trying to encrypt a special folder. This must be a recent regression because I tested this some months ago and it worked fine.

Hi,
I have tried this on Windows 10 (1511,1703,1709&RS4TP)
Gpg4win Version 3.0.0
Regards

Hi,
I was using Windows 7 Professional.
The last version that worked was gpg4win 2.3.4 (I didn't try any beta or rc), and encryption/decryption works fine for single files.

Hi, thanks for the report.

I have also experience the same bug and reported it on:
https://bugs.kde.org/show_bug.cgi?id=385390

Since this is a bug that is related to two different parts of the gpg4win package, this bug now only cares about the GpgOL Issue, that GpgOL crashes and cant decrypt messages from the sent folder that are encrypted with S/MIME. All File Based Issues are belonging to Kleopatra are documentet in the KDE Phabricator (https://phabricator.kde.org/T7310).

1. Mails encrypted with S/MIME are stored with "No Data" in the sent EMail folder, but arrive properly at the recipients (you will recieve a readable copy, if you add yourself to the list of recipients). This Issue breaks the GpgOL Plugin after some time which is leading to the described Problem.

2. Files that are Signed and Encrypted to a S/MIME Certificate is broken. When you select a file and encrypt and sign it to a recipient, only a detached signature will be created and the Encrpyted file is missing. (Very similar to Issue 1, but file based).

https://phabricator.kde.org/D8368

So far we could recreate the following issues:

There are more Logfiles:

See T3441 for one additional screenshot with error codes.

The log file shows that gpgex (or explorer) crashes.

The output from gpgsm -K in the last quote is perfectly okay. -K works by iterating over all public keys and checking for each public key whether the private key part is also available. If the private key is not available gpg-agent returns an error.

Sorry to have overlooked your report initially.
We fixed some bugs related to this. Can you please try with the latest Beta from https://files.gpg4win.org/Beta/current/

The beta is not released, but maybe Andre can make use of that info.

Fixed in b00cf0913243ad5432e4cb859146d88b6691f9a3.

With Gpg4win-3.0 ( https://wiki.gnupg.org/Gpg4win/Testversions ) Kleopatra is a completely different beast and I think this is fixed. I've tried it in various setups with Virtual Machines running for a long time and never had this problem anymore.

Thanks. Fixed in the repo.

Secure deletion is a hard problem that depends on the operating system and the
file system used and might even depend on the hardware. I'm not sure if the way
mentioned in this wish would result in "Secure deletion".

GnuPG is not the tool for this.