[Fix #419] start gpg-agent also with ssh-support off

[nasenatmer]

I committed the fix by @fwalch in [#419] and added a note on the variables exported by this module into the README.md

[sorin-ionescu]

Que? Complete sentences por favor.

[nasenatmer]

Few, had a hard time squashing the commits to enhance the README, but that seems solved now. Back to business, the BSD-ps issue will need some serious shell magic. I guess checking for the PID (as done in Arch's gpg-agent.sh) might be the right answer to that. I'll hopefully get to that soon.

[sorin-ionescu]

I have decided to rewrite this module.

[ColinHebert]

While rewriting this module, could you add the support of pinentry in CLI?

http://support.gpgtools.org/discussions/everything/1891-how-to-perform-gpg-decrypt-on-command-line-instead-of-gui-asking-for-passphrase

[sorin-ionescu]

@ColinHebert Whatever pinentry is (it has no README file), the link reports that export PINENTRY_USER_DATA="USE_CURSES=1" doesn't work. That said, both gpg and gpg2, installed via homebrew show me the ncurses prompt.

[ColinHebert]

pinentry is the application in which the GPG password will be typed: http://www.gnupg.org/related_software/pinentry/

There are multiple pinentry applications depending your needs (with a GUI, CLI, for gnome, KDE, MacOS).
When using GPGtools (the MacOS bundle for GPG), the pinentry tends to be /usr/local/MacGPG2/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac which is a graphical one.

This means that an access from the CLI (through SSH for example) will open a window (at least try to do so) instead of asking the pin through the CLI.

export PINENTRY_USER_DATA="USE_CURSES=1" will allow to open a ncurses prompt instead (without manually changing the pinentry application.

This is working, the link I gave states it (a nightly release from 2012, which has since been properly release), see also http://support.gpgtools.org/kb/faq/how-to-enter-your-passphrase-directly-in-the-terminal

[sorin-ionescu]

Check it out 5a22c65. Let me know if it works.

[ColinHebert]

I thought you would remove the write-env-file option altogether

[sorin-ionescu]

@ColinHebert Isn't pinentry more applicable to the osx module than gpg-agent?

[sorin-ionescu]

@ColinHebert I changed the env file path to its default location. Since there is no environment variable for it, I suspect other apps or programs will look for it there. It's designed for programs that are not started under the current tty to find the agent.

[ColinHebert]

Honestly I do not know, I assumed that this option was the convention for every pinentry with a GUI but I do not know for sure.

[sorin-ionescu]

This module is called gpg-agent, not gpg. Both it and ssh-agent are relics from OMZ, which I've cleaned up before as best I could, but since I used neither, bugs remained. That said, I can rename gpg-agent to gpg and ssh-agent to ssh and allow them to be extend. In hindsight, it seems a bit silly to have modules dedicated to third party tools instead of the tool instead. There is no shortage of GPG and SSH tools.

[ColinHebert]

I would agree except that the pinentry is determined by the GPG-agent. I'm not sure there would be much more to configure in the GPG module though.

[sorin-ionescu]

So rename the modules? Then add the pinentry ncurses?

[sorin-ionescu]

Actually, pinentry is a dependency of both gpg2 and gpg-agent.

[ColinHebert]

Okay, so there is a few points I want to raise:

• I think there is a mixup between gpg_agent_info (which contains something along the lines of /Users/username/.gnupg/S.gpg-agent:94832:1) and what is written in the env file which is something like:

    GPG_AGENT_INFO=/Users/username/.gnupg/S.gpg-agent:7284:1; export GPG_AGENT_INFO;
    SSH_AUTH_SOCK=/Users/username/.gnupg/S.gpg-agent.ssh; export SSH_AUTH_SOCK;
    SSH_AGENT_PID=7284; export SSH_AGENT_PID;

• The env variables can either be obtained in a file (with the --write-env-file option) or from the stdout of gpg-agent if this one is started as a daemon.
• The content of .gpg-agent-info should not be modified!
• In our case, there is no need to write an env_file, change the chmod, source it and execute some exports, we could just execute the result of gpg-agent.
• GPG-agent can be started only once, otherwise it will result in gpg-agent[7289]: a gpg-agent is already running - not starting a new one, it might be useful to try to try to run it anyway and handle the fact that it might fail (instead of doing things with egrep and ps

[nasenatmer]

On 27/04/13 23:24, Sorin Ionescu wrote:

@ColinHebert Isn't pinentry more applicable to the osx module, then gpg-agent?

No, gnupg > 2.0 set the use of gpg-agent as obligatory. That said, it makes sense to have a module for gpg-agent, mainly for the reasons @ColinHebert t raised.

[sorin-ionescu]

Have a look https://github.com/sorin-ionescu/prezto/tree/gpg/modules/gpg.

[ColinHebert]

Almost the entire module can (and should) be replaced with:

eval $(gpg-agent --daemon 2> /dev/null)

The only thing that could be useful here is adding --enable-ssh-support, there is no reason to do anything else (except for the pinentry obviously).

[sorin-ionescu]

What about the exports?

export GPG_TTY="$(tty)"
export SSH_AUTH_SOCK
export SSH_AGENT_PID

[sorin-ionescu]

Not on my system. I only see the first one: GPG_AGENT_INFO. What about GPG_TTY?

[nasenatmer]

I don't understand why it would be renamed, cause clearly it's a module starting up gpg-agent, not gpg in itself.

[sorin-ionescu]

@ColinHebert, stupid me, I had ssh support turned off. Sorry. That leaves GPG_TTY.

@nasenatmer, now it does more. It controls pinentry. Also there is no reason not to add aliases for managing keys, encrypting and decrypting files.

[ColinHebert]

I'm saying it would be better to use ps -U "$USER" -c -o command so you can remove the call to egrep and use grep 'gpg-agent' instead.

[sorin-ionescu]

Right, and -c on Linux ps says, show different scheduler information for the -l option.

[ColinHebert]

Okay so for Linux using -c in conjunction with -o will indeed show:

Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
COMMAND
sshd-user
bash
ps

Fortunately Linux's ps supports the BSD syntax out of the box, so ps co command -U "$USER" will work on both BSD and Linux (it's also possible to do ps c -o command -U "$USER" but hey we should stick to one syntax).

cf. http://linux.die.net/man/1/ps

[sorin-ionescu]

ps co command U "$USER" doesn't work here. ps co command -U "$USER" does. While this takes care of Linux and BSD. There are many unixes out there. Occasionally, someone opens an issue about Solaris, for example.

[sorin-ionescu]

Since, $PINENTRY_USER_DATA is only set during an interactive shell session, either locally or via SSH, it should not affect GUI programs while keeping terminal interaction consistent.

[ColinHebert]

Didn't you say you were using Mac OS Keychain to handle your SSH password? How is that different from wanting to use a graphical pinentry from the command line if you have a graphical environment nearby?

Personally I'm using the graphical pinentry when I have a graphical environment. The only time I can't use it is through SSH.

[ColinHebert]

If you prefer to use the Linux syntax everywhere it's fine too, ps -U "$USER" -o comm should do the trick.

[ColinHebert]

Or even better -o ucomm

[sorin-ionescu]

@ColinHebert The Mac OS X Keychain has never asked me for a SSH password. It just works. It seems to have special support, but whenever I mess with security find-generic-password, and I get a GUI dialogue, it iterates me, especially when I have the terminal in full screen. Terminal work should stay in the terminal and GUI work should stay in the GUI.

[ColinHebert]

Hum that's because you unlock your Mac OS keychain only once (try to lock it manually and do anything SSH related).

---

Anyway, I'm not saying I'm right or that you aren't. I think both ways are valid.
As I said, if someone doesn't want the graphical pinentry at all, I would recommend to add export PINENTRY_USER_DATA='USE_CURSES=1' in zshenv so it applies all the time (at least every time pinentry is started from the CLI). BTW, there is no need to check for $GPG_TTY.

But imposing a personal preference when it isn't necessary is in my opinion not a good thing.

Setting it only when SSH is enabled doesn't aim to apply a personal preference, it aims to have a decent behaviour in a case were it is known that not using curses will simply not work.
Whatever you prefer for your environment, there is no chance anyone would want the GUI pinentry started when using SSH. Addressing that case and that case only leaves room for users to specify their own preferences later on.

[nasenatmer]

Hm I can't contribute much to the discussion about the different ps options, asking myself what happens in that line after egrep:

ps -U "$USER" -o 'command' | egrep -q '^gpg-agent( |$)' \

---

But regarding the question of PINENTRY_USER_DATA, maybe we should rather add a line in the README? I mean it would be a bit funny as people can just RTFM, but I see the point of @ColinHebert and as I reported earlier, at least here, USE_CURSES=1 didn't have any effect anyways. So instead of taking on the responsibility of providing environments that are supposed to work we could thereby rather leave it to the users to care about that themselves…

@sorin-ionescu : I'll test a2abb74 tomorrow and give you feedback then.

[sorin-ionescu]

Sometimes the environment variable does not work. You'll have to add pinentry-program /usr/bin/pinentry-curses to gpg-agent.conf.

[nasenatmer]

But that would mean setting it permanently when I only want pinentry-curses when I work in the CLI. Here's how I understodd it:
There's a default pinentry which in Arch is defined by a symlink from /usr/bin/pinentry → /usr/bin/pinentry-gtk-2. I can additionally set that in gpg-agent.conf if I want to be 100% sure and don't trust the package maintainers they don't change this symlink. If I set it to pinentry-curses in the conf, it'll obviously work with curses all the time.

However, I thought that the whole point of USE_CURSES=1 is that it would enable me to have pinentry set to gtk2 (for GUI programmes) by the symlink/or the conf and to curses by the USE_CURSES=1 switch.

@sorin-ionescu : how regularly is "sometimes"? If it is rather the norm then I think we shouldn't take on the responsibility for that and rather just mention it and that this sometimes is a bit wonky under Linux.

[ColinHebert]

I found USE_CURSES=1 on gpgtools it might very well be something specific to that tool, I would expect pientry-gtk2 to be able to switch back to curses in some way though

[sorin-ionescu]

@nasenatmer The GUI pinentry is default. It is so because it's more secure. It captures the keyboard so that there is no fake entry. The cursers version cannot do that. There are many pinentry implementations, which may or may not respect that environment variable. So, it depends on the PGP implementation.

I want GUI pinentry for GUI programs and curses pinentry for CLI programs. @ColinHebert wants GUI pinentry for all programs except during SSH.

[ColinHebert]

Something that may be interesting: GPGTools/pinentry-mac#2

[nasenatmer]

@sorin-ionescu I think I'm with you there, however, if the pinentry behaviour is so different in various implementations shouldn't we try to stay independent from that and provide a solution that produces behaviour that we can predict to 99% and not every fancy possibility that is out there?

[sorin-ionescu]

What happens when you start a new tty in Linux, no X, and you do not have that environment variable set because it's only set during SSH connections? Does pinentry work?

[sorin-ionescu]

@nasenatmer I think we're there. The only debate remaining is to export or not to export that variable all the time during CLI.

[ColinHebert]

From my reading it seems that on linux it doesn't rely on USE_CURSES=1 but on the $DISPLAY variable which is set by X.
So the default linux behaviour should be using the graphical one if a graphical environment is available (unfortunately I can't test that), if not the CLI version (probably using curses?) will be started (for shells not opened from X).

[ColinHebert]

More here: http://superuser.com/questions/520980/how-to-force-gpg-to-use-console-mode-pinentry-to-prompt-for-passwords

PS: this echo RELOADAGENT | gpg-connect-agent could be useful too

[nasenatmer]

@sorin-ionescu : As @ColinHebert said: If there's no $DISPLAY, pinentry will be launched in curses flavour.
Regarding the debate, then, I think I made my stance to that clear.

[sorin-ionescu]

@ColinHebert I think echo RELOADAGENT | gpg-connect-agent should be executed manually.

[sorin-ionescu]

@ColinHebert ssh-agent on Mac OS X 10.5 explains the custom behaviour on Mac. Attempting to replace ssh-agent with gpg-agent will probably cause problems.

[sorin-ionescu]

@ColinHebert It's possible to disable Apple's SSH extensions.

[sorin-ionescu]

Enough: ea5e6d7.

[nasenatmer]

Great, looks good!