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?

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

Yes I thought to use GnuTLS here.

The depedencies I see [1] are:
gmp -> No further depedencies
libgnurx -> No further dependencies
nettle -> depenendcy to gmp

Apart from that gettext and zlip which we already have.
So it should not be that hard to package. I really would like to get rid of it,
too but until then..

Would you accept a patch against gnupg to include GnuTLS 3.x in the Windows
installer?

1: https://github.com/mxe/mxe/blob/master/src/gnutls.mk

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

Thanks -> resolved.

yeah no, With the gnupg-w32 installer becoming part of gpgwin we really need
support for hkps in that installer. Yeah gnutls sucks but thats what we have.

I'll prepare a patch.

Our tests show this works. Thanks!

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.

I am pretty sure this should be fixed with the current master version of pinentry.

This version does no longer use the std::string stuff as it uses the usual qt
widgets.

Feel free to reopen this bug but I am so sure about it that I'll mark it as
resolved now :-)

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)

I can't reproduce this. I've tried running gpa for several days in a Vbox and
doing crypto operations now and then. It never crashes.

This on Windows 10 32bit.

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

This will be fixed in the upcoming pinentry release as pinentry-qt no longer
uses std::string

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

The Mail you show is a so called PGP/MIME mail.

We are well aware that GpgOL for Outlook 2010 and later versions only provides a
very basic OpenPGP support and no PGP/MIME Support. It is mentioned on the
website and in the documentation.

We are hoping to develop this but this is a huge Feature and very problematic to
implement given Outlook's extension API.

Compendium is updated with f941252 It now makes it clear that you have to edit
gpg.conf.

Wildly clicking around and changing components in GpgOL for quite some time I
was able to trigger this crash once (right before I was about to give up)

So there definitely is something here. Probably a threading / timing thing as it
is so hard to reproduce. Should not be though as all the extension code runs in
Outlooks main thread.

I've tried to reproduce it a second time but failed. Even with a script changing
components and opening encrypted mails in Outlook I was unable to reproduce it a
second time.

If I don't find more I'll add some more trace code in the debug output for a new
release. That should help us to at least tell us where it crashes in that function.

Does this mean it would also not be possible to generate a CSR with SHA256 as
hash algo with 2.0 at all? I think I've tested this some time ago and it worked
but that might have been 2.1

I'd like to see this fixed as the change was part of the NEWS for 2.0.28 and do
we really want to have a NEWS entry like "The default hash algo for a CSR is now
SHA-1 again because we failed to get SHA-256 working"? :-p

Neal: Pinentry-qt Uses a hardcoded magic Number of 256 characters
(pinentrydialog.cpp:140)

So with pinentry-qt you can't enter longer passphrases. I don't know why. Maybe
we want to change that?

This was done with 26ab44b.

I'm now using pinentry-qt5 as my main pinentry but I doubt that there will be
any problems. After dropping the "Secure widgets" There were no code changes
necessary to support Qt5.

This should work. GpgOL 2010 just queries the Plain Text from outlook and
encrypts that.

KMail (Which is my primary mail client and testing client) works fine with such
mails.

Robert, could you send an example mail created by GpgOL that kmail does not decrypt?

To: aheinecke@intevation.de

My keyid is: C97822F5

You can find it attached.

Appears to be working. I had no reports of more problems with Exchange domain
addresses since 1.2.1

Hi,
sorry for the late reply. Missed this report.

In your debug output I can see that GpgOL appears to cause the crash in the
GetCustomUI function.

This is a very simple and static function that is called very often.

Is this issue reproducable for you? What were you doing exactly when it crashed?

(From the debug output it looks like you've opened the Tasks view but this works
ok for me)

Do you have any other Addins installed in Outlook?

As this did not happen with 2.0.27 against 1.6.3 (which was part of gpg4win
2.2.4) I ran a git bisect on gnupg:

bdf439035d123e4751e133ad42982673b0c86b75 is the first bad commit
commit bdf439035d123e4751e133ad42982673b0c86b75
Author: Werner Koch <wk@gnupg.org>
Date: Wed Mar 25 10:12:11 2015 +0100

sm: Change default algos to SHA256 (CSR) and AES128 (bulk encryption).

* sm/certreqgen.c (create_request): Change default hash algo.
* sm/gpgsm.c (main): Change default bulk cipher algo.
--

Signed-off-by: Werner Koch <wk@gnupg.org>

I can reproduce the Problem with gpg4win 2.2.5 and under GNU/Linux running
libgcrypt master and gnupg stable branch.

Does not happen with GnuPG master (2.1)

Ok now I found kbxutil and learned about ephemeral certificates (Yep reading
helps) ;-)

After the first import kbxutil lists the Root certificate three times.
Twice with ephemeral flags, once without. So gpgsm -k shows it only once. But
kbxutil --find-dups already lists those duplicates.

fpr=11:B9:1B:31:EE:09:E0:84:4D:25:4E:58:7A:65:CE:51:84:F3:6B:70 recno=5 7 8
fpr=98:2D:D4:1D:BE:91:EE:72:B3:B8:43:33:F2:21:F7:74:64:39:08:7E recno=2 4 6

Now after the verify gpgsm takes the first of those certificates and unsets the
ephemeral flag as it was used as part of a complete trustchain. (sm/certchain.c:

If the first certificate was ephemeral we now have two certificates that are not
ephemeral but are the same and gpgsm -k shows both.

My solution is to check in keydb_store_cert for ephemeral certificates and
instead of inserting those again without the ephemeral flag to remove the
ephemeral flag of the existing certificate.

It's still unclear to me though why there were three certificates (Two ephemeral
and one normal) I would have expected one ephemeral and one normal certificate.

Patch attached.

D287: 648_0001-sm-Fix-cert-storage-for-ephemeral-certs.patch

I've tested this again and again the problem was no longer visible.

So I ran the following script for some time:

    export GNUPGHOME=$(mktemp -d)
    echo 11B91B31EE09E0844D254E587A65CE5184F36B70 S > $GNUPGHOME/trustlist.txt
    echo disable-crl-checks > $GNUPGHOME/gpgsm.conf
    gpgsm --import aheinecke.der > /dev/null 2>&1
    gpgsm --verify testsig > /dev/null 2>&1
    if [ $(gpgsm -k | grep 0x84F36B70 | wc -l) = "2" ]; then
        echo bug >> bugs
        echo bug
    else
        echo nobug >> nobugs
        echo nobug
    fi
    rm -r "$GNUPGHOME"

This resulted in 85 "bug" and 31 "nobug" entries. Entries were also always in a
row. Like 10 "nobug" followed by 30 "bug" situations and then again 5 "nobug".

Probably related to system I/O.

Werner do you need me to provide more information here or can you reproduce this?

amd64
libgcrypt 1.6.2
libksba 1.3.4-beta1

Btw. If I roll back your commit the crashes no longer happen.

As an additional note. From checking why dirmngr takes so long in my setup I
know that I have several certificates in my keyring where the CRL is not
available. Maybe thats part of the problem.

In valgrind it did not crash. The keylisting exited normally. But showed several
errors.

Attached is the valigrind log.