Backported to GnuPG 2.2.

I take this ticket. The way to go is removing all such cases.

Reference to a CVE for old MinGW-W64: https://nvd.nist.gov/vuln/detail/CVE-2018-1000101
https://sourceforge.net/p/mingw-w64/bugs/709/

At least old Windows versions did not add a nul in the truncation case. Thus I used to make that sure. I don't think we need it anymore.

AFAIK the above case has a lot of wiggle room to fit one PID and the surrounded string into 400 bytes and even if it would need to truncate, it would write terminating character, at least on Linux:

Pushed the solution which doesn't require new flag for libassuan.

^-- I withdraw the solution (with error value) above.

Or, it would be good for client side (in this case, gpg-agent) to specify the flag in the inquiry callback, that is, it's a kind of transient flag for a single transaction.

Revised version with new flag ASSUAN_CLEAR_INQUIRY_DATA.

For this particular issue of assuan_inquire, if it's needed, the point we should fix is:

AFAICS, we need to implement a new Assuan flag and wipe the data passed to the callback after the callback returned.

Editing a formatted password should work now as expected.

Its an issue of cursor position. If one either deletes or inputs a a character anywhere in the password string, the cursor always jumps to the end of the string.

On at least some small terminals (like the smartphone size I mentioned in my original comment), I can confirm that this is a true loop. When originally reporting the issue, one of the things I tested was repeatedly pressing the Enter key with an empty password field. In that test, the password prompt looped for the 20 or so times I continued to press Enter.

I experimented a bit. The problem is the size of button texts of the confirmation dialog, i.e. of "Yes, protection is not needed" and "Enter new passphrase". pinentry-curses checks if 3 times the size of the longest text plus a few pixels for the frame fit into the terminal's width. There can be up to 3 buttons, but in case there are only two buttons this check is too strict.

Hmm, okay. Trying the same on an 80x72 terminal I can indeed reproduce a loop. Sorry, for the noise.

Just one bit of additional information: Using gpg (GnuPG) 2.3.5-beta17 on a large terminal I just tried quick generating a new key with a fresh GNUPGHOME where I only set pinentry-program /usr/bin/pinentry-curses in ${GNUPGHOME}/gpg-agent.conf.

I don't see a point in trying to make the fancy curses pinentry work on small terminals.

There is also the very simple pinentry-tty

As an end user, the --pinentry-mode=loopback flag does exactly what I'd want to resolve this issue. Just to give it more visibility, is there any chance we could try to detect when the user's terminal is too small, and print a message suggesting they use that flag?

I don't see a point in trying to make the fancy curses pinentry work on small terminals. People using small terminals can use --pinentry-mode=loopback to get a simple passphrase prompt that works on terminals of any size.

From my point of view it should be fixed by adding line-breaks to make it work on small terminals. It is better to break the formatting, but allow it, instead of bailing out and leaving the user only with the option to use the more complicated interface. This problem could also affect other password entries where a longer information is displayed.

An alternative to password creation in small terminals could be https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html#Unattended-GPG-key-generation

@LRitzdorf it should work if you enter an acceptable passphrase. (I've just tried with 56x51 widthxheight and it worked)

And I move functions from pinentry.c to pinentry-curses.c, so that pinentry-w32.exe can be build with no libiconv (which is actually not used).

Thank you for your report.

Do you mean something like this

Ready for testing

pinentry-qt with new icon:

I will add a suitable icon from the Breeze style.

Closing this task since the original feature request is still in the QA queue.

While searching for a solution to this, I found multiple reports of people that appear to be impacted by this 5 year old issue.

Btw. had to revert your unique ptr change ;-) I didn't want to raise the c++ level just for that.

ikloecker I have just added the ki18n main code to pinentry-qt as qti18n.cpp this fixes it for me. I have commented out everything but the base catalog.

OTOH, inst-qttranslations.nsi copies all .qm files needed by the qt_<language>.qm files.

For the appimage I have added a patch (backported from ki18n) that makes sure that the Qt translations for qtbase are loaded even if the (unneeded) translations for qtscript, qtmultimedia, and qtxmlpatterns are missing. See 0001-Load-Qt-translations-even-if-some-catalogs-are-missi.patch.

You'll have to talk to the people you got pinentry-mac from.

I don't know about pinentry-mac but it seems to be another name for
one our our regular pinentry variants.

We provide lots of different flavors of pinentry, but we do not provide pinentry-mac. You'll have to talk to the people you got pinentry-mac from.

That is a security feature of WIndows. We can't do much about it except for bad hacks. Checkout Kleopatra to see how you can improve this.

What would be setting those? And how do I disable it?

It does have them defined!

$ gpg-connect-agent "getinfo getenv COLUMNS" /bye
D 80
OK
$ gpg-connect-agent "getinfo getenv LINES" /bye
D 24
OK

What would be setting those? And how do I disable it?

A possibility is that gpg-agent which invokes pinentry happens have COLUMNS and LINES defined, then, pinentry misbehaves.

Thanks again for further information.

Hmm, I added that to my formula, and see ncurses 6.3 now, however the issue still occurs.

dyld[20991]: <55AFFB3D-2011-35CC-9486-B30BC1CA12F7> /opt/homebrew/Cellar/pinentry/1.2.0/bin/pinentry-curses
dyld[20991]: <AAD35EC9-FC8A-3ED4-A829-C59E710CEA8A> /opt/homebrew/Cellar/libassuan/2.5.5/lib/libassuan.0.dylib
dyld[20991]: <59683137-0511-3681-8BA6-04A78592B197> /opt/homebrew/Cellar/libgpg-error/1.43/lib/libgpg-error.0.dylib
dyld[20991]: <A9DA1A80-D101-339B-9637-85A65285E050> /opt/homebrew/Cellar/ncurses/6.3/lib/libncursesw.6.dylib
dyld[20991]: <679CDB15-D472-38E8-8840-B38874010D51> /usr/lib/libSystem.B.dylib
dyld[20991]: <BB47A721-69A7-3EEA-9D9B-82F88FFF2641> /usr/lib/system/libcache.dylib
dyld[20991]: <E6CCD148-5E91-3111-BE37-1C19402F4637> /usr/lib/system/libcommonCrypto.dylib
dyld[20991]: <92001FF7-799E-3BA8-BF46-5FA01FFB952C> /usr/lib/system/libcompiler_rt.dylib
dyld[20991]: <6BE94DC2-F363-3D76-B056-F45D4B56E152> /usr/lib/system/libcopyfile.dylib
dyld[20991]: <881973B2-0426-325F-8D1A-17D60AE0CBFA> /usr/lib/system/libcorecrypto.dylib
dyld[20991]: <9C4116F5-B8EB-3A00-B4B5-54AF6A76F66B> /usr/lib/system/libdispatch.dylib
dyld[20991]: <96ECED73-F10C-3941-91A7-00254B907499> /usr/lib/system/libdyld.dylib
dyld[20991]: <F7CDC52B-7961-3283-A30F-B06E2E6ED6AB> /usr/lib/system/libkeymgr.dylib
dyld[20991]: <8D2BECEF-1038-3F2C-B8EF-B02C03092286> /usr/lib/system/libmacho.dylib
dyld[20991]: <3D861651-91A7-3D78-B43B-ECAA41D63D9E> /usr/lib/system/libquarantine.dylib
dyld[20991]: <FA2D8F89-D9C4-316F-9FDC-BFF1A791BD4E> /usr/lib/system/libremovefile.dylib
dyld[20991]: <61963381-E322-3D0F-855D-CE1EA31FA4E1> /usr/lib/system/libsystem_asl.dylib
dyld[20991]: <770FEB1F-FE27-3670-810F-A063D281CC8D> /usr/lib/system/libsystem_blocks.dylib
dyld[20991]: <660D7866-E2A2-3651-A0A5-806E9217736B> /usr/lib/system/libsystem_c.dylib
dyld[20991]: <1F580793-A1C3-30C6-A9BC-7789C14677AE> /usr/lib/system/libsystem_collections.dylib
dyld[20991]: <8370E8A5-EADF-3A2C-9D5B-CA148723A5CA> /usr/lib/system/libsystem_configuration.dylib
dyld[20991]: <30C492F6-C9E6-3C1D-BE52-CA4F4FC824D6> /usr/lib/system/libsystem_containermanager.dylib
dyld[20991]: <F2A34B01-C264-3B7E-B3C9-1671E9E3C185> /usr/lib/system/libsystem_coreservices.dylib
dyld[20991]: <01C0D793-E5FB-3141-95D6-32A973F9FFF8> /usr/lib/system/libsystem_darwin.dylib
dyld[20991]: <AED9DAFC-7AB1-31CF-96A1-14C87B614DD3> /usr/lib/system/libsystem_dnssd.dylib
dyld[20991]: <F0456F65-B4DF-3E14-91DC-C0C2A7954233> /usr/lib/system/libsystem_featureflags.dylib
dyld[20991]: <5E36F087-5EF7-33B7-ACDA-CAE1C4A97621> /usr/lib/system/libsystem_info.dylib
dyld[20991]: <6AB180A4-1D1E-3FA1-88B7-A7866EFACFC8> /usr/lib/system/libsystem_m.dylib
dyld[20991]: <7C9F7726-62C1-3B03-8130-03E8A2A68DDF> /usr/lib/system/libsystem_malloc.dylib
dyld[20991]: <2F331637-80F6-3208-816F-618DA9081899> /usr/lib/system/libsystem_networkextension.dylib
dyld[20991]: <3701D756-7023-30C0-9A36-852971092AA9> /usr/lib/system/libsystem_notify.dylib
dyld[20991]: <4234FAEC-7D18-30E7-AEAD-E9FB6922AFE9> /usr/lib/system/libsystem_product_info_filter.dylib
dyld[20991]: <1214F568-24BF-379F-8A86-FF947EE5F18A> /usr/lib/system/libsystem_sandbox.dylib
dyld[20991]: <49553CC1-66C3-32B1-91C6-4415DE230F58> /usr/lib/system/libsystem_secinit.dylib
dyld[20991]: <17550B77-D255-389A-B779-906AF75314B6> /usr/lib/system/libsystem_kernel.dylib
dyld[20991]: <8B28F7A3-6681-3D34-92AE-3688A74F50E6> /usr/lib/system/libsystem_platform.dylib
dyld[20991]: <AA39FF66-B3F0-3777-99BC-F4A4C5CBD566> /usr/lib/system/libsystem_pthread.dylib
dyld[20991]: <73885FA5-76B6-3AA3-8D91-60B2E0078F99> /usr/lib/system/libsystem_symptoms.dylib
dyld[20991]: <362E885B-20EA-395B-BB01-6E46B864294D> /usr/lib/system/libsystem_trace.dylib
dyld[20991]: <D0A538E3-7A75-395A-993C-A3EA7947F55A> /usr/lib/system/libunwind.dylib
dyld[20991]: <A77B4CE2-0855-3C19-B4A6-47B094CF0DDA> /usr/lib/system/libxpc.dylib
dyld[20991]: <52A50407-CD9B-3A67-A0C2-2D9D6F3043BF> /usr/lib/libc++abi.dylib
dyld[20991]: <8FCA2160-F786-398A-AEAC-2B3D5BD72BB8> /usr/lib/libobjc.A.dylib
dyld[20991]: <6B0DE0DE-0EA2-3948-8B7D-8BA309414B27> /usr/lib/liboah.dylib
dyld[20991]: <20FBE382-CC21-324E-8813-C84B94CC04EF> /usr/lib/libc++.1.dylib
dyld[20991]: <A714AC09-9E2D-3608-B8C1-D6300E852308> /usr/lib/libiconv.2.dylib
dyld[20991]: <1907D41B-6D4B-3EA0-AD3B-5770431B6327> /usr/lib/libcharset.1.dylib

So, the solution is to build pinentry with newer ncurses. As I wrote in another comment, it's adding a single line to the formula.

Thank you for the info.

I ran DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 DYLD_PRINT_RPATHS=1 pinentry-curses and see libncurses.5.4 (full output below).

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

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

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

For completeness here's a screenshot that shows the situation on a TERM=sun-console text console with the latest code :

After thinking a little more about this issue, I am of the opinion that the best option here is to provide a compile time configure option :

It would be convenient if the -c option could be easily set in the gpg-agent.conf or in some configuration file for pinentry. The workaround that I use now to create a script that I can then use as pinentry-program is extra work because it requires an additional script.

The typo is fixed now and after pulling the latest sources from the repo and configure --disable-ncurses :

Thanks for testing. I pushed a fix for my typo: rPb713f31c5b04: curses: Fix the previous commit.