This is no longer an issue with gnupg master:

% socat - tcp-listen:11371
GET /pks/lookup?op=index&options=mr&search=foobr HTTP/1.0
Host: localhost:11371
Connection: close
Via: 1.0 tinyproxy (tinyproxy/1.8.3)
Pragma: no-cache
Cache-Control: no-cache

Feel free to reopen with more specific information.

As far as I can tell this is a feature and not a bug. gpgconf reads stderr and
writes that to the eighth column.

I cannot reproduce this with current master. Feel free to reopen this bug if
you manage to reproduce it.

Fixed in abb352d.

Sorry, that second log does not show anything new. I'm attaching a verbose log
for reference that I obtained the way I described using the version you used.
For me all tests pass, so unless we get more information on the failures it is
impossible to tell what's going on.

hi, this is my new test log, my cmd is
$ make -C tests/openpgp check verbose=2

Ok, if you agree that this is a useful feature then I will implement it.

Adding an API to the --quick-* commands of gpg 2.1 is no my shortlist for GPGME.
This will make things much easier - including key signing.

I can understand the reason to avoid binary data in a repo.

I have not checked but iff we use estream to access a plain old keyring it would
be possible to use the existing unarmor code and feed that to an es_fopenmem
object.

(Sorry about the question about the OS - my fault)

Please also tell us what OS you are using.
Are you running in FIPS mode?
The output of "gpg --version" would also be helpful.

Fixed in 42d4c276. Thanks!

It is not trivial, but I guess we could create a temporary keyring and import
the key. But to be honest I don't understand why storing base64-encoded random
junk is somehow better than storing the junk itself, I mean it wont diff better
or something.

I approved you as a user, if you still cannot comment on the bug, please ping me
again.

I'm changing this from "nobug" to "bug", because it is clearly causing problems
for people with separate per-device signing keys, or with multiple smartcards
(e.g. work and home)

Werner,

Thanks a lot. I will try to apply the patch.
Can you please let us know if your company is offering enterprise level
support.

Thanks
Sandeep

Fixed on 2016-03-19 with commmit af9a4afb. Note that --quiet shall not suppress
all output.

(The commit you gave is wrong).

Thanks for the report. Probably fixed with commit e2c5781.

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

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?

I think in my previous messages the most important feature I'm missing was not
clear as I've mostly talked about subkeys and ECC curves. But what really
hinders me in making Kleopatra's key gen dialog more user friendly immediately,
even with default parameters for the key, is the API limit of only one user ID.

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

I don't think this is a doc or FAQ issue, i think it's an actual bug that has a
significant effect on usability.

If gpg has an available key that would work, it should use it, rather than
preferring the unavailable key.

If the user explicitly specifies an unavailable subkey then sure, gpg should
fail. But if they've only specified their primary (or their UID) then gpg
should be willing to use any available active (non-revoked, non-expired) subkey
with the right usage flags instead of failing if an unavailable one has a newer
date.

Leaving the GUI vs. Commandline argument aside. I still think the batch keygen
API needs to be "modernized"

E.g. with improved authentication support in gnupg 2.1 it will become more
common to generate a key with an authentication subkey. Even the common case of
different Certify / Sign / Encrypt subkeys is not supported by the current API.

Maybe the Curves / Algos can be split up but I think gpgme needs API to query
supported Curves / Algos from GnuPG as this is more dynamic in GnuPG 2.1 then it
has been in previous versions.

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

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?

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

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)

There won't be any output if the keyserver responds with success. In other
cases you will see an error message (modulo the resolved bug T1832).
However, even if the keyserver responded with OK, there is no guarantee that the
keyserver worked as expected or that it properly syncs with other keyservers.

To make sure that you key is really on the keyservers, you should ask an
arbitrary keyserver for your key after giving it a few days to sync up.

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.

The actual plan is to restrict the wauys how gpgme can create keys. In the
future there will be only one way to create a key and no way to select an
algorithm. Those who want to use non-default algorithm should resort to the
command line and the --expert option.

Fixed with commit 1aad5c6.
Thanks for the easy test case.