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

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.

You should not change a cipher algo because the OpenPGp preference system takes
care of it. If you really want to do it, you need to change the config files
directly. See also the FAQ.

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!

Here is the actual error. how to overcome in AIX 6.1
Some of the users have bash shell and some have ksh.

#gpg-connect-agent 'getinfo version' /bye
gpg-connect-agent: can't connect to the agent: IPC connect call failed

This has been fixed (see the message from Werner today on gnupg-devel with
message-id <87bn6mr28v.fsf@wheatstone.g10code.de>)

I have only been pulling from .tar.gz files.

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?