Thanks, now this works as expected for me :-)

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

[11:26:04] <gitbot> [git] GnuPG - branch master updated by Werner Koch:
4997433 agent: New option --pinentry-timeout

Good idea.

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.

I suggest to report this to the mintty developers.

The problem itself has been fixed. Please open another bug for the UX problem.

We wont fix that because it has been fixed in 2.1 and backporting make no sense
given that an easy workaround is available.

Please given an example.

I don't count win-iconv a small helper.
We can solve this problem more easily by moving the ut8conv.c code to
libgpg-error which alread has some of the conversion code.

I change the category to whis because this is not a bug but a build requirement.

I am not sure about which code part you are talking. Please can one of you
explain. If this is what I assume, please have a look at commit 25f0f05.

FWIW, we do not copy to create the backup but use atomic renames:

  lock(pubring.gpg.lock)
  read(pubring.gpg) -> process -> write(pubring.tmp)
  rename(pubring.gpg, pubring.gpg~)
  rename(pubring.tmp, pubring.gpg)
  unlock(pubring.gpg.lock)

Thus the worst case is that another non-updating process sees no pubring.gpg
during the time between the two renames.

Note that under Windows we don't have inodes :-(
See also T2135 .
As I remarked several times in the past the only solid way to handle these
problem is to allow access to the keyrings only via a dedicated processs.

We have never seen a real-world bug here. Thus I change this to a minor-bug.
You solution is not that easy becuase we need to maintain that order for all
time and we can't cope with older gpg versions which are still in use on the
same ~/.gnupg - they would have a different lock order and that would indeed
lead to a deadlock. As of now this is mitigated by all gpg versions using the
same config file and thus the same order of keyrings.

Fix will be in 2.1.11. Thanks for testing.

I have pushed chnages to master to fix this problem. One drawback is that
during an import another process "gpg -k" may rarely see no keys at all. A full
fix would either require that we lock the keyrings during all read-only
operations, which would severely hit on the performance of all common
operations, or change the whole system to use a new key access daemon.

If this works the changes need to be backported to 2.0.

Actually this is a copy of the web site version. I fixed both versions. Thanks.

Please ask on the gnupg-users mailing list for help. This is a bug tracker and
not a help forum, sorry.

It would be different issue, but we have similar problem for 'fetch' failure
with an error message like:

gpg: key B00DC692: rejected by import filter" followed by "gpg: Total number
processed: 1

Finally, I confirmed the problem. Sorry for taking long time. My understanding
was bad. I'm going to fix this.

OK, thanks for the response Werner. Perhaps this bug then is to update the website
docs to reflect what I gather may be big changes to this feature as compared to earlier
gnupg releases.

It seems that everything that can be found here (the best source I have found for using
gnupg w/ DNS) is now outdated and will no longer work:
http://gushi.org/make-dns-cert/HOWTO.html

I wanted to learn more about the new changes but I was only able to find the following
references which I'll document here in case someone else comes across it.
Unfortunately, I won't be able to test out the new method as I don't run my own bind
server and like many of us rely on a DNS provider that doesn't allow me to create the
form of DNS record output by --print-pka-records.

I only found three references to the new '--print-pka-records':

2.1.3 Announce:
https://lists.gnupg.org/pipermail/gnupg-announce/2015q2/000365.html

"* gpg: New option --print-pka-records. Changed the PKA method to use

   CERT records and hashed names."

gnupg docs:
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Input-and-Output.html

"--print-pka-records
Modify the output of the list commands to print PKA records suitable to put into DNS
zone files. An ORIGIN line is printed before each record to allow diverting the records
to the corresponding zone file."

And finally an announcement from you in gnupg-devel from last year where you state that
all of the old functionality for PKA has been removed and replaced with something
entirely new (which is just for key 'validation' and not for key installation?):
http://marc.info/?l=gnupg-devel&m=142488047809150&w=2