Ooops - I should know it is my installer :-(
1.6.3.

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

Okay

D325: 675_0001-cache-test.patch

I've attached a patched that demonstrates the problem. This uses a single
keyring. Here is the output using the cache consistency fix:

  $ gpg2
  : keydb_search: preparing cache
  : keydb_search: preparing cache
  : keydb_get_keyblock: enter (cache state: 1).
  : keydb_get_keyblock: filling cache.
  : keydb_get_keyblock: enter (cache state: 1).
  : keydb_get_keyblock: filling cache.
  : desc1: Werner Koch (ha ha test) <wk@gnupg.org>
  : desc2: Werner Koch <wk@g10code.com>
  : Looks good.

And here is the output when the patch is not applied:

  $ gpg2
  : keydb_search: preparing cache
  : keydb_search: preparing cache
  : keydb_get_keyblock: enter (cache state: 1).
  : keydb_get_keyblock: filling cache.
  : keydb_get_keyblock: enter (cache state: 2).
  : keydb_get_keyblock: returning data from cache.
  : desc1: Werner Koch <wk@g10code.com>
  : desc2: Werner Koch <wk@g10code.com>
  : Same name (fail)!

As you can see, the second time keydb_get_block is called, it sees a filled
cache and simply returns the contents. However, the contents are for a
different search. I hope you now agree that fixing this bug is not really
problematic, that the problem has nothing to do with multiple keyrings and this
bug doesn't relate to the 15 year old discussion.

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?

Just to be clear: this bug has nothing to do with multiple keyrings; it will
continue to occur even if we decide to use just a single keyring. The problem
has to do with multiple handles.

Why do you think fixing this is problematic? My simple patch ensures cache
consistency. What's the problem with it?

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

Fixing this is really problematic. For this very reason I proposed to drop the
feature of using several keyrings but too many users insisting on keeping it.
IIRC, this discussion is more the 15 years old.

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)

yes there are no remaining problems that I can see here.

Thanks -> resolved.

Originally dirmngr was a system wide daemon. Thus a limit made a lot of sense
so that users could not oincrease the memory usage of dirmngr. As a user daemon
this is not too problematic anymore but (in contrast to GNU policy), having
limits is still good to avoid DoS. The packet parser also employs certain
limits, like 2K for a user ID or 16M for an attribute packet.

I assume keyservers also have some limit - or at least they should have one to
help against misuse as cheap storage provider. What about using this limit?

can you explain why the limit is useful? e.g. does it increase efficiency in
some metric? defend against certain classes of attack? something else? sorry
that i don't understand the tradeoff fully.

a runtime configuration would be better than a hard fail, but in either case it
seems like we're asking the user to fiddle with things that they shouldn't have
to think about or understand. is there a way that we can automatically detect
the reason for the failure and make things Just Work for normal users without
opening up the tooling to more problems?

2.17 has been released with this patch.

This has been implemented 2 weeks ago.

aheinecke: Did you had a chance to test this with 2.1.7 or master?

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.

Our tests show this works. Thanks!

To clarify werners comment. The revert is part of the 2.0 branch. I've
confoirmed the fix works so -> resolved) But awaiting a package / downstream
deployment.
The default for 2.0 won't be changed away from SHA-1.

This will be part of the next gpg4win release.

(Btw. Good to see you here sandro ;-) )

Kgpg is unmaintained upstream (meaning KDE) Afaik it does not work with gnupg 2.1

We (talking as a kdepim developer here) are currently in the process of removing
libkgpg dependencies in the hope to remove Kgpg altogether. You should use
Kleopatra and nag the Kleopatra developers (me) about features of KGpgp you will
miss in Kleopatra.

This bug has nothing to do with Gpg and should be filed on bugs.kde.org against
kgpg (but as I said it's unmaintained so you probably should not bother)

The limit set by dirmngr is in general useful. Shall we make the limit
configurable at runtime?

Oh well, the hang is indeed a libassuan bug. The assuan_inquire fucntion
stopped reading as soon as a supplied limit was reached and returned to the
caller. The caller (dirmngr), printed an error and sends back an ERR line.
Hwoever, the client kept on sending the remaining lines and thus messed uo the
protocol.

Just fixed it in libassuan (5a52404) by reading up the extra lines before
returing from assuan_inquire.

Did you mean:
In this case we should also return 0 ?

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

Please send us a more detailed bug report. See
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Do not forget to tell us your OS and also send the output of "gpg --version"
You may also want to update to a decent version of gpg.

BTW I had this problem on Debian unstable with version 2.0.28-3:
$ gpg2 --version
gpg (GnuPG) 2.0.28
libgcrypt 1.6.3
[...]

agent/findkey.c:unprotect (for instance) imposes a password limit of 99 bytes
(pi->max_length = 100). I've raised this limit to 255 bytes in commit 348a6eb.
I'd appreciate it if you could test this and confirm that this fix is
sufficient. Note: we are not going to raise the limit about 256 bytes.

If you can't manage to fit 128-bits of entropy in 256 bytes, then you need to
fix your passphrase generation scheme.

This is a regression in 2.0.28. The fix is
commit 35d3ced4fda90a5410a579850ca92ea6a356b402
which reverts to use SHA-1 for a CSR.

It works fine in 2.1 but backporting the changes is not planned.

I can't reproduce this. Looks like your X509 cert store is corrupted.
Can you list your X509 certificates on the command line without error?

Try (listing the public certifcates):
gpgsm -k
and (listing your certificates)
gpgsm -K

Have you done anything else remarkable? e.g. tried out gnupg 2.1 or imported a
new certificate before this