May 9 2022
Apr 21 2022
Apr 1 2022
Jan 22 2022
Oct 10 2021
Fixed in gpgex 1.0.8
Sep 23 2021
Patch has been applied to Kleopatra. See T5619: Kleopatra does not create the UI-Server socket in the socketdir.
Sep 22 2021
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
should be sufficient. Take care this is fully untested and not very elegant.
It will be useful to have support in libkleo:.
Sep 21 2021
Aug 13 2021
Jan 28 2021
Aug 13 2020
Thanks a lot.
Aug 7 2020
Aug 6 2020
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.
Jul 1 2020
I think this might be the issue with High DPI support problems. T4819 which is not yet released.
Jun 29 2020
May 11 2020
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.
May 8 2020
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.
Apr 17 2020
Please let us know which version of Gpg4win you are using.
Nov 12 2019
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.
Feb 27 2019
I'll try to reproduce it.
Jan 30 2019
Jun 18 2018
We did not have more reports about this so I'm resolving it here.
Apr 3 2018
Mar 29 2018
fixed with rev. 4fbbd134b865b1203b1914eb1623fa65aab8cb75
Mar 21 2018
Jan 29 2018
Confirming this bug in Gpg4win version 3.0.3 (previous version was OK).
Nov 29 2017
Sorry for the delay, been a busy busy couple of weeks..
Nov 28 2017
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.
Nov 27 2017
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.
Nov 21 2017
Since there was no action for half a year, I think this task can be closed.