Is there some other command I should run to check which curses it's using? I see there's a --debug flag but I'm not sure how to use it.

I think that either of following might be true:
(1) macOS has older ncurses (which doesn't support ioctl well, to get columns/lines info) in system
(2) macOS has BSD curses (with no suport for ioctl)

I installed it with brew and didn't provide any special options. This is one of the new M1 macs though, so perhaps there is some platform check deep in the install that is getting confused?

Thank you for the information. So, you don't have these environment variables set.

printenv COLUMNS LINES shows no output, however if I echo $COLUMNS $LINES I see 160 48 both before and after the password prompt.

Curses application (of pinentry) get information of screen size by:

• environment variables (COLUMNS, LINES)
• operating system using TIOCGSIZE or TIOCGWINSZ ioctl
• tinfo data base

Caveat, Caveat (Warning, Warning) I know I've been quite busy with other activities, and ITMT my client status went really bad and even worse reached its final point and self-rebooted while I was trying to suspend it, but anyway this update is needed because I just discovered that my last choice to prepend %ProgramFiles(x86)%\Gpg4win\bin;%ProgramFiles(x86)%\GnuPG\bin;%PATH% was not very good. Why ? Simple, as I discovered today (few hours ago) using this syntax, will only be valid&useful only if you really want to restrict Gpg4win v3.1.16 usage only to accounts in Administrators group.
Ok, so now you're wondering: How I discovered this effect ? Again simple, desktop shortcut that I have for starting new 'Command Prompt' was modified to always run as Admin, so I have to specifically choose when I want to run it without Admin privileges, and so today, after I didn't notice I had launched Kleopatra before, right after closing it, I launched a new Command Prompt and so when I tried to run 'gpgconf --kill gpg-agent' I only received this answer :

'gpgconf' is not recognized as an internal or external command,
operable program or batch file.

So then I obviously opened another 'Command Prompt' as an Admin and correctly killed gpg-agent so ensuring that everything was indeed still working as expected.
So now you're asking, why in the past I had confirmed that prepending those paths I was expecting to work, really worked ?
If you remember well how I reported Iìve done my past installations and tests, I also made those changes in OS System Environment Variables really on the fly and then just re-confirmed they were valid via GUI by simply pressing [ OK ].
And so this is the test I just repeated again and so I can re-confirm you that only after by doing so, every new 'Command Prompt' started as non Admin user will have proper access to those newly prepended paths.
Otherwise, those paths will work only for any new 'Command Prompt' if run with an account in Administrators group.
So while this can still be temporarily fine for me, I'm unsure it might have been a real standard choice for Gpg4win v3.1.16 setup run without experiencing the error I'm reporting in this bug, so please just ensure to avoid using %ProgramFiles(x86)%\Gpg4win\bin;%ProgramFiles(x86)%\GnuPG\bin; syntax when changing your paths on the fly by prepending it or appending to %PATH% even if you should try to definitely solve same error I found and reported with this bug. OK ?
Thanks for your attention (for now).

Thanks for the help. After running make clean / aclocal / autoconf / autoupdate … &etc, the patch worked & make check passed all eleven 11 tests, ie the new 12th test was not performed.

Thank you for your log.

Here is ”config.log", or did you want just the screen output?

Please show us the log of configure, not just the result of the failure.

I’m not that geeky anymore.

If you see wrong result for the decision of the HAVE_LOCK_OPTIMIZATION (for running the test), it's better to contribute to gnulib (https://www.gnu.org/software/gnulib/) for the detection of thread features.

I've just confirmed that the fixes in the commit "rE50e0f32b1935" above to configure.ca & tests/makefile.am do NOT fix the problem under MacOSX Catalina 10.15.7 using Xcode 12.4, gcc Apple clang-1200.0.32.28.

I'm getting the same error even when compiling with x86_64/glibc (from Apple clang-1200.0.32.28) :(

To be conservative, given the situation most implementations already support zero-removal and zero-recovery, it's better to output zero-removed signature, that is, signature with well-formed MPI.

My proposal is applying SOS (MPI with leading zero octets) patches, for 2.2, because there may be existing keys with SOS already.

It's not yet solved.

Reading the documentation of musl, it seems that there are no equivalent feature which detects if an application is single-threaded or not.

In the libgpg-error implementation, it may skip synchronization when it can detect an application is single threaded. The t-lock-single-thread test checks if it really skips as intended.

Thank you.

(forgot to upload the patch to the last comment)

I am fine with either way. The memcmp variant is probably cleaner to make sure all works as expected in all cases.

Thanks for the well written bug report and the fix.

So that you don't need to chase the downstream bug report, the problem from a user's perspective looks like this:

Thank you. Extending the semantics of GCRYCTL_CLOSE_RANDOM_DEVICE sounds good to me. I think the deinit functions were created initially especially not to change the semantics of existing code using GCRYCTL_CLOSE_RANDOM_DEVICE, but I agree that it will probably not be an issue.

I guess this is solved. Feel free to re-open and schedule for 2.2.34

Second issue is also fixed.

Here's a patch against b091a250d1411f9962385d1338c13481da2e0f9e.

PS, knowing little about it, I tend to look at builds scripts here https://github.com/msys2/MINGW-packages on how to do things.
eg https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-libgcrypt

Thank you, it successfully cross-compiles from latest git commit (not sure if it "runs", not tested it).

Part 1 was applied. Part 3, Part 4, and Part 7 are irrelevant now, because we now have rndgetentropy which doesn't use device.

It was in the middle of merging jitterentropy. Please see T5692 (newer jitterentropy uses pthread by default, which was disabled now).

First issue is fixed.

Rating as High because this can be used for a DoS attack on individual users.

Following patch should prevent assembly files being built at all with --disable-asm:

Thanks for your report.

Please see T5696.

cross-compilation settings:

The cross-compilation settings:

{ # 2019.12.13 # https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=summary
	#'repo_type' : 'archive',
	'#url' : 'https://www.gnupg.org/ftp/gcrypt/libgpg-error/libgpg-error-1.43.tar.bz2',
	#
	'repo_type' : 'git',
	'recursive_git' : True,
	'url' : 'git://git.gnupg.org/libgpg-error.git', # https://git.gnupg.org/ # https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=summary
	##'url' : 'https://dev.gnupg.org/source/libgpg-error.git', # https://git.gnupg.org/ # https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=summary
	#
	'configure_options': '--host={target_host} --prefix={target_prefix} --disable-shared --enable-static --disable-rpath --disable-doc --disable-tests --with-libiconv-prefix={target_prefix}', # --with-libintl=no --with-libpth=no',
	'custom_cflag' : ' ', # 2019.12.13 it fails to build with anything other than this, eg it crashes with -O3 and -fstack-protector-all -D_FORTIFY_SOURCE=2 
	'run_post_regexreplace' : (
		'autoreconf -fiv',
		'./autogen.sh --build-w64 ', 								 
	),
	'depends_on' : (
		'iconv', 
	),
}

Pinentry: pinentry-curses (pinentry) 1.2.0
OS: macOS 12.0
Terminal: xterm-256color (via zsh in the default Terminal.app)

Additionally, poly1305-s390x.S is being compiled despite running/targeting a PC system:

What is your Pinentry version, which OS is that, and which terminal type?

In the documentation, I found:

Please also refer to https://github.com/microsoft/vcpkg/discussions/20755 where we discuss on how to approach GnuPG libraries for a native Windows compilation.

In T5687#151853, @werner wrote:

FWIW, the gnupg installer comes with dll, header and import files. You may use them.

No, our admin left us and took all scripts and docs with him. We need to set it up again. You better use this system anyway, patches etc on GitHib are not used.

GnuPG requires a Unix system to build. We do not support building natively on Windows. Sorry.

Adding the check on host side, I pushed the change: rGa575b0aba542: scd:openpgp: Support longer data for INTERNAL_AUTHENTICATE.

Or, we can use memcmp to avoid arguing semantics of strncmp, and make it a bit cleaner to avoid calling strlen multple times by put_membuf_str.

diff --git a/g10/export.c b/g10/export.c
index 98c4623cf..c7cfcfaa4 100644
--- a/g10/export.c
+++ b/g10/export.c
@@ -2133,14 +2133,15 @@ key_to_sshblob (membuf_t *mb, const char *identifier, ...)
   size_t buflen;
   gcry_mpi_t a;

We know that problematic strncmp implementation: T5443
So, I don't blame Coverity. But I think that it's better to fix strncmp implementation.

I tried following the README instructions, but getting:

I just read https://github.com/gpg/libgpg-error/blob/master/README#L119 and realize this is by design...

Okay, I revisited the code:

The internal hashing of ed25519 is not used by OpenPGP but instead we pass the hash of the message to the ed25519 function and thus to the card. Pushing a message through a card is a no-go - way too slow for any normal sized message.

Since hashing happens on-card for ed25519 I'm not sure what limits gpg wants to impose, currently the data is passed straight through and scdaemon will happily try to send more than 255 bytes of data as a short apdu here. My patch is probably not correct, I assume it needs to care about cardcap.ext_lc_le and chunking as well.

That does not seem to be right. You don't need 255 bytes for an ECC key. It would be best to get scdaemon logs simialr to the gpg-agent logs. Set "debug ipc,cardio" into scdaemon.conf.

Under C11, it seems OK (strncmp).
https://stackoverflow.com/questions/38878195/does-this-usage-of-strncmp-contain-an-out-of-bounds-read

I applied most of gnupg-coverity.patch.

• Part 1 is not applied; It should be handled later.
• Part 2: applied
• Part 3: applied
• Part 4: applied, but spell fixes not require ChangeLog entry
• Part 5
  • ecdh part is fixed differently
  • export.c part is not applied for now, because of semantics/interpretation of strncmp; POSIX says differently although it says it's ISO C standard which defines. https://pubs.opengroup.org/onlinepubs/9699919799/functions/strncmp.html
• Part 6: applied
• Part 7: applied, but empty initializer is GNU extension (or the way of C++), so first 0
• Part 8: applied
• Part 9: applied, but one more fix