Documenting gpg-agent

Documenting gpg-agent

[Richard Stallman]

We've been waiting for a few weeks for someone to document gpg-agent.
Many bugs in the code have been fixed, but this problem, which doesn't
require debugging, has not been addressed.

Would someone please do this?

It is not essential for the text you write to be publication-quality.
It is enough if you write something that is rough but clear.  Once
there is text I can read and understand, I will polish it up.

Re: Documenting gpg-agent

[Sascha Wilde]

[-- Attachment #1.1.1: Type: text/plain, Size: 549 bytes --]

Richard Stallman <rms@gnu.org> wrote:

> We've been waiting for a few weeks for someone to document gpg-agent.
> Many bugs in the code have been fixed, but this problem, which doesn't
> require debugging, has not been addressed.

The feature it self, and the only customize able part of it, the
variable `pgg-gpg-use-agent' has been documented since introduction.

I have added a short paragraph (see attached patch) to point out, that
the use of gpg-agent is recommended and where to get further information.

What else is missing?

cheers
sascha


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: Type: text/x-patch, Size: 1529 bytes --]

diff -r e3d805626288 -r 58598ea5efbb man/ChangeLog
*** a/man/ChangeLog	Fri Dec 15 09:20:40 2006 +0100
--- b/man/ChangeLog	Sun Dec 17 19:29:55 2006 +0100
***************
*** 1,3 ****
--- 1,7 ----
+ 2006-12-17  Sascha Wilde  <wilde@sha-bang.de>
+ 
+ 	* pgg.texi: Added short note on gpg-agent to the introduction.
+ 
  2006-12-13  Reiner Steib  <Reiner.Steib@gmx.de>
  
  	* gnus.texi (Hiding Headers): Document that `long-to' and `many-to'
diff -r e3d805626288 -r 58598ea5efbb man/pgg.texi
*** a/man/pgg.texi	Fri Dec 15 09:20:40 2006 +0100
--- b/man/pgg.texi	Sun Dec 17 19:29:55 2006 +0100
***************
*** 77,83 ****
  By default, PGG uses GnuPG, but Pretty Good Privacy version 2 or version
  5 are also supported.  If you are new to such a system, I recommend that
  you should look over the GNU Privacy Handbook (GPH) which is available
! at @uref{http://www.gnupg.org/gph/}.
  
  @node How to use
  @chapter How to use
--- 77,88 ----
  By default, PGG uses GnuPG, but Pretty Good Privacy version 2 or version
  5 are also supported.  If you are new to such a system, I recommend that
  you should look over the GNU Privacy Handbook (GPH) which is available
! at @uref{http://www.gnupg.org/documentation/}.
! 
! When using GnuPG the additional use of the gpg-agent (@pxref{Caching
! passphrase}) is highly recommended, as it provides the most secure way
! for input and caching of passphrases.  Please refer to the documentation
! of GnuPG for details on installation and usage.
  
  @node How to use
  @chapter How to use

[-- Attachment #1.1.3: Type: text/plain, Size: 258 bytes --]


-- 
Sascha Wilde  :  "I heard that if you play the Windows CD backward, you
              :  get a satanic message. But that's nothing compared to
              :  when you play it forward: It installs Windows...." 
              :  -- G. R. Gaudreau

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Documenting gpg-agent

[Sascha Wilde]

[-- Attachment #1.1: Type: text/plain, Size: 624 bytes --]

Sascha Wilde <wilde@sha-bang.de> wrote:

> I have added a short paragraph (see attached patch) to point out, that
> the use of gpg-agent is recommended and where to get further information.

Since GnuPG2 and therefor gpg-agent is released, and we are
recommending its use: should we change the default value of
pgg-gpg-use-agent to t?

When no agent is available the old passphrase input/caching will still
be used as a fallback so changing the default should not do much harm.

cheers
sascha
-- 
Sascha Wilde : "Lies, was ich meine, nicht, was ich schreibe."
             : (Urs Traenkner in de.alt.admin)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Documenting gpg-agent

[Chong Yidong]

Sascha Wilde <wilde@sha-bang.de> writes:

> The feature it self, and the only customize able part of it, the
> variable `pgg-gpg-use-agent' has been documented since introduction.
>
> I have added a short paragraph (see attached patch) to point out,
> that the use of gpg-agent is recommended and where to get further
> information.

That should be fine.  I checked it in for you, thanks.

> Since GnuPG2 and therefor gpg-agent is released, and we are
> recommending its use: should we change the default value of
> pgg-gpg-use-agent to t?  When no agent is available the old
> passphrase input/caching will still be used as a fallback so
> changing the default should not do much harm.

Sounds good; I went ahead and did that.

Re: Documenting gpg-agent

[Richard Stallman]

    ! When using GnuPG the additional use of the gpg-agent (@pxref{Caching
    ! passphrase}) is highly recommended, as it provides the most secure way
    ! for input and caching of passphrases.  Please refer to the documentation
    ! of GnuPG for details on installation and usage.

This isn't sufficient, because

1. It should have an Info xref to the proper node in the other manual.
"Please refer to the documentation of GnuPG" is not sufficient.

2. Just an xref is not enough.  This needs to actually explain the
simple usage of gpg-agent.

3. If this is the preferred method, to avoid a security hole,
then we should remove or deprecate other methods.

Re: Documenting gpg-agent

[Richard Stallman]

    Since GnuPG2 and therefor gpg-agent is released, and we are
    recommending its use: should we change the default value of
    pgg-gpg-use-agent to t?

    When no agent is available the old passphrase input/caching will still
    be used as a fallback so changing the default should not do much harm.

That seems like the right thing, but I don't really know anything
about this, so I can't be sure.  Please let's wait a few days to see
if anyone presents a valid objection.

Re: Documenting gpg-agent

[Ken Manheimer]

On 12/18/06, Richard Stallman <rms@gnu.org> wrote:

>     Since GnuPG2 and therefor gpg-agent is released, and we are
>     recommending its use: should we change the default value of
>     pgg-gpg-use-agent to t?
>
>     When no agent is available the old passphrase input/caching will still
>     be used as a fallback so changing the default should not do much harm.
>
> That seems like the right thing, but I don't really know anything
> about this, so I can't be sure.  Please let's wait a few days to see
> if anyone presents a valid objection.

my allout encryption provisions are badly disrupted with the new pgg
revision, when gpg-agent is active.  it may be that i can work around
that by inhibiting use of gpg-agent in my code (assuming that the new
pgg revisions provide an easy way to do that?).  the timing is bad,
though - i have one week before i'm away for three weeks, and my time
available for unexpected problems like this, up to then, is extremely
limited.  so i'm in a bind, and worried about it.

one problem shows with allout symmetric-key encryption.  allout
prompts for the passphrase, and then pinentry prompts (multiple times,
because allout is checking validity of the symmetric key against a
dummy string, as well as using it for the target text) on each
encryption and decryption.  allout's key caching works, so it doesn't
prompt the user until the cached entry times out, but pinentry still
prompts multiple times on every encryption and decryption.

i wonder whether the new pgg provisions are ignoring a passed-in
passphrase when one is provided?  that would render useless allout's
caching, as appears to be happening.

i'll look at having allout do transient inhibition of the new
gpg-agent provisions (eg, let-binding pgg-gpg-use-agent to nil), but
doubt i'll have time to look at the new pgg code to see about whether
passed-in passphrases are disregarded.  so barring the former
workaround, i doubt i'll have time to look at proper integration with
the new pgg provisions before late january.

--
ken
http://myriadicity.net

Re: Documenting gpg-agent

[David Kastrup]

"Ken Manheimer" <ken.manheimer@gmail.com> writes:

> my allout encryption provisions are badly disrupted with the new pgg
> revision, when gpg-agent is active.

[...]

> i'll look at having allout do transient inhibition of the new
> gpg-agent provisions (eg, let-binding pgg-gpg-use-agent to nil), but
> doubt i'll have time to look at the new pgg code to see about
> whether passed-in passphrases are disregarded.  so barring the
> former workaround, i doubt i'll have time to look at proper
> integration with the new pgg provisions before late january.

I'd like to see Emacs 22 out before we have to update all copyright
notices to 2007.  And I am afraid of a full month certain delay before
the release.  It is bad enough having to fight last-minute changes;
we'd argue ourselves to exhaustion about last-month changes.  "Why, we
still have a full month for testing" is what I expect to hear then.

So personally I'd really be glad if this could be resolved before your
hiatus, leaving one less excuse to further delay.  That does not mean
that other reasons for delay might not crop up, but at least there is
a _chance_ that we'll get this beast out the door at one point of
time.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Documenting gpg-agent

[Ken Manheimer]

On 12/23/06, David Kastrup <dak@gnu.org> wrote:
> "Ken Manheimer" <ken.manheimer@gmail.com> writes:
>
> > my allout encryption provisions are badly disrupted with the new pgg
> > revision, when gpg-agent is active.
>
> [...]
>
> > i'll look at having allout do transient inhibition of the new
> > gpg-agent provisions (eg, let-binding pgg-gpg-use-agent to nil), but
> > doubt i'll have time to look at the new pgg code to see about
> > whether passed-in passphrases are disregarded.  so barring the
> > former workaround, i doubt i'll have time to look at proper
> > integration with the new pgg provisions before late january.
>
> I'd like to see Emacs 22 out before we have to update all copyright
> notices to 2007.  And I am afraid of a full month certain delay before
> the release.  It is bad enough having to fight last-minute changes;
> we'd argue ourselves to exhaustion about last-month changes.  "Why, we
> still have a full month for testing" is what I expect to hear then.
>
> So personally I'd really be glad if this could be resolved before your
> hiatus, leaving one less excuse to further delay.  That does not mean
> that other reasons for delay might not crop up, but at least there is
> a _chance_ that we'll get this beast out the door at one point of
> time.

i've (just) posted a patch that inhibits pgg's use of gpg-agent within
the scope of a let body where allout does the encryption.  i hope it's
applied soon, so i can verify the update while i have some time.

the posted patch is a minimal workaround, though.  i suspect something
closer to a fix would be to have pgg not resort to pgg-agent when
passphrases are passed in to it - that might be considered a bug in
the current pgg implementation.  that would also give me a path to
incrementally integrating gpg-agent functionality to allout's
encryption - that may never make sense for symmetric keys, but may be
fairly easy to do (without sacrificing current allout encryption
conveniences) for key pair encryption.
-- 
ken
http://myriadicity.net

Re: Documenting gpg-agent

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     ! When using GnuPG the additional use of the gpg-agent (@pxref{Caching
>     ! passphrase}) is highly recommended, as it provides the most secure way
>     ! for input and caching of passphrases.  Please refer to the documentation
>     ! of GnuPG for details on installation and usage.
>
> This isn't sufficient, because
>
> 1. It should have an Info xref to the proper node in the other manual.
> "Please refer to the documentation of GnuPG" is not sufficient.
>
> 2. Just an xref is not enough.  This needs to actually explain the
> simple usage of gpg-agent.
>
> 3. If this is the preferred method, to avoid a security hole,
> then we should remove or deprecate other methods.

How aboout this?

*** emacs/man/pgg.texi.~1.14.~	2006-12-17 18:16:25.000000000 -0500
--- emacs/man/pgg.texi	2006-12-23 20:04:50.000000000 -0500
***************
*** 74,88 ****
  This document assumes that you have already obtained and installed them
  and that you are familiar with its basic functions.
  
! By default, PGG uses GnuPG, but Pretty Good Privacy version 2 or version
! 5 are also supported.  If you are new to such a system, I recommend that
! you should look over the GNU Privacy Handbook (GPH) which is available
! at @uref{http://www.gnupg.org/documentation/}.
! 
! When using GnuPG the additional use of the gpg-agent (@pxref{Caching
! passphrase}) is highly recommended, as it provides the most secure way
! for input and caching of passphrases.  Please refer to the documentation
! of GnuPG for details on installation and usage.
  
  @node How to use
  @chapter How to use
--- 74,92 ----
  This document assumes that you have already obtained and installed them
  and that you are familiar with its basic functions.
  
! By default, PGG uses GnuPG.  If you are new to such a system, I
! recommend that you should look over the GNU Privacy Handbook (GPH)
! which is available at @uref{http://www.gnupg.org/documentation/}.
! 
! When using GnuPG, we recommend the use of the @code{gpg-agent}
! program, which is distributed with versions 2.0 and later of GnuPG.
! This is a daemon to manage private keys independently from any
! protocol, and provides the most secure way to input and cache your
! passphrases (@pxref{Caching passphrase}).  By default, PGG will
! attempt to use gpg-agent if it is running.  @xref{Invoking
! GPG-AGENT,,,gnupg,Using the GNU Privacy Guard}.
! 
! PGG also supports Pretty Good Privacy version 2 or version 5.
  
  @node How to use
  @chapter How to use
***************
*** 243,250 ****
  When using GnuPG (gpg) as PGP scheme you can use @code{gpg-agent} for
  caching@footnote{Actually @code{gpg-agent} does not cache passphrases
  but private keys.  On the other hand, from a users point of view this
! technical difference isn't visible.}.  If non-@code{nil} try to use a
! running @code{gpg-agent}.  It defaults to @code{nil}.
  @end defvar
  
  @node Default user identity
--- 247,254 ----
  When using GnuPG (gpg) as PGP scheme you can use @code{gpg-agent} for
  caching@footnote{Actually @code{gpg-agent} does not cache passphrases
  but private keys.  On the other hand, from a users point of view this
! technical difference isn't visible.}.  It defaults to @code{t}.
! Setting this to @code{nil} is not recommended.
  @end defvar
  
  @node Default user identity

Re: Documenting gpg-agent

[Richard Stallman]

    the attached patch works around problems with the new version of pgg's
    use of pgg-agent.

When you say "pgg-agent", you mean "gpg-agent", right?

		       when the agent is active, passphrases passed in to
    pgg are effectively ignored, such that pgg-agent continues to prompt
    (via pinentry) for the passphrase.

That sounds like a bug in pgg or gpg-agent.  Passing in passphrases
from the caller may not be recommended use, but it shouldn't just stop
working.

Would the GPG people please respond to this?

Re: Documenting gpg-agent

[Richard Stallman]

    > 1. It should have an Info xref to the proper node in the other manual.
    > "Please refer to the documentation of GnuPG" is not sufficient.
    >
    > 2. Just an xref is not enough.  This needs to actually explain the
    > simple usage of gpg-agent.
    >
    > 3. If this is the preferred method, to avoid a security hole,
    > then we should remove or deprecate other methods.

    How aboout this?

    *** emacs/man/pgg.texi.~1.14.~	2006-12-17 18:16:25.000000000 -0500
    --- emacs/man/pgg.texi	2006-12-23 20:04:50.000000000 -0500
    ***************

Your change takes care of #1 and #3, but doesn't do #2.
Please install the change, but we need a little more.

Meanwhile, there's a use of gpg-agent which needs @code.

Re: Documenting gpg-agent

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     > 1. It should have an Info xref to the proper node in the other manual.
>     > "Please refer to the documentation of GnuPG" is not sufficient.
>     >
>     > 2. Just an xref is not enough.  This needs to actually explain the
>     > simple usage of gpg-agent.
>     >
>     > 3. If this is the preferred method, to avoid a security hole,
>     > then we should remove or deprecate other methods.
>
>     How aboout this?
>
>     *** emacs/man/pgg.texi.~1.14.~	2006-12-17 18:16:25.000000000 -0500
>     --- emacs/man/pgg.texi	2006-12-23 20:04:50.000000000 -0500
>     ***************
>
> Your change takes care of #1 and #3, but doesn't do #2.
> Please install the change, but we need a little more.

Done.

Re: Documenting gpg-agent

[Daiki Ueno]

>>>>> In <E1GyIHM-00035O-FV@fencepost.gnu.org> 
>>>>>	Richard Stallman <rms@gnu.org> wrote:
> 		       when the agent is active, passphrases passed in to
>     pgg are effectively ignored, such that pgg-agent continues to prompt
>     (via pinentry) for the passphrase.

> That sounds like a bug in pgg or gpg-agent.  Passing in passphrases
> from the caller may not be recommended use, but it shouldn't just stop
> working.

Since allout exploits the use of PGG's passphrase handling functions to
provide a custom passphrase handling, it's not a bug in PGG or gpg-agent,
I think.

Ken, is it hard to make allout skip its own passphrase handling if
pgg-gpg-use-agent is t, as PGG does?  I know it disables passphrase
caching for symmetric encryption, but it seems a practical solution for
the release.
-- 
Daiki Ueno

Re: Documenting gpg-agent

[Richard Stallman]

    Since allout exploits the use of PGG's passphrase handling functions to
    provide a custom passphrase handling, it's not a bug in PGG or gpg-agent,
    I think.

I am not convinced of that.  He says that PGG was ignoring the
passphrases that allout passes in.  Why isn't that a bug?

Meanwhile...we decided that the only secure way to handle passphrases
in Emacs was to do it thru gpg-agent.  So doesn't that mean allout
has a problem due to failing to use gpg-agent?

Re: Documenting gpg-agent

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     > 2. Just an xref is not enough.  This needs to actually explain the
>     > simple usage of gpg-agent.
>
> Your change takes care of #1 and #3, but doesn't do #2.

I don't quite understand why do we need to explain how to use
gpg-agent.  That's described in the gpg-agent documentation (and we
have a link to its info file).

Re: Documenting gpg-agent

[Ken Manheimer]

On 12/24/06, Daiki Ueno <ueno@unixuser.org> wrote:
> >>>>> In <E1GyIHM-00035O-FV@fencepost.gnu.org>
> >>>>>   Richard Stallman <rms@gnu.org> wrote:
> >                      when the agent is active, passphrases passed in to
> >     pgg are effectively ignored, such that pgg-agent continues to prompt
> >     (via pinentry) for the passphrase.
>
> > That sounds like a bug in pgg or gpg-agent.  Passing in passphrases
> > from the caller may not be recommended use, but it shouldn't just stop
> > working.
>
> Since allout exploits the use of PGG's passphrase handling functions to
> provide a custom passphrase handling, it's not a bug in PGG or gpg-agent,
> I think.

the thing i'm seeing as a problem is that allout is passing in the
right passphrase to pgg, but gpg-agent is still prompting for the
passphrase if it doesn't already have it cached.  it seems to me that
if the calling routine is doing its own passphrase handling, pgg
should respect that.

that said, i agree that it's preferable to have gpg-agent do the
passphrase handling when gpg-agent is available and applicable.

unfortunately, i would expect that gpg-agent is *not* applicable when
it comes to symmetric keys, because symmetric keys are not specific to
any signature of the encrypted text's envelope.  ie, i don't think
that gpg-agent can, in principle, cache symmetric keys, because it
can't know which key belongs to which message - and in practice, that
seems to be the case.  (let me know if i'm mistaken here.)

symmetric keys are a particular concern for allout, because allout
enables having myriad independently encrypted messages in an outline.
varying keys for various symmetric-key-encoded messages in an
outline/file would easily grow to an unmanagable burden for the user,
so allout provides file-specific key verification and user-set
reminder for a single symmetric key per file.  this makes symmetric
keys quite useful with allout, and i expect is way outside the purview
of gpg-agent.  so it looks like i need to have allout continue using
its internal passphrase caching for symmetric keys.

so i will arrange for allout to take care of symmetric-key caching,
but defer to pgg when it comes to keypair passphrases.  (i could
arrange for allout to do keypair caching when pgg-gpg-use-agent is
nil, but i think i want to get allout out of the business of touching
the much more sensitive keypair keys, so i'll submit a patch that has
allout doing the caching for symmetric keys only.)

> Ken, is it hard to make allout skip its own passphrase handling if
> pgg-gpg-use-agent is t, as PGG does?  I know it disables passphrase
> caching for symmetric encryption, but it seems a practical solution for
> the release.

i think the balance the patch i propose, above, is a good one.

as far as i can tell, gpg-agent doesn't and can't provide for
symmetric key caching, and it definitely can't provide for the special
considerations that come with having multiple independently
symmetrically-encrypted messages in a file.  the allout provisions for
multiple independently encrypted symmetric messages entails an extra
decryption (to decrypt a random string, stored on an emacs file local
variable, which acts as a verifier for user passphrase input) on any
symmetric-key encryption or decryption, which intensifies the need for
symmetric key caching.  the patch i'll submit will leave
responsibility for symmetric keys to allout's caching, which will
cover all these concerns while gpg-agent wouldn't.

keypair keys, on the other hand, don't need those other provisions,
and are more sensitive secrets, so i'm happier to leave responsibilty
for them outside of allout.  the patch will leave that responsibility
to pgg, which will defer to gpg-agent when available.

the only downside to this late change is that i will likely not have
time to tend to problems if it introduces any.  i'm confident enough
about it that i'm willing to go with that, though i'm not crazy about
the timing.
-- 
ken
http://myriadicity.net

Re: Documenting gpg-agent

[Daiki Ueno]

>>>>> In <E1Gyt4c-0005JD-8J@fencepost.gnu.org> 
>>>>>	Richard Stallman <rms@gnu.org> wrote:
>     Since allout exploits the use of PGG's passphrase handling functions to
>     provide a custom passphrase handling, it's not a bug in PGG or gpg-agent,
>     I think.

> I am not convinced of that.  He says that PGG was ignoring the
> passphrases that allout passes in.  Why isn't that a bug?

I'm sorry for that I misunderstood his explanation and the current
gpg-agent support of PGG.  I just looked at the code and found it
actually has a bug.  PGG checks whether to use a given passphrase or
gpg-agent two times, for the first time a given passphrase wins, but for
the second time gpg-agent wins.  Here is a tiny patch to fix this.

Sascha, can you check this?

Index: lisp/pgg-gpg.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/pgg-gpg.el,v
retrieving revision 1.19
diff -c -r1.19 pgg-gpg.el
*** lisp/pgg-gpg.el	17 Dec 2006 23:18:36 -0000	1.19
--- lisp/pgg-gpg.el	26 Dec 2006 01:00:29 -0000
***************
*** 61,67 ****
    "GnuPG ID of your default identity.")
  
  (defun pgg-gpg-process-region (start end passphrase program args)
!   (let* ((use-agent (pgg-gpg-use-agent-p)) 
  	 (output-file-name (pgg-make-temp-file "pgg-output"))
  	 (args
  	  `("--status-fd" "2"
--- 61,67 ----
    "GnuPG ID of your default identity.")
  
  (defun pgg-gpg-process-region (start end passphrase program args)
!   (let* ((use-agent (and (null passphrase) (pgg-gpg-use-agent-p)))
  	 (output-file-name (pgg-make-temp-file "pgg-output"))
  	 (args
  	  `("--status-fd" "2"

-- 
Daiki Ueno

Re: Documenting gpg-agent

[Richard Stallman]

    > Your change takes care of #1 and #3, but doesn't do #2.

    I don't quite understand why do we need to explain how to use
    gpg-agent.

Because people should NOT have to turn to another manual
just to learn the basic use of this Emacs feature.
The simple standard recipe should be given in the Emacs documentation.

Re: Documenting gpg-agent

[Sascha Wilde]

Daiki Ueno <ueno@unixuser.org> wrote:
[...]
> I just looked at the code and found it actually has a bug.  PGG
> checks whether to use a given passphrase or gpg-agent two times, for
> the first time a given passphrase wins, but for the second time
> gpg-agent wins.  Here is a tiny patch to fix this.

Thanks for fixing this.

> Sascha, can you check this?

I don't have CVS write access (neither for GNU Emacs nor for gnus),
sorry.

cheers
sascha
-- 
Sascha Wilde
"Structure is _nothing_ if it is all you got.  Skeletons _spook_ people if
 thwy try to walk around on their own.  I really wonder why XML does
 not."            -- Erik Naggum <erik@naggum.net> in comp.lang.lisp

Re: Documenting gpg-agent

[Sascha Wilde]

Richard Stallman <rms@gnu.org> wrote:

>     > Your change takes care of #1 and #3, but doesn't do #2.
>
>     I don't quite understand why do we need to explain how to use
>     gpg-agent.
>
> Because people should NOT have to turn to another manual
> just to learn the basic use of this Emacs feature.
> The simple standard recipe should be given in the Emacs documentation.

I strongly disagree.  gpg-agent is not a emacs feature, but a gnupg
feature, and gnupg is utilized by emacs.  It's not in the scope of the
Emacs manual to teach users everything they need to know to make
sensible use of OpenPGP Mail encryption.  Just as it isn't the duty of
the Emacs manual to tell people about make, only because we have M-x
compile...

cheers
sascha
-- 
Sascha Wilde  :  "The PROPER way to handle HTML postings is to cancel
the article, then hire a hitman to kill the poster, his wife and kids,
and fuck his dog and smash his computer into little bits. Anything
more is just extremism."  -- Paul Tomblin

Re: Documenting gpg-agent

[Richard Stallman]

    I strongly disagree.  gpg-agent is not a emacs feature, but a gnupg
    feature, and gnupg is utilized by emacs.  It's not in the scope of the
    Emacs manual to teach users everything they need to know to make
    sensible use of OpenPGP Mail encryption.

It is a mistake to design documentation based on rigid modularity.

Following a cross reference is a pain in the neck, for a human reader,
and many just won't do it.  So when the material in question is small,
it is much better to copy it and avoid the cross reference.

      Just as it isn't the duty of
    the Emacs manual to tell people about make, only because we have M-x
    compile...

If in 20 lines we could teach most people using M-x compile
all they need to know about make, we would include that too.

Re: Documenting gpg-agent

[Ken Manheimer]

i believe the patch/issue discussed below has slipped between the
cracks.  pgg-gpg-process-region still disregards a passed-in
passphrase, so that the gpg-agent prompts the user despite it having
been explicitly passed in as a parameter.

i can verify that the patch daiki ueno proposes in the discussion
settles the problem for me.  this being a security-related routine, it
would be nice to know that the "right" eyes, and not just "many eyes",
have evaluated it - and everyone waiting for someone else to be the
right eyes may be why it has languished...

i currently have a provision in allout to disable use of gpg-agent
within the critical region where this bug occurs, but it would be
better to correct pgg-gpg-process-region, and remove the workaround
from allout.  is there a way to get the change evaluated sufficiently?
-- 
ken
http://myriadicity.net

On 12/25/06, Daiki Ueno <ueno@unixuser.org> wrote:
> >>>>> In <E1Gyt4c-0005JD-8J@fencepost.gnu.org>
> >>>>>   Richard Stallman <rms@gnu.org> wrote:
> >     Since allout exploits the use of PGG's passphrase handling functions to
> >     provide a custom passphrase handling, it's not a bug in PGG or gpg-agent,
> >     I think.
>
> > I am not convinced of that.  He says that PGG was ignoring the
> > passphrases that allout passes in.  Why isn't that a bug?
>
> I'm sorry for that I misunderstood his explanation and the current
> gpg-agent support of PGG.  I just looked at the code and found it
> actually has a bug.  PGG checks whether to use a given passphrase or
> gpg-agent two times, for the first time a given passphrase wins, but for
> the second time gpg-agent wins.  Here is a tiny patch to fix this.
>
> Sascha, can you check this?
>
> Index: lisp/pgg-gpg.el
> ===================================================================
> RCS file: /sources/emacs/emacs/lisp/pgg-gpg.el,v
> retrieving revision 1.19
> diff -c -r1.19 pgg-gpg.el
> *** lisp/pgg-gpg.el     17 Dec 2006 23:18:36 -0000      1.19
> --- lisp/pgg-gpg.el     26 Dec 2006 01:00:29 -0000
> ***************
> *** 61,67 ****
>     "GnuPG ID of your default identity.")
>
>   (defun pgg-gpg-process-region (start end passphrase program args)
> !   (let* ((use-agent (pgg-gpg-use-agent-p))
>          (output-file-name (pgg-make-temp-file "pgg-output"))
>          (args
>           `("--status-fd" "2"
> --- 61,67 ----
>     "GnuPG ID of your default identity.")
>
>   (defun pgg-gpg-process-region (start end passphrase program args)
> !   (let* ((use-agent (and (null passphrase) (pgg-gpg-use-agent-p)))
>          (output-file-name (pgg-make-temp-file "pgg-output"))
>          (args
>           `("--status-fd" "2"
>
> --
> Daiki Ueno

Re: Documenting gpg-agent

[Richard Stallman]

I installed this.  Thanks.