Yesterday I had a failed Keygeneration while GpgOL's certificate selection
dialog in Kleopatra was open. Tried again and it worked. I did not get Debug
output but the pattern suggests to me that the Certificate selection dialog
looked for changes in the pubring while generating a key and the locking broke
again.

This problem is rising in my priority of Windows Issues as it causes random
failures. There is also a load of similar reports on various channels to be
found through google https://www.google.at/search?q=pubring.bak

This is fixed in GpgOL master.

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!

due to pth-2.0.7/bin not being added to PATH

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.

What compiler are you using?

Such re-definitions/declarations are a common pattern and are actually useful to
implement an OO system in standard C. Hoever, it is easy to change. See commit
98f9e14 .

Fixed in 1.4.20 (and 2.0.28).

Thanks, I can confirm that this solves it.

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.

Yes, pasting into pinentry-gtk-2 with the middle mouse button does work.

I noticed that pinentry-gnome3 uses GcrSystemPrompt, which is documented as
being a system modal prompt. I'm not very familiar with libgcr, but maybe
pinentry-gnome3 could use GcrPromptDialog if no-grab is set.

New Debian package is uploaded based on master branch of Poldi.
Problem has gone, so, closing this issue.

Fixed with rev. b879f5b

The gnome3 problem is due to libgcr, which disables and manages the dialog.

I'll take a look at the gtk2 issue soon. Does pasting with the middle mouse
button work?

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.

In the current master, there is no problem.
In Debian, we needed to add -lgpg-error due to questionable patch introduced by
Debian itself: https://bugs.debian.org/405238

When we use libgcrypt installed by released version of libgcrypt, the master
branch of poldi has no problem.

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.