The limit set by dirmngr is in general useful. Shall we make the limit
configurable at runtime?

Oh well, the hang is indeed a libassuan bug. The assuan_inquire fucntion
stopped reading as soon as a supplied limit was reached and returned to the
caller. The caller (dirmngr), printed an error and sends back an ERR line.
Hwoever, the client kept on sending the remaining lines and thus messed uo the
protocol.

Just fixed it in libassuan (5a52404) by reading up the extra lines before
returing from assuan_inquire.

Hi Neal, you are right about the entropy. I tought it was gpg but I think it's
because my system is too minimal to produce enough entropy. I finally decided to
generate my keys in another machine and transfer them to my minimal
installation. Now it works perfectly, with pinentry 0.9.5.

Thanks for your help,

Regards,

Felix

Can you still replicate this with gnupg-w32-2.1.7 ?

I can't reproduce this. I'm using pinentry 0.9.5 and GnuPG from git. When I
generate a key, it talks nearly 3 minutes for GnuPG to gather the required
amount of entropy, but it eventually returns. Attaching to gpg-agent using gdb,
it appears that gpg-agent is "suck" in the generate key function:

  #9  0x00007f13a08da9ce in ?? () from /lib/x86_64-linux-gnu/libgcrypt.so.20
  (gdb) 
  #10 0x00007f13a08ca2db in gcry_pk_genkey ()
     from /lib/x86_64-linux-gnu/libgcrypt.so.20
  (gdb) 
  #11 0x000000000041f51f in agent_genkey (ctrl=0x1b69e80, cache_nonce=0x0, 
      keyparam=0x7f1398001e70 "(genkey(rsa(nbits 4:1024)))", keyparamlen=27, 
      no_protection=0, override_passphrase=0x0, preset=0, outbuf=0x7f139fccfdb0)
      at ../../../gnupg/agent/genkey.c:479
  479	  rc = gcry_pk_genkey (&s_key, s_keyparam );

So, I seriously doubt that this is a problem with pinentry. And also I doubt
that it is a problem with GnuPG. Most likely, you need to wait for the system
to generate more entropy.

If you think gpg or gpg-agent is really hung, it would be nice if you could use
gdb to attach and then get a backtrace and post that here.

Thanks!

Neal

I take this because I have a related other improvement in mind.

D304: 668_0001-Make-try-all-secrets-work-for-hidden-recipients.patch

I have also encountered this while testing the --throw-keyids option with 2.1.6.
It seemed to me that the fix is not that hard, so I'm attaching a patch.

Here is the content of my gpg-agent.conf:
debug-pinentry
log-file /home/fxleblanc/gpg-errors.txt
pinentry-program /usr/bin/pinentry-curses

Here is the content of my log file:
gpg: reading options from '/home/fxleblanc/.gnupg/gpg.conf'
gpg (GnuPG) 2.1.6; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat
trust hashing cardio ipc clock lookup extprog

gpg: signal Interrupt caught ... exiting

I interrupted the program because it wasn't doing anything after I entered my
passphrase.

--debug-pinentry is an option for the gpg-agent. Thus put the line

debug-pinentry

into gpg-agent.conf and make sure that there is also a log-file option.

I compiled pinentry version 0.9.5 and tried to regenerate my keys. The good news
is that the curses window appeared and I could enter my passphrase. The bad news
is that after I entered the passphrase(with the repetition), the program
freezed, not returning any prompt and not giving any sign of life(I checked with
top to be sure and nothing).

Also, when I tried to use the --debug-pinentry, gpg didn't recognize it as a
valid argument. I use gpg 2.1.6.

Please update to pinentry 0.95 and try again. You may also use the gpg-agent
option --debug-pinentry which shows the communication between gpg-agent and
pinentry.

pinentry-curses 0.9.1

Which pinentry version are you using?

Dup key fixed with commit 4a326d7

commit f05a63b fixes the main problem.
I'll now check why the migration creates a duplicate key.

Another small note: The problematic key was in wide-spread use and additionally
it was distributed until few years ago with Apache's KEYS file and still is
listed here: https://people.apache.org/keys/committer/lars.asc

And I would not call my keyring "very large", it contains less than 1700 keys,
mostly fetched using "keyserver-options auto-key-retrieve" when reading mailing
lists.

So it probably does not only affect me.

Two more details:

1. All secret keys become unusable in this situation until you revert to a

backup of the public keyring, therefore I propose status "critical" (data loss)

2. The duplicates (or even triplicates with my own keyring) of the keys only

have one uid, even if the original has more.

Probably already fixed.

In gpg4win there is a kwatchgnupg.exe but it throws an error stating that it is
not "installed" within my $PATH variable. The weird thing is, that I started it
from a command prompt somewhere in my filesystem, so its path is set in my $PATH
variable. Strange ...

In last consequence I even tried it with Wireshark and did not get any results
observing localhost and running the command again.

Isn't the output of the log (posted before) enough information or is there any
other way to collect the information you need?

watchgnupg might be missing in the installer. It should be in gpg4win, though.
Anyway using it on Unix with --tcp is much more convenient.

Sorry, but this is not working for me. I do not find watchgnupg executable and
gnupg.org states that this tool does not exist for windows. Maybe I am not clever
enough to find it.
Anyhow I extended the gpg.conf according to your suggestion. (gpg-agent.conf was
already configured like that) I don't know why there is no additional log file
gpg.conf created. I attached my two config files to this issue.

I deleted the "gpg-v21-migrated" file and rerun "gpg -K --verbose". Attached to
this issue you will find my gpg-agent.log . This time it looks like it has more
output in it than the last time.

Not different than in 2.0. You need to enable logging also for gpg-agent. The
best way to do this is by adding

log-file socket:///temp/S.gnupg-log
debug 1024

to gpg-agent.conf and gpg.conf. gpg-agent.conf is usuallay sufficient.
You may then use

   watchgnupg /temp/S.gnupg-log

to view the log in real time. Frankly, under Windows I often use

log-file tcp://1.2.3.4:4711

or

log-file tcp://[2001:db8::1]:4711

along with

watchgnupg --tcp 4711

Would you mind to explain how to enable logging in 2.1?
I tried with --log-file [filename] and --logger-file [filename] but it only
created an empty (0 Bytes) file.
I tried to pipe the output to a file with "gpg -K [--verbose] >
c:\temp\gpg21.log" but this didn't work either. Is the K command supposed to be
"unpipeable"? (The output of "gpg --version" can be piped.)

The "migration succeeded" despite of the I/O errors smells fishy. Can you
please delete the "gpg-v21-migrated" file in
C:/Users/xxxxx/AppData/Roaming/gnupg/ and try again with a log file?

This also extends to keys stored on smartcards, see
https://lists.gnupg.org/pipermail/gnupg-devel/2015-June/029959.html

It was fixed in 2.1.4.

perhaps I missed something but...with the command removed how are we able to see
the private keys (esp the details on where they are stored (smartcards)).

The command should be removed because it does not make much sense anymore.
However, it is doumented at many places thus it is not easy to remove.

This reminds me that we don't have a mail keyserver in 2.1 yet. Need to
evaluate whether it will be useful.

(funny due date removed)

Lot of things pertaining to keyservers changed in the meantime and we have a
couple of other things in mind as well.

Please try 2.1.3 or the soon to be released 2.1.4

Fix committed as 971d558e862db878a7310e06ed7116dbe36886ab.

Here's the lsusb output:

Bus 001 Device 002: ID 058f:9540 Alcor Micro Corp.
Device Descriptor:

bLength                18
bDescriptorType         1
bcdUSB               2.01
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0 
bDeviceProtocol         0 
bMaxPacketSize0         8
idVendor           0x058f Alcor Micro Corp.
idProduct          0x9540 
bcdDevice            1.20
iManufacturer           1 Generic
iProduct                2 EMV Smartcard Reader
iSerial                 0 
bNumConfigurations      1
Configuration Descriptor:
  bLength                 9
  bDescriptorType         2
  wTotalLength           93
  bNumInterfaces          1
  bConfigurationValue     1
  iConfiguration          0 
  bmAttributes         0xa0
    (Bus Powered)
    Remote Wakeup
  MaxPower               50mA
  Interface Descriptor:
    bLength                 9
    bDescriptorType         4
    bInterfaceNumber        0
    bAlternateSetting       0
    bNumEndpoints           3
    bInterfaceClass        11 Chip/SmartCard
    bInterfaceSubClass      0 
    bInterfaceProtocol      0 
    iInterface              0 
    ChipCard Interface Descriptor:
      bLength                54
      bDescriptorType        33
      bcdCCID              1.10  (Warning: Only accurate for version 1.0)
      nMaxSlotIndex           0
      bVoltageSupport         7  5.0V 3.0V 1.8V 
      dwProtocols             3  T=0 T=1
      dwDefaultClock       3700
      dwMaxiumumClock     12000
      bNumClockSupported      3
      dwDataRate           9946 bps
      dwMaxDataRate      688172 bps
      bNumDataRatesSupp.    138
      dwMaxIFSD             254
      dwSyncProtocols  00000007  2-wire 3-wire I2C
      dwMechanical     00000000 
      dwFeatures       000404BE
        Auto configuration based on ATR
        Auto activation on insert
        Auto voltage selection
        Auto clock change
        Auto baud rate change
        Auto PPS made by CCID
        Auto IFSD exchange
        Short and extended APDU level exchange
      dwMaxCCIDMsgLen       272
      bClassGetResponse    echo
      bClassEnvelope       echo
      wlcdLayout           none
      bPINSupport             0 
      bMaxCCIDBusySlots       1
    Endpoint Descriptor:
      bLength                 7
      bDescriptorType         5
      bEndpointAddress     0x81  EP 1 IN
      bmAttributes            3
        Transfer Type            Interrupt
        Synch Type               None
        Usage Type               Data
      wMaxPacketSize     0x0004  1x 4 bytes
      bInterval               1
    Endpoint Descriptor:
      bLength                 7
      bDescriptorType         5
      bEndpointAddress     0x02  EP 2 OUT
      bmAttributes            2
        Transfer Type            Bulk
        Synch Type               None
        Usage Type               Data
      wMaxPacketSize     0x0010  1x 16 bytes
      bInterval               0
    Endpoint Descriptor:
      bLength                 7
      bDescriptorType         5
      bEndpointAddress     0x83  EP 3 IN
      bmAttributes            2
        Transfer Type            Bulk
        Synch Type               None
        Usage Type               Data
      wMaxPacketSize     0x0010  1x 16 bytes
      bInterval               0

Binary Object Store Descriptor:

bLength                 5
bDescriptorType        15
wTotalLength           12
bNumDeviceCaps          1
USB 2.0 Extension Device Capability:
  bLength                 7
  bDescriptorType        16
  bDevCapabilityType      2
  bmAttributes   0x00000002
    Link Power Management (LPM) Supported

Device Status: 0x0000

  (Bus Powered)

For the scdaemon log, do you need it:

• with pcscd running or with GnuPG direct ccid implementation?
• in “working” condition (for example doing a gpg --card-status or gpg --sign)?
• during the “breakage” (doing a gpg --decrypt)
• in “broken” condition (after doing a gpg --decrypt).

Sorry if my report wasn't so clear. The broken behavior only appears:

• when using GnuPG ccid implementation (instead of pcscd);
• when doing a decrypt operation (maybe also an encrypt, I didn't check yet, but I'd be surprised since the smartcard hardly do any job here)

After trying a decrypt operation, the USB reader is in a non working condition, and I can only restore working condition by doing a reboot (I'v
tried to cut power to the USB bus but that doesn't seem enough).

Please give me the output of lsusb -v -d 058f:9540
and debug log of scdaemon.
Do you mean --card-status works bug --decrypt fails?

Never mind. Just pushed the changes for the 2.0 branch.

Thanks!

Is there a need to backport it to 2.0 ?

No

Done for master (gpg21). 2.1.3 will be released in a few days.

Is there a need to backport it to 2.0 ?

Thanks. That was helpful.

Fixed with commit cf83ff0. You should now see no more leading zero bytes and
correct bit lengths after decrypting a protected key. Internally GnuPG may use
a leading zero byte but with an gpg --export it will be removed.

The problem was with protected private keys - I've got my own tool for
decrypting them, and that's how I found the problem in the first place.

I've attached two keypairs which exhibit the issue, both in keyring and in
keybox+key formats (password is "password") - both use NIST P-256, and the
encryption key on Test2 (4e86073a308aa22e) has the extra leading zero byte on
its 'd' value.

[Sorry, I didn't found your mail anymore.]

I fixed two bug related to the encoding of MPI created by ECC operations.
ab17f7b gpg: Create all MPIs with RFC-4880 correct length headers.
8bc1deb gpg: Fix broken write of opaque MPI length header.

However your problem was with private keys. Protected private keys or
non-protected? Can you add an example file.

Posted to the list, though not as a subscriber (so it'll need to be approved).

I apologize if I jumped the gun by posting here first - given that my question
was effectively "is this a bug?" (and that I was expecting the answer to be
"yes"), I was erring on the side of caution.

Well, this sounds more like a question than a bug. Can you please post it to
gnupg-devel?