I think that it is (long standing) bug in estream.c. Please see the attached
patch for a possible fix.
The enhancement in gnupg, the commit of 12af263 does READ then WRITE with
estream, and it reveals this bug.

Finally, I managed to reproduce the same (I suppose) situation.
Please see: https://lists.gnupg.org/pipermail/gnupg-devel/2016-June/031211.html
It is READ vs. WRITE race condition.

I think that this patch improve the situation.
It moves the creation of the hash table to the place where it creates version
record (holding the lock).

D205: 846_gpg14-create_hashtable-fix.diff

Thank you for update.
msg8431 seems to be another race condition. I only fixed one race in 2015.

My saying in T1675 (gniibe on May 25 2015, 07:38 AM / Roundup) sounds wrong (now, for me).
For example, create_hashtable does lseek to SEEK_END.
When some another process is adding new entry (say, also calling
create_hashtable), we have a valid race condition here.
I mean,

(1) process A calls lseek with SEEK_END, seek goes to a point.
    Then, context switch.
(2) process B calls lseek with SEEK_END. seek goes same point as A.
(3) process B update info using the point.  context switch to A.
(4) process A wrongly overrides info using the point.
    It results inconsistent data.

It was fixed in db1ecc8212defdd183abbb6b1407fcc8d2dc9552 for 2.1.
In 2.1, HDRLEN=0 for all callers, so, there will be no same "Ohhhh jeeee" any more.

In 1.4 and 2.0, HDRLEN is used as a hint. There is no need to change 1.4 and
2.0. Detail is described in:
https://lists.gnupg.org/pipermail/gnupg-devel/2016-June/031178.html

In 1.4 and 2.0, --import just copies the block, so the bug doesn't hit. In 2.1,
when it tries to write to keybox, the bug hits.

The check what Neal introduced is somehow orthogonal to the change of mine.

The key in question, there is a User ID packet of length >= 256 (because he
include ssh key string in his User ID).
In the code of build-packet.c, gpg assumed the length of User ID is < 256 and it
is hard coded to have header length 2.
With the check (in gpg 2.1), it causes an error. I think that, in gpg 1.4 and
2.0, gpg creates malformed packet with incorrect length (LSB of the length).

I don't know the reason, but User ID length is hardcoded.

diff --git a/g10/build-packet.c b/g10/build-packet.c
index 4bfc2ac..1353a86 100644

• a/g10/build-packet.c

+++ b/g10/build-packet.c
@@ -329,7 +329,7 @@ do_user_id( IOBUF out, int ctb, PKT_user_id *uid )

  }
else
  {

• write_header2( out, ctb, uid->len, 2 );

+ write_header2( out, ctb, uid->len, 0 );

    rc = iobuf_write( out, uid->name, uid->len );
  }
return rc;

D368: 838_gnupg-master-20160527.diff

Thank you for the report.
Indeed, the configure script has a bug.
Attached is a patch to fix this.

Thank you for the version information which worked.

Speaking of the code of scdaemon, there is no difference for unblocking (by
resetcode and by admin) between 2.1.11/12 and 2.0.30.

Please note that there are two subcommands.

    admin -> passwd -> 2: unblocking by Admin
    unblock: unblocking by resetcode

Latter requires setting resetcode beforehand.

Here is another session after another three times failure.

This time, unblock by admin with Admin PIN.

$ gpg --card-edit

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

gpg/card> admin
Admin commands are allowed

gpg/card> passwd
gpg: OpenPGP card no. D276000124010200FFFE870215340000 detected

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 2

[ Admin PIN ]
[ New PIN ]
[ Repeat New PIN ]

PIN unblocked and new PIN set.

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? q

gpg/card>

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

$

My case with Gnuk Token.
First, I intentionally input wrong PIN for singing three times.
Then, I invoke gpg --card-edit (with 2.1.2 on Debian experimental) to unblock
the token by resetcode.

$ gpg --card-edit

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 2 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

gpg/card> unblock
gpg: OpenPGP card no. D276000124010200FFFE870215340000 detected

[ Resetcode ]
[ New PIN ]
[ Repeat New PIN ]

PIN changed.

gpg/card>

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

gpg/card> quit

Please note that 'unblock' subcommand is to unblock with resetcode.

For some reason, I can't reproduce your problem in 2.1.x. Isn't it a problem of
your smartcard implementation?
Please describe the specific version number of GnuPG which is possible to
unblock this particular implementation of smartcard.

Fixed in 83a90a916e8e2f8e44c3b11d11e1dd75f65a87fb (master).

Thank you for the report and your cooperation.
At least, this fix is needed.

D367: 835_sig-check-correction.diff

This will be useful for GnuPG itself. For example, currently in
gnupg/agent/command-ssh.c, we have a function ssh_receive_key which compose a
private key from 'ssh-add'. With this API, it will be cleaned up.

Fixed in all branches.

Master 2.1: d9f9b3be036747c9f55060aed47896f951bfb853
1.4: d957e4388f72581b1ec801613b5629b5ea3f586d
2.0: eb7806d63df63663170ba86f0673caa34b944c28

For some reason, the commit messages of 1.4 and 2.0 refers
master commit of 2f3e42047d17313eeb38d354048f343158402a8d.
Perhaps, I did in my repo and it was 2f3e420 and apply it to 1.4 and 2.0.
Then, I pushed 1.4, 2.0, and 2.1. and 2.1 was failed because of
non-fast-forward. Then I rebased for 2.1.

Cofactor is defined by the curve. I guess that the cofactor of the curve in
libaacs is 1. Although my patch includes the code which gets cofactor from key
parameters, the ECDSA computation itself doesn't use cofactor actually.

Well, I haven't expected there is a user who uses (flags param), because it was
mostly for our development. There must be more bugs around that...

Good catch.
Fixed in c7430aa752232aa690c5d8f16575a345442ad8d7.

Thank you.
I think that it's better to use sem_init with pshared=1.
I'm sending my proposal patch to gnupg-devel.

Another problem has been fixed in 6677d8b.
I intentionally set up more hubs from computer to the device to cause an error.
When an error occurred, scdaemon continued to report "Card error", even after I
inserted the device directly to the computer.
Now, it returns "No such device" for severe errors, and scdaemon can recover
from such errors.

The particular problem of T2306 (aheinecke on Apr 25 2016, 06:53 PM / Roundup) has been fixed in cb4fee8.

I think that it was not always reproducible because it depends on timing (only
when it detected an error at bulk_in, the problem happened). I'm not sure if
the difference of old/new libusb mattered for this problem.

libgpg-error 1.22 is out with fix. Please test.

libgpg-error 1.2.2 is out. Please test with it.

I'm reading the implementation of new libusb.
If I guess correctly, the picture of the problem would be:

• New libusb somehow caches (or uses cache of kernel's) USB device list structures.
• When the device is plugged off/on (or hardware failures), the cache should be

updated.

• GnuPG's ccid-driver possibly keeps using staled data of USB device list.

I'll check the implementation detail, and try fixing this.
I think that current ccid-driver with new libusb has an issue for memory leaks
for device list, so, it should be reviewed and modified anyway.

It would be good if we could have a reproducible scenario.

Please describe the interaction. IIUC, isn't it pinentry problem?
Did you input your PIN? For "2 - unblock PIN" operation, you need to
authenticate as admin, did you input your PIN for admin? Wasn't it a failure of
PIN input for admin or user, whatever?

libgcrypt 1.7.0 is out. Please test with it.

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.

Possible causes would be SUSPEND/RESUME of usb device.
Let me see about libusb implementation differences.

Thank you for your report and the log, but it doesn't have useful information so
that I can debug.

The information of card reader is required, if the problem happens for specific
card reader only. Please include full log which includes card reader information.

I think that I fixed this issue in master. If you have time, please test, from
git repo.

bkuptocard had been not implemented, but it was finally implemented in 2.1.11.
If any problem, please let us know.

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

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 your report. Yes, it is the alignment issue.

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

Reading the report, it seems for me that there is nothing we can do as GnuPG Team;
When poll/select returns 0 for /dev/random, it is natural for GnuPG (or any
applications) to wait.
If it is Solaris 10 kernel which changed the behaviour of /dev/random, it should
be fixed or it is better (for us) to know some way to workaround this change.

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

Please test.

By "all zero", I mean that a limb can be with bits of all zeros, so that e =
ep[i] can be zero.

D359: 783_mpi-pow-normalize-expo.diff

Thank you very much. It is reproducible for me, too. I located the issue.
I think that it is reproducible for any libgcrypt (even < 1.5.3).
With the patch attached, problem seems to be gone.
Problem is that the DH exchange introduced in the commit fc4a969a in libssh2,
the EXPO argument is coming without normalization, so, count_leading_zeros
results undefined value on IA-32.
In libssh2, it's random bytes, so, it can be all 0.

If it is difficult for you to minimize your test case, as long as it is
reproducible, please let us have your test case. We'll try to figure out the bug.

I can't show you math proof at hand, but I'm confident enough J can't be negative.
This implementation of mpi_powm was introduced in October 2013.

libgcrypt 1.5.3 was the one with old implementation.

Thank you for your experiment.
I suspect other cause(s). In the code itself, there is no possibility J can be
negative. However, it could be possible, in practice, when the stack is
corrupted because of wrong allocation of memory or by other threads.

When you get negative value for J on entry of the for loop, you can examine four
arguments to _gcry_mpi_powm. And then, you can write standalone program to
emulate it. Debugger or printf.

In what condition can J can be initialized < 0?
Do you have some idea?

Sorry, here it is.

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

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.

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.

D350: 764_0001-g10-Make-sure-to-have-the-directory-for-trustdb.patch

Thank you for the report. Confirmed. It was my mistake, I didn't test the code
path with no homedir.

I believe 1.6.5 has no problem.

I think that we could add -lrt in configure script.
Solaris also has a problem for lock object.

Its pthread_mutex_t seems have alignment of 8-byte.
In posix-lock-obj.h, we will have a padding after vers and the union u.
So, it fails at assert (!"sizeof lock obj");

Reference:
http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/types.h

It would be different issue, but we have similar problem for 'fetch' failure
with an error message like:

gpg: key B00DC692: rejected by import filter" followed by "gpg: Total number
processed: 1