bug#3953: 23.0.94; GPG interaction fails

bug#3953: 23.0.94; GPG interaction fails

[Torsten Bronger]

In response to bug report #2412:

Daiki Ueno <ueno@unixuser.org> writes:

> Sven Joachim <svenjoac@gmx.de> writes:
>
>>> -    (accept-process-output (epg-context-process context) 1)))
>>> +    (accept-process-output (epg-context-process context) 1))
>>> +  (sleep-for 0.1))
>>
>> That seems to do the trick.  At least, I had no problem in ~15 attempts
>> to preview/send signed messages, whereas without your patch the "Sign
>> failed" error would happen about every second time.
>
> Thanks for testing.  I've checked in the patch.

I experience the same problem but the above patch doesn't really
help me.  Without the sleeping time, I get failures with signature
checking of incoming emails almost always; with the sleeping time,
it works at least in 20% of the cases.  I increased the time to even
10 seconds but the success rate didn't increase further.  The
behaviour remains probabilistic.

All aspects of GPG interaction -- signature checking, signing and
encrypting -- are affected by this behaviour.

Tschö,
Torsten.




In GNU Emacs 23.0.94.1 (x86_64-unknown-linux-gnu)
 of 2009-06-07 on wilson
Windowing system distributor `The X.Org Foundation', version 11.0.10600000
configured using `configure  '--prefix=/usr/local/' '--mandir=/usr/local/share/man/' '--infodir=/usr/local/share/info/' '--with-x-toolkit=no' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-x''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  gnus-undo-mode: t
  shell-dirtrack-mode: t
  global-auto-revert-mode: t
  savehist-mode: t
  display-time-mode: t
  desktop-save-mode: t
  mouse-wheel-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

bug#3953: 23.0.94; GPG interaction fails

[Daiki Ueno]

reopen 2412
merge 2412 3953
thanks

>>>>> In <20090727194515.F1958E42E9@wilson.homeunix.com> 
>>>>>	Torsten Bronger <bronger@physik.rwth-aachen.de> wrote:
> >>> -    (accept-process-output (epg-context-process context) 1)))
> >>> +    (accept-process-output (epg-context-process context) 1))
> >>> +  (sleep-for 0.1))
> >>
> >> That seems to do the trick.  At least, I had no problem in ~15 attempts
> >> to preview/send signed messages, whereas without your patch the "Sign
> >> failed" error would happen about every second time.
> >
> > Thanks for testing.  I've checked in the patch.

> I experience the same problem but the above patch doesn't really
> help me.  Without the sleeping time, I get failures with signature
> checking of incoming emails almost always; with the sleeping time,
> it works at least in 20% of the cases.  I increased the time to even
> 10 seconds but the success rate didn't increase further.  The
> behaviour remains probabilistic.

Thanks for further testing.  Well, in that case an essential part of
process-filter might not be executed in 20% of the cases.

Does replacing (sleep-for 0.1) with:

(epg--process-filter (epg-context-process context) "")

change the situation?

Regards,
-- 
Daiki Ueno

bug#3953: 23.0.94; GPG interaction fails

[Torsten Bronger]

Hallöchen!

Daiki Ueno writes:

> [...]
>
>> I experience the same problem but the above patch doesn't really
>> help me.  Without the sleeping time, I get failures with
>> signature checking of incoming emails almost always; with the
>> sleeping time, it works at least in 20% of the cases.  I
>> increased the time to even 10 seconds but the success rate didn't
>> increase further.  The behaviour remains probabilistic.
>
> Thanks for further testing.  Well, in that case an essential part of
> process-filter might not be executed in 20% of the cases.
>
> Does replacing (sleep-for 0.1) with:
>
> (epg--process-filter (epg-context-process context) "")
>
> change the situation?

It has the same effect as (sleep-for 0.1): It helps, but only
slightly.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de
                                  or http://bronger-jmp.appspot.com

bug#3953: 23.0.94; GPG interaction fails

[Daiki Ueno]

>>>>> In <87ws5sv6tb.fsf@physik.rwth-aachen.de> 
>>>>>	Torsten Bronger <bronger@physik.rwth-aachen.de> wrote:
> > Does replacing (sleep-for 0.1) with:
> >
> > (epg--process-filter (epg-context-process context) "")
> >
> > change the situation?

> It has the same effect as (sleep-for 0.1): It helps, but only
> slightly.

Hmm, is your epg-debug output as innocent as the one that the original
reporter provided?

Currently, I suspect that the code in the following clause might be
skipped:

(unless epg-process-filter-running ...)

Can you insert debug-prints in epg-wait-for-completion?  It would be
something like:

(message "epg-process-filter-running: %S" epg-process-filter-running)

Regards,
-- 
Daiki Ueno

bug#3953: 23.0.94; GPG interaction fails

[Torsten Bronger]

Hallöchen!

Daiki Ueno writes:

> [...]
>
>>> Does replacing (sleep-for 0.1) with:
>>>
>>> (epg--process-filter (epg-context-process context) "")
>>>
>>> change the situation?
>
>> It has the same effect as (sleep-for 0.1): It helps, but only
>> slightly.
>
> Hmm, is your epg-debug output as innocent as the one that the original
> reporter provided?

It's every time:

gpg --no-tty --status-fd 1 --yes --command-fd 0 --output /tmp/epg-output6267bsQ -
[GNUPG:] PLAINTEXT 74 0 
gpg: Signatur am Mo 29 Jun 2009 10:31:28 CEST mit DSA Schlüssel, ID 9F516B77, erfolgt
[GNUPG:] SIG_ID jkbjBUZ5Lu5ozCYNw6Tsx9qYwsY 2009-06-29 1246264288
[GNUPG:] GOODSIG D5E3CEFC9F516B77 Torsten Bronger <bronger@physik.rwth-aachen.de>
gpg: Korrekte Unterschrift von 'Torsten Bronger <bronger@physik.rwth-aachen.de>'
[GNUPG:] VALIDSIG C5C8D6E279D2EFE98C0F6D77D5E3CEFC9F516B77 2009-06-29 1246264288 0 3 0 17 2 01 C5C8D6E279D2EFE98C0F6D77D5E3CEFC9F516B77
[GNUPG:] TRUST_ULTIMATE

> Currently, I suspect that the code in the following clause might be
> skipped:
>
> (unless epg-process-filter-running ...)
>
> Can you insert debug-prints in epg-wait-for-completion?  It would be
> something like:
>
> (message "epg-process-filter-running: %S" epg-process-filter-running)

And where should I put it exactly?  (I don't speak Lisp.)  I now
wrote

	(unless epg-process-filter-running
	  (message "epg-process-filter-running: %S" epg-process-filter-running)

And then, *Messages* say

epg-process-filter-running: nil

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de
                                  or http://bronger-jmp.appspot.com

bug#3953: 23.0.94; GPG interaction fails

[Daiki Ueno]

>>>>> In <87vdlbtho2.fsf@physik.rwth-aachen.de> 
>>>>>	Torsten Bronger <bronger@physik.rwth-aachen.de> wrote:
> > Can you insert debug-prints in epg-wait-for-completion?  It would be
> > something like:
> >
> > (message "epg-process-filter-running: %S" epg-process-filter-running)

> And where should I put it exactly?

Like this:

(defun epg-wait-for-completion (context)
  "Wait until the `epg-gpg-program' process completes."
  (while (eq (process-status (epg-context-process context)) 'run)
    (accept-process-output (epg-context-process context) 1))
  (message "epg-process-filter-running: %S" epg-process-filter-running) ;; <-
  (sleep-for 0.1)
  (message "epg-process-filter-running: %S" epg-process-filter-running) ;; <-
  )

Regards,
-- 
Daiki Ueno

bug#3953: 23.0.94; GPG interaction fails

[Torsten Bronger]

Hallöchen!

Daiki Ueno writes:

> [...]
>
>>> Can you insert debug-prints in epg-wait-for-completion?  It
>>> would be something like:
>>>
>>> (message "epg-process-filter-running: %S" epg-process-filter-running)
>
>> And where should I put it exactly?
>
> Like this:
>
> (defun epg-wait-for-completion (context)
>   "Wait until the `epg-gpg-program' process completes."
>   (while (eq (process-status (epg-context-process context)) 'run)
>     (accept-process-output (epg-context-process context) 1))
>   (message "epg-process-filter-running: %S" epg-process-filter-running) ;; <-
>   (sleep-for 0.1)
>   (message "epg-process-filter-running: %S" epg-process-filter-running) ;; <-
>   )

I get (no matter whether Gnus shows the correct result or not):

epg-process-filter-running: nil [2 times]

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de
                                  or http://bronger-jmp.appspot.com

bug#3953: 23.0.94; GPG interaction fails

[Daiki Ueno]

>>>>> In <87ab2mzs2i.fsf@physik.rwth-aachen.de> 
>>>>>	Torsten Bronger <bronger@physik.rwth-aachen.de> wrote:
> >>> Can you insert debug-prints in epg-wait-for-completion?  It
> >>> would be something like:
> >>>
> >>> (message "epg-process-filter-running: %S" epg-process-filter-running)

> I get (no matter whether Gnus shows the correct result or not):

> epg-process-filter-running: nil [2 times]

Do you get the same result on both successful and failed cases?
(Since I have never been able to reproduce the problem at all, I need
data on failed cases).

Regards,
-- 
Daiki Ueno

bug#3953: 23.0.94; GPG interaction fails

[Torsten Bronger]

Hallöchen!

Daiki Ueno writes:

>>>>>> In <87ab2mzs2i.fsf@physik.rwth-aachen.de> 
>>>>>>	Torsten Bronger <bronger@physik.rwth-aachen.de> wrote:
>> >>> Can you insert debug-prints in epg-wait-for-completion?  It
>> >>> would be something like:
>> >>>
>> >>> (message "epg-process-filter-running: %S" epg-process-filter-running)
>
>> I get (no matter whether Gnus shows the correct result or not):
>
>> epg-process-filter-running: nil [2 times]
>
> Do you get the same result on both successful and failed cases?

Yes.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de
                                  or http://bronger-jmp.appspot.com

bug#3953: 23.0.94; GPG interaction fails

[Ashish SHUKLA]

Hi,

I'm also exhibiting this behaviour in the following version of Emacs:

GNU Emacs 23.1.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.16.5)
 of 2009-08-03 on chateau.d.lf

Following are the last few lines of the " *epg-debug*" buffer:

#v+
[GNUPG:] SIG_CREATED D 17 2 01 1249292155 1E00467977E4F8EE2E4B56F21F2F8410762E5E74
/usr/bin/gpg2 --no-tty --status-fd 1 --yes --use-agent --command-fd 0 --armor --textmode --output /tmp/epg-output31278mXX --detach-sign
[GNUPG:] USERID_HINT 1F2F8410762E5E74 Ashish Shukla (.......) <wahjava@gmail.com>
[GNUPG:] NEED_PASSPHRASE 1F2F8410762E5E74 1F2F8410762E5E74 17 0
[GNUPG:] GOOD_PASSPHRASE
[GNUPG:] BEGIN_SIGNING H2
[GNUPG:] SIG_CREATED D 17 2 01 1249292356 1E00467977E4F8EE2E4B56F21F2F8410762E5E74
/usr/bin/gpg2 --no-tty --status-fd 1 --yes --use-agent --command-fd 0 --armor --textmode --output /tmp/epg-output31278zhd --detach-sign
[GNUPG:] USERID_HINT 1F2F8410762E5E74 Ashish Shukla (.......) <wahjava@gmail.com>
[GNUPG:] NEED_PASSPHRASE 1F2F8410762E5E74 1F2F8410762E5E74 17 0
[GNUPG:] GOOD_PASSPHRASE
[GNUPG:] BEGIN_SIGNING H2
[GNUPG:] SIG_CREATED D 17 2 01 1249292357 1E00467977E4F8EE2E4B56F21F2F8410762E5E74
#v-

Like Torsten, I've also got the same string in both cases:

#v+
epg-process-filter-running: nil [12 times]
#v-

HTH
-- 
Ashish SHUKLA

bug#3953: 23.0.94; GPG interaction fails

[Torsten Bronger]

Hallöchen!

Why was this bug closed?  The problem still persists.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de
                                  or http://bronger-jmp.appspot.com