In T6085#162921, @aheinecke wrote:

@ikloecker yes as mentioned in my response the current hints are only for symmetric.

@ikloecker yes as mentioned in my response the current hints are only for symmetric.

well, when creating openPGP keys with kleopatra I did not see any hints. I do not think that the issue would be vaild for password based encryption. There the common usecase is autogeneration, anyway

The long hint is "hidden" in the tooltip of the short hint.

And the issue for which @ebo opened this ticket is in my opinion that you have to fail first before you see the hint.

I think there was a misunderstanding here. We already set .pinentry.constraints.hint.long and .pinentry.constraints.hint.short in GnuPG-VSD but firstly they are only about symmetric.
And the issue for which @ebo opened this ticket is in my opinion that you have to fail first before you see the hint.

Fully done in my opinion.

This is in for so long we can mark it as resolved. I had tested it on Windows.

That's a fair point, cheers!

In T6161#162306, @ikloecker wrote:

I'm not sure I understand. If you don't want pinentries depending on libX11, then simply disable those pinentries with --disable-pinentry-qt5, etc. For Wayland it may make sense to allow disabling it.

I'm not sure I understand. If you don't want pinentries depending on libX11, then simply disable those pinentries with --disable-pinentry-qt5, etc. For Wayland it may make sense to allow disabling it.

Let's turn this into a feature request.

Fixed in 1.2.1.

Fixed in 1.2.1.

Fixed in 1.2.1.

At least, pinentry-qt offers this functionality since 1.2.0 (see T5517: Improvements for symmetric encryption).

Isn't this (mostly?) done? See T5517: Improvements for symmetric encryption.

pinentry 1.2.1 has been released today

Fix issues found while testing with NVDA.

Should be fixed. A copy of an older version of pinentry's source code that can be built with Q4 is now included and will result in a pinentry-qt4 executable. Note that while we won't break this pinentry intentionally we won't maintain it either.

New release of libassuan is expected to make sure it's cleared off.

@gniibe Thanks!

In the repo, for all related software, it's done.

Note that versions since 2020-11-07 to 2021-07-03 have major problem with non-POSIX shell, which doesn't support $(..) construct.

Thank you.

it seems to be a GnuPG-VSD packaging issue, then

It's already possible to define a short and a long hint for the constraints via the file doc/help.txt and its translations. This is a standard technique used by GnuPG for customization of several UI texts. Since the passphrase constraints can be very complex we don't try to come up with a suitable default hint.

It looks like having it set will stop fallback from working entirely? Would you say that this cannot be fixed if WAYLAND_DISPLAY is set like I do above?

It looks like having it set will stop fallback from working entirely? Would you say that this cannot be fixed if WAYLAND_DISPLAY is set like I do above?

pinentry does the following to check if it's running in a GUI session:

// check a few environment variables that are usually set on X11 or Wayland sessions
const bool hasWaylandDisplay = qEnvironmentVariableIsSet("WAYLAND_DISPLAY");
const bool isWaylandSessionType = qgetenv("XDG_SESSION_TYPE") == "wayland";
const bool hasX11Display = pinentry_have_display(argc, argv);
const bool isX11SessionType = qgetenv("XDG_SESSION_TYPE") == "x11";
const bool isGUISession = hasWaylandDisplay || isWaylandSessionType || hasX11Display || isX11SessionType;

i.e. it checks if a few environment variables are set or have a specific value.

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