0

I need to be able to GPG-sign git commits in two different Linux environments.

  1. In a full GUI X-Window setup using the GUI-based password dialog box

  2. In an SSH, without X-forwarding, using command-line only password entry

In both cases I need to be able to use different UID's for signing, all of which are in my keyring. The local and remote access use the same user account on a single machine, and may both be active at the same time. The computer is running openSUSE Leap 15 (4.12.14), using GnuPG 2.2.11, and libgcrypt 1.8.4. My typical remote connection uses ConnectBot v1.9.5 on Android v5.1.1, though I often also use Terminus v4.3.12 on iOS 12.1.1, and I could use a public Win 10 PC on occasion.

I do not want a 'permanent' solution which forces me to use the CLI method locally. Doing so would affect all other uses of gpg, including email.

Reading this question, I tried several variations which seemed to suggest themselves. Even though the solutions there, including the accepted one, were aimed at a permanent solution. I hoped they'd lead to a solution in my use case.

I have tried several variations of setting the pinentry-command in my gpg-agent.conf file. In all cases, the gpg-connect-agent reloadagent /bye command is executed after a change to the config file. The remote session was started fresh after any change and tested, as-is, and after each of the following commands, in sequence:

  1. export GPG_TTY=$(tty)
  2. unset DISPLAY
  3. gpg-connect-agent updatestartuptty /bye

The results have been the same before and after all three commands, and are as follows:

  • Using pinentry gives the GUI method locally - whether I am executing the command locally or remotely (The remote screen simply hangs until time-out happens for the dialog box.)
  • Using pinentry-tty forces CLI in all cases. (Remote usage prompts in the remote terminal and local usage prompts in the local terminal.)
  • Using pinentry-gtk-2 duplicates the results of pinentry
  • Using pinentry-qt also duplicates the results of pinentry
  • Using pinentry-curses provides the curses box, but otherwise duplicates the results of pinentry-tty

In all cases, if the setting results in a command-line prompt locally, all non CLI uses, such as Thunderbird, fail with an error.

I will not include the password on the command line or in a text file (no --passphrase-* option to GnuPG).

I will not use a password-less key.

It does no good to hard code any one key as I often use several within a short span of time.

I will use a command line option, if possible, to force the correct pinentry choice. I'm not sure it's possible to pass gpg options through git.

I would prefer the ability to have the pinentry automatically "pick" the proper option. I would also prefer that the command line pinentry work for all commands. At the moment, however, I only need it to work in connection with git usage. (Signing is often one key while push/pull operations require a different key.) Currently, my main remote SSH client can execute custom commands at login, so a script that affects the current session/tty only would also be acceptable, though not ideal. A per-connection modification of the gpg-agent.conf file (manually or scripted) would not be acceptable.

There was one hopeful answer for making this work on a mac. Attempting it with the above options, however, produced no different results. (I also tried ="USE_TTY=1", just in case it worked.)

I can work with suggestions in an effort to find a real solution (team-effort so to speak) if there are possibilities which might work but cannot be tested outside of my environment.

  • What you're asking for is already the default behavior. Can you confirm that gpg-connect-agent "getinfo std_session_env" /bye, immediately after updatestartuptty, does not have DISPLAY anymore? – grawity Jul 9 at 21:35
  • @grawity Somehow the "default" behavior isn't compliant in my system. The command given, after using unset DISPLAY and DISPLAY="" followed by updatestartuptty still lists DISPLAY=:0 as well as the correct GPG_TTY=/dev/pts/17. Using the local terminal to 'echo "testing" /dev/pts/17` causes the message to appear on the remote terminal. Perhaps the DISPLAY remains fixed because the local machine is still logged in, and my use case requires that to be an option. – Gypsy Spellweaver Jul 9 at 23:36
  • No it doesn't – gpg-agent does not care about "logins" of any shape. But you are saying that none of the environment variables get updated within gpg-agent (e.g. GPG_TTY in std_session_env is supposed to always correspond to the current tty), so DISPLAY is not special in your case. – grawity Jul 10 at 4:34
  • I should have specified that "immediately" also includes "within the same terminal window and within the same shell instance". – grawity Jul 10 at 4:35
  • @grawity The GPG_TTY does show the correct pts number for each shell, even before updatestartuptty, the DISPLAY remains locked, irrespective of which shell/session is calling gpg-connect-agent. Using the echo command from another shell confirmed that the reported pts was correct. – Gypsy Spellweaver Jul 10 at 14:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.