Verifying inline gpg signatures

Verifying inline gpg signatures

[Graham Murray]

Is there any way of automatically verifying gpg/pgp inline
signatures? Pgp/MIME signatures are automatically verified and their
status displayed in the button. The only way I have found of
verifying inline signatures is to select the region between "BEGIN
PGP SIGNED MESSAGE" and the end of the signature, then M-x
pgg-verify-region. Is there a more automated or simpler way? 

Re: Verifying inline gpg signatures

[Jesper Harder]

Graham Murray <graham@gmurray.org.uk> writes:

> Is there any way of automatically verifying gpg/pgp inline
> signatures?

These settings work for me:

(setq mm-verify-option 'always)
(setq gnus-buttonized-mime-types '("multipart/signed"))

Re: Verifying inline gpg signatures

[Graham Murray]

Jesper Harder <harder@myrealbox.com> writes:

> Graham Murray <graham@gmurray.org.uk> writes:
>
>> Is there any way of automatically verifying gpg/pgp inline
>> signatures?
>
> These settings work for me:
>
> (setq mm-verify-option 'always)
> (setq gnus-buttonized-mime-types '("multipart/signed"))

I already have these set and everything works fine for
'multipart/signed' messages/articles. The problem is with single-part
text/plain (ie non-MIME) messages of the form

--BEGIN PGP SIGNED MESSAGE----

message body

----BEGIN PGP SIGNATURE-----
signature
----END PGP SIGNATURE----

Re: Verifying inline gpg signatures

[Jesper Harder]

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

Graham Murray <graham@gmurray.org.uk> writes:

> Jesper Harder <harder@myrealbox.com> writes:
>
>> These settings work for me:
>>
>> (setq mm-verify-option 'always)
>> (setq gnus-buttonized-mime-types '("multipart/signed"))
>
> I already have these set and everything works fine for
> 'multipart/signed' messages/articles. The problem is with single-part
> text/plain (ie non-MIME) messages of the form
>
> --BEGIN PGP SIGNED MESSAGE----
>
> message body
>
> ----BEGIN PGP SIGNATURE-----
> signature
> ----END PGP SIGNATURE----

That also works for me with the above settings.  Doesn't this message
get verified automatically for you?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+b6aXzEN/MEcathkRAkoAAKCTI458kz9WNEzQLzyFVeiMwx52dgCfYm2R
PLo8hSQcQ0J7lqwhcS1jPhE=
=4Q4Z
-----END PGP SIGNATURE-----

Re: Verifying inline gpg signatures

[Graham Murray]

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

Jesper Harder <harder@ifa.au.dk> writes:

> That also works for me with the above settings.  Doesn't this message
> get verified automatically for you?

Yes. Looking again at the messages which do not automatically verify,
they are sent from Mozilla and have Content-Type: flowed. So that
could be what is causing the problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+b7cZEhN/ETQwnEERAoJCAJ92WG1MzZuG5TTS1eTPQ8V3UXqvFQCfVUTM
B4CXOVzKqCP4dJyJ7PiM7IE=
=Bi/a
-----END PGP SIGNATURE-----

Re: Verifying inline gpg signatures

[Jesper Harder]

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

Graham Murray <graham@gmurray.org.uk> writes:

> Yes. Looking again at the messages which do not automatically 
> verify, they are sent from Mozilla and have Content-Type: 
> flowed. So that could be what is causing the problem.

Yes, format=flowed is the problem -- I can reproduce that with f=f 
messages produced by Gnus, too.  Like this one.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+b8CuzEN/MEcathkRAueGAKCwZvA1JwrovUknujmYeOYUgG/k0wCgreMp
no/GtRrmEw6lLNHvxGMb10c=
=dkWm
-----END PGP SIGNATURE-----

Re: Verifying inline gpg signatures

[Simon Josefsson]

Jesper Harder <harder@ifa.au.dk> writes:

> Graham Murray <graham@gmurray.org.uk> writes:
>
>> Yes. Looking again at the messages which do not automatically
>> verify, they are sent from Mozilla and have Content-Type: flowed. So
>> that could be what is causing the problem.
>
> Yes, format=flowed is the problem -- I can reproduce that with f=f
> messages produced by Gnus, too.  Like this one.

The reason is that `gnus-display-mime' says

...
      (let* ((handles (or ihandles
			  (mm-dissect-buffer nil gnus-article-loose-mime)
			  (and gnus-article-emulate-mime
			       (mm-uu-dissect))))
...

which means that pre-MIME parsing (mm-uu-dissect) is only done when
MIME isn't found.  Apparently, a MIME message with only a text/plain
part makes mm-dissect-buffer return nil, so it is treated as a
pre-MIME message.  So messages with CT parameters, such as
format=flowed, or generally any non-trivial MIME message, is treated
as a text part and mm-uu-dissect is never run.

Perhaps mm-uu-dissect should be run on all text/plain parts?  Or all
text/.* parts?  Opinions?

Re: Verifying inline gpg signatures

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

> Jesper Harder <harder@ifa.au.dk> writes:
>
>> Yes, format=flowed is the problem -- I can reproduce that with f=f
>> messages produced by Gnus, too.  Like this one.
>
> The reason is that `gnus-display-mime' says
>
> ...
>       (let* ((handles (or ihandles
> 			  (mm-dissect-buffer nil gnus-article-loose-mime)
> 			  (and gnus-article-emulate-mime
> 			       (mm-uu-dissect))))
> ...
>
> which means that pre-MIME parsing (mm-uu-dissect) is only done when
> MIME isn't found.  Apparently, a MIME message with only a text/plain
> part makes mm-dissect-buffer return nil, so it is treated as a
> pre-MIME message.  So messages with CT parameters, such as
> format=flowed, or generally any non-trivial MIME message, is treated
> as a text part and mm-uu-dissect is never run.
>
> Perhaps mm-uu-dissect should be run on all text/plain parts?  Or all
> text/.* parts?  Opinions?

It's a step in the right direction ... but not enough.  The problem is
that text/plain parts with a format parameter haven't been QP decoded
at this stage, so uu-dissect will fail.

It happens because of this code in `article-decode-charset':

     (when (and (or (not ctl)
		     (equal (car ctl) "text/plain"))
		 (not format)) ;; article with format will decode later.
	(mm-decode-body
	 charset (and cte (intern (downcase
				   (gnus-strip-whitespace cte))))
	 (car ctl) prompt))

I didn't investigate what happens if the exception for text/plain parts
with a format parameter is removed -- but it was obviously put there
deliberately.

Re: Verifying inline gpg signatures

[ShengHuo ZHU]

Simon Josefsson <jas@extundo.com> writes:

[...]

> Perhaps mm-uu-dissect should be run on all text/plain parts?  Or all
> text/.* parts?  Opinions?

I think it might be easier to handle these in mm-inline-text.

ShengHuo

Re: Verifying inline gpg signatures

[Jesper Harder]

Jesper Harder <harder@myrealbox.com> writes:

[We fail to detect inline PGP with format=flowed]

> Simon Josefsson <jas@extundo.com> writes:
>
>> Perhaps mm-uu-dissect should be run on all text/plain parts?  Or all
>> text/.* parts?  Opinions?
>
> It's a step in the right direction ... but not enough.  The problem is
> that text/plain parts with a format parameter haven't been QP decoded
> at this stage, so uu-dissect will fail.

But I suppose making it work for non-QP encoded articles is better than
nothing?

I first assumed that it wouldn't be useful because Gnus always QP
encodes inline PGP, so it didn't work when I tested it with a message
from Gnus.  But the Mozilla plugin which probably generates all of the
problematic messages doesn't do it for us-ascii, so it works in that
case.

Should we do it?

Re: Verifying inline gpg signatures

[Simon Josefsson]

Jesper Harder <harder@myrealbox.com> writes:

> Jesper Harder <harder@myrealbox.com> writes:
>
> [We fail to detect inline PGP with format=flowed]
>
>> Simon Josefsson <jas@extundo.com> writes:
>>
>>> Perhaps mm-uu-dissect should be run on all text/plain parts?  Or all
>>> text/.* parts?  Opinions?
>>
>> It's a step in the right direction ... but not enough.  The problem is
>> that text/plain parts with a format parameter haven't been QP decoded
>> at this stage, so uu-dissect will fail.
>
> But I suppose making it work for non-QP encoded articles is better than
> nothing?

Unless it breaks something...

> I first assumed that it wouldn't be useful because Gnus always QP
> encodes inline PGP, so it didn't work when I tested it with a message
> from Gnus.  But the Mozilla plugin which probably generates all of the
> problematic messages doesn't do it for us-ascii, so it works in that
> case.
>
> Should we do it?

IMHO the ideal seems to be to run the mm-uu stuff both before and
after MIME processing.  Perhaps even iteratively until no more actions
can be performed.  Of course, it would have to be careful to not
infloop or some other silly thing.  This way we could detect all UU
things (shar archives, gnats, diff, binhex, yenc pgp, etc) no matter
how deep.  Consider a postscript file binhex encoded and PGP encrypted
and then PGP signed.