Meanwhile the toggle command is a dummy and the extra infos for secret keys are
always displayed.

I commited an adjusted patch for GnuPG 2.1 (3e50236).

GnuPG 2.1.11 will print PROGRESS lines which allows in connection with
--exit-on-status-write-error to use that correctly. We should add that option
to gpg invocation of gpgme, though.

That works.
Thanks for your kind support.

Here's something i got from running dbx with benchmark (with "check -access" option
to detect illegal memory access):

dbx benchmark

Reading benchmark
Reading ld.so.1
Reading libgcrypt.so.20.0.4
Reading libgpg-error.so.0.17.0
Reading librt.so.1
Reading libsocket.so.1
Reading libc.so.1
Reading libgcc_s.so.1
Reading libaio.so.1
Reading libmd.so.1
Reading libnsl.so.1
(dbx) check -access
access checking - ON
(dbx) run --verbose
Running: benchmark --verbose
(process id 20779)
Reading rtcapihook.so
Reading libdl.so.1
Reading rtcaudit.so
Reading libmapmalloc.so.1
Reading libgen.so.1
Reading libm.so.2
Reading libm_hwcap1.so.2
Reading libc_psr.so.1
Reading rtcboot.so
Reading librtc.so
RTC: Enabling Error Checking...
RTC: Running program...

...

Algorithm generate 100*sign 100*verify

RSA 1024 bit Read from uninitialized (rui):
Attempting to read 1 byte at address 0xffbfeba8

which is 312 bytes above the current stack pointer

stopped in add_randomness at line 1085 in file "random-csprng.c"
1085 rndpool[pool_writepos++] ^= *p++;
(dbx)

Hope this helps solve the issue.

I'm sorry, do you mean the zip file that i uploaded earlier? That was just
screenshots of the output message which i listed in my second post. It's just
benchmark and keygen, and i am pretty sure both errors are related to ECC key
generation.

It's my first time using this site, please let me know if i need to provide more
information. And thanks!

Re-assigning to GnuPG. It won't be fixed in the old dirmngr package.

Thanks. I did some modifications and also fixed an unrelated bug in the
detection of the poolname. Will go into 2.1.11.

That is a build/runtime linker problem. You have build against a newer
libassuan version than installed on your system. Use ldconfig or as a quick
workaround set LD_LIBRARY_PATH to point to the place where libassuan has been
installed.

assuan_sock_set_flag was introduced with libassuan 2.4.0 which also changed also
chnaged the minor SO number.

And that other bug report was?
You have full user permissions and thus you may comment on all bug reports.

Please describe your problem and do not just post a picture, schreenshort or
whatever. See https://bugs.gnupg.org on how to send a bug report.

From the title of your report it seems to be more a question than a bug - please
ask on one of the mailing lists for help.

Can't seem to edit my first post, so create this second post to provide extra info.

Ran all tests in libgcrypt/libgcrypt-1.6.4/tests directory, benchmark and keygen
failed. Here's the output:

./benchmark --verbose

.
.
.

Algorithm generate 100*sign 100*verify

RSA 1024 bit 310ms 1040ms 50ms
RSA 2048 bit 2370ms 7070ms 150ms
RSA 3072 bit 15950ms 21660ms 340ms
RSA 4096 bit 139410ms 47920ms 620ms
DSA 1024/160 - 600ms 820ms
DSA 2048/224 - 2920ms 3940ms
DSA 3072/256 - 6730ms 9520ms
ECDSA 192 bit
Segmentation Fault (core dumped)

./keygen --verbose
keygen: creating 1024 bit RSA key
keygen: creating 512 bit RSA key with e=257
keygen: creating 512 bit RSA key with default e
keygen: public exponent: 29
keygen: creating 1024 bit Elgamal key
keygen: creating 5 1024 bit DSA keys
keygen: creating 1536 bit DSA key
keygen: creating ECC key using curve NIST P-521
Segmentation Fault (core dumped)

/usr/local/bin/gpg-agent -v --daemon

gpg-agent[2676]: listening on socket '/home/nui/.gnupg/S.gpg-agent'
/usr/local/bin/gpg-agent: relocation error: /usr/local/bin/gpg-agent: symbol
assuan_sock_set_flag, version LIBASSUAN_1.0 not defined in file libassuan.so.0
with link time reference

Yes, with exit code = 127

This is caused by gpg inability of merging the secret keys. We can't fix that
in 1.4 or 2.0. 2.1 does not have this problem anymore.

Start the agent this way:

/usr/local/bin/gpg-agent -v --daemon

errors?

Fixed with commit 09117e7 to be released with 2.1.11

gpg-connect-agent -v

gpg-connect-agent: no running gpg-agent - starting '/usr/local/bin/gpg-agent'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: waiting for the agent to come up ... (4s)
gpg-connect-agent: waiting for the agent to come up ... (3s)
gpg-connect-agent: waiting for the agent to come up ... (2s)
gpg-connect-agent: waiting for the agent to come up ... (1s)
gpg-connect-agent: can't connect to the agent: IPC connect call failed
gpg-connect-agent: error sending standard options: No agent running

Please run

gpg-connect-agent -v

getinfo version
/bye

Please see T1778 (gduzan on Jan 20 2016, 03:41 PM / Roundup) on T1778 for a workaround.

AIX defaults to "unlimited" descriptors. However, the value may be overridden by
setting the hard limit. In tcsh, for example, one can work around the issue with:
limit descriptors 4096
limit -h descriptors 4096

since Outlook 2007 there is no Word editor option anymore. We will not add
support for this to Outlook 2003 as Outlook 2003 is End of Life.

Sorry that this bug was never fixed.

Regards,
Andre

Fixed. Thanks.

The --s2k- options are expert options and should in general not be chnaged at
all. We can't make a list of all such minor chnages related to moving secret
keys to gpg-agent. People who care about this will know anyway.

Werner, there is a typo in your new commit 56275e4392a7b38abe5fdd84fe9d67599cf5e6d1

'defaulte' should be 'default'

+Use @code{name} as the digest algorithm used to mangle the passphrases
+for symmetric encryption. The defaulte is SHA-1.

Also, might it be beneficial to add this change of behavior to either the man page or
to the 'What's changed in 2.1' docs?

Thanks

I have tested 2.1.10, same behaviour asking for a password for the subkey.
------Original Message------
From: Werner Koch via BTS
To: Mr Pratish Surendra Neerputh
To: wk@gnupg.org
ReplyTo: GnuPG's BTS
ReplyTo: GnuPG's BTS
Subject: [issue1848] gpg 2.1.2 with pinentry-curses prompts for passphrase when adding subkeys
Sent: Jan 18, 2016 09:46

I have tried version 2.1.9 as I couldn't get the latest version. It still prompts for a password when adding a subkey, I have also seen this behaviour with a windows binary. It does not seem to affect signing or encryption as signing still just requires the passphrase for the master key.
------Original Message------
From: Werner Koch via BTS
To: Mr Pratish Surendra Neerputh
To: wk@gnupg.org
ReplyTo: GnuPG's BTS
ReplyTo: GnuPG's BTS
Subject: [issue1848] gpg 2.1.2 with pinentry-curses prompts for passphrase when adding subkeys
Sent: Jan 18, 2016 09:46

It is a bug and not a feature.

Thanks for reporting. I'll change this for 2.1.11.

My original problem was that when generating one signing key with gnupg stable aka 2.0.29 and adding a seperate encryption subkey it only asked for my passphase to unlock the master secret key.

Feel free to -re-opne if you experience the same problem with a current gnupg
version.

Ping.
Please tell us the OS version and the GnuPG version.

Several such bugs have been fixed since 2.1.2. Thus I assume this has been
resolved.

Some time passed. Did you tried with a newer version (2.1.10 is current)?

I changed this to a wish because it it questionable whether this is a bug or a
feature of libsecret.

To replicate this bug we need more information: What is yopur OS, which version
of libgcrypt and libksba are you using? "gpgsm --version" tells you these
version numbers.

If you send us the smime.p7m we might be able to find the problem without the
need for the key. Sending that file encrypted to wk@gnupg.org, keyid 1442b367
would be okay.

Let's assume this is the case and the bug has been resolved.

D321: 754_0001-Fix-possible-_SC_OPEN_MAX-max-problem-on-AIX.patch

Given that you are using gpgme, the problem might already be there. if my
assumption is right the "...SC_OPEN_MAX-max-prob..." patch should fix this for
gpgme.

D322: 753_0001-Fix-possible-AIX-problem-with-sysconf-in-rndunix.patch

Just in case you are not using /dev/random, the "Fix-posssible..." patch may
help for 1.4.

D323: 752_0001-common-Cope-with-AIX-problem-on-number-of-open-files.patch

Indeed the sysconf patch had not been backported to gnupg 2.0. Please
try the attached patch for 2.0.x (sorry for the trailing white space changes).

(newer?) AIX versions have the bug that sysconf returns INT_MAX32 for the number
of max. open file descriptors. That leads to a long delay due to closing all
possible open file descriptors. See T1778.

That bug has been fixed in GnuPG 2.1 but not in libassuan. I have fixed it with
commit 7101fcb for libassuan which wilk go into libassaun 2.4.3. This might
also help with GnuPG 2.0.26 but I need to check that.