headers
Simon Josefsson | 1 Apr 2006 11:06

Re: Small patch to enable use of gpg-agent with pgg

Romain Francoise <romain <at> orebokech.com> writes:

> Simon Josefsson <jas <at> extundo.com> writes:
>
>> I've installed it, with this modification, on v5-10, trunk and in
>> emacs CVS.
>
> There's a problem with this patch, at least in my setup: untrusted
> signatures are no longer denoted as such in the PGP button in the
> Article buffer.  (It might be due to an earlier patch, my working copy
> hadn't been updated for a few days.  I'm using the trunk.)

Weird, that shouldn't be affected by that patch.  Uhm, if you do 'cvs
update -D 2006-03-01 pgg-gpg.el' (or some date before the patch), does
it work again?

Daiki, do you have any ideas?  Does your patch change what status
information gpg outputs, perhaps?
Permalink | Reply | 16 comments |
headers
Romain Francoise | 1 Apr 2006 11:23
X-Face
Favicon
Gravatar

Re: Small patch to enable use of gpg-agent with pgg

Simon Josefsson <jas <at> extundo.com> writes:

> Weird, that shouldn't be affected by that patch.  Uhm, if you do 'cvs
> update -D 2006-03-01 pgg-gpg.el' (or some date before the patch), does
> it work again?

Yes.

> Daiki, do you have any ideas?  Does your patch change what status
> information gpg outputs, perhaps?

Bisecting shows that it's caused by the following change:

2006-03-27  Daiki Ueno  <ueno <at> unixuser.org>

	* pgg-gpg.el: Invoke gpg asynchronous, to avoid querying for
	passphrases when it is not needed.
	(pgg-gpg-use-agent): Add, to hard code that pgg shouldn't wait for
	passphrase stuff from gpg, should only be necessary when you use
	gpg with a smartcard.

Stepping through the mml2015 code, I see that after this change, the
*MML2015 Result* buffer no longer contains the GnuPG status lines (the
ones that start with ``[GNUPG:]'', in particular the ``[GNUPG:]
TRUST_UNDEFINED'' line), so `mml2015-gpg-extract-signature-details'
doesn't find the trust level of the signature.  So yeah, status
information gets lost somewhere in PGG due to the new asynchronous
interface.

I'm using Emacs from CVS (from March 30th).
(Continue reading)

Permalink | Reply | 15 comments |
headers
Richard Stallman | 1 Apr 2006 15:46
Picon
Picon

Re: defcustom :version

If you want to work on the doc string of defface, go ahead.
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 Apr 2006 16:23
Picon

Re: defcustom :version

> Comments: In-reply-to Richard Stallman <rms <at> gnu.org>
> 	message dated "Fri, 31 Mar 2006 12:28:34 -0500."
> Date: Fri, 31 Mar 2006 10:11:59 -0800
> From: Bill Wohler <wohler <at> newt.com>
> Cc: ding <at> gnus.org, emacs-devel <at> gnu.org
> 
> Richard Stallman <rms <at> gnu.org> wrote:
> 
> >     I didn't realize that a face could have a version as the defface
> >     docstring doesn't indicate it. Sure enough, defface, as well as
> >     defgroup, call custom-handle-all-keywords so :version is supported. Why
> >     then, are not all the keywords documented in all three macros?
> > 
> > They are, in the node Common Keywords.  
> 
> The docstring implies only :group is supported:
> 
>     The remaining arguments should have the form
> 
>        [KEYWORD VALUE]...
> 
>     The following KEYWORDs are defined:
> 
>     :group  VALUE should be a customization group.
> 	    Add face to that group.
> 
> It also doesn't mention the ARGS argument. I would suggest either
> enumerating all the legal keywords, or:
> 
>     The remaining arguments ARGS should have the form
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Manheimer | 2 Apr 2006 02:30
Picon
Gravatar

Re: Small patch to enable use of gpg-agent with pgg

hi, all.  i'm just catching up on this development - partly spurred by
breakage of some of my code (allout's encryption stuff) which depends
on functions that have been removed from pgg-gpg,
pgg-gpg-symmetric-key-p and pgg-gpg-select-matching-key.

on looking at the pgg-gpg, i noticed that some other convenience
functions on which i depend have been removed, as well:
pgg-gpg-lookup-key-owner and pgg-gpg-key-id-from-key-owner, and i
suppose others.

unless replaced with something equivalent, i think that the  removal
of these functions means that application code can not anticipate the
kind of key to request from the user.  am i missing something here?

the ChangeLog says nothing about these changes...
--
ken manheimer
ken.manheimer <at> gmail.com
http://myriadicity.net
Permalink | Reply | 0 comments |
headers
Daiki Ueno | 2 Apr 2006 10:28
Gravatar

Re: Small patch to enable use of gpg-agent with pgg

Hello Ken,

>>>>> In <2cd46e7f0604011630r6388edackc4c7ef21b92ecaa7 <at> mail.gmail.com> 
>>>>>	"Ken Manheimer" <ken.manheimer <at> gmail.com> wrote:
> hi, all.  i'm just catching up on this development - partly spurred by
> breakage of some of my code (allout's encryption stuff) which depends
> on functions that have been removed from pgg-gpg,
> pgg-gpg-symmetric-key-p and pgg-gpg-select-matching-key.

I'm sorry I missed that.

However, pgg-gpg is one of backend modules of pgg and it should not
provide its own API.  If we revive these functions, we should add them
to pgg.el instead of pgg-gpg.el.

I'll read allout's encryption stuff and try to prepare a fix.

Regards,
--

-- 
Daiki Ueno
Permalink | Reply | 0 comments |
headers
Reiner Steib | 3 Apr 2006 10:14
X-Face

"[GNUPG:] TRUST_UNDEFINED" not indicated (was: Small patch to enable use of gpg-agent with pgg)

On Sat, Apr 01 2006, Romain Francoise wrote:

> Simon Josefsson <jas <at> extundo.com> writes:
>> Daiki, do you have any ideas?  Does your patch change what status
>> information gpg outputs, perhaps?
>
> Bisecting shows that it's caused by the following change:
>
> 2006-03-27  Daiki Ueno  <ueno <at> unixuser.org>
>
> 	* pgg-gpg.el: Invoke gpg asynchronous, to avoid querying for
> 	passphrases when it is not needed.
> 	(pgg-gpg-use-agent): Add, to hard code that pgg shouldn't wait for
> 	passphrase stuff from gpg, should only be necessary when you use
> 	gpg with a smartcard.
>
> Stepping through the mml2015 code, I see that after this change, the
> *MML2015 Result* buffer no longer contains the GnuPG status lines (the
> ones that start with ``[GNUPG:]'', in particular the ``[GNUPG:]
> TRUST_UNDEFINED'' line), so `mml2015-gpg-extract-signature-details'
> doesn't find the trust level of the signature.  So yeah, status
> information gets lost somewhere in PGG due to the new asynchronous
> interface.

Simon, what do you suggest to do for Gnus 5.10.8?  Should we revert
pgg-gpg.el to 2006-03-21 (before adding gpg-agent support)?

Bye, Reiner.
--

-- 
       ,,,
(Continue reading)

Permalink | Reply | 14 comments |
headers
Daiki Ueno | 3 Apr 2006 10:32
Gravatar

Re: "[GNUPG:] TRUST_UNDEFINED" not indicated

>>>>> In <v93bgvoz33.fsf <at> marauder.physik.uni-ulm.de> 
>>>>>	Reiner Steib <reinersteib+gmane <at> imap.cc> wrote:
> On Sat, Apr 01 2006, Romain Francoise wrote:

> > Simon Josefsson <jas <at> extundo.com> writes:
> >> Daiki, do you have any ideas?  Does your patch change what status
> >> information gpg outputs, perhaps?
> >
> > Bisecting shows that it's caused by the following change:
> >
> > 2006-03-27  Daiki Ueno  <ueno <at> unixuser.org>
> >
> > 	* pgg-gpg.el: Invoke gpg asynchronous, to avoid querying for
> > 	passphrases when it is not needed.
> > 	(pgg-gpg-use-agent): Add, to hard code that pgg shouldn't wait for
> > 	passphrase stuff from gpg, should only be necessary when you use
> > 	gpg with a smartcard.
> >
> > Stepping through the mml2015 code, I see that after this change, the
> > *MML2015 Result* buffer no longer contains the GnuPG status lines (the
> > ones that start with ``[GNUPG:]'', in particular the ``[GNUPG:]
> > TRUST_UNDEFINED'' line), so `mml2015-gpg-extract-signature-details'
> > doesn't find the trust level of the signature.  So yeah, status
> > information gets lost somewhere in PGG due to the new asynchronous
> > interface.

> Simon, what do you suggest to do for Gnus 5.10.8?  Should we revert
> pgg-gpg.el to 2006-03-21 (before adding gpg-agent support)?

Here is the temporary fix for this problem.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Romain Francoise | 3 Apr 2006 10:48
X-Face
Favicon
Gravatar

Re: "[GNUPG:] TRUST_UNDEFINED" not indicated

Daiki Ueno <ueno <at> unixuser.org> writes:

> diff -u -r7.17 pgg-gpg.el
> --- pgg-gpg.el	29 Mar 2006 07:51:17 -0000	7.17
> +++ pgg-gpg.el	3 Apr 2006 08:24:53 -0000
>  <at>  <at>  -144,7 +144,7  <at>  <at> 
>      (when (buffer-live-p (process-buffer process))
>        (insert-buffer-substring (process-buffer process))
>        (goto-char (point-min))
> -      (delete-matching-lines "^\\[GNUPG:] ")
> +      ;(delete-matching-lines "^\\[GNUPG:] ")
>        (goto-char (point-min))
>        (while (re-search-forward "^gpg: " nil t)
>  	(replace-match "")))

Indeed, this fixes the problem I reported about trust information
missing from the signature button.

However, there are still issues with the asynchronous interface; for
example if one moves with N and P through a group where all articles are
signed faster than GnuPG can check the signatures, sometimes this error
is signalled:

| error in process filter: sit-for: Selecting deleted buffer
| error in process filter: Selecting deleted buffer

--

-- 
Romain Francoise <romain <at> orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter
(Continue reading)

Permalink | Reply | 11 comments |
headers
Simon Josefsson | 3 Apr 2006 10:49

Re: "[GNUPG:] TRUST_UNDEFINED" not indicated (was: Small patch to

> Simon, what do you suggest to do for Gnus 5.10.8?  Should we revert
> pgg-gpg.el to 2006-03-21 (before adding gpg-agent support)?

I installed Daiki's temporary fix, if we can confirm that it solves this
problem, I think we should release 5.10 as is, otherwise I tend to agree
to revert this stuff for v5-10, and wait for it to stabilize on the trunk
until we move it back to v5-10.  It can always go into 5.10.9.
Permalink | Reply | 0 comments |

Gmane