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.

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,

The error is now handled by Kleopatra:

http://commits.kde.org/kdepim/2a58b4cb452cdb132553c2381ce810bbc2606e55

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.

D192: 523_0001-Fix-gpgtar-8-bit-encoding-handling-on-Win32.patch

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
command line.

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:

1. Convert all command line arguments from native to utf8. (Or even to expect

them to be utf-16 *brr*)

2. Expect files-from / stdio file names to be utf8 encoded (and update the callers)
3. 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
boehmtho

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

kleopatra.

  -> Should make the rest of the problems "uncritical"

I hope to get this done tomorrow evening.

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
conversion missing.

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
not done!

I won't call that leaking memory.

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
issue..

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.

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.

The bug is pretty obvious. I consider to rewrite it by calling gpgconf
--list-dirs to get the home directory. This would be simliar to what we do in
gpgme. Or well, we could link to to gpgme to and make use of its higher level
interface.

Thanks for looking at this. If you like I could test your fixes. I currently
have a build setup and a test setup where I can reproduce the crash.

Btw. Maybe I don't understand c++ enough but afaik this just makes no sense and
is broken:

  try { name = ((string) dir) + "\\S.uiserver"; } catch (...) {}

should be rather something like:
if (dir)
name = string(dir) + "\\S.uiserver";

I have some fixes sitting here in my local repo. I need to check them.

issue1530 and T1536 also describe this bug.
I've closed the other two as duplicates as this one was the first.

Closing this as a duplicate of T1516

Duplicate of T1516

This is a duplicate of T1516

Duplicate of T1516

Hi Werner,

I've reproduced this crash. Last trace before the crash is uiserver_connect.

I believe the crash (without having a backtrace) to be caused by the free in
default_socket_name or by that weird cast.

dir = default_homedir ();
if (dir)

{

	  try { name = ((string) dir) + "\\S.uiserver"; } catch (...) {}
	  free ((void *) dir);

}

    }

default_homedir can return a pointer to an environment variable or a static
string! So just calling free there is definitely a very bad idea.

standard_homedir (which might also be called from default_homedir) also returns
eiher a Heap allocated value or a static string.

I think we should ensure that default_homedir and standard_homedir always return
allocated memory so that it can be safely freed.

I notice that there are other users with the crash problem who are using a non-
standard location for the home directory, and using GNUPGHOME in the Environment
Variables to point to the homedir.

As an experiment, I tested moving the GNUPGHOME pointer from the "User
variables" to the "System Variables" section of the configuration screen. It
makes NO difference - gpgex crashes Windows 7 Explorer in both scenarios,
although Kleopatra functions as expected in both scenarios.

For diagnostic reasons: could you try with Kleopatra as well?

Maybe this is relevant:
I only installed gpg, gpgEX and GPA from the GPG4Win package.

Using gpg.exe on the command line works perfect.
I can en- and decrypt files and sign and whatnot.
Only gpgEX is affected.

The crash happen regardless of what I did before. Usually I use Q-Dir as file
browser. When I trigger a gpgex action via context menu in one Q-Dir OR Windows
Explorer the program (the one I used) crashes.

I set GNUPGHOME as a user variable via Windows' Extended System Settings.

I followed Bernhard's suggestion and attached the GpgEX debug log.

Please provide a proper bug report so that we are able to replicate this. For
example, how did you set GNUGHOME, what process have been started before that
etc. A complete run trough on how to exhibit the bug would be a appreciated.

Thanks for asking again, I did not remember that GPGex was missing from the
compendium.

It works similiar to GpgOL, see
http://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gpgex.git;a=blob_plain;f=README;hb=HEAD
and in German:
http://lists.wald.intevation.org/pipermail/gpg4win-users-de/2013-
August/000593.html

Actually, I can't.
The link you provided leads to a site with some general infos.
There is another link into the compendium with infos about
some GPG4Win components but not a single word on gpgex.

So HOW do I provide some more diagnostic output?

Hi Henning,
thanks for your feedback on Gpg4win and of trying the new Gpgex.

Can you help us further by trying to get some more diagnostic output?
See the link in the last section of http://gpg4win.org/reporting-bugs.html

Best,
Bernhard

works with Gpg4win 2.2.0. But there is a failure after decrypting folder with
umlauts: see gpg4win wald issue #6451
(https://wald.intevation.org/tracker/index.php?func=detail&aid=6451&group_id=11&atid=126)

Issue 1530 notes that gpgex crashed Explorer (Win7-64bit) when the Environment
Variable for GNUPGHOME is not at the default setting.

I can confirm this! My configuration is customized, and I am not using the
default path.

I've done more testing, If the gnupg folder is not moved from its default
location gpgex.dll works in v 2.2.0.

The gpgex.dll problem occurs in version 2.2.0 when the user's GNUPGHOME
environment variable has been set to a non-default location (not the user's
default \AppData\Roaming\gnupg)

Kleopatra works fine but for some reason gpgex doesn't work. It produces an
error "Cannot connect to the GnuPG interface (Kleopatra): IPC Connect call failed"

1 month, and not even a single comment. Am I the ONLY person on earth with this
problem, or the ONLY 1 who cares?

OK. The case is closed.
In the Kleopatra screens it is always the primary key that is visible. There was
no expiration date on that key. Looking into the properties of the key, I noticed
that there was an expiration date on the subkey.
So I could sign with the key, but not encrypt.

It seems that one of your keys is not capable of encryption or expired. Thus it
is not be listed for encryption tasks.

Here is some additional information which may be helpful:

(1) Output of Events Viewer

Faulting application name: Explorer.EXE, version: 6.1.7601.17567, time stamp:
0x4d672ee4
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec4aa8e
Exception code: 0xc0000374
Fault offset: 0x00000000000c40f2
Faulting process id: 0x1934
Faulting application start time: 0x01ce82dff437854c
Faulting application path: C:\Windows\Explorer.EXE
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 9f753f17-eee3-11e2-9f80-0016d33c76d0

I hope this is helpful. Thank you.