I tried to reproduce on my FreeBSD 14 machine and didn't get an error....

Can you try again but create $HOME/.gnupg/gpg-agent.conf file with

debug 0xffff
log-file /tmp/agent.log

What are your locale settings - the output of locale?

Hi, thanks for the quick turnaround

This is the locale output:

LC_CTYPE="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_TIME="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=

I also got the suggestion to try with --pinentry-mode=loopback and that resolved the issue. I guess it maybe tried to open an X session back over ssh and failed with that, or something similar.

I attached the agent log also. It seems to maybe contain sensitive data, but this was all just for a test, so no problem to share. It contains two runs, first the reproduction of the failure and then the working one.

The agent.log says that the error comes from pinentry-curses:

`
2023-03-05 12:32:15 gpg-agent[928] DBG: chan_8 -> INQUIRE PINENTRY_LAUNCHED 929 curses 1.2.1 /dev/pts/0 alacritty - 20620/1001/4 1001/1001 0
2023-03-05 12:32:15 gpg-agent[928] DBG: chan_8 <- END
2023-03-05 12:32:16 gpg-agent[928] DBG: error calling pinentry: Screen or window too small <Pinentry>
2023-03-05 12:32:16 gpg-agent[928] command 'GENKEY' failed: Screen or window too small <Pinentry>
2023-03-05 12:32:16 gpg-agent[928] DBG: chan_8 -> ERR 83886381 Screen or window too small <Pinentry>
2023-03-05 12:32:16 gpg-agent[928] DBG: chan_8 <- [eof]
`

What is the value of the $TERM variable? What does stty -a say?

I have tried the same connecting via ssh to the FreeBSD server (with X11 enabled as well as disabled) and the pinentry-curses terminal popped up fine, even on a very narrow terminal window (42 characters wide). My TERM is rxvt-unicode-256color and I am using urxvt as my terminal emulator.

$term is 'alacritty', stty -a is:

speed 38400 baud; 54 rows; 180 columns;
lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
	-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
	-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff -ixany -imaxbel -ignbrk
	brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
	-dtrflow -mdmbuf rtsdtr
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
	eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
	lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
	status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

Could this be a duplicate of T4924: pinentry: pinentry-curses doesn't allow to set no password or weak passwords on 80 char width and smaller terminals?

@ikloecker not sure we are there yet. I was able to set a weak password on a terminal that was 42 characters wide. I think the problem here is unrelated to FreeBSD but to the fact that @capitol uses alacritty https://github.com/alacritty/alacritty

@capitol does this problem happen also if you use something like a classic xterm ? (I hope you meant $TERM not $term). Are you running the command on the remote server connected via SSH?

Can you run tput -T alacritty longname on the same machine you were trying to generate the keys ? What does it say?

I don't know what is going here really. I have installed alacritty and I can reproduce T4924 easily if I provide an empty passphrase on an narrow window. At least I get pinentry-curses popping up.

However, alacritty installed from FreeBSD port gives me $TERM set to xterm-256color an things seem to be working fine, also over SSH connection to another FreeBSD machine.

If I set TERM to alacritty manually, no terminal definition can be found and pinentry stops with

2023-03-06 11:51:07 gpg-agent[50757] starting a new PIN Entry
2023-03-06 11:51:07 gpg-agent[50757] DBG: connection to PIN e
ntry established
2023-03-06 11:51:07 gpg-agent[50757] DBG: chan_8 -> INQUIRE P
INENTRY_LAUNCHED 50768 curses 1.1.1 /dev/pts/2 alacritty loca
lhost:10.0 20620/169/4 169/20 0
2023-03-06 11:51:07 gpg-agent[50757] DBG: chan_8 <- END
2023-03-06 11:51:08 gpg-agent[50757] DBG: error calling pinen
try: Required environment variable not set <Pinentry>
2023-03-06 11:51:08 gpg-agent[50757] command 'GENKEY' failed:
 Required environment variable not set <Pinentry>
2023-03-06 11:51:08 gpg-agent[50757] DBG: chan_8 -> ERR 83886
383 Required environment variable not set <Pinentry>
2023-03-06 11:51:08 gpg-agent[50757] DBG: chan_8 <- [eof]

(but this is kind of expected).

I get some errors compiling alacritty terminfo https://github.com/alacritty/alacritty/blob/e0b9771dbcab56f666daa3bd02fc7a889107ccfa/extra/alacritty.info with FreeBSD's /usr/bin/tic - and then, when I use TERM set to alacritty my agent complains right away trying to start pinentry-curses

2023-03-06 13:21:50 gpg-agent[77861] starting a new PIN Entry
2023-03-06 13:21:50 gpg-agent[77861] DBG: connection to PIN entry established
2023-03-06 13:21:50 gpg-agent[77861] DBG: chan_8 -> INQUIRE PINENTRY_LAUNCHED 77862 curses 1.2.1 /dev/pts/7 alacritty - 20620/169/4 1002/1002 0
2023-03-06 13:21:50 gpg-agent[77861] DBG: chan_8 <- END
2023-03-06 13:21:51 gpg-agent[77861] DBG: error calling pinentry: Permission denied <Pinentry>
2023-03-06 13:21:51 gpg-agent[77861] command 'GENKEY' failed: Permission denied <Pinentry>
2023-03-06 13:21:51 gpg-agent[77861] DBG: chan_8 -> ERR 83918849 Permission denied <Pinentry>

So I am pretty sure there is something with termcap vs terminfo vs whatever. Maybe not using alacritty as $TERM is a solution.

Looks like the TERM alacritty was the culprit, I'm ssh'ing into the freebsd machine from my archlinux laptop.

I can confirm that running TERM=xterm-256color gpg --expert --full-generate-key works.

Thank you!

I think we have an interesting kind of regression:

With the TERM set to the terminal name that cannot be used on the system, pinentry-curses 1.1.1 stops with "Key generation failed: Required environment variable not set".
pinentry-curses 1.2.1 stops with "Key generation failed: Screen or window too small".

I think the message from 1.1.1 is slightly better.