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.

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

As Dashamir Hoxha in the mailinglist gnupg-users mentioned, even with the
--quiet flag enabled, there still is logging output after/during the validation
of the trust-db.

When the user enables the --quiet flag, there should be no log_info output to
the stdin. At most points in the code its managed like in ./g10/trustdb.c:970
(Commit b752d2c93778e6a1c1de3eddf8fc725b0ddd354e in master from the public Git).
But after the silenced output there, it goes into the validate function, where
still is a log_info output in ./g10/trustdb.c:2057 (Same commit as mentioned
above).

relevant to T1424

I have not tried this on 2.1.

To reproduce

% gpg --recv-keys 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9

74D1153FB159BB3D1BAC641CAC504BE650012B98

    % gpg --edit-key 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
    tsign with 2 (I trust fully), depth 1, domain "aclu.org"
    Check validity of 74D1153FB159BB3D1BAC641CAC504BE650012B98

If you make the trust signature without a domain specified,
74D1153FB159BB3D1BAC641CAC504BE650012B98 will appear as "full". With the domain
specified, it appears as "unknown".

That's excellent! I tried with no luck to find a roadmap on when 1.7 could be released;
do you have any ETA? How could I help to make it happen?

Thanks!

It is fully supported but you need to link agains libgcrypt 1.7 which has not
yet been released.

Hi Clint,

Out of curiosity, have you tried this on 2.1?

I realize this is probably very easy to reproduce, but could you nevertheless
list the commands that you used to show the bug?

Thanks!

Updated patch to check that the requested key usage is SIG before checking for a
secret key.

D296: 793_sign-fix.patch

Werner pointed out that the quick integrity check is not used due to an attack
by Mister and Zuccherato. However, this attack does not make use of any
information from the PK-ESK packet. It just uses the session key. As such, the
quick integrity check should not be done in the dek->symmetric case either.

I think it is possible to fix this issue so that we can use the quick integrity
check in the future. My post about this to the openpgp group is here:
http://mailarchive.ietf.org/arch/msg/openpgp/A_r93YIukOqzvrmd44F-Jl3dHbc .

My suggestion is a not-backwards compatible change. For messages that currently
exist, it is acceptable to do the quick integrity check if we can rate limit the
oracle (to recover the first two bytes from N blocks costs (N+1) * 2^15
decryption attempts). This is definitely safe, as Mister and Zuccerato point
out, in the interactive case. Do we have a way to reliably detect this?

Sorry, I was using --check-trustdb as a shorthand for the actual function.

bkuptocard had been not implemented, but it was finally implemented in 2.1.11.
If any problem, please let us know.

I cannot reproduce this with current master and a Yubikey4. Can you please
retry with the current master?

Also, are you sure that you are not mixing GnuPG components you compiled with
the ones provided by your operating system? Also, what made you try to compile
GnuPG in the first place?

Please open a separate bug for the other issue. No 'by the way's in bug reports
please.

Fixed in eea139c.

On Sunday 06 March 2016 at 15:18:54, Neal Walfield via BTS wrote:

is for --check-trustdb

Thanks for reporting this. The right solution is for --check-trustdb to ignore
legacy keys.

If i remove the com-certs I get the exact same behavior as I'm seeing on windows.

aheinecke@esus ~/a/e/src> export GNUPGHOME=$(mktemp -d)
aheinecke@esus ~/a/e/src> gpgsm -k
gpgsm: keybox '/tmp/tmp.hyElMR6oUi/pubring.kbx' created
aheinecke@esus ~/a/e/src> gpg2 --import
~/arbeit/gpg4win/zertifikate/testuserA-pub.asc
gpg: /tmp/tmp.hyElMR6oUi/trustdb.gpg: trustdb created
gpg: key 6CFBC912: public key "Test UserA <testusera@example.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
aheinecke@esus ~/a/e/src> gpgsm -k
gpgsm: keydb_search failed: Invalid argument

From the debug output it looks to me that gnupg is using keyring functions to
work with the keybox.

I can reproduce this now without Kleopatra and on GNU/Linux:

export GNUPGHOME=$(mktemp -d)
gpgsm -k

< imports /opt/gnupg/share/gnupg/com-certs.pem >
(this is not done on windows so maybe the errors differ because of that)

gpg2 --import ~/arbeit/gpg4win/zertifikate/testuserA-pub.asc

Result:

gpg: [don't know]: invalid packet (ctb=00)
gpg: keydb_get_keyblock failed: Value not found
gpg: [don't know]: invalid packet (ctb=00)
gpg: /tmp/tmp.f5ub2ZRYC0/pubring.kbx: copy to
'/tmp/tmp.f5ub2ZRYC0/pubring.kbx.tmp' failed: Invalid packet
gpg: error writing keyring '/tmp/tmp.f5ub2ZRYC0/pubring.kbx': Invalid packet
gpg: [don't know]: invalid packet (ctb=00)
gpg: keydb_search failed: Invalid packet
gpg: key 6CFBC912: public key "[User ID not found]" imported
gpg: [don't know]: invalid packet (ctb=00)
gpg: error reading
'/home/aheinecke/arbeit/gpg4win/zertifikate/testuserA-pub.asc': Invalid packet
gpg: import from '/home/aheinecke/arbeit/gpg4win/zertifikate/testuserA-pub.asc'
failed: Invalid packet
gpg: Total number processed: 0
gpg: imported: 1

gpg2 --version
gpg (GnuPG) 2.1.11
libgcrypt 1.7.0-beta307

I'll try now with git master.

The debug output from gnupg for an import that caused a corruped keybox.

It's not for the attached pubring.kbx but I have the file that was generated If
you need it.

What I did in the log was to start kleopatra (The output of process is 2428 is
likely the debug output of the initial keylisting kleopatra did)

Then imported a test key and afterwards closed kleopatra.