@gniibe I have submitted D565 to change the error message on curses initialization to "Required environment variable not set"

Major problem here (before the change) was that clock_gettime returned an error with no valid value of the time, which confuses gpg-agent's calibration of time. This occurred on (not newest) Solaris kernel, as it offers clock_gettime function in the library and CLOCK_THREAD_CPUTIME_ID constant in the header.

I mentioned the two POSIX getconf settings you referenced in those links, and the developer that implemented CLOCK_THREAD_CPUTIME_ID and a couple other CLOCK_THREAD types had this to say:

FreeBSD has _POSIX_THREAD_CPUTIME > 0.
GNU/Linux has _POSIX_THREAD_CPUTIME == 0, because older kernel doesn't support the system call.

Reading pages of the following links:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html
https://docs.oracle.com/cd/E36784_01/html/E36873/unistd.h-3head.html

Hi gniibe!

Opened https://dev.gnupg.org/T5631 for the pinentry-curses issue.

do you want me to open a separate bug report for the pinentry issue and reference this bug report?

You did all the work to locate the bug, gniibe! Nice job identifying it so quickly.

Thank you for locating the bug for (1).

You're definitely on the correct track: setting 's2k-count 29176832' in my gpg-agent.conf fixed the gpg-agent hang. Now the decrypt I was trying earlier works. Also, 'gpg-agent' is no longer accumulating CPU time, and I can kill it off with gpgconf.

s2k-count matters when you import the key.

When I run the gpg-connect-agent, it starts the agent and then hangs without responding with the time:

My current keypair is old, but it's stored on my workstation's disk and appears to have been correctly imported into the private-keys-v1.d/ store. I do still have my 'secring.gpg' too, in case I ever need it for an older GPG.

It seems that there are some problems: https://bugs.python.org/issue35455

After the passphrase has been entered and gpg hangs, gpg-agent starts to accumulate CPU time at a rapid rate, as displayed by 'ps -ef'.

gpg-agent doesn't disappear from the process list after entering the passphrase; in fact it can't be killed with anything but 'kill -9'. 'gpgconf --kill gpg-agent' cannot kill it, the gpg-conf command just hangs when trying to.

Yes, xterm as a terminal type is correctly supported on OpenIndiana. I have been using it for many years, for both command-line and curses-based programs. It works well.

With the options that Werner recommended for debugging in my ~/.gnupg/gpg-agent.conf:

I think that the first problem is related to T5577: Null ptr dereference in gpg-agent (gnupg 2.3.2).
If gpg-agent has gone (after entering passphrase, it must be SEGV.

Let us try to solve problems, one by one.

Hi gniibe!

BTW, when pinentry interaction doesn't work well, use of --pinentry-mode loopback option for gpg may help you.

It seems for me that there are multiple problems.
For pinentry-curses, please have a look at: T4771: pinentry-tty/pinentry-curses interact a user as background process
It only works well in some situations; It doesn't work when the screen is occupied by foreground program like Emacs and Midnight Commander.

Thanks for the guidance, Werner!

Just to be sure. please provide the output of

Note: The commit in master (1.9) is rCe0898d0628789414
and in 1.8 it is rC03e6d6597198ee

It is possible to disable the mlock thingy and if that is not wanted the application should be modified to be suid(root) during Libgcrypt initialization - this is actually how we handle this in GnuPG. Or maybe I don't understand the bug described here. It seems to be more of a support question.

No, c99 was never required. Meanwhile we use a few c99 features but those are supported without any compiler option.

-std=c99 is probably the reason that the tests fail.

Please try with out supplied CFLAGS or change them from

@sarman: Your question is actually a support question and not a bug report. Please read the documentation, use the public help channels (so that other can also learn from the issue), or get in touch with a commercial support provider.

I think that what you want is adding --batch option. In the gpg manual, we have:

--passphrase-file file
       Read  the passphrase from file file. Only the first line will be
       read from  file  file.  This  can  only  be  used  if  only  one
       passphrase is supplied. Obviously, a passphrase stored in a file
       is of questionable security if other users can read  this  file.
       Don't use this option if you can avoid it.

Hello Team,

For operations which require private key, it is needed to unlock private key.

Regarding Cygwin: The sources are a bit hard to find.
https://cygwin.com/packages.html
-> https://cygwin.com/packaging/repos.html
-> https://cygwin.com/git-cygwin-packages/
-> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/libgcrypt.git;a=summary

Regarding GNU/kFreeBSD, my machine is using the FreeBSD 9.0 kernel, which does not yet have the security.bsd.unprivileged_mlock oid. Like what was mentioned here: https://lists.debian.org/debian-bsd/2014/08/msg00092.html

For Cygwin, I can't find how its libgcrypt package is built.
I found this for MSYS2: https://github.com/msys2/MSYS2-packages/tree/master/libgcrypt
This for Mingw-w64: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-libgcrypt

I tested on FreeBSD. Same errors (t-secmen and t-sexp) are reproducible when we set:

On Solaris, the test errors are because of:

USAGE
       Because of the impact on system resources, the use of mlock() and
       munlock() is restricted to users with the {PRIV_PROC_LOCK_MEMORY}
       privilege.

OK, I identified the problem on OpenIndiana. The inclusion of <unistd.h> causes inclusion of <sys/types.h> before config.h. I'm going to fix this.

For GNU/Linux or GNU/kFreeBSD system, libgcrypt 1.8 with libgpg-error 1.36 has no problem in Debian build:
https://buildd.debian.org/status/package.php?p=libgcrypt20

In solaris11openindiana-log2, we have two errors: one for ulong, and another for ushort.
I fixed the former. It is because of our mistake of using ulong before it is handled by libgcrypt/src/types.h. In the first place, it is implemented by "unsigned long", so, there is no need to use ulong here.