Thanks a lot.
Jan 28 2021
Aug 13 2020
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.
With the Release of Gpg4win 3.0.1 this error doesn't appear anymore for me while testing.
Nov 14 2017
Multiple bugs fixed here:
Nov 13 2017
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.
Oct 28 2017
I have tried this on Windows 10 (1511,1703,1709&RS4TP)
Gpg4win Version 3.0.0
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.
Oct 27 2017
Hi, thanks for the report.
I have also experience the same bug and reported it on:
Oct 24 2017
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).
- 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.
Oct 23 2017
- 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).
Oct 19 2017
So far we could recreate the following issues:
Oct 17 2017
There are more Logfiles:
Oct 11 2017
Oct 10 2017
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.
Oct 9 2017
Sep 12 2017
Jul 27 2017
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/
Jul 26 2017
The beta is not released, but maybe Andre can make use of that info.
Jul 17 2017
Jun 28 2017
Fixed in b00cf0913243ad5432e4cb859146d88b6691f9a3.
Apr 24 2017
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.
Mar 30 2017
Dec 14 2016
May 10 2016
Thanks. Fixed in the repo.
Mar 10 2016
Dec 8 2015
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.
Nov 28 2014
I did install gpg4win 2.2.3 which does include the fix for Umlaut. I prefer to
use GPA as frontend for encryption and decryption. For decryption, I did link
.gpg to be always opened with GPA. Unfortunatly if the File or Path to the .gpg
has an Umlaut included the GPA GUI crashes. Only if I use the open button from
GPA the file can be added to the GPA frontend and decrypted. For non-umlaut
files the link to open .gpg works fine. Do you also work on GPA bugs or do I
have to report this under the GPA category?
Thank you & regards,
Oct 27 2014
The error is now handled by Kleopatra:
I'm a bit scared of regressions, though as the Input handling is so
"generalized" in kleo that I don't know if I now broke cases where input errors
are expected :-/
Attached is a screenshot how it looks now with a broken gpgtar version. And
files are no longer deleted as the operation is no longer thought to be successful.
Oct 24 2014
Werner: Please see attached Patch.
I've tested this with kleopatra and it works now to encrypt a folder which has
special characters in the local code page in filenames. And tested it on the
This should improve the status quo a lot as full utf16 file names are rarer and
gpgtar / gpg4win is not the only tool which has problems with utf16 filenames ;-)
I did not go for proper unicode support because this would mean:
- Convert all command line arguments from native to utf8. (Or even to expect
them to be utf-16 *brr*)
- Expect files-from / stdio file names to be utf8 encoded (and update the callers)
- Use wide char file io functions. Which would add lots of #ifdefs.
But we would have to discuss if we should do 2. also on non-Windows systems.
Currently gpgtar expects local 8 bit encoding there. So tools using gpgtar would
have to convert their arguments differently for Windows.
Thank you for working on this problem. I also use GPA 0.9.4 for Windows as gpg
frontend. Would be great if the fix will make the file encryption working with
umlaut also in GPA and kleopatra.
Thank you & Regards
Oct 23 2014
gpgtar correctly returns an exit code != 0 in case an error happens. This exit
code is eaten by kleopatra so the problem that success is reported on error is
on kleos side.
But gpgtar has the encoding problems. From the kleopatra side it looks ok file
names are handed over to gpgtar in local 8 bit encoding and not in utf-8. And
even directly on the command line it fails.
C:\Users\aheinecke\Desktop>"c:\Program Files\GNU\GnuPG\gpgtar.exe" --skip-crypto
--verbose -o c:\Users\aheinecke\Desktop\test.tar -e fäil.txt
gpgtar: error stat-ing `fΣil.txt': The system cannot find the file specified.
The problem is that internally gpgtar treats argument file names as UTF-8 and
even converts the return value from syscalls like findfirstfile to UTF-8 before
opening them. The open uses the utf8 encoded filename and fails as the file
system usually does not use utf8 file names on Windows.
A workaround would be to convert to ACP (CP_ACP (afaik ACP is correct for
filenames)) instead of converting to UTF-8. But this will not work for 💩
but as gpgex and kleopatra already fail earlier on "Non 8 bit representable
characters" this should be acceptable for now.
So two fixes need to be done:
- Use system 8 bit encoding for open in gpgtar. -> Should fix most problems
- Handle the return value of gpgtar correctly and escalate it to the user in
-> Should make the rest of the problems "uncritical"
I hope to get this done tomorrow evening.
Sep 12 2014
accidentally removed the original reporter from the nosy. Sorry (readded)
I can reproduce this on my test system, if I just create a folder with the name
"földer" Kleopatra / gpg2 /gpgtar don't show an error they just fail silently
and create an empty archive. I guess there is some utf8 to system locale
As kleopatra offers me the option to "Delete unencrypted files" after encryption
I am marking this as critical as it can lead to data loss.
At least there should be an error so that the removal after the encryption is
Aug 5 2014
Jul 30 2014
I won't call that leaking memory.
Jul 28 2014
With your fix it no longer crashes. But you are leaking memory in case
default_homedir returns allocated memory from read_w32_registry_string or
standard_homedir with a successful call to w32_shgetfolderpath.
As the result should be cached in the static variable this is probably not an
I just pushed a fix.
The problem with gpgme is that we need to stop the Explorer if we want to update
or uninstall gpgme. Given tha we can't use gpgex with the portable version
anyway, I think it is better to keep the existing code and don't switch to gpgme.
Jul 25 2014
Using gpgme would be nice of course to avoid duplicated functionality (this same
stuff is also implemented in gpgol although without the bug) but remember that
we would then also need a x64 version of gpgme.