After some uninstall/install cycles on Win8.1 for several gpg4win versions, I
can tell that only the mentioned gpg4win versions are troublesome as soon as
there's GnuPG 2.0.27+ bundled.

I also tried the plain vanilla gnupg-w32-2.1.11_20160209.exe and everything's
fine, too. As there's no 2.0.x non gpg4win binary on the server, I can't tell if
that's really only a gpg4win whatsoever issue. Pretty strange... For me that's
fine to use, but as most Windows users will stick to gpg4win and the 2.0.x
versions, probably still worth checking.

gpg: Total number processed: 307
gpg: unchanged: 307

C:\Users\mech>gpg --version
gpg (GnuPG) 2.1.11
libgcrypt 1.6.5

Got feedback from users with MacOS GnuPG 2.0.28 and Debian testing GnuPG 2.1.11.
-> not affected despite very similar, if not identical keyring sizes.

So currently only Windows setups having trouble with --refresh-keys.
Will try to get more feedback for Windows with gpg4win.

Thanks for reporting this! These types of bugs are important. Thanks for
reporting it. I will take a look at it soon.

Current code is perfectly fine as crc-intel-pclmul.c is i386/amd64-only source
file and that target architecture can handle unaligned loads.

Thanks for testing 2.1 and for reporting the results.
Good to know that it works now.

I have good news : gpg 2.1 rocks !
Problem solved and here is the solution :

As Sijie said, the "smartcard compatible" pageant was loading the SIG key and
the AUTH key.

Unfortunately, under gpg 2.0.x, when you export a public key and use gpg2ssh,
the output is the ssh key for the SIG key (and not the auth).

So when using gpg-agent, it was waiting for putty to request the AUTH key and
not the SIG key (as it should !). The "smartcard enabled" pageant was sending
the SIG key so it was working with it.

Now for the good part : with gpg 2.1, we can now natively use --export-ssh-key,
and this command export the AUTH key, so in the end, it works :)

Thank you everyone for the help, and I hope it can helps other people too !

Can we close this bug please ?

Regards

This should be somehow a uncommon thing but i wanted to get notice. I sync my
tofu.d directory with git annex. Removed the .git directory in that place lead a
lot of symbolic link not find the original file, as expected, but when trying to
open a mail from mutt i was not able to see them and the keys were not recreated
as the .git directory wasn't there

gpg: Firmado el jue 10 mar 2016 19:16:12 CLT
gpg: usando RSA clave XXXXXXXXXXXX
gpg: Warning: Home directory contains both tofu.db and tofu.d.
gpg: Using split format for TOFU database
gpg: error opening TOFU database
'/home/guido/.gnupg/tofu.d/email/se/some_email.db': unable to open database file

gpg: signal Segmentation fault caught ... exiting
Violación de segmento

it's probably very small, but i wanted to let you know

thanks for your work!

For history purpose, and trying to maximize information, I have been asked to post some part of the discussion I have
on the mailing list about this problem. Here it is :

I tried older version (of gpg4win) (which, at the time, worked for people with the
same setup as myself), but I can try new version too of course.

That is helpful, because development right now is concentrating more
on Gpg4win 3 with the new GnuPG 2.1 (to become 2.2) and this is where
gpg-agent and pinentry is handled slightly differently. So making sure that
it works with the new version is better for the future.

Ok, I installed gpg4win 3.0.0 BETA 128.
The problem stay the same, no pin is asked.

In the mean time, I tried this tool : http://smartcard-auth.de/ssh-en.html
It replace the pageant.exe that ships with putty. And it works. When I
log on the server with putty, I got asked for the PIN. So I think this
is not a problem with the smartcard or with keys. It seems that it's
only that gpg-agent doesn't trigger the pinentry.

I tried witht gpg-agent on another computer (fresh install) running Windows 7 x64, and
with another smartcard, same problem : no pinentry asked.

Yes gpg-agent is started before, I can see it in the process list (and even the scdaemon process).

In fact, pageant can't be started at the same time as gpg-agent (I suppose it share the same mutex because it
says "pageant is already running" when I try to start pageant while gpg-agent is already running).

Did you start gpg-agent before putty or pageant?

The code in question is only for i386 and given that no SSE instructions are
used I wonder why you consider this a bug. The code might be faster if we would
access the short properly aligned but the question is whether this is worth an
extra copy operation.

jussi: What do you say?

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.

I think this can be resolved. Yes older versions did not allow pasting but
recent versions do allow this. So we've fixed the bug in recent versions ->
resolved. No?

The reporter says he is using ubuntu 14 (i assume 14.4) where the default
pinentry is pinentry-gtk2 0.8.3

ping - will check tonight.

I have two ideas on how to imrpove this:

1. If an appropriate card is plugged in we could try to use it. This is similar to what we do in command-ssh.c

2. Rework the private key file format to allow adding several serial numbers for one card. This rework needs to be done anyway for another features (OpenSSH certifcactes)

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.

That is the commit we have in our source code repository. I copy the patch
below. It is small enough to be applied by hand.

commit 776bee6d370602ff95e93a4aea6a70005dff9ae6
Author: Werner Koch <wk@gnupg.org>
Date: Fri Jan 15 15:32:18 2016 +0100

    common: Cope with AIX problem on number of open files.
    
    * common/exechelp.c: Limit returned value for too hight values.
    --
    
    GnuPG-bug-id: 1778
    
    (backport from master commit 987532b038a2d9b9e76c0de425ee036ca2bffa1b)
    
    Signed-off-by: Werner Koch <wk@gnupg.org>

diff --git a/common/exechelp.c b/common/exechelp.c
index cd9ba7b..6d60b07 100644

• a/common/exechelp.c

+++ b/common/exechelp.c
@@ -21,6 +21,9 @@

#include <stdio.h>
#include <stdlib.h>
+#ifdef HAVE_STDINT_H
+# include <stdint.h>
+#endif
#include <string.h>
#include <errno.h>
#include <assert.h>
@@ -134,6 +137,13 @@ get_max_fds (void)

  if (max_fds == -1)
    max_fds = 256;  /* Arbitrary limit.  */

+ /* AIX returns INT32_MAX instead of a proper value. We assume that
+ this is always an error and use an arbitrary limit. */
+#ifdef INT32_MAX
+ if (max_fds == INT32_MAX)
+ max_fds = 256;
+#endif
+

return max_fds;

}

There seems to be a problem with your reader. We would need to closer analyze
the log (which I copy below):

DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0
DBG: ccid-driver: PC_to_RDR_IccPowerOn:
DBG: ccid-driver: dwLength ..........: 0
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 145
DBG: ccid-driver: bPowerSelect ......: 0x01 (5.0 V)
DBG: ccid-driver: [0008] 00 00
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 21
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 145
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] 3B DA 18 FF 81 B1
DBG: ccid-driver: [0016] FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
DBG: ccid-driver: PC_to_RDR_XfrBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 146
DBG: ccid-driver: bBWI ..............: 0x00
DBG: ccid-driver: wLevelParameter ...: 0x0000
DBG: ccid-driver: [0010] FF 11 18 F6
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 146
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] FF 11 18 F6
DBG: ccid-driver: PC_to_RDR_SetParameters:
DBG: ccid-driver: dwLength ..........: 7
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 147
DBG: ccid-driver: bProtocolNum ......: 0x01
DBG: ccid-driver: [0008] 00 00 18 10 FF 75 00 FE
DBG: ccid-driver: [0016] 10
DBG: ccid-driver: RDR_to_PC_Parameters:
DBG: ccid-driver: dwLength ..........: 7
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 147
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: protocol ..........: T=1
DBG: ccid-driver: bmFindexDindex ....: 18
DBG: ccid-driver: bmTCCKST1 .........: 10
DBG: ccid-driver: bGuardTimeT1 ......: FF
DBG: ccid-driver: bmWaitingIntegersT1: 75
DBG: ccid-driver: bClockStop ........: 00
DBG: ccid-driver: bIFSC .............: 254
DBG: ccid-driver: bNadValue .........: 16
DBG: ccid-driver: PC_to_RDR_XfrBlock:
DBG: ccid-driver: dwLength ..........: 5
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 148
DBG: ccid-driver: bBWI ..............: 0x00
DBG: ccid-driver: wLevelParameter ...: 0x0000
DBG: ccid-driver: [0010] 10 C1 01 FE 2E
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 148
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] 00 82 00 82
DBG: ccid-driver: invalid response for S-block (Change-IFSD)
apdu_send_simple(0) failed: unknown host status error
DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0

The underlying problem is that make clean in gpg4win does not clean up
translations. So they were not regenerated during the build of 3.0.0-beta128 and
the new string was not picked up.

Thanks for reporting.

I've fixed the link.

Without pcscd running, I get a "Not supported" error. The scd.log is attached.
Using pcscd, it works, except for that special case.

Thanks Werner.
For normal users home path is set. Output is taken from root user. We will
update home path as needed. We are focusing on nfiles issue currently.

Would you mind to elaborate about "Commit is
776bee6d370602ff95e93a4aea6a70005dff9ae6". I didn't understand this line.

Thanks
Sandeep

aixtools: Had you a chance to test it?

It seems $HOME is not set in your environment and thus you see the double-slash
for agent-socket and homedir. gpg uses ~/.gnupg as it default home directry and
needs $HOME to resolve "~". As a quick workaround you may export
GNUPGHOME=/home/whereever/.gnupg

The nfiles problem has been fixed in the repo but thre is no released 2.0
version for it, yet. commit is 776bee6d370602ff95e93a4aea6a70005dff9ae6

debug 2048
debug 1024

is what I need.

Thanks. We need to know some more detailed information. Please
put

debug 2018
debug 1024
log-file /somewhere/scd.log

into scdaemon.conf, kill scdaemon and try again. It seems you have not yet been
asked for a PIN so the log won't reveal the PIN. Anyway, you may want to send
the log to me by PM (wk@gnupg.org - key 1e42b367).

I took a look at the source code and now understand what is going on here.
The code indicates: One or more secret keys (primary or sub) were found.
But the UI message suggests that the secret key of the current (primary) key was
found, hence my confusion.

Here are some ideas:

1. EASY: Update the message to indicate it is generic and not specific to the key

being edited.

OR

2. HARDER: Improve the logic so the message is specific to the key being edited.

Thoughts?

Fails with 2.0.29 too, compiled from source. With enabled debug-all verbose in
scdaemon.conf, the log ends with:

2016-03-19 10:12:09 scdaemon[1988] DBG: response: sw=6A88 datalen=0
2016-03-19 10:12:09 scdaemon[1988] operation decipher result: Missing item in object
2016-03-19 10:12:09 scdaemon[1988] app_decipher failed: Missing item in object
scdaemon[1988]: chan_7 -> ERR 100663364 Missing item in object <SCD>
scdaemon[1988]: chan_7 <- RESTART
scdaemon[1988]: chan_7 -> OK

Werner,

Thanks for your response. Here is the requested output.

sysconfdir:/opt/freeware/etc/gnupg
bindir:/opt/freeware/bin
libexecdir:/opt/freeware/libexec
libdir:/opt/freeware/lib/gnupg
datadir:/opt/freeware/share/gnupg
localedir:/opt/freeware/share/locale
dirmngr-socket:/var/run/dirmngr/socket
agent-socket://.gnupg/S.gpg-agent
homedir://.gnupg

Good news is gpg2 is functioning now.
I have resolved the issues by following some of your recommendations.
We are able to generate keys however there are still some issues that should
be fixed on AIX 6.1 system. Also we wonder if there are known bugs in
gpg2.0.29 on AIX 6.1

Here is the list of rpm packages installed.

zlib-1.2.8-1
pth-2.0.7-3
gcc-cpp-4.8.3-1
libgomp-4.8.3-1
gcc-c++-4.8.3-1
curl-7.47.0-1
hexdump-20130926-1
bash-4.2-3
bzip2-1.0.6-1
libffi-3.2.1-1
libgcrypt-1.5.4-1
libiconv-1.14-2
libidn-1.29-1
info-5.2-1
libassuan-2.4.2-1
openldap-2.4.23-0.3
libgcc-4.8.3-1
libksba-1.3.0-1
libssh2-1.4.3-2
gpgme-1.6.0-1
npth-1.2-1
readline-6.3-5
libgpg-error-1.21-1
expat-2.1.0-1
glib2-2.38.2-1
libstdc++-4.8.3-1
pkg-config-0.28-1
libssh2-docs-1.4.3-2
gmp-5.1.3-1
mpfr-3.1.2-1
libmpc-1.0.2-1
libstdc++-devel-4.8.3-1
gcc-4.8.3-1
gettext-0.17-1
gnupg-1.4.20-1
gnupg2-2.0.26-1
openssl-1.0.1r-2

Here is the history of what I have done to fix the issue.

Downloaded source packages from https://www.gnupg.org/
Compiled libgpg-error,pinentry-0.9.7,libgcrypt-1.6.5,libassuan-2.4.2,
libksba-1.3.3 and compiled the below two packages in a different way.

pth-2.0.7

./configure --with-fdsetsize=8192
make
make install

gnupg-2.0.29

ulimit -H -n 8192; CC="gcc -DFD_SETSIZE=8192" ./configure
ulimit -H -n 8192; CC="gcc -DFD_SETSIZE=8192" make
ulimit -H -n 8192; CC="gcc -DFD_SETSIZE=8192" make install

And even while generating the keys I have to set the ulimits (nofiles to

8192. on AIX system which I think it won't work on real time systems.

Currently gpg1, gpg2 (2.0.26) and gpg2 (2.0.29) are co-existing on the
system.

Would you please assist me on how to overcome this nofiles ( ulimit ) issue.
I wish to use plain command i.e., gpg2 --gen-keys instead of ulimit -Hn
8192;gpg2 --gen-keys everytime.

For sure I cannot change the nofiles (ulimit value) at OS level as it may
impact the running application.
Kindly let me know if there are any patches that should be installed.

Also please Share the pricing / support model information if your company is
offering enterprise level support.

Thanks
Sandeep

Here you go:

My master key is offline and I have subkeys on a Yubikey. As expected, I see sec# when listing keys when using the
online system:

gpg -K
sec# 4096R/2FFA7695 2016-02-01 [expires: 2020-01-31]
uid NAME <EMAIL@ADDRESS.COM>
ssb> 2048R/EA7CCF1B 2016-02-01
ssb> 2048R/1E8DA9B9 2016-02-01
ssb> 2048R/5BA60C24 2016-02-01
However, when I go into edit mode, gpg indicates that the "Secret is available":

gpg --edit-key 2FFA7695
gpg (GnuPG) 1.4.19; 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.

Secret key is available.

pub 4096R/2FFA7695 created: 2016-02-01 expires: 2020-01-31 usage: C

trust: ultimate      validity: ultimate

sub 2048R/EA7CCF1B created: 2016-02-01 expires: 2018-01-31 usage: S
sub 2048R/1E8DA9B9 created: 2016-02-01 expires: 2018-01-31 usage: E
sub 2048R/5BA60C24 created: 2016-02-01 expires: 2018-01-31 usage: A
[ultimate] (1). NAME <EMAIL@ADDRESS.COM>
[ultimate] (2) [jpeg image of size 1234]

Tested with several recent versions of GnuPG. Am I misunderstanding this message?

We now require a 64 bit integer type for >= 1.7 (commit 897ccd2)

There are still problems with libtool; see recent Debian problems on building
gnupg for Windows. Thus we won't chnage libtool for 1.7.0.

(The patch has been applied to 1.6 and master)

Please describe the error _here_ and do not link to an external page.

What is the output of

  gpgconf --list-dirs

?

We should create a test case for trust signatures before we start to fix it.

That is for LDAP keyservers.

and there is no w64 version of 1.4

We won't fix such things for 1.4 (Windows)

The current version is 2.0.29 - please try again using this version.

As soon as it is ready. 1.7. will be the next release we plan to do - before
gnupg 2.1.12.

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.

Bug system broke the link URL. Here is a shorter one:
http://security.stackexchange.com/q/115230/16036