Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> I wrote rfc2015.el, which is supposed to fill the gap between Gnus 5.8
> and mailcrypt.  Because it is not finished, I just put it in contrib
> directory.

A few months ago, Lars suggested to keep MIME-PGP support separate
because of crypto export regulation issues.

> To sign something, say
> 
> <#part type="text/plain" disposition=inline postprocess=pgp-sign>
> The text to sign.
> <#/part>

My package uses a somewhat different approach:

<#multipart type=signed>
This is a signed multipart.
<#part type="text/plain" filename="~/some-file" disposition=attachment description="signed attachment">
<#/multipart>

This is achieved by hooking into "mml-generate-multipart-alist".
To be honest, I think "mml-generate-mime-preprocess-function" and
"mml-generate-mime-postprocess-function" are unnecessary.  At least
you can't use them to generate RFC 2015 messages.  There are special
requirements regarding quoted-printable encoding of parts inside
"multipart/signed" or "multipart/encrypted", and I don't think you can
set the appropriate variable ("mm-use-ultra-safe-encoding") during
MML-to-MIME translation using your hooks.

My code is available at:

        http://cert.uni-stuttgart.de/people/fw/gpg-mime.el

At the moment, it's very alpha, and it's likely that it doesn't
work. :-/ Of course, it only does the easy part, i.e. creating
"multipart/signed" and "multipart/encrypted", not the other way round.

It requires some packages found in the same directory.  At the moment,
it is GnuPG-specific, but you should be able to use other (Open)PGP
implementations if you customize the settings in gpg.el.  Mailcrypt
wasn't used because of some security problems and the unwillingness
of the maintainer to respond to suggestions regarding detached
signatures.

Now to the hard part, signature verification and decryption.  For
verification, I think we need a hook into "mm-dissect-multipart",
which verifies the signature (at this place, all the necessary
information is still present) and generates a suitable MML handle.
After that, the part can be displayed using a user-defined display
function (by specifying it in "gnus-mime-multipart-functions").

Decryption should only occur if explicitly requested by the user.  No
hook into "mm-dissect-multipart" is required for it; we can decrypt
and call "mm-dissect-buffer" on the plaintext on user request.

(Maybe we should continue this discussion on the gnus-rfc2015 list?
I've subscribed you.)