Applied the RSA part.

Ah, other possible case is .. in hostname.

It's hard to investigate your problem, with no information of host for the query.
I mean, there is no case to replicate (for us).

Fixed in 2.3.3.

Fixed in GnuPG 2.3.3.

Fixed in GnuPG 2.3.3.

Thank you for locating the bug!

I should have explained the context.
No, there is no discussion about this in the WG.

I'm reading RFC5297, which says:

SIV can be used as a drop-in replacement for any specification that uses [RFC3394] or [RFC3217], including the aforementioned use. It is a more general purpose solution as it allows for associated data to be specified.

I think that a simple way is defining a table (string -> token) by ourselves in yylex, not enabling %token-table.
(Then, we don't need to depend on the feature of string with %token, which is not supported by POSIX yacc.)

Now configure with
--enable-hmac-binary-check="I know engineers. They love to change things." works.

Please tell me reader names to skip.

I push a change: rC070935965763: build: Use KEY_FOR_BINARY_CHECK for --enable-hmac-binary-check..

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

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.

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.

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.

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

@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

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

Thank you for locating the bug for (1).

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:

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'.

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.

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.

Thank you for reporting.
Fixed in master.

Use of version 5 format for Ed448/X448 was pushed by rG86cb04a23d2b: gpg: Ed448 and X448 are only for v5 (for subkey)..

As the bug I located is a simple fix, I think it can be also applied to 2.2.

Bug in creating such a blob is fixed in rG08a3a4db27dc: kbx: A 20 byte fingerprint is right filled in version 2 blob..

Fixed in rGcc6152b802f2: gpg: Skip the packet when not used for AEAD., but I put wrong bug-id in the commit message.

I was wrong to fix this issue; It is specifically the issue of PKT_ENCRYPTED_AEAD packet. And we already have code to skip the data part by free_encrypted. The problem is that free_encrypted is *not* called when it was PKT_ENCRYPTED_AEAD.

Pushed the change to libgpg-error and libgcrypt (1.9 and master).
Let us see if there are any problem(s) for that, I will apply it to other libraries when it will be found no problem.

Thank you for the information.
For the record, I put the link to the email submitted:
https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html

It parses wrongly. I think that we need a fix like:

diff --git a/g10/mainproc.c b/g10/mainproc.c
index 1ee5b9a6e..7f51b263b 100644
--- a/g10/mainproc.c
+++ b/g10/mainproc.c
@@ -725,6 +725,9 @@ proc_encrypted (CTX c, PACKET *pkt)

Thank you for pointing out. Since hmac256.{c,h} can be used by others, I think that it is better to keep those two files, instead of merging it into one.

Thank you.

I see your point. I'd like to locate/identify where the change comes from.
I think that what you refer by "new libtool.m4" is actually macOS local change (I mean, not from libtool upstream, AFAIK).
Could you please point out the source of the change?

I misunderstood as if we need to update libtool from upstream.

About merging our local changes.