bugs: slow scoring in emacs 22, slow PGP in No Gnus v0.4, serious PGP signing bug

bugs: slow scoring in emacs 22, slow PGP in No Gnus v0.4, serious PGP signing bug

[Max Froumentin]

Hi, 

3 preliminary bug reports, for which I'd like to find out of someone
else has noticed it, before I start looking deeper.

1. scoring in emacs 22

I recently gave emacs 22 a try and noticed a bug with gnus, which
completely prevents me from using it: In some groups, articles are
scored on body contents. With emacs 21.4, scoring an nnfolder group
with around 500 articles takes 2 seconds. On emacs 22, it takes about
30 seconds. It's obviously something to do with emacs 22, but I
haven't found a mention of regexp-search being slow. But it might be
something else, like loading article bodies during the scoring.

2. slowness in parsing PGP signed messages.

I've been sticking to No Gnus CVS fairly closely, and just when No
Gnus 0.4 was released I noticed that displaying an article with a PGP
signature took longer than before (~1 sec, vs immediate).

3. serious bug in PGP signed outgoing messages

I've been signing my emails using inline PGP, and since updating to No
Gnus 0.4, and further CVS updates, it's happened that some outgoing
emails had had their bodies removed before sending.  Even the saved
GCC was empty. Very annoying...

Max.

Re: bugs: slow scoring in emacs 22, slow PGP in No Gnus v0.4, serious PGP signing bug

[Elias Oltmanns]

Max Froumentin <max@lapin-bleu.net> wrote:
> Hi, 
>
> 3 preliminary bug reports, for which I'd like to find out of someone
> else has noticed it, before I start looking deeper.
>
> 1. scoring in emacs 22
>
> I recently gave emacs 22 a try and noticed a bug with gnus, which
> completely prevents me from using it: In some groups, articles are
> scored on body contents. With emacs 21.4, scoring an nnfolder group
> with around 500 articles takes 2 seconds. On emacs 22, it takes about
> 30 seconds. It's obviously something to do with emacs 22, but I
> haven't found a mention of regexp-search being slow. But it might be
> something else, like loading article bodies during the scoring.

I suspect that this is related to the problem I reported a few weeks
ago on this list. Unfortunately, I've not been able to follow this up
on emacs MLs yet. Did anybody else?

Please see the thread "No Gnus v0.4 / emacs-cvs terribly slowly
operating on large nnfolders" at
<http://permalink.gmane.org/gmane.emacs.gnus.general/62304>
for further reference.

Regards,

Elias

Re: bugs: slow scoring in emacs 22

[Max Froumentin]

Elias Oltmanns <oltmanns@uni-bonn.de> writes:

>> 1. scoring in emacs 22
>>
> I suspect that this is related to the problem I reported a few weeks
> ago on this list. Unfortunately, I've not been able to follow this up
> on emacs MLs yet. Did anybody else?

> Please see the thread "No Gnus v0.4 / emacs-cvs terribly slowly
> operating on large nnfolders" at
> <http://permalink.gmane.org/gmane.emacs.gnus.general/62304>
> for further reference.

Ah, thanks. Sorry I missed that thread. It's indeed exactly the same 
problem. So obviously, I'd be interested to hear about any development
from the emacs lists too.

Max.

Re: bugs: slow scoring in emacs 22

[Elias Oltmanns]

Max Froumentin <max@lapin-bleu.net> wrote:
> Elias Oltmanns <oltmanns@uni-bonn.de> writes:
>
>>> 1. scoring in emacs 22
>>>
>> I suspect that this is related to the problem I reported a few weeks
>> ago on this list. Unfortunately, I've not been able to follow this up
>> on emacs MLs yet. Did anybody else?
>
>> Please see the thread "No Gnus v0.4 / emacs-cvs terribly slowly
>> operating on large nnfolders" at
>> <http://permalink.gmane.org/gmane.emacs.gnus.general/62304>
>> for further reference.
>
> Ah, thanks. Sorry I missed that thread. It's indeed exactly the same 
> problem. So obviously, I'd be interested to hear about any development
> from the emacs lists too.

Here is a work around that fixes the problem for me. It is not a
general solution and may break case-folding in some languages, namely
those that use U+51050 and U+51051. In fact, I don't even know which
characters are assigned to these codes but I don't use them anyway,
thats for sure.

Can you confirm that this fixes your problem too?

--- ~/.emacs ---
(unless (< emacs-major-version 22)
  (set-case-syntax 331856 "w" (standard-case-table))
  (set-case-syntax 331857 "w" (standard-case-table)))
--- ~/.emacs ---

This deletes the two named characters from the equivalences list
for the ascii character i in the standard case table of emacs 22.
Without this a slower searching / matching algorithm is used whenever
the search string contains the character i or I because those
mysterious unicode characters are considered equivalent to i.

I don't know whether this is an issue to be dealt with in emacs or in
packages like gnus. Perhaps the only solution is to make users aware
of this problem and to advise them to edit their .emacs if
appropriate. What's your opinion on this topic?

Regards,

Elias

Re: bugs: slow scoring in emacs 22, slow PGP in No Gnus v0.4, serious PGP signing bug

[Lars Magne Ingebrigtsen]

Max Froumentin <max@lapin-bleu.net> writes:

> I recently gave emacs 22 a try and noticed a bug with gnus, which
> completely prevents me from using it: In some groups, articles are
> scored on body contents. With emacs 21.4, scoring an nnfolder group
> with around 500 articles takes 2 seconds. On emacs 22, it takes about
> 30 seconds. It's obviously something to do with emacs 22, but I
> haven't found a mention of regexp-search being slow. But it might be
> something else, like loading article bodies during the scoring.

Try `M-x elp-instrument-package RET gnus RET' (and the same with
"nn"), and then `M-x elp-results' after entering a slow group.  That
should give you an idea what function is taking all that time. 

> I've been sticking to No Gnus CVS fairly closely, and just when No
> Gnus 0.4 was released I noticed that displaying an article with a PGP
> signature took longer than before (~1 sec, vs immediate).

Hm...  do you have an example message?

> I've been signing my emails using inline PGP, and since updating to No
> Gnus 0.4, and further CVS updates, it's happened that some outgoing
> emails had had their bodies removed before sending.  Even the saved
> GCC was empty. Very annoying...

That's very odd.  Has anybody else seen this?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: bugs: slow scoring in emacs 22, slow PGP in No Gnus v0.4, serious PGP signing bug

[Max Froumentin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> I've been sticking to No Gnus CVS fairly closely, and just when No
>> Gnus 0.4 was released I noticed that displaying an article with a PGP
>> signature took longer than before (~1 sec, vs immediate).

> Hm...  do you have an example message?

I'm signing this one for people to test, hoping that it doesn't arrive
empty...

>> I've been signing my emails using inline PGP, and since updating to No
>> Gnus 0.4, and further CVS updates, it's happened that some outgoing
>> emails had had their bodies removed before sending.  Even the saved
>> GCC was empty. Very annoying...

> That's very odd.  Has anybody else seen this?

I'm about to start looking into this more closely (which doesn't seem
easy given the apparent randomness of the bug's occurences), but since
my message I read on this group that there'd been some reshuffling of
the GPG code, so maybe it's not worth me exploring the current code.

Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQEVAwUBREzNWnIYIGQDEmwFAQI0mwgAl9s37cYc9ROPLiMzszSWxULOgKPcZwHC
Yj8Gdcs3hFVdrLOljAV0hPLFo0ivcYQagCW3A/fWmM3dHBh4BAz/EjWMQY+6jL78
U7EaSIDOJoyY/ajeaOuqdEft67mSSLkC+FfRrS/Jq3L4fR0aumYKC8jX8H0/ms8/
44YL0xyuoxwV0ywFoYTPU9lIRxZ5YMxXySH/DL0Si0LSSuHbl3Bd6XpGQOsWGdqP
Vl7/kQVKQhDtbr3IqEUFFvU/Nfj3Kp/dW0quiB03hbAjPzkTup/W9PtpwRR2M0B4
10oaZR2MTU6pTfEgzry9kI0q4pvEFRgJf6BFEtTWn6flcVIWfHNxJg==
=eSgc
-----END PGP SIGNATURE-----

Re: slow PGP in No Gnus v0.4

[Max Froumentin]

Max Froumentin <max@lapin-bleu.net> writes:

>>> I've been signing my emails using inline PGP, and since updating to No
>>> Gnus 0.4, and further CVS updates, it's happened that some outgoing
>>> emails had had their bodies removed before sending.  Even the saved
>>> GCC was empty. Very annoying...

>> That's very odd.  Has anybody else seen this?

> I'm about to start looking into this more closely (which doesn't seem
> easy given the apparent randomness of the bug's occurences), but since
> my message I read on this group that there'd been some reshuffling of
> the GPG code, so maybe it's not worth me exploring the current code.

A little bit of profiling revealed that it's the signature
verification that slows things down (when gnus calls gpg and waits in
pgg-gpg-wait-for-completion, specifically). What's funny is that I
always had (setq mm-verify-option 'always) in my .emacs and I'd never
noticed any slowdown before. But now I can just turn it off.

In fact, unless I've missed something, the current behaviour defeats
the purpose of (setq mm-verify-option 'always), since it doesn't show
the result of the verification. Only if you verify again with
gnus-summary-force-verify-and-decrypt can you see the
[[PGPpart:... ]] button. 

Max.

Re: slow PGP in No Gnus v0.4

[Jochen Küpper]

Max Froumentin <max-j8nGiIS5Ut1oeR6VNtCasQ@public.gmane.org> writes:

> In fact, unless I've missed something, the current behaviour defeats
> the purpose of (setq mm-verify-option 'always), since it doesn't
> show the result of the verification. 

What do you mean. Your last message showed the button for me right
away.
,----
| [[PGP Signed Part:Max Froumentin (W3C) <mf-Pl0VvzL1eo4@public.gmane.org>]]
`----
I do have (setq mm-verify-option 'always).

> Only if you verify again with gnus-summary-force-verify-and-decrypt
> can you see the [[PGPpart:...
> ]] button.

Where would that be called for me?

,----[system]
| GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-04-01
| No Gnus v0.4
`----

Greetings,
Jochen

PS: I do see the 1 s slowdown as well, but haven't worried much yet.
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: slow PGP in No Gnus v0.4

[Max Froumentin]

Jochen Küpper  writes:

> Max Froumentin <max@lapin-bleu.net> writes:

>> In fact, unless I've missed something, the current behaviour defeats
>> the purpose of (setq mm-verify-option 'always), since it doesn't
>> show the result of the verification. 

> What do you mean. Your last message showed the button for me right
> away.

That's bizarre. I've tried on a completely uncustomised emacs/gnus,
apart from (setq mm-verify-option 'always), and I get the same result:
by default, when a PGP-signed article is displayed, gnus verifies the
signature but doesn't show the button. Only if you verify
interactively with gnus-summary-force-security-verify-or-decrypt does
it show it.

The code confirms this: gnus-buttonized-mime-types is nil, and so
gnus-mime-display-security doesn't display the button.
Whereas gnus-summary-force-verify-and-decrypt sets
gnus-buttonized-mime-types to ("multipart/signed"
"multipart/encrypted") before calling gnus-mime-display-security.

Indeed, the documentation for gnus-buttonized-mime-types says "To see
e.g. security buttons you could set this to `(\"multipart/signed\")'."
When I do that it works...

So I'll restate my "defeats the purpose" statement: setting
(setq mm-verify-option 'always)
is useless if you don't set 
(setq gnus-buttonized-mime-types '("multipart/signed"))
as well.

Max.

Re: slow PGP in No Gnus v0.4

[Jochen Küpper]

Max Froumentin <max-j8nGiIS5Ut1oeR6VNtCasQ@public.gmane.org> writes:

> So I'll restate my "defeats the purpose" statement: setting
> (setq mm-verify-option 'always)
> is useless if you don't set 
> (setq gnus-buttonized-mime-types '("multipart/signed"))
> as well.

That does explain it. I do have this in .gnus:

,----[ C-h v gnus-buttonized-mime-types RET ]
| gnus-buttonized-mime-types is a variable defined in `gnus-art.el'.
| Its value is 
| ("multipart/alternative" "multipart/encrypted" "multipart/signed")
[...]
`----

Maybe a sentence should be added to the documentation of mm-verify-option?

Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: slow PGP in No Gnus v0.4

[Max Froumentin]

Jochen Küpper writes:

>> So I'll restate my "defeats the purpose" statement: setting
>> (setq mm-verify-option 'always)
>> is useless if you don't set 
>> (setq gnus-buttonized-mime-types '("multipart/signed"))
>> as well.

> Maybe a sentence should be added to the documentation of
> mm-verify-option?

Wouldn't it make more sense to add multipart/signed to
gnus-buttonized-mime-types when mm-verify-option is set to 'always ?
Who could possibly want signatures to be automatically verified but
wouldn't want to see the results?

Max.

Re: slow PGP in No Gnus v0.4

[Simon Josefsson]

Max Froumentin <max@lapin-bleu.net> writes:

> Jochen Küpper writes:
>
>>> So I'll restate my "defeats the purpose" statement: setting
>>> (setq mm-verify-option 'always)
>>> is useless if you don't set 
>>> (setq gnus-buttonized-mime-types '("multipart/signed"))
>>> as well.
>
>> Maybe a sentence should be added to the documentation of
>> mm-verify-option?
>
> Wouldn't it make more sense to add multipart/signed to
> gnus-buttonized-mime-types when mm-verify-option is set to 'always ?
> Who could possibly want signatures to be automatically verified but
> wouldn't want to see the results?

I agree.  If someone really doesn't want them,
gnus-unbuttonized-mime-types should work.  Patches welcome. ;)

Display of GPG results (was: slow PGP in No Gnus v0.4)

[Reiner Steib]

On Wed, Apr 26 2006, Simon Josefsson wrote:

> Max Froumentin <max@lapin-bleu.net> writes:
>> Jochen Küpper writes:
>>>> So I'll restate my "defeats the purpose" statement: setting
>>>> (setq mm-verify-option 'always)
>>>> is useless if you don't set 
>>>> (setq gnus-buttonized-mime-types '("multipart/signed"))
>>>> as well.
>>
>>> Maybe a sentence should be added to the documentation of
>>> mm-verify-option?
>>
>> Wouldn't it make more sense to add multipart/signed to
>> gnus-buttonized-mime-types when mm-verify-option is set to 'always ?
>> Who could possibly want signatures to be automatically verified but
>> wouldn't want to see the results?

I've installed both suggestions in the trunk.  Feel free to adjust.
Should it go to v5-10 as well?

	* mm-decode.el (mm-verify-option): Add gnus-buttonized-mime-types
	to doc string.

	* gnus-art.el (gnus-buttonized-mime-types): Add "multipart/signed"
	depending on mm-verify-option.

> I agree.  If someone really doesn't want them,
> gnus-unbuttonized-mime-types should work.  

`gnus-unbuttonized-mime-types' is  ignored if
`gnus-buttonized-mime-types' in non-nil:

,----[ <f1> v gnus-buttonized-mime-types RET ]
| gnus-buttonized-mime-types is a variable defined in `gnus-art.el'.
| Its value is 
| ("multipart/alternative" ".*/signed")
| 
| 
| Documentation:
| List of MIME types that should be given buttons when rendered inline.
| If set, this variable overrides `gnus-unbuttonized-mime-types'.
| To see e.g. security buttons you could set this to
| `("multipart/signed")'.  You could also add "multipart/alternative" to
| this list to display radio buttons that allow you to choose one of two
| media types those mails include.  See also `mm-discouraged-alternatives'.
| This variable is only used when `gnus-inhibit-mime-unbuttonizing' is nil.
`----

> Patches welcome. ;)

BTW, we already have lock-broken.xpm lock-ok.xpm and lock.xpm in
etc/images.  For people using the tool bar, these icons could be used
to indicate the verification status.  Maybe on more icon for
"Untrusted" should be added.

It would also be nice to display the verification results in different
colors (or add a colored symbol to the mode line or change the
background color of the subject), for example:

  Undecided: orange
  Failed: red
  Good signature, Untrusted: blue (?)
  Trusted: green

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Display of GPG results

[Max Froumentin]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> I've installed both suggestions in the trunk.  Feel free to adjust.
> Should it go to v5-10 as well?

> 	* mm-decode.el (mm-verify-option): Add gnus-buttonized-mime-types
> 	to doc string.

> 	* gnus-art.el (gnus-buttonized-mime-types): Add "multipart/signed"
> 	depending on mm-verify-option.

I see you've added: 

(defcustom gnus-buttonized-mime-types (unless (eq mm-verify-option 'never)
                                      '("multipart/signed"))

I'm not too familiar with the initialisation of custom variables, but
I don't believe that this works if you already have contents in the
variable in your .emacs (such as "multipart/alternative"). At least it doesn't 
work here.

I've been working on a patch, which I'll submit once I'll have tested
it a bit more.  Basically it adds "multipart/signed" to
gnus-buttonized-mime-types inside gnus-mime-display-security, since
within that function it appears that verification has always been performed.

More soon.

Max.

Re: Display of GPG results

[Max Froumentin]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

Max Froumentin <max@lapin-bleu.net> writes:

> I've been working on a patch, which I'll submit once I'll have tested
> it a bit more.  Basically it adds "multipart/signed" to
> gnus-buttonized-mime-types inside gnus-mime-display-security, since
> within that function it appears that verification has always been performed.

OK, the attached patch seems to work. Basically, it resets the
definition of gnus-buttonized-mime-types to nil, and in
gnus-mime-display-security, it wraps the body within a redefinition of
the variable:

  (let ((gnus-buttonized-mime-types 
         (if (or (eq mm-verify-option 'always) (eq mm-verify-option 'known))
             (append '("multipart/signed") gnus-buttonized-mime-types)
           gnus-buttonized-mime-types)))

Max.


[-- Attachment #2: diff against 7.168 --]
[-- Type: text/plain, Size: 1900 bytes --]

873,874c873
< (defcustom gnus-buttonized-mime-types (unless (eq mm-verify-option 'never)
< 					'("multipart/signed"))
---
> (defcustom gnus-buttonized-mime-types nil
7714,7729c7713,7734
<   (save-restriction
<     (narrow-to-region (point) (point))
<     (unless (gnus-unbuttonized-mime-type-p (car handle))
<       (gnus-insert-mime-security-button handle))
<     (gnus-mime-display-part (cadr handle))
<     (unless (bolp)
<       (insert "\n"))
<     (unless (gnus-unbuttonized-mime-type-p (car handle))
<       (let ((gnus-mime-security-button-line-format
< 	     gnus-mime-security-button-end-line-format))
< 	(gnus-insert-mime-security-button handle)))
<     (mm-set-handle-multipart-parameter
<      handle 'gnus-region
<      (cons (set-marker (make-marker) (point-min))
< 	   (set-marker (make-marker) (point-max))))))
< 
---
>   (let ((gnus-buttonized-mime-types 
>          ;; when this function is called, the signature has been verified,
>          ;; so we might as well display the button.
>          (if (or (eq mm-verify-option 'always) (eq mm-verify-option 'known))
>              (append '("multipart/signed") gnus-buttonized-mime-types)
>            gnus-buttonized-mime-types)))
>     (save-restriction
>       (narrow-to-region (point) (point))
>       (unless (gnus-unbuttonized-mime-type-p (car handle))
>         (gnus-insert-mime-security-button handle))
>       (gnus-mime-display-part (cadr handle))
>       (unless (bolp)
>         (insert "\n"))
>       (unless (gnus-unbuttonized-mime-type-p (car handle))
>         (let ((gnus-mime-security-button-line-format
>                gnus-mime-security-button-end-line-format))
>           (gnus-insert-mime-security-button handle)))
>       (mm-set-handle-multipart-parameter
>        handle 'gnus-region
>        (cons (set-marker (make-marker) (point-min))
>              (set-marker (make-marker) (point-max)))))))
>   

Security buttons without a face (was: Display of GPG results)

[Max Froumentin]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

Me again...

So, now that I can see my PGP signature buttons, I'm bothered because they
don't look like other buttons. Indeed, gnus-article-button-face isn't used to
display them. And that applies to mime buttons, too.

Is it intended?

If not, I suggest a simple fix: insert

    (when gnus-article-button-face
      (gnus-overlay-put (gnus-make-overlay b e)
                        'face gnus-article-button-face))

in both button creation functions (taken from gnus-article-add-button).
Patch attached.


[-- Attachment #2: diff against 7.168 --]
[-- Type: text/plain, Size: 3024 bytes --]

--- gnus-art.el	2006-04-28 15:59:02.000000000 +0100
+++ gnus-art-new.el	2006-04-28 15:58:35.000000000 +0100
@@ -870,8 +870,7 @@
   :group 'gnus-article-mime
   :type '(repeat regexp))
 
-(defcustom gnus-buttonized-mime-types (unless (eq mm-verify-option 'never)
-					'("multipart/signed"))
+(defcustom gnus-buttonized-mime-types nil
   "List of MIME types that should be given buttons when rendered inline.
 If set, this variable overrides `gnus-unbuttonized-mime-types'.
 To see e.g. security buttons you could set this to
@@ -4993,6 +4992,9 @@
 		;; Exclude a newline.
 		(1- (point))
 	      (point)))
+    (when gnus-article-button-face
+      (gnus-overlay-put (gnus-make-overlay b e)
+                        'face gnus-article-button-face))
     (widget-convert-button
      'link b e
      :mime-handle handle
@@ -7694,6 +7696,9 @@
 		;; Exclude a newline.
 		(1- (point))
 	      (point)))
+    (when gnus-article-button-face
+      (gnus-overlay-put (gnus-make-overlay b e)
+                        'face gnus-article-button-face))
     (widget-convert-button
      'link b e
      :mime-handle handle
@@ -7711,22 +7716,28 @@
 	(aref gnus-down-mouse-3 0))))))
 
 (defun gnus-mime-display-security (handle)
-  (save-restriction
-    (narrow-to-region (point) (point))
-    (unless (gnus-unbuttonized-mime-type-p (car handle))
-      (gnus-insert-mime-security-button handle))
-    (gnus-mime-display-part (cadr handle))
-    (unless (bolp)
-      (insert "\n"))
-    (unless (gnus-unbuttonized-mime-type-p (car handle))
-      (let ((gnus-mime-security-button-line-format
-	     gnus-mime-security-button-end-line-format))
-	(gnus-insert-mime-security-button handle)))
-    (mm-set-handle-multipart-parameter
-     handle 'gnus-region
-     (cons (set-marker (make-marker) (point-min))
-	   (set-marker (make-marker) (point-max))))))
-
+  (let ((gnus-buttonized-mime-types 
+         ;; when this function is called, the signature has been verified,
+         ;; so we might as well display the button.
+         (if (or (eq mm-verify-option 'always) (eq mm-verify-option 'known))
+             (append '("multipart/signed") gnus-buttonized-mime-types)
+           gnus-buttonized-mime-types)))
+    (save-restriction
+      (narrow-to-region (point) (point))
+      (unless (gnus-unbuttonized-mime-type-p (car handle))
+        (gnus-insert-mime-security-button handle))
+      (gnus-mime-display-part (cadr handle))
+      (unless (bolp)
+        (insert "\n"))
+      (unless (gnus-unbuttonized-mime-type-p (car handle))
+        (let ((gnus-mime-security-button-line-format
+               gnus-mime-security-button-end-line-format))
+          (gnus-insert-mime-security-button handle)))
+      (mm-set-handle-multipart-parameter
+       handle 'gnus-region
+       (cons (set-marker (make-marker) (point-min))
+             (set-marker (make-marker) (point-max)))))))
+  
 (defun gnus-mime-security-run-function (function)
   "Run FUNCTION with the security part under point."
   (gnus-article-check-buffer)

[-- Attachment #3: Type: text/plain, Size: 6 bytes --]


Max.

Re: Display of GPG results

[Reiner Steib]

On Thu, Apr 27 2006, Max Froumentin wrote:

> OK, the attached patch seems to work. Basically, it resets the
> definition of gnus-buttonized-mime-types to nil, and in
> gnus-mime-display-security, it wraps the body within a redefinition of
> the variable:

Max, there are already a few "tiny changes" from you in Gnus.  In
total your contribution probably (I'm too lazy to count the lines) is
larger than 10-15 lines (i.e. it's not a "tiny change") so we need
legal papers to install it.  Gnus is a part of Emacs and since Emacs
is a core GNU project, the Free Software Foundation (FSF) requires an
assignment of copyright for contributions, so that it is able to
defend Emacs' legal status without doubts, should the need arise.

You don't seem to have an assignment on file yet.  If you agree, I can
send you the required request form.  After the assignment process
completes (you get sent forms which you have to read and sign and send
back), we could install your patch in Gnus.

You can either sign papers only for Gnus or for Emacs (which covers
Gnus, too).  I'd recommend you to sign papers for Emacs.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Display of GPG results

[Max Froumentin]

Hi Reiner,

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> Max, there are already a few "tiny changes" from you in Gnus.  In
> total your contribution probably (I'm too lazy to count the lines) is
> larger than 10-15 lines (i.e. it's not a "tiny change") so we need
> legal papers to install it.  Gnus is a part of Emacs and since Emacs
> is a core GNU project, the Free Software Foundation (FSF) requires an
> assignment of copyright for contributions, so that it is able to
> defend Emacs' legal status without doubts, should the need arise.

> You don't seem to have an assignment on file yet.  If you agree, I can
> send you the required request form.  After the assignment process
> completes (you get sent forms which you have to read and sign and send
> back), we could install your patch in Gnus.

> You can either sign papers only for Gnus or for Emacs (which covers
> Gnus, too).  I'd recommend you to sign papers for Emacs.

No problem, I'll sign the papers for Emacs.

Max.

Re: Display of GPG results

[Lars Magne Ingebrigtsen]

Max Froumentin <max@lapin-bleu.net> writes:

>>   (let ((gnus-buttonized-mime-types 
>>          ;; when this function is called, the signature has been verified,
>>          ;; so we might as well display the button.
>>          (if (or (eq mm-verify-option 'always) (eq mm-verify-option 'known))
>>              (append '("multipart/signed") gnus-buttonized-mime-types)
>>            gnus-buttonized-mime-types)))

I don't think this is the right solution.  The user may well want to
verify a signature, but display the results in some other way than
displaying a button.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Display of GPG results

[Max Froumentin]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>>>   (let ((gnus-buttonized-mime-types 
>>>          ;; when this function is called, the signature has been verified,
>>>          ;; so we might as well display the button.
>>>          (if (or (eq mm-verify-option 'always) (eq mm-verify-option 'known))
>>>              (append '("multipart/signed") gnus-buttonized-mime-types)
>>>            gnus-buttonized-mime-types)))

> I don't think this is the right solution.  The user may well want to
> verify a signature, but display the results in some other way than
> displaying a button.

Does the code offer some other way? Or perhaps you're thinking of
a hook in the code?

Max.

Re: Display of GPG results

[Max Froumentin]

Max Froumentin <max@lapin-bleu.net> writes:

> Does the code offer some other way? Or perhaps you're thinking of
> a hook in the code?

Please ignore that. I'd missed the other thread. That'll teach me to 
change the Subject...

Max.

Re: slow PGP in No Gnus v0.4

[Lars Magne Ingebrigtsen]

Max Froumentin <max@lapin-bleu.net> writes:

> Wouldn't it make more sense to add multipart/signed to
> gnus-buttonized-mime-types when mm-verify-option is set to 'always ?
> Who could possibly want signatures to be automatically verified but
> wouldn't want to see the results?

The verification should be displayed in the article buffer mode line,
I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: slow PGP in No Gnus v0.4

[Jochen Küpper]

Lars Magne Ingebrigtsen <larsi-smP1P7uqpqc@public.gmane.org> writes:

> Max Froumentin <max-j8nGiIS5Ut1oeR6VNtCasQ@public.gmane.org> writes:
>
>> Wouldn't it make more sense to add multipart/signed to
>> gnus-buttonized-mime-types when mm-verify-option is set to 'always ?
>> Who could possibly want signatures to be automatically verified but
>> wouldn't want to see the results?
>
> The verification should be displayed in the article buffer mode line,
> I think.

I don't see any space for that in *Article* modelines at all. 

The background color of the whole modeline could change accordingly,
but that might be to colorful;)

Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: slow PGP in No Gnus v0.4

[Lars Magne Ingebrigtsen]

Jochen Küpper
<jochen@fhi-berlin.mpg.de> writes:

> I don't see any space for that in *Article* modelines at all. 

There's a status thing down there that says something about what's
been done.  For instance, it says "[ h   ]" for me now, which means
that headers have been hidden.

> The background color of the whole modeline could change accordingly,
> but that might be to colorful;)

It's a possibility.  Kinda analogous to what Firefox does with https.

But I think it might be overkill.  If the signature verifies, then
that's all good, but I don't really see the need for any big splashy
way of saying so.  It's what's supposed to happen, and the user
doesn't need to know about it.

On the other hand, if the verification fails, then Gnus should make
the user plainly aware of this fact.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: slow PGP in No Gnus v0.4

[Elias Oltmanns]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Jochen Küpper
> <jochen@fhi-berlin.mpg.de> writes:
[...]
>> The background color of the whole modeline could change accordingly,
>> but that might be to colorful;)
>
> It's a possibility.  Kinda analogous to what Firefox does with https.
>
> But I think it might be overkill.  If the signature verifies, then
> that's all good, but I don't really see the need for any big splashy
> way of saying so.  It's what's supposed to happen, and the user
> doesn't need to know about it.

I disagree on that one, I'm afraid. There are three states of a
message which the user should be able to tell apart easily:
1. Message has been signed and verification failed (obvious);
2. message has been signed and verification succeeded (as opposed to)
3. message hasn't been signed in the first place.

Regards,

Elias

Re: slow PGP in No Gnus v0.4

[Lars Magne Ingebrigtsen]

Elias Oltmanns <oltmanns@uni-bonn.de> writes:

> I disagree on that one, I'm afraid. There are three states of a
> message which the user should be able to tell apart easily:
> 1. Message has been signed and verification failed (obvious);
> 2. message has been signed and verification succeeded (as opposed to)
> 3. message hasn't been signed in the first place.

In my opinion, the difference between 2 and 3 is only interesting if
you're trying to determine the validity of the mail message
seriously.  When you're reading mail normally, it's about as
interesting as whether the message is encoded in quoted-printable or
base64.  That is, not very.

Of course, you're free to disagree.  :-)  Which is why we have
`gnus-buttonized-mime-types'.  Which I still think should always
default to nil.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: slow PGP in No Gnus v0.4

[Juliusz Chroboczek]

>> 1. Message has been signed and verification failed (obvious);
>> 2. message has been signed and verification succeeded (as opposed to)
>> 3. message hasn't been signed in the first place.

I actually see six states.

  1a. verification has failed because the public key is not available;
  1b. verification has failed for some other reason.
  2a. verification successful, key valid (``trusted'').
  2b. verification successful, key validity unknown (``untrusted'').
  3. message insecure (not signed).
  4. message is signed but hasn't been verified because mm-verify-option
     is not set.
 
Unlike 1b, which is obviously bad, 1a happens all the time.  And Gnus
(even with gnus-buttonized-mime-types set to multipart/signed) doesn't
allow me to easily distinguish between the two -- the button just says
``Failed''.  Which I hereby report as a bug.

> In my opinion, the difference between 2 and 3 is [not interesting]

A visible flag in the modeline would be an improvement over the
current situation.  You could replace the current ``p'' with a choice
of well-chosen characters.  Perhaps someone can make a better design
than

  1a. ?
  1b. -
  2a. +
  2b. ?
  3. space
  4. p

And if these could be coloured, that would be cool.

> Of course, you're free to disagree.

Thank you.  What the button is important for is knowing which part of
the message is protected, and reminding people that headers are not
protected.

In particular, there's absolutely nothing preventing me from signing a
message with my key and putting ``From: larsi@'' in the headers.
There's absolutely nothing to indicate that case in the non-buttonised
interface.  Which I hereby report as a bug.

Gnus should notice that case and put something like 

  Juliusz Chroboczek <jch@> (posing as <larsi@>)

in both the From header line and the summary line.  (Yes, that requires
rewriting the summary after verification.)

(There's also nothing preventing me from taking a plain text messaged
signed by larsi@, putting it into a text/fake subpart of a
multipart/mixed, and following it with an unsigned text/plain.)

                                        Juliusz

Re: slow PGP in No Gnus v0.4

[gdt]

I concur with all the points in your message.  I've been out of PGP
practice lately, and one of my reasons for choosing gnus to read mail
was PGP/MIME support.

    Juliusz Chroboczek <jch@> (posing as <larsi@>)

I'm not sure that's the right UI, but if a signed message has a From:
that isn't in the keyid, then that should be obvious.  Perhaps a
X-PGP-From: right after it with the primary uid from the key, or
perhaps Juliusz's suggestion.

It may be helpful to have a mail-encrypted-paranoia meta-variable that
flips all the PGP processing into behavior appropriate for tha
paranoid mindset, from behavior appropriate for those who find PGP
signatures an annoying waste of space.  (Both can be valid views, but
they lead to very different desires.)


-- 
	Greg Troxel <gdt@work.lexort.com>

Re: slow PGP in No Gnus v0.4

[Juliusz Chroboczek]

> Perhaps a X-PGP-From: right after it with the primary uid from the
> key, or perhaps Juliusz's suggestion.

Both, actually: X-PGP-Signer: in the message buffer, and something
like what I suggested in the Summary buffer.

> It may be helpful to have a mail-encrypted-paranoia meta-variable that
> flips all the PGP processing into behavior appropriate for tha
> paranoid mindset, from behavior appropriate for those who find PGP
> signatures an annoying waste of space.

Ideally, we can work out a behaviour that suits both classes of users.

(OT: PGP signatures are an annoying waste of space.  Getting your key
into the keyservers and connected to the WOT can turn out to be really
handy at some later time.)

                                        Juliusz

Re: slow PGP in No Gnus v0.4

[Lars Magne Ingebrigtsen]

Juliusz Chroboczek <jch@pps.jussieu.fr> writes:

> Unlike 1b, which is obviously bad, 1a happens all the time.  And Gnus
> (even with gnus-buttonized-mime-types set to multipart/signed) doesn't
> allow me to easily distinguish between the two -- the button just says
> ``Failed''.  Which I hereby report as a bug.

Yes, that seems bad.

You wouldn't want to fix this yourself?  :-)  I doubt I even have gpg
installed here, which makes debugging slighly more tricky. 

> A visible flag in the modeline would be an improvement over the
> current situation.  You could replace the current ``p'' with a choice
> of well-chosen characters.  Perhaps someone can make a better design
> than
>
>   1a. ?
>   1b. -
>   2a. +
>   2b. ?
>   3. space
>   4. p
>
> And if these could be coloured, that would be cool.

Looks OK to me.

> In particular, there's absolutely nothing preventing me from signing a
> message with my key and putting ``From: larsi@'' in the headers.
> There's absolutely nothing to indicate that case in the non-buttonised
> interface.  Which I hereby report as a bug.

That does seem rather bad.

But that reminds me -- has anybody done any work on dkim?  Or did that
go the way of the dodo, too?  The last time I checked into the
"verified mail" thingies, (some) people were all het up about dkim.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: slow PGP in No Gnus v0.4

[Juliusz Chroboczek]

> You wouldn't want to fix this yourself?  :-)

Well, life is short, and the number of Free Software projects to work
on is infinite.  But I'm currently doing some rather interesting Gnus
hacking, and I'll have to learn about decorating Gnus buffers anyway
-- so I might end up doing that.

(In case anyone is interested: together with Z. Landau, we're
integrating the Darcs version control system with Gnus.  And in case
anyone is still listening -- any pointers to examples of code that
decorates summary buffers?)

> But that reminds me -- has anybody done any work on dkim?

DomainKeys (the nonstandard ancestor of DKIM) is being deployed by
Gmail and Pobox, which is a significant number of users.  DKIM is
being worked on, but last time I checked the spec had some rather
serious bugs due to the conflicting goals of securing mail and
permitting mailing list exploders to add random crap in messages.

> Or did that go the way of the dodo, too?

The technically correct term is ``the way of USEFOR''.

                                        Juliusz

Re: slow PGP in No Gnus v0.4

[Lars Magne Ingebrigtsen]

Juliusz Chroboczek <jch@pps.jussieu.fr> writes:

> (In case anyone is interested: together with Z. Landau, we're
> integrating the Darcs version control system with Gnus.  And in case
> anyone is still listening -- any pointers to examples of code that
> decorates summary buffers?)

The Gnus buffers are mainly made colourful by using the various
`gnus-*-mode-line' variables.

>> But that reminds me -- has anybody done any work on dkim?
>
> DomainKeys (the nonstandard ancestor of DKIM) is being deployed by
> Gmail and Pobox, which is a significant number of users.  DKIM is
> being worked on, but last time I checked the spec had some rather
> serious bugs due to the conflicting goals of securing mail and
> permitting mailing list exploders to add random crap in messages.

Right.  *sigh*

>> Or did that go the way of the dodo, too?
>
> The technically correct term is ``the way of USEFOR''.

Heh heh heh.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Display of GPG results (was: slow PGP in No Gnus v0.4)

[Reiner Steib]

On Sun, Apr 30 2006, Lars Magne Ingebrigtsen wrote:

[ `gnus-buttonized-mime-types' ]
> Which I still think should always default to nil.

I've reverted the change in `gnus-buttonized-mime-types'.  But I kept
the suggestion in the doc string of `mm-verify-option'.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/