Pushed the change: rC082ea0efa9b1: cipher: Add sign+hash, verify+hash, and random-override API.

What do you mean by asking on a ML or on IRC for networking help?

Hi, I have installed 2.2.32, but still get the same error.

Thank you for your reply! I have updated version numbers and the used OS. I will try with GnuPG 2.2.32

I can't tell you why you get this error. However, since Oct 1 the keyserver access does in many case not work anymnore. This has been fixed in GnuPG 2.2.32, which I released a few minutes ago. You may install this on top of gpg4win 3.1.16.

Please update to 2.2.32 if you have problems with keyservers etc.

Backported to 2.2.32

We have been hit by the Let's Encrypt root cert switch. Thus a fixed version will soon be released. See T5639 for details of the problem.

You mean Gpg4win. The solution for Gpg4win 3.1.x is to install the latest GnUPG LTS installer for Windows on top of the latest Gpg4win version. See
https://lists.gnupg.org/pipermail/gnupg-announce/2021q3/000464.html
Noet that there will very soon be a 2.2.32 to fix a problem with Let's encrypt protected keyservers (T5639).

Just for everbody else who might be waiting for a new release. Workaround is to simply use the previous version: https://www.gpg4win.de/change-history-de.html (3.1.15)

Thanks for the report. However, for 1.4 we will only apply important real world security patches. A brief review did not reveal any setious problems. Theoretical memory leaks will not be fixed. Note that your report also includes patches to parts of the code which are not anymore used.

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

Thank you for your investigation.

Hi gniibe!

Hi gniibe!

Currently, I am using --lock-never config to avoid generating lock file as a workaround.

How about:

• Only when hash-handle is used for multiple purposes, a user needs to compose SEXP
• when hash-handle is used for a single purpose, a user doesn't need to compose SEXP, but static one.

In the original SuSE's patch, _gcry_pk_sign_md function gets data template as SEXP as an argument, and the implementation does decomposing SEXP to get hash-algo. (A user of the function needs to compose SEXP with hash-algo.)

For 2.3, when you use PC/SC, please use the disable-ccid option in your .gnupg/scdaemon.conf.

Hey, are there any other logs that I can grab? Is there a way to override the defaults, which will allow me to use the right key to sign?

okidok - understand and thank you.

Quite possibe and thanks for the report. However, this is a dev state of the things and thus not expected to work. I'll keep this open as a reminder for me, but in general I would prefer to get a report at the gnupg-devel ML.

Sorry, a hostname with slash is simply not allowed by IETF standards. Given that the hostname is part of temporary file names, you will run into an error. Yes, we could remap the slash in the mktemp function but there are lot of other plzces where the hostname is used and certain properties are expected.

After testing about a dozen different term types and doing some library tracing, it appears to be that any terminfo type for which has_colors() is false (so the start_color code is never called) works correctly.

Hi gniibe!

Another link: http://hea-www.harvard.edu/~fine/opinions/xterm-problems.html

Just tracking my own additional investigation still about past Werner statement "percent escaping is correct and required" when this bug was closed for 1st time.
Also found interesting past references into rG055f8854d3f4 and rGe064c75b08a5 but only this last seems indeed much more specifically directly involved since it really contains related part of code (common/stringhelp.c) directly involved with this bug report for 'percent escaping' ':' (colon) character with '%3a' string even if sometimes, when possibly un-needlingly done, may even provide users unexpected on-screen displayed results like those I documented in this bug.
Problem now is that to really fully understand why on-screen displayed strings by 'gpgconf --list-dirs' correctly show a ':' (colon) correctly expected character near an unexpected (by end users) '%3a' (percent escaped) string that should just have corresponded with another simple (& user correctly expected) ':' colon character I can only really see to 2 options:
A) reopening this bug once again :-S ;
B) simply opening a new separate one asking for some additional explanations and maybe even to consider some future slight code changes to (at least for Windows OSes) ensure 'gpgconf --list-dirs' directory displayed paths results are more UI consistent with 'gpgconf --list-dirs homedir' or 'gpgconf --list-dirs sysconfdir' displayed ones where displayed C:\... paths always correctly display ':' (colon) instead of '%3a'.
So far this last seems me best viable option also because in same rGe064c75b08a5 I also saw another piece of code (tools/gpgconf-comp.c) with some similar code lines, that apparently (it seems me) if directly referenced (at least only for Windows OSes only, so maybe when a system variable %OS%==Windows_NT exists) instead of current one (common/stringhelp.c) also providing '%3a' 'percent escaping' results, might then have probably also easily avoided '%3a' user unexpected on-screen displayed results only depending by 'percent escaping'.

Just adding this note for any future reference needs only (or even message localization reference, since involved text characters strings are also expected to be among Italian language localized messages even if involved strings are not specifically being localized).

Well this seems to be a gcc 4.2 bug. But well, forward declarations should go into a separate file so that tehre is only one place which would require changes. In this case it does not matter.

All of my testing has been done while connecting via ssh to my OpenIndiana workstation. I'm using PuTTY 0.76 as my terminal/SSH client.

It appears to you identified the problem really quickly again. If I select the entire screen and paste it, the dialog text is there:

@mooney Just in case when it's color related problem, could you try to cut&paste the text of the screen when pinentry should display a dialog box?

I found some links:
XTerm FAQ:
https://invisible-island.net/xterm/xterm.faq.html
Why not just use TERM set to "xterm"?
https://invisible-island.net/ncurses/ncurses.faq.html#xterm_generic
What $TERM should I use?
https://tools.ietf.org/doc/xterm/xterm.faq.html#xterm_terminfo