I did not test 2.1 on windows 10 but 2.0 from gpg4win.

Let's consolidate issues though. To simplify things I resolve all reports
regarding this to my report where I will report on debugging / fixing this in
issue2085.

Duplicate of T2085

Duplicate of T2085

Nope not fixed. But let's track this in T2085.

It's not the pinentry. If i install a working pinentry signing files works but
still the migration fails.
Windows Event logs also report that the agent crashed and the process is not
running afterwards.

issue2085 might be related.

Seeing the same on Windows 10 with latest gnupg-w32 package.

Attached is the gpg.log

Migration suceeds from nearly the same homedir under windows 7.

I think the problem is that pinentry-basic does not work on Windows 8.1 and
later. Although I wonder why this should break the migration as I don't get a
pinentry dialog when migrating on Windows 7. (Or on GNU/Linux platforms for that
matter)

Did you reported that at gnupg-users? Let's discuss things in the mail thread.
Andre tested it on Windows 10 so in general it works. The problem must be due
to your local configuration.

For gpg4win 3.0 this will be a problem again as I no longer patch it.

We have to find a solution here. I do not find it acceptable that gnupg does not
understand globs on windows.

Can you still replicate this with gnupg-w32-2.1.7 ?

The problem is likely due to a bug in libgpg-error. You may want to test the
latest master.

This has since been handled in: T1691
It is fixed in Gpg4win.

If you can't do that we can't help you here. You should contact a commercial
supporter (cf. https://gnupg.org/service.html).

Please note that 1.4.12 has security problems and should be updated anyway.

I can't do it on production environment.
Have to fix it like it is, but still don't know where is an issue.

Probably already fixed.

PS: The second problem is persistent if GPG4Win is installed or not. But
knowing how to handle it, I think it's no real problem.

Hmm, let's see:

GPG with GPG4Win installed (I indented it a bit):

% gpgconf --check-programs
gpg:GPG for OpenPGP: C%3a\Program Files (x86)\GnuPG\bin\gpg.exe:1:1:
gpg-agent:GPG Agent: C%3a\Program Files
(x86)\GnuPG\bin\gpg-agent.exe:1:1:
scdaemon:Smartcard Daemon: C%3a\Program Files
(x86)\GnuPG\bin\scdaemon.exe:1:1:
gpgsm:GPG for S/MIME: C%3a\Program Files (x86)\GnuPG\bin\gpgsm.exe:1:1:
dirmngr:Directory Manager: C%3a\Program Files
(x86)\GnuPG\bin\dirmngr.exe:1:1:
pinentry:PIN and Passphrase Entry: C%3a\Program Files
(x86)\GnuPG\bin\pinentry-basic.exe:1:1:

after the deinstallation of GPG4Win:

gpg:GPG for OpenPGP: C%3a\Program Files (x86)\GnuPG\bin\gpg.exe:1:1:
gpg-agent:GPG Agent: C%3a\Program Files
(x86)\GnuPG\bin\gpg-agent.exe:1:1:
scdaemon:Smartcard Daemon: C%3a\Program Files
(x86)\GnuPG\bin\scdaemon.exe:1:1:
gpgsm:GPG for S/MIME: C%3a\Program Files (x86)\GnuPG\bin\gpgsm.exe:1:1:
dirmngr:Directory Manager: C%3a\Program Files
(x86)\GnuPG\bin\dirmngr.exe:1:1:
pinentry:PIN and Passphrase Entry: C%3a\Program Files
(x86)\GnuPG\bin\pinentry-basic.exe:1:1:

From within the GPG4Win folder:
weber in /c/Program Files (x86)/GNU/GnuPG [13:26:16]
% ./gpgconf --check-programs
gpg:GPG for OpenPGP: C%3a\Program Files (x86)\GNU\GnuPG\gpg2.exe:1:1:
gpg-agent:GPG Agent: C%3a\Program Files (x86)\GNU\GnuPG\gpg-agent.exe:1:1:
scdaemon:Smartcard Daemon: C%3a\Program Files (x86)\GNU\GnuPG\scdaemon.exe:1:1:
gpgsm:GPG for S/MIME: C%3a\Program Files (x86)\GNU\GnuPG\gpgsm.exe:1:1:
dirmngr:Directory Manager: C%3a\Program Files (x86)\GNU\GnuPG\dirmngr.exe:1:1:

The old scdaemon could be some problem with the setup - I had 2.1.13 installed,
but before filing this bug-report, I used the installer from gnupg.org to udpate
to a current version to re-check the behaviour.

But I think I may have two separate problems here now:

• "Unknown IPC command" on recv-keys (from cmd and zsh) - it seems I can't

reproduce this after reinstalling GPG4Win. Maybe my environment was screwed up
without me noticing it.

• "Unknown IPC command" on gpg-connect-agent <command> /bye (only in zsh) -

this seems to be persistent, but I just noticed if I add an empty argument
between the command and the /bye, I don't get the "Unknown IPC Command".
Which means gpg-connect-agent '' /bye works flawlessly. Maybe something to do
with MSYS2 or zsh.

Sorry for being such a weird case xD

Sorry, I only noticed the properties page and I never use teh task manager
(sysinternals Process Epxlorer is much more useful). The different version
number of scdaemon is an indication that an older version is still installed or
at least running.

To see GnuPG's idea of the installed programs you can use

  gpgconf

or to actually test whether they are installed:

gpgconf --check-programs

It's the running process information from the task manager (right-click the
running process, properties) - I would be astonished if Microsoft would screw
even that up.

Just for testing it, I reinstalled GPG4Win:

% gpg-connect-agent 'getinfo version' /bye
D 2.1.5
OK
ERR 67109139 Unknown IPC command <GPG Agent>

% gpg --version
gpg (GnuPG) 2.1.5
[...]

% gpg-connect-agent --version
gpg-connect-agent (GnuPG) 2.1.5
[...]

% scdaemon --version
scdaemon (GnuPG) 2.1.3

So it is using the right executables for gpg-agent, gpg-connect-agent and gpg,
but as long as GPG4Win is installed in another directory, it fails on some IPC
Commands..
Scdaemon seems to be 0.0.2 versions behind, which irritates me a bit. But it's
definitely not the one from GPG4Win.

Values from within the GPG4Win directory:

weber in /c/Program Files (x86)/GNU/GnuPG [13:09:03]
% ./gpg2.exe --version
gpg (GnuPG) 2.0.27 (Gpg4win 2.2.4)

% ./gpg-agent.exe --version
gpg-agent (GnuPG) 2.0.27 (Gpg4win 2.2.4)

% ./scdaemon.exe --version
scdaemon (GnuPG) 2.0.27 (Gpg4win 2.2.4)

% ./gpg-connect-agent.exe --version
gpg-connect-agent (GnuPG) 2.0.27 (Gpg4win 2.2.4)

The screenshots show the program but not the running process. It is quite
possible that the older one is still running. If that happens again, please run

  gpg-connect-agent 'getinfo version' /bye

to show the version of the running gpg-agent.

Oh, and thanks overall for making me uninstall GPG4Win :)

Yes and no.
The gpg-agent process running was definitely the 2.1.5 version (see screenshots).

But nontheless, uninstalling GPG4Win solved the problem.

On a sidenote: I had installed GPG4Win solely for the purpose of using it's
pinentry, as it was playing along with my SmartCard-Reader better than the GnuPG
version (pinentry on the device vs on screen) - but somewhere in one of the
later updates, the GnuPG-Pinentry seems to have caught up - everything works now
with just one installation - thanks :)

In gpg4win there is a kwatchgnupg.exe but it throws an error stating that it is
not "installed" within my $PATH variable. The weird thing is, that I started it
from a command prompt somewhere in my filesystem, so its path is set in my $PATH
variable. Strange ...

In last consequence I even tried it with Wireshark and did not get any results
observing localhost and running the command again.

Isn't the output of the log (posted before) enough information or is there any
other way to collect the information you need?

watchgnupg might be missing in the installer. It should be in gpg4win, though.
Anyway using it on Unix with --tcp is much more convenient.

Sorry, but this is not working for me. I do not find watchgnupg executable and
gnupg.org states that this tool does not exist for windows. Maybe I am not clever
enough to find it.
Anyhow I extended the gpg.conf according to your suggestion. (gpg-agent.conf was
already configured like that) I don't know why there is no additional log file
gpg.conf created. I attached my two config files to this issue.

I deleted the "gpg-v21-migrated" file and rerun "gpg -K --verbose". Attached to
this issue you will find my gpg-agent.log . This time it looks like it has more
output in it than the last time.

Not different than in 2.0. You need to enable logging also for gpg-agent. The
best way to do this is by adding

log-file socket:///temp/S.gnupg-log
debug 1024

to gpg-agent.conf and gpg.conf. gpg-agent.conf is usuallay sufficient.
You may then use

   watchgnupg /temp/S.gnupg-log

to view the log in real time. Frankly, under Windows I often use

log-file tcp://1.2.3.4:4711

or

log-file tcp://[2001:db8::1]:4711

along with

watchgnupg --tcp 4711

Would you mind to explain how to enable logging in 2.1?
I tried with --log-file [filename] and --logger-file [filename] but it only
created an empty (0 Bytes) file.
I tried to pipe the output to a file with "gpg -K [--verbose] >
c:\temp\gpg21.log" but this didn't work either. Is the K command supposed to be
"unpipeable"? (The output of "gpg --version" can be piped.)

Please try 2.1.3 or the soon to be released 2.1.4

Fixed for master (2.1).
Will not be backported to 2.0.

Use a backslash and it should work.

Agreed, at most places gpg takes a normal slash just fine and the Windows API is
also specified to work with it. I will consider to also test for a forward slash.

It probably would have been better to create two issues:
a) Dataloss with Kleo in 2.2.2 (fixed now)
b) crash with gpa

Windows does not allow file names with a '*'. I'm not sure on what level but Its
ok not to handle this case.
I don't expect any problems for internal usage. Keep in mind that this is a
regression, we had wildcard expansion before we made the switch to mingw-w64.

We also don't need this in gpgwrap as gpgwrap just passes the argument on and it
will be expanded in the process itself.

But I actually like the idea to do the wildcard expansion in kleowrap / gpgwrap.
This way it would be contained in Gpg4win and we catch all our "user exposed"
processes. Ok?

I won't do that just for gpg - this would be inconsistent. The wrapper we put
into the PATH directory needs this as well. What about gtk and qt libraries -
they run exe files internally - will the quoting continue to work? A single '*'
in a file name would likely break Enigmail.

Well just gpg would be enough imho as this is by far the most prominent command
line tool.

On the other hand it might be more prudent for us to hack / patch it just in the
gpg4win build to have it enabled globally for all tools we ship so that it is
more consistent. This would mean patching the compiler tough which we tried to
avoid so far.

I would be fine with moving this patch to the version independet gnupg2 patches
in gpg4win as it is kind of a "distribution" option forced upon gpg4win by the
compiler we are currently using.

Werner: If you agree please give a short ping here and I'll move the patch /
close the issue.

Now, shall I add this to gnupg 2.1? To which tools? All or just gpg?

I've changed the category to gpa, adjusted the topic and version to 2.2.3
As you've already described the problem together with GPA here I think this is
better then opening a new bug.

I'll also no longer call this critical as the original data loss problem
(Encrypting files where one has an umlaut -> kleo thinks its a success and
deletes the original) Should be resolved.

The fix in GPA should be fairly easy. Some conversion from native to utf-8 on
input and utf-8 to native on output. So I'm taking this issue.

Werner: Could you please take a look at the patch for gpgtar. I will probably
propose something quite similar for GPA. Not real unicode support but at least
for 8 bit filenames.

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,

Patch is included in gpg4win now with a comment that it should be obsolete with
newer mingw versions.

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.

Got two more reports about this for Windows XP users. So we can safely assume
that this was not just a corner case problem for a broken setup of the Original
Reporter but that it is a real problem.

I'll add a reversion of the commit mentioned fpr 2.2.3

accidentally removed the original reporter from the nosy. Sorry (readded)

T1624 is another issue related to this. GPGex
/ Kleopatra file / folder encrypt does not work with non ASCII characters.

To use --multifile with files on the command line. Such a use will suddenly
break. This is the same as using grep on a large number of files - only rookies
do that.

Fortuntately g_rand_new is only used by the dbus support and by tests. Thus we
can easily revert to the old state.

FWIW: Changing the semantics of an existing function to suddenly claim
"cryptographically secure" is a questionable move. You can't rely on it and the
name of the function indicates that it is a wrapper around the usual rand
function. If a CSRNG is needed, an approriate function needs to be added.