Thanks for the info and the patch.
I have pushed commit 4545372 to master and it will eventually go into 1.7.1.

commit d02de6c should fix that.

Use '=' for an exact match and optionally '*' for a substring match.

Thank you for your patch. Yes, we already located the issue is the alignment.
I think that it were good if the MTX were placed at the head. While your patch
works, it changes ABI of the lock object for existing archs, unfortunately.

I fixed the detection of Solaris in:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=f7a77c5c236ecec846de9be46703026f9b01008f

And I believe that the bug reported here had gone.
Please test current development master.

The attached is an analysis from the Solaris/SPARC point of view.

One of the possible SPARC specific fixes:

• ./src/posix-lock-obj.h.orig Wed Apr 13 08:24:20 2016

+++ ./src/posix-lock-obj.h Wed Apr 13 08:24:25 2016
@@ -29,7 +29,7 @@

typedef struct
{

• long vers;

+ long long vers;
#if USE_POSIX_THREADS

union {
  pthread_mutex_t mtx;

• ./src/gen-posix-lock-obj.c.orig Wed Apr 13 08:23:59 2016

+++ ./src/gen-posix-lock-obj.c Wed Apr 13 08:24:29 2016
@@ -66,7 +66,7 @@

int i;

#endif

struct {

• long vers;

+ long long vers;
#ifdef USE_POSIX_THREADS

pthread_mutex_t mtx;

#endif
@@ -105,7 +105,7 @@

   union and include a long and a pointer to a long.  */
printf ("typedef struct\n"
        "{\n"

• " long _vers;\n"

+ " long long _vers;\n"

"  union {\n"
"    volatile char _priv[%d];\n"
"%s"

@@ -138,7 +138,7 @@

printf ("/* Dummy object - no locking available.  */\n"
        "typedef struct\n"
        "{\n"

• " long _vers;\n"

+ " long long _vers;\n"

           "} gpgrt_lock_t;\n"
           "\n"
           "#define GPGRT_LOCK_INITIALIZER {%d}\n",

Note, that this was not fully tested on other platforms and might need
additional changes in the header files. I did some minor tests on
Solaris amd64/SPARCv9/SPARCv7, Linux amd64/SPARCv9.

Fixed on 2016-03-19 with commmit af9a4afb. Note that --quiet shall not suppress
all output.

(The commit you gave is wrong).

Thanks for the report. Probably fixed with commit e2c5781.

Not easy yet, need more time to dig.

GpgOL-1.4 which we will include in 2.3.1 will have an option dialog where you
can enable and disable S/MIME. Default in 1.4 is off.

-> Testing until 2.3.1 is released.

ping - will check tonight.

Fixed with commit 1aad5c6.
Thanks for the easy test case.

I believe I have also seen this issue (or something very similar) on my Windows
7 64bit machine. I am running gpg 2.1.11. I hope this isn't redundant, but it
seems that I need to restart scdaemon anytime I unplug/replug my yubikey or
suspend/resume my computer.

Sometimes it doesn't recover even after restarting scdaemon. In those cases, I
am able to fix it by stopping scdaemon, removing the yubikey, starting scdaemon,
and finally reinserting the yubikey.

I have only been pulling from .tar.gz files.

Ibraheem very kindly tested again. However, it is still not working completely.
He writes:

It's still core dumping... Out of curiosity, I explicitly defined

'USE_DOUBLE_FOR_ALIGNMENT 1' and the checks were passing on Solaris with no more
core dumps. I guess that means they're on the right track, just have to get the
preprocessor directives right for gcc and Solaris.

Full details are in
https://mail-index.netbsd.org/pkgsrc-users/2016/03/01/msg023078.html

Thank you for clarification. I didn't know that pkgsrc supports other
platforms. Now, I understand.

I changed more:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commitdiff;h=34b07146bbb0863436fc9381a84314b18bdfb807;hp=49655fb6ef39b307787e1b6e00c996f9c7db64f7

The intention is that USE_DOUBLE_FOR_ALIGNMENT for Solaris 32-bit version.
I thought that checking ILP32 worked (but not, in fact). I believe that LP64
checking works (at least with GCC).

I'm working on pkgsrc, which is a portable packaging system origination on
NetBSD. I myself work mostly on NetBSD.

However, we have patches for non-NetBSD platforms in pkgsrc, and this patch was
worked on by the two people mentioned earlier. Since I can not test on Solaris,
I asked them to test on Solaris, and Ibraheem did that.

I hope that clears it up.

Let me clarify/confirm. Does it work on Solaris? And now do you speak for NetBSD?
My fix is specific to Solaris (no matter if it's Sparc or not). It doesn't
handle any issues for NetBSD.

I seems that Sparc GNU/Linux doesn't have this alignment issue, but (for me) it
is highly likely that sparc architecutre requires the alignment of 8-byte.

Thank you for the patch.
I don't have the environment, but I asked the original reporter to test.
Sadly, his reply is negative, see:

https://mail-index.netbsd.org/pkgsrc-users/2016/02/27/msg023071.html

Fixed in
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=5168b97fb5e2eebdc99b40f96f9b6289647e87d2

Please test.

I assume that this patch solved the problem. Thanks for reporting!

Hi Neal,

Thanks for the patch, works great on the couple of keys I tried it on.
Unfortunately I'm unsure how to build OpenPGP keys with deliberately wrongly
ordered packets, so my tests are probably not exhaustive :-( But looking at
your code (from an outsider's perspective), I can't see how revocation
certificates etc would be handled differently from certificate signatures.

I found two issues though:

+ ndataa = pubkey_get_nsig (a->pubkey_algo);
+ ndatab = pubkey_get_nsig (a->pubkey_algo);

I guess it should be "b->pubkey_algo" on the second line.

Also, since the "check" command of the GnuPG prompt can modify the keyblock, it
should set "modify" accordingly:

-8<----------------------------------------------------------------------------------->8-
diff --git a/g10/keyedit.c b/g10/keyedit.c
index d7c2a4b..ede350a 100644

• a/g10/keyedit.c

+++ b/g10/keyedit.c
@@ -2190,8 +2190,9 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t
locusr,

         break;

       case cmdCHECK:

• check_all_keysigs (keyblock, count_selected_uids (keyblock),
• !strcmp (arg_string, "selfsig"));

+ if (check_all_keysigs (keyblock, count_selected_uids (keyblock),
+ !strcmp (arg_string, "selfsig")))
+ modified = 1;

         break;

       case

cmdSIGN:-8<----------------------------------------------------------------------------------->8-

I understand that by default only selfsigs are reordered for performance
reasons. May I suggest to also consider the key to sign with (for instance
specified with "--local-user")? This can be useful, otherwise in order to avoid
potential duplicates signers might have to type "check" before signing a key.

Also (repeating what we discussed about on IRC so it gets indexed on the web :-)
Due to the append-only nature of keyservers, an uploaded badly ordered key
can't be fixed on the keyserver. As a consequence, with the current algorithm
each refresh would undo fixing the packets' order and removing the duplicates.
Ideally keys would be reordered upon import, and the merge algorithm would avoid
duplicate (for instance it could assume the local copy to be properly ordered,
and not add a packet to the local copy if said packet was found elsewhere on the
keyblock).

Yes, that patch fixed the problem for me.

This should be fixed in acac103. (I was able to exactly reproduce your problem
and the patch fixed it for me.) If you are able to test and it works for you,
please report back here.

Thanks!

Patch looks good, thanks!

Sorry, here it is.

D347: 767_0001-g10-Make-sure-to-have-the-directory-for-trustdb-v3.patch

I think you attached the original patch once again by mistake...

D348: 766_0001-g10-Make-sure-to-have-the-directory-for-trustdb-v3.patch

This would be final version.
If !create, we can let it return earlier.

You are right to have the check against CREATE.
I'll include that check.

D349: 765_0001-g10-Make-sure-to-have-the-directory-for-trustdb-v2.patch

Thanks for the patch, but it still needs a small change. You don't want to
create the directory or the lock file if the user specified --no-auto-check-trustdb.

How about this patch?

Please try attached patch.
While I understand it's a regression (and it's urgent for you), I downgrade the
priority.
It will be soon in the repo.

to be released with 1.6.5

I commited an adjusted patch for GnuPG 2.1 (3e50236).

Thanks. I did some modifications and also fixed an unrelated bug in the
detection of the poolname. Will go into 2.1.11.

Thanks, now this works as expected for me :-)

Please see T1778 (gduzan on Jan 20 2016, 03:41 PM / Roundup) on T1778 for a workaround.

After installing gpg4win 2.3.0 (GpgOL 1.3.0) I had no more crashes.
Thanks for your fix.

I've tested to generate an rsa2048 key with backup on a v2.0 card and it works
now. I have not tested restoring from backup etc. But as this report was about
the failed generation, this issue is resolved imo.

Thanks!

The patch seems to have fixed it.

I removed the not-working checkbkupkey subcommand in
44aee35e69540510617aea4b886ef845590960fe

Also fixed the bkuptocard subcommand in: 40959add1ba0efc1f4aa87fa075fa42423eff73c

Thank you again.

It is likely that the token itself doesn't work well after wakeup from sleep
mode. In this case, all that we can do is re-inserting the token manually.

I'm not sure how PC/SC service handles USB reset after wakeup.

Sorry to say, but mapping the error to "no reader" doesn't help. The first
reset event doesn't get handled. Later it trys to remove the reader but it's
not getting correctly resetted/reinserted again.

I've attached the debug log again

Thank you for further testing.
I think that current code doesn't handle the case when card goes inactive/reset
while reader keeps working. Current code only goes to the reset sequence for a
card again when it detects reader failure. So, although the concept is
different, I think mapping PSCS_W_CARD_RESET to SW_HOST_NO_READER (for now) will
work. Given the situation we don't yet support multiple cards, this workaround
would be OK for a while.

Nope. Neither mapping the "reset card" event to SW_HOST_CARD_INACTIVE or
SW_HOST_NO_CARD helps. It seems that somewhere in the code the return code
SW error codes are not being handled correctly and the card doesn't get
resetted.

I've attached a small log where you can see that pcsc returns the error
reason "reset card" which then gets remapped to "Card reset required" (was
general error before). I also can see that the error is getting mapped to
GPG_ERR_CARD_RESET (because of the error message "Card reset required")
leaving the daemon around with no working card and reporting general errors
again (0x100b).

Additional Info: This bug only happens when you put your computer/laptop
into sleep mode while the smartcard/reader (yubikey) is plugged in. If I
remove the reader before putting it to sleep and attaching it after getting
out of the sleep mode, the scdaemon works fine.

D338: 740_0002-scd-map-card-reset-event.patch

Maybe it's more appropriate to map the PSCS_W_CARD_RESET event to the
SW_HOST_CARD_INACTIVE error code which later gets mapped to GPG_ERR_CARD_RESET
error code.

I've attached the patch file. It would make sense to backport this mapping as
well. Right now it's not yet tested.

I found another problem with the smartcard service under windows. Putting
the system into sleep mode and waking it up again creates an 0x80100068
error code (aka PCSC_W_RESET_CARD).

I'll test if it helps to map the RESET_CARD event to the same REMOVE_CARD
event to get the card reactivated after sleep mode.

Logfile:
2015-12-21 22:16:57 scdaemon[10040] DBG: send apdu: c=00 i=CA p1=00 p2=C4
lc=-1 le=256 em=0
2015-12-21 22:16:57 scdaemon[10040] DBG: PCSC_data: 00 CA 00 C4 00
2015-12-21 22:16:57 scdaemon[10040] pcsc_transmit failed: reset card
(0x80100068)
2015-12-21 22:16:57 scdaemon[10040] apdu_send_simple(0) failed: general
error

Thanks, I can confirm that this solves it.

Fixed with commit af14285

Fixed in
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=b30c15bf7c5336c4abb1f9dcd974cd77ba6c61a7

I've implemented this in fc010b6. If you get a chance to test it, I'd
appreciate any feedback! Thanks!