[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fix needed for communication with gpg-agent

From: Werner Koch
Subject: Re: Fix needed for communication with gpg-agent
Date: Fri, 23 Feb 2007 09:53:09 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6)

On Thu, 22 Feb 2007 19:40, address@hidden said:

> In that case, I think Emacs should disable use of gpg-agent when
> running in a console, except when gpg-agent already has a passphrase
> cached.  Then all we need is some method for Emacs to determine if the

That is only a short term solution.  The goal of gpg-agent is to take
care of _all_ secret key[1] management.  gpg and gpgsm will delegate
all secret key operations to gpg-agent and nevermwork with a secret
key directly.  This is already the case for gpgsm, the S/MIME variant
of gpg.  As time permits this will be implemented in gpg too.  Using
gpg-agent as a passphrase cache for gpg is only a temporrary solution.

> > Is it possible to enhance server-start/emacsclient so that it does not
> > edit a file but asks for string and returns that one?  Pinentry could
> > then use this feature for user interaction.
> I'm not sure how this suggestion could work.

Recall that pinentry is called on the sole discretion of gpg-agent.
Only gpg-agent knows whether Pinentry needs to be called.

My suggestion is this:

 +-------+    +-----------+    +-----------+       +----------+
 | emacs | -> | gpg/gpgsm | -> | gpg-agent | ----> | pinentry |
 +-------+    +-----------+    +-----------+ (may) +----------+
     ^                                                  |
     |                                                  |
           (some mechanism to loop back to emacs)

Pinentry uses this:

  if DISPLAY set
     Use GUI mode; no problem
  else if SOME_EMACS_ENVVAR set
     Loop back to emacs
     Use Curses

to decide wether that emacs loop back method is to be used.  It will
then ask emacs: Please create a form or a minibuffer with this or that
description and return the user input to me.

I don't know the emacsclient protocol and whether it can easiliy be
enhanced for that case.  To me this sounds like a viable solution
which does not require emacs to stop other processing if no pinentry
is required.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]