As I am not sure how to attach files to this report I have uploaded them here:
http://www.elstel.org/uploads/gnupg/

The patch seems to have fixed it.

I removed the not-working checkbkupkey subcommand in
44aee35e69540510617aea4b886ef845590960fe

Also fixed the bkuptocard subcommand in: 40959add1ba0efc1f4aa87fa075fa42423eff73c

Fixed in aecf1a3c.

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

I was using "gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11)", and then I
just updated to "gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)". Sadly,
no change.

Okay, Feel free to re-open if you see it again.

Fixed in 1.4.20 (and 2.0.28).

Thanks, I can confirm that this solves it.

That fingerprint looks more like gibberish than something which should be
compared by the user. In that regard a SHA-1 fingerprint looks much more
serious and IMHO will be more secure than a base-64 fingerprint where you have
to explain that the users also need to match the case - if they are at all able
to compare that fingerprint.

We should take this to the mailing list.

Fixed with commit af14285

pkg-config weirdness.

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

backported by dkg with commit 0c3d764 for 1.4.19

I'm considering fixing this.

Fixed with rev. b879f5b

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

This is a bug and was fixed in 2e4e10c1. As you correctly observe, it only
impacts fingerprints and thus your workaround is good. Sorry about that!

To do writes, we use a copy-update-move scheme. Thus, all updates are atomic.
A read fopen()s the keyring or keybox, seeks and reads. If an update occurs
between the seek and read, the reader will see the old version: fopen is
associated with the inode, not the filename:

  reader                writer
  -------               -------
  fopen("keyring.pub")
  seek(fp)
                         cp("keyring.pub", "keyring.pub~")
                         update("keyring.pub~")
                         mv("keyring.pub~", "keyring.pub")
  read(fp)

Thus, writers don't interfere with readers.

We need to lock the underlying file for updates to avoid the case in which two
updates occur nearly simultaneously, but only one is saved. (Also, since the
updates occur in keyring.pub~, we need to ensure exclusive access to that file.)

  writer1                           writer2
  -------                           -------
  cp("keyring.pub", "keyring.pub~")
  update("keyring.pub~")
                                    cp("keyring.pub", "keyring.pub~")
                                    update("keyring.pub~")
  mv("keyring.pub~", "keyring.pub")
                                    mv("keyring.pub~", "keyring.pub")

In the above case, writer1's update is lost. (Note: it could be worse: if both
update keyring.pub~ simultaneously, there could be corruption.)

The bug that I'm describing below only has to do with the key present cache,
which becomes inconsistent, because we don't track external writes.

It is base64 trimmed the last '='.

Introducing new specifier, say %f, would be good, while keeping %F as is.
%f includes the hash algorithm string as SSH does.

I think that current lock/unlock mechanism is only for mutual exclusion between
multiple writers. I mean, lock/unlock is done to avoid inconsistency caused by
multiple writers.

It seems that we forget to implement mutual exclusion between writers and
readers, as Neal described.

Before 2.1.10, the write access was limited to specific interactive usage
patterns and it didn't cause major problems (it caused rarely if happened).
Now, I think that we should implement mutual exclusion between readers and writers.

D342: 738_0001-gpg-Fix-TOCTTOU-when-updating-keyblocks.patch

I've attached a fix that does a very small and straightforward modification to
keydb_update_keyblock, which fixes this problem for both the keyring and keybox.

I confirm that I'm not able to reproduce T2176 (guilhem on Dec 11 2015, 02:21 PM / Roundup) nor T2176 (guilhem on Dec 11 2015, 01:07 PM / Roundup) with 4ffe44c, so
I'm changing the issue to “resolved”. Thanks for the prompt action!

My proposed solution is to change keydb_update_keyblock. We don't actually need
to touch the keybox or keyring code.

By the new behavior, I guess you mean getting an error when deleting a key, but
it fails because another process already deleted it. If something like this
were to current occur, then we'd end up with silent corruption. So, it's not
clear how this new behavior would introduce new behavior that could raise problems.

atomicly here mean that the update/insert functions locate an possibly existing
key using the fingerprint while holding the lock.

Anyway, to really fix that we need a daemon taking control of all keys - a task
for 2.3,

I was aware of that problem but always wondered why I never noticed such a case.
Your analysis is correct and explains the problem. The locking of the keyblock
does not help here (it was introduced only a few years ago).

Instead of making use of found.offset and fix that with your suggested trick we
should not use the offset at all but let the update and insert functions handle
it atomicly - this may result in an insert/update error (e.g. if another process
inserted/deleted the key) but that is an expected outcome if two processes
manipulate the same key.

This should not be fixed for the old keyring format but only for the keybox format:

1. The keyring format is deprecated
2. This introduces a new behaviour and may raise other problems.

If you want to fix that, please do that in a new branch.

This should be fixed in 2e4e10c. Please let me know if it works for you (and
feel free to mark this bug as resolved if it does).

I found the bug. I'll try to create a patch soon. Thanks for reporting this.

This is a good suggestion. Thanks.

Just to be clear: you tested with, say, a long key id, and the output was fine?
In other words, the problem only occurs when specifying a fingerprint?

I think that this was fixed in:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=d1a97585c5e73fbc7d4cf90e38f76ffc5aea305f

It will be in 2.1.11 and 2.0.30.

I confirmed that this is fixed in 2.0 and 2.1.

Thank you. There is no reason. It is fixed in:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=4ee881bff4c8fdfa4b3b7a4b7afab611471e97f1

Thank you for your audit.

It ignores the calculated value if it detects failure of gcry_pk_verify.
This is now a kind of standard practice to avoid possible attacks.

Here is a reference:
https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perfect-forward-secrecy/

For my case with OpenPGPcard, the patch fixed the problem of wrong fingerprint
computation. Please test with the patch.

Sorry for my mistake for reading your post. I considered it would be the case
for m, but I also fixed the case for e, the exponent.
Here, I reproduce the problem with OpenPGPcard (while it only occurs 1/256 with
Gnuk Token).
I confirmed that original OpenPGPcard returns e as four bytes 00 01 00 01 with
0x00 in front. This causes 100% failure for fingerprint computation.
I'm going to test the patch with OpenPGPcard. (I'm now installing newer
libgpg-error, to build master of GnuPG.)

Note the corruption that occurs is rather subtle. It occurs silently, because
copy_some_packets doesn't throw an error if the next packet to process doesn't
start on STOPOFF, but continues until the offset of the next packet to process
is at *or exceeds* STOPOFF.

Imagine that we have a keyblock A at offset 0 and a second keyblock B at offset
100 with 2 packets:

• A
• B
• The first gpg process does a search for the key at offset 100
• A second process looks up and updates the key block (A') at offset 0 such

that it now has a length of 150 and 4 packets after offset 100.

3. The initial process "updates" B to B'. hd->found.offset now point into the

middle of A'. In keyring.c:do_copy, the first 100 bytes plus any bytes required
to complete the last packet are copied (by copy_some_packets). The next 2
packets are deleted (skip_some_packets) and the new keyblock is inserted. We
now have the following:

• 100+ bytes of A'
• B'
• Last two packets of A'
• B

And B appears to be duplicated.

Note: there is also a TOCTTOU bug for keydb_search / keydb_get_keyblock.

Hi Neal, I am not able to reproduce the issue with GnuPG 2.1.10 anymore.

Hello Andre,