IIRC, we fixed the alignment in Libgcrypt but I am not sure whether this has
been backported to Libgcrypt 1.6. Which libgcrypt version is used?

Forgot to resolve this as superseeded.

With gcrypt compiled with -mstackrealign as analyzed in T2085 this problem
is also fixed.

So I'm marking this as a duplicate of T2085.

Duplicate of T2085

Backtrace with debug symbols:

(gdb) bt full
#0 0x655ea3e9 in aesni_do_setkey (ctx=0xc6f868,

key=0x6565dc10 <key_128.65421>

"\350\351\352\353\355\356\357\360\362\363\364\365\367\370\371\372\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004",
<incomplete sequence \343>)

at

/home/aheinecke/arbeit/gpg4win/src/gnupg-w32-2.1.7/PLAY/src/libgcrypt/cipher/rijndael.c:248
No locals.
#1 0x655ead8a in do_setkey (ctx=0xc6f868,

key=0x6565dc10 <key_128.65421>

"\350\351\352\353\355\356\357\360\362\363\364\365\367\370\371\372\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004",
<incomplete sequence \343>, keylen=16)

at

/home/aheinecke/arbeit/gpg4win/src/gnupg-w32-2.1.7/PLAY/src/libgcrypt/cipher/rijndael.c:569

initialized = 1
selftest_failed = 0x0
rounds = 10
i = 1
j = 1
r = 1
t = 13813018
rconpointer = 0
KC = 4
hwfeatures = 1472

#2 0x655eb2b1 in rijndael_setkey (context=0xc6f868,

key=0x6565dc10 <key_128.65421>

"\350\351\352\353\355\356\357\360\362\363\364\365\367\370\371\372\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004",
<incomplete sequence \343>, keylen=16)

at

/home/aheinecke/arbeit/gpg4win/src/gnupg-w32-2.1.7/PLAY/src/libgcrypt/cipher/rijndael.c:668

ctx = 0xc6f868

...

info registers
eax 0x6565dc10 1701174288
ecx 0xd25110 13783312
edx 0xc6f868 13039720
ebx 0x0 0
esp 0xc6f760 0xc6f760
ebp 0xc6f760 0xc6f760
esi 0x0 0
edi 0xd24478 13780088
eip 0x655ea3e9 0x655ea3e9 <aesni_do_setkey+31>
eflags 0x10297 [ CF PF AF SF IF RF ]
cs 0x1b 27
ss 0x23 35
ds 0x23 35
es 0x23 35
fs 0x3b 59
gs 0x0 0

disas 0x655ea3e2,0x655ea3ff

Dump of assembler code from 0x655ea3e2 to 0x655ea3ff:

0x655ea3e2 <aesni_do_setkey+24>:     mov    0xc(%ebp),%eax
0x655ea3e5 <aesni_do_setkey+27>:     movdqu (%eax),%xmm1

> 0x655ea3e9 <aesni_do_setkey+31>: movdqa %xmm1,(%edx)

   0x655ea3ed <aesni_do_setkey+35>:     aeskeygenassist $0x1,%xmm1,%xmm2
   0x655ea3f3 <aesni_do_setkey+41>:     pshufd $0xff,%xmm2,%xmm2
   0x655ea3f8 <aesni_do_setkey+46>:     movdqa %xmm1,%xmm3
   0x655ea3fc <aesni_do_setkey+50>:     pslldq $0x4,%xmm3

It appears to be that this is crash is due to the fact that windows uses a 4
Byte stack alignment and the movdqa call expects 16 byte alignment.

I've found some info on this here:
http://www.peterstock.co.uk/games/mingw_sse/

I also confirmed that with "-mstackrealign" the crash no longer happens.

Werner: should we add this globaly to the configure options of gcrypt or do you
have a better fix for this?

This issue seems fixed in gnupg-w32-2.1.7.

...
Or printf debugging was the wrong approach here.

Attaching gdb to the agent led to the following backtrace:

#0 0x655ea3e9 in aesni_do_setkey () from C:\Program
Files\GnuPG\bin\libgcrypt-20.dll
#1 0x655ead8a in do_setkey () from C:\Program Files\GnuPG\bin\libgcrypt-20.dll
#2 0x655eb2b1 in rijndael_setkey () from C:\Program
Files\GnuPG\bin\libgcrypt-20.dll
#3 0x655edadd in selftest_basic_128 () from C:\Program
Files\GnuPG\bin\libgcrypt-20.dll
#4 0x655ede09 in selftest () from C:\Program Files\GnuPG\bin\libgcrypt-20.dll
#5 0x655eabfc in do_setkey () from C:\Program Files\GnuPG\bin\libgcrypt-20.dll
#6 0x655eb2b1 in rijndael_setkey () from C:\Program
Files\GnuPG\bin\libgcrypt-20.dll
#7 0x655cd4ae in cipher_setkey () from C:\Program Files\GnuPG\bin\libgcrypt-20.dll
#8 0x655ce076 in _gcry_cipher_setkey () from C:\Program
Files\GnuPG\bin\libgcrypt-20.dll
#9 0x655c2308 in gcry_cipher_setkey () from C:\Program
Files\GnuPG\bin\libgcrypt-20.dll
#10 0x0041aea8 in agent_protect ()
#11 0x004189a9 in store_key ()
#12 0x0041950b in agent_genkey ()
#13 0x00407a5e in cmd_genkey ()

So I've built libgcrypt again with --disable-aesni-support (Which is also what
gpg4win uses). And the crash goes away.

Surprise. This issue is weird.

Agent calls: hash_passphrase in agent/protect.c:do_encryption
I've added a load of debug output there but this is where it crashes.
I've moved the get_standard_s2k_count out of that call to verify that this is
not he crashing part.

My code looks like this:

  log_debug ("%s:%s: Line: %d", __FILE__, __func__, __LINE__);
  unsigned long s2kcnt = get_standard_s2k_count();
  log_debug ("%s:%s: Line: %d", __FILE__, __func__, __LINE__);
  rc = hash_passphrase (passphrase, GCRY_MD_SHA1,
                        3, iv+2*blklen,
                        s2kcnt,
			key, keylen);
  log_debug ("%s:%s: Line: %d", __FILE__, __func__, __LINE__);

The debug output after the hash_passphrase is not reached. The line before is.

But now this is where it gets weird.

With (debug enhanced):

static int
hash_passphrase (const char *passphrase, int hashalgo,

int s2kmode,
const unsigned char *s2ksalt,
unsigned long s2kcount,
unsigned char *key, size_t keylen)

{

  /* The key derive function does not support a zero length string for
     the passphrase in the S2K modes.  Return a better suited error
     code than GPG_ERR_INV_DATA.  */
  int ret;
  log_debug ("%s:%s: Line: %d", __FILE__, __func__, __LINE__);
  if (!passphrase || !*passphrase)
    return gpg_error (GPG_ERR_NO_PASSPHRASE);
  log_debug ("%s:%s: Line: %d", __FILE__, __func__, __LINE__);
  ret = gcry_kdf_derive (passphrase, strlen (passphrase),
                         s2kmode == 3? GCRY_KDF_ITERSALTED_S2K :
                         s2kmode == 1? GCRY_KDF_SALTED_S2K :
                         s2kmode == 0? GCRY_KDF_SIMPLE_S2K : GCRY_KDF_NONE,
                         hashalgo, s2ksalt, 8, s2kcount,
                         keylen, key);
  log_debug ("%s:%s: Line: %d", __FILE__, __func__, __LINE__);
  log_debug ("ret: %i ", ret);

  return ret;

}

I can see the debug line above the return statement is executed and that it
returns 0! But i don't see the call returning to do_encryption.

The only idea explaining this behavior that i have so far is some kind of stack
corruption where has_passphrase tries to return to an invalid pointer. But i
don't see the problem atm.

This was already reported in T1819 and T2083.

Let's fix it here :-)

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

The "migration succeeded" despite of the I/O errors smells fishy. Can you
please delete the "gpg-v21-migrated" file in
C:/Users/xxxxx/AppData/Roaming/gnupg/ and try again with a log file?

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.