Page MenuHome GnuPG

pinentry: pinentry-curses doesn't allow to set no password or weak passwords on 80 char width and smaller terminals
Open, NormalPublic

Description

Debian Buster
pinentry-curses 1.1.0
gnupg 2.2.12

I want to generate a key pair without password protection with pinentry-curses.
It doesn't work: I get into a loop reasking me for a password.
If I use a graphical pinentry it works.

Editing a key pair to remove the password, also doesn't work.

Details

Version
1.1.0

Event Timeline

I just tried and Pinentry ask me whether I really want to use an unprotected key. Take care that you hit the right button.

Perhaps I explain the steps, I'm doing.
I'm on a minimal debian buster instance.

  1. gpg2 --full-gen-key
  2. Insert stuff.
  3. See Dialog:

Real name: Test1 Tester
Email address: test1@example.com
Comment: no pw
You selected this USER-ID:

"Test1 Tester (no pw) <test1@example.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?
-> Insert O

  1. See dialog: ┌──────────────────────────────────────────────────────┐ │ Please enter the passphrase to │ │ protect your new key │ │ │ │ Passphrase: ________________________________________ │ │ │ │ <OK> <Cancel> │ └──────────────────────────────────────────────────────┘
  1. Press TAB -> <OK> is highlighted.
  2. Press Return.

> I expect it to ask me, if I don't want protection, but after 0.5 sec the dialog:

┌──────────────────────────────────────────────────────┐
│ Please enter the passphrase to                                                                                                        │
│ protect your new key                                                                                                                         │
│                                                                                                                                                                   │
│ Passphrase: ________________________________________                                                           │
│                                                                                                                                                                    │
│       <OK>                              <Cancel>                                                                                                │
└──────────────────────────────────────────────────────┘

reappeared.

And yes: If I install pinentry-gtk2 and follow the steps, it works as excepted.

I'm not sure, if the dialog comes from pinentry-curses or is some kind of gnupg on-board dialog. But it seems,
that this dialog doesn't work as excepted.

It is the pinentry-curses, which is needed to reproduce the problem.
Using tab and Return to navigate the dialog.
After pressing ok, the password question dialog reappears. I tried 20 times to press ok, every time the password question dialog reappeared.
If I press cancel, the process aborts. So I'm sure, I hit the right button.

I debugged some more.

The problem is triggered if the terminal is 80x25.
After pressing ok in the pinentry-curses dialog, I see:
DBG: error calling pinentry: Screen or window too small <Pinentry>

If I enlarge the console size to: 115x25 with the same setup, I see the

You have not entered a passphrase - this is in general a bad idea!
Please confirm that you do not want to have any protection on your key.

dialog, like excepted.

aheinecke triaged this task as Normal priority.
aheinecke added a subscriber: aheinecke.

I can reproduce this.

DISPLAY= gpg --yes --homedir $(mktemp -d) --quick-gen-key foo@bar.baz

@werner Do you think that pinentry-curses should be fixed to avoid GPG_ERR_WINDOW_TOO_SMALL by adding line breaks or do you think gpg-agent should handle this better and error out instead of looping.

I think gpg-agent should just abort in that case and print the window too small error.

aheinecke renamed this task from pinentry doesn't allow to set no password to pinentry: pinentry-curses doesn't allow to set no password on small terminals.May 8 2020, 12:32 PM

@aheinecke thanks for commenting.

IMO it should be fixed, because some terminal width cannot easily be changed, so it should work
at least down to 60 characters of width, I'd say. (Of course it is fine to fail if it is getting ridicouosly small, like 10 chars . :) )

It's worth noting that this issue is particularly impactful for devices with small screens whose sizes cannot be changed. A Raspberry Pi with an Adafruit touchscreen would almost certainly have issues, for example.
This also applies to mobile devices. For context, I use Termux on my Android phone, and this issue manifests there. I can enter the passphrase for an existing key and decrypt/sign with it, but any attempt to create a new key throws me into the same loop that the OP describes. (Interestingly, this happens whether or not I actually supply a new passphrase.)
Since I am on a mobile device in this scenario, my terminal dimensions are 56x115. I'm not familiar with the implementation details of GPG, but is there any chance we could fall back to a single-line, sudo-style password prompt if pinentry fails (or have pinentry fall back to that internally if the normal mode fails)? That should work on terminals of just about any size.
(As an additional note, I've also tried flipping into landscape orientation, hoping that would increase my screen width sufficiently. However, my keyboard then occupies most of the screen, and I receive the expected error message, gpg: agent_genkey failed: Screen or window too small.)
EDIT: I'm running GPG 2.3.1 and pinentry 1.1.1.

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

bernhard renamed this task from pinentry: pinentry-curses doesn't allow to set no password on small terminals to pinentry: pinentry-curses doesn't allow to set no password or weak passwords on small terminals.Mar 31 2022, 5:12 PM

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.

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.

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?

There is also the very simple pinentry-tty

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

The problem is that a width of 80 characters, where it fails, is a quite normal width, it is common.

And there is the usability defect that people do not see the reason why it fails, they just get a pinentry loop in the situation of entering a new passphrase for example. Users have no indication that they should chose a different pinentry.

bernhard renamed this task from pinentry: pinentry-curses doesn't allow to set no password or weak passwords on small terminals to pinentry: pinentry-curses doesn't allow to set no password or weak passwords on 80 char width and smaller terminals.Apr 1 2022, 9:30 AM

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.

After entering an empty passphrase and confirming that I don't want protection, I was asked a second time for a passphrase and had to confirm a second time that I don't want protection. After that the key was created successfully.

Now I'm wondering whether there is actually a loop as reported in the initial report or whether gpg simply asks a second time for a passphrase for the encryption subkey in case an empty passphrase was entered for the main key. Somehow this initial issue seems to have been replaced in the discussion with the maybe completely unrelated issue with small terminals.

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

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.

I have made an experimental patch which checks for enough space for the actually needed number of buttons. This patch fixes the issue at least for 80xsomething terminals. It still doesn't work for smaller terminals (or for languages with too long translations) because the description of the confirmation is very wide (which could be fixed easily with a few line breaks).

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.