I'm alive!

I'm alive!

[Lars Magne Ingebrigtsen]

... 928 unread articles in gnu.emacs.gnus and 505 in nnml:ding.  Er.
Perhaps I'm dead.

*rolls up virtual sleeves*

To work!

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen

Re: I'm alive!

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> ... 928 unread articles in gnu.emacs.gnus and 505 in nnml:ding.  Er.
> Perhaps I'm dead.
> *rolls up virtual sleeves*
> To work!

...with the strains of Lehrer's _Masochism Tango_ in the background...

Re: I'm alive!

[Wes Hardaker]

>>>>> On 11 Jun 1999 21:43:11 +0200, Lars Magne Ingebrigtsen <larsi@ifi.uio.no> said:

Lars> ... 928 unread articles in gnu.emacs.gnus and 505 in nnml:ding.
Lars> Er.  Perhaps I'm dead.

Lars> *rolls up virtual sleeves*

Lars> To work!

Thats the Lars we know and love!  Dive right in!

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

Re: I'm alive!

[Harry Putnam]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> *rolls up virtual sleeves*
> 
> To work!

Alright!  Thats the hyper active, super energetic fellow, we've all
seen in action.

Go Lars Go!

Re: I'm alive!

[Lars Magne Ingebrigtsen]

Florian Weimer <fw@cygnus.stuttgart.netsurf.de> writes:

> While you were away, I've stated publicly that I consider implementing
> RFC 2015 support (MIME-PGP) for Gnus.  It seems that quite a few people
> are interested in that feature.

They are.

> As far as I understand the current MIME implementation, there is neither
> a hook which makes it possible to generate MIME content based on the
> encoded representation of another part (required for encoding), nor a
> hook with which you can feed the raw message text contained in a part
> through an external program (or an elisp function, for that matter)
> and recursively process the output of this filter. I think a facility
> analogous to `mailcap-mime-data' could be used.

There is a `gnus-mime-multipart-functions' variable, and it can do
whatever it wants with the multiparts it receives.  (I added this to
make it possible to do RFC 2015.)  I haven't really looked all that
closely at what a function that were to do RFC 2015 decoding would
have to do, though.  

> In addition, a small change to `quoted-printable-encode-region' is
> necessary: Optionally, "\nFrom " has to be encoded as "\nFrom=20" (as
> required by MIME-PGP, because MTAs tend to replace a "\nFrom " with a
> "\n>From ", thus invalidating the signature).  In addition, when encoding
> a part inside a `multipart/signed', `quoted-printable-encode-region'
> has to be called not only for parts containing 8-bit characters, but
> also when a "\nFrom " is encountered.

I don't think this belongs in `quoted-printable-encode-region'.  I
certainly wouldn't want to see (say) a news article get bumped up from 
7bit to qouted-printable just because there's a "\nFrom " in the
message somewhere.  I think the RFC 2015 function itself should do
this encoding -- by calling `quoted-printable-encode-region', and then 
encoding the "\nFrom "'s itself.

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

MIME-PGP (was: Re: I'm alive!)

[Florian Weimer]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> There is a `gnus-mime-multipart-functions' variable, and it can do
> whatever it wants with the multiparts it receives.  (I added this to
> make it possible to do RFC 2015.)  I haven't really looked all that
> closely at what a function that were to do RFC 2015 decoding would
> have to do, though.  

I don't think that this hook can be used.  Let's have a look at the
following message which conforms to RFC 2015:

----------------------------------------------------------------------
Date: Sun, 13 Jun 1999 13:32:15 +0200
From: mutt@cygnus.stuttgart.netsurf.de
To: Florian Weimer <fw@deneb.cygnus.stuttgart.netsurf.de>
Subject: Signed with attachment
X-Gnus-Mail-Source: directory:~/Mail/INCOMING/
Message-ID: <19990613133215.B2917@deneb.cygnus.stuttgart.netsurf.de>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary=YD3LsXFS42OYHhNZ; micalg=pgp-md5;
	protocol="application/pgp-signature"
X-Mailer: Mutt 0.95.1i
Lines: 50
Xref: deneb.cygnus.stuttgart.netsurf.de misc:178


--YD3LsXFS42OYHhNZ
Content-Type: multipart/mixed; boundary=ADZbWkCsHQ7r3kzd


--ADZbWkCsHQ7r3kzd
Content-Type: text/plain; charset=us-ascii
Content-Description: Message

A signed message with an attachment.


--ADZbWkCsHQ7r3kzd
Content-Type: text/plain; charset=us-ascii
Content-Description: Assembler code
Content-Disposition: attachment; filename="t.s"

	.file	"t.c"
	.version	"01.01"
gcc2_compiled.:
.text
	.align 4
.globl foo
	.type	 foo,@function
foo:
	pushl %ebp
	movl %esp,%ebp
	movl 4660,%eax
	movl %ebp,%esp
	popl %ebp
	ret
.Lfe1:
	.size	 foo,.Lfe1-foo
	.ident	"GCC: (GNU) egcs-2.91.57 19980901 (egcs-1.1 release)"

--ADZbWkCsHQ7r3kzd--

--YD3LsXFS42OYHhNZ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i

iQBFAwUBN2OWvzyNAitYx2a1AQHgRgGA5fYIevSaZao25ZMudtaN+PDAbLIze3rn
aChV9rUthqm8lOp2nsD313AiGxpJwhr/
=eKxI
-----END PGP SIGNATURE-----

--YD3LsXFS42OYHhNZ--
----------------------------------------------------------------------

The `micalg' and `protocol' parameters in the primary `Content-Type'
header are vital, but it seems as if they aren't passed to functions
listed in `gnus-mime-multipart-functions'.  In addition, everything
between the first and second `--YD3LsXFS42OYHhNZ' boundary is covered
by the PGP signature, including the MIME headers and boundaries, which
get lost during the translation from raw message text to MIME handles.

Finally, in the `multipart/encrypted' case, as shown below, the encrypted
part contains data which has to be put through the MIME translation
process as well.  This has not happend during the first translation,
because obviously, the data contained in the part wasn't readable then.

----------------------------------------------------------------------
Date: Sun, 13 Jun 1999 12:17:23 +0200
From: mutt@cygnus.stuttgart.netsurf.de
To: Florian Weimer <fw@deneb.cygnus.stuttgart.netsurf.de>
Subject: test
X-Gnus-Mail-Source: directory:~/Mail/INCOMING/
Message-ID: <19990613121723.A2917@deneb.cygnus.stuttgart.netsurf.de>
Mime-Version: 1.0
Content-Type: multipart/encrypted; boundary=Kj7319i9nmIyA2yE;
	protocol="application/pgp-encrypted"
X-Mailer: Mutt 0.95.1i
Lines: 24
Xref: deneb.cygnus.stuttgart.netsurf.de misc:177


--Kj7319i9nmIyA2yE
Content-Type: application/pgp-encrypted

Version: 1

--Kj7319i9nmIyA2yE
Content-Type: application/octet-stream

-----BEGIN PGP MESSAGE-----
Version: 2.6.3i

hIwDbSMVHQQS92EBBACFUjqnO8eDDinYfo183PYgd7GQInt3BHhZCnRP807uGwra
F2zAc4PBgGhBKYnU/nZiOZvqYVh+CA7JqjTzku0sM12RLg2R6bg2nB+V+CzOkK8R
5TQczKGI/Tyhs/ktej0pbMxR5rt5FwvDuB8hcCNKPPTfaeu/4RQsfnlaxsJXm4Q8
AzyNAitYx2a1AQGAug9oiCsl6+omafWxqlJBohEjXJCKjAASE9pfBHNqk6vhUMx3
qbLv6ai7AXOa9voApgAAAFwh2dnqGHsvY9WxPhIGgwkE9/CdjCX8p+jIG50F05Qe
HUyZLv61ibRCm8EYEO2SBUO0brS2u7wtJuOhtGO03SLiDuPuZh2gaqIkpB7xwDxv
T3BUKwC4W9ZIVybX7A==
=oXnI
-----END PGP MESSAGE-----

--Kj7319i9nmIyA2yE--
----------------------------------------------------------------------

The encrypted data looks like this (but it might contain attachments
and other MIME mess as well):

----------------------------------------------------------------------
Content-Type: text/plain; charset=us-ascii

Just another test
----------------------------------------------------------------------


IMHO, an appropiate hook into `mm-dissect-buffer' would allow
to do all these things in a relatively straightforward manner.
`gnus-mime-multipart-functions' could be used to put information gathered
during the MIME translation process (signer, valid/invalid signature,
beginning/end of signed data) into the *Article* buffer in a nicely
formatted form.

For the other way round, i.e. creating MIME-PGP messages, a hook into
`mml-generate-mime' which allows post-processing the generated message
text (encryption, added signature) should be sufficient.

A hook into into `mml-generate-mime-1' surely would be more general
because it would allow to sign and/or encrypt only some parts of a
message in a MIME-PGP compliant way.  But I don't think this is really
necessary.

> I don't think this belongs in `quoted-printable-encode-region'.  I
> certainly wouldn't want to see (say) a news article get bumped up from 
> 7bit to qouted-printable just because there's a "\nFrom " in the
> message somewhere.  I think the RFC 2015 function itself should do
> this encoding -- by calling `quoted-printable-encode-region', and then 
> encoding the "\nFrom "'s itself.

I didn't want to suggest that this should be made the default behaviour.
But what if `quoted-printable-encode-region' checked a global variable
and encodes "\nFrom " if it is non-nil -- this wouldn't change anything
for regular messages?  This variable should never be set explicitly,
but bound by a wrapper of `message-encode-message-body'.  This way,
the information that "\nFrom " has to be encoded can easily be passed
down the encoding process.  Of course, the checks whether to call
`quoted-printable-encode-region' have to be changed as well, so that
this function is really called if the flag variable is non-nil and
there's a line beginning with `From ' in the text to be encoded.

Re: MIME-PGP (was: Re: I'm alive!)

[Lars Magne Ingebrigtsen]

Florian Weimer <fw@cygnus.stuttgart.netsurf.de> writes:

> Content-Type: multipart/signed; boundary=YD3LsXFS42OYHhNZ; micalg=pgp-md5;
> 	protocol="application/pgp-signature"

[...]

> The `micalg' and `protocol' parameters in the primary `Content-Type'
> header are vital, but it seems as if they aren't passed to functions
> listed in `gnus-mime-multipart-functions'.

All the parameters in the Content-Type header are contained in the
MIME handle.

> In addition, everything between the first and second
> `--YD3LsXFS42OYHhNZ' boundary is covered by the PGP signature,
> including the MIME headers and boundaries, which get lost during the
> translation from raw message text to MIME handles.

Right.

> Finally, in the `multipart/encrypted' case, as shown below, the encrypted
> part contains data which has to be put through the MIME translation
> process as well.  This has not happend during the first translation,
> because obviously, the data contained in the part wasn't readable then.

Yup.

> IMHO, an appropiate hook into `mm-dissect-buffer' would allow
> to do all these things in a relatively straightforward manner.
> `gnus-mime-multipart-functions' could be used to put information gathered
> during the MIME translation process (signer, valid/invalid signature,
> beginning/end of signed data) into the *Article* buffer in a nicely
> formatted form.

Do you mean that the decryption/verification hook should sweep the
message first, and then transform the message in some way?  By
decoding stuff or verifying stuff, and then replacing that stuff with
the decoded/verified stuff?  Hm.

A different way of doing this would be doing it like I said :-), but
add the "raw" part to the MIME handles as well.  Then it could verify
the headers as well.  And the decryption multipart handle is free to
MIME-decode the handles it gets, and then let Gnus handle the decoded
parts (recursively).

> I didn't want to suggest that this should be made the default behaviour.
> But what if `quoted-printable-encode-region' checked a global variable
> and encodes "\nFrom " if it is non-nil -- this wouldn't change anything
> for regular messages?

Well, why not just quote the "\nFrom " lines before calling the
qp-encode function?  It seems like a cleaner way to do this.

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

Re: MIME-PGP

[Florian Weimer]

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

> Do you mean that the decryption/verification hook should sweep the
> message first, and then transform the message in some way?  By
> decoding stuff or verifying stuff, and then replacing that stuff with
> the decoded/verified stuff?  Hm.

Well, sort of.  Did you get the code I sent to you?  I hoped it would
clarify my approach (although it's an utter mess).

I'd like to suggest the following solution:

- encoding: provide a hook which allows to generate MIME multiparts
  based on the encoded version of the contained parts.  This means that
  you can write (had to fake it a bit, so that Gnus groks it ;):

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

  ...and Gnus will do the necessary work automatically when you send
  the message.

- decoding: do all verification and decryption during the dissection
  phase (don't defer it until the article is actually displayed; an
  appropriate hook is required, of course).

> Well, why not just quote the "\nFrom " lines before calling the
> qp-encode function?  It seems like a cleaner way to do this.

Eh, I don't see how this could work.  If a s/^From /From=20/ is done
before qp-encode is called, wouldn't this result in `From=3D20'?

Re: MIME-PGP

[Lars Magne Ingebrigtsen]

Florian Weimer <fw@s.netic.de> writes:

> - encoding: provide a hook which allows to generate MIME multiparts
>   based on the encoded version of the contained parts.  This means that
>   you can write (had to fake it a bit, so that Gnus groks it ;):
> 
>     | <# multipart type=signed>
>     | This is a signed multipart.
>     | <# part type="text/plain" filename="~/file2"
>     |   disposition=attachment description="signed attachment">
>     | <# /part>
>     | <# /multipart>
> 
>   ...and Gnus will do the necessary work automatically when you send
>   the message.

This sounds good.

> - decoding: do all verification and decryption during the dissection
>   phase (don't defer it until the article is actually displayed; an
>   appropriate hook is required, of course).

This doesn't, really.  For instance, I would guess most users will
want to see the message whether it can be verified or not, and there
should be some user interface thing to the verification.  For
decoding, the user may have to type in a password or the like, and
that can't take place during dissection, since that's supposed to
happen at a very low level.

> > Well, why not just quote the "\nFrom " lines before calling the
> > qp-encode function?  It seems like a cleaner way to do this.
> 
> Eh, I don't see how this could work.  If a s/^From /From=20/ is done
> before qp-encode is called, wouldn't this result in `From=3D20'?

Yes.  So quote the "\nFrom " lines after encoding, then.  :-)

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

Re: MIME-PGP

[Florian Weimer]

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

> > - decoding: do all verification and decryption during the dissection
> >   phase (don't defer it until the article is actually displayed; an
> >   appropriate hook is required, of course).
> 
> This doesn't, really.  For instance, I would guess most users will
> want to see the message whether it can be verified or not, and there
> should be some user interface thing to the verification.

Verification can be done automatically during dissection, no user
interaction is required (personally, I don't like automatic key fetching
anyway ;).  I have yet to investigate whether it is possible to put
the result of the verification into the `multipart/signed' MIME handle
and use `gnus-mime-multipart-functions' to display the information to
the user.

If verification is done during the display phase, the format of the MIME
handles has to be modified to contain information on how to obtain the
raw message data.  I don't know how feasible this is.

> For decoding, the user may have to type in a password or the like,
> and that can't take place during dissection, since that's supposed
> to happen at a very low level.

I see.  In addition, it might be a good idea letting the user decide when
he wants to decrypt the message (i.e. when nobody is watching him ;).
In contrast to verification, decryption doesn't need the raw message
data, which means that the representation of the MIME handles doesn't
have to be changed.

> > > Well, why not just quote the "\nFrom " lines before calling the
> > > qp-encode function?  It seems like a cleaner way to do this.
> > 
> > Eh, I don't see how this could work.  If a s/^From /From=20/ is done
> > before qp-encode is called, wouldn't this result in `From=3D20'?
> 
> Yes.  So quote the "\nFrom " lines after encoding, then.  :-)

But this will only work if the part has already been encoded as
quoted-printable.  It might well happen that Gnus has chosen to use
7-bit encoding (because it doesn't contain any strange characters),
so it would be necessary to recode the part as quoted-printable first
and then do the "\nFrom " translation.

A related problem is that RFC 2015 forbids to use 8-bit or binary
encoding (because parts might get mangled by MTAs, which would be
deadly for the signature) and I haven't found a way to efficiently
disable these encodings.

Re: MIME-PGP

[Toby Speight]

Florian> Florian Weimer <URL:mailto:fw@s.netic.de>

0> In <URL:news:m37logql14.fsf@deneb.cygnus.stuttgart.netsurf.de>,
0> Florian wrote:

Florian> If a s/^From /From=20/ is done ...

I think that s/^From/=46rom/ and s/^from/=66rom/ are both necessary,
given some of the MTAs I've experienced.

Re: MIME-PGP

[Lars Magne Ingebrigtsen]

Florian Weimer <fw@s.netic.de> writes:

> If verification is done during the display phase, the format of the MIME
> handles has to be modified to contain information on how to obtain the
> raw message data.  I don't know how feasible this is.

It's no problem -- I'll just add a `mm-handle-raw-content' accessor,
and store the raw contents where they can be got at.

> I see.  In addition, it might be a good idea letting the user decide when
> he wants to decrypt the message (i.e. when nobody is watching him ;).
> In contrast to verification, decryption doesn't need the raw message
> data, which means that the representation of the MIME handles doesn't
> have to be changed.

Right.

> But this will only work if the part has already been encoded as
> quoted-printable.  It might well happen that Gnus has chosen to use
> 7-bit encoding (because it doesn't contain any strange characters),
> so it would be necessary to recode the part as quoted-printable first
> and then do the "\nFrom " translation.
> 
> A related problem is that RFC 2015 forbids to use 8-bit or binary
> encoding (because parts might get mangled by MTAs, which would be
> deadly for the signature) and I haven't found a way to efficiently
> disable these encodings.

I would imagine that we would add some encoding handlers for MIME
encryption that would force mml to encode using qp, no matter what.
There's no such thing in there yet, but I don't think it would be
difficult to add stuff like that.

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

Re: MIME-PGP

[Florian Weimer]

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

> > If verification is done during the display phase, the format of the MIME
> > handles has to be modified to contain information on how to obtain the
> > raw message data.  I don't know how feasible this is.
> 
> It's no problem -- I'll just add a `mm-handle-raw-content' accessor,
> and store the raw contents where they can be got at.

Great.  For the encoding case, I'd like to suggest the following hook
(diff against pgnus 0.95):

--- /opt/pgnus/lisp/mml.el	Sat Jul 10 11:15:29 1999
+++ /tmp/mml.el	Sat Jul 10 20:08:09 1999
@@ -31,6 +31,19 @@
 (eval-and-compile
   (autoload 'message-make-message-id "message"))
 
+(defvar mml-generate-multipart-alist
+  '(("signed" . rfc2015-generate-signed-multipart)
+    ("encrypted" . rfc2015-generate-encrypted-multipart))
+  "*Alist of multipart generation functions.
+
+Each entry has the form (NAME . FUNCTION), where
+NAME: is a string containing the name of the part (without the 
+leading \"/multipart/\"),
+FUNCTION: is a Lisp function which is called to generate the part.
+
+The Lisp function has to supply the appropriate MIME headers and the
+contents of this part.")
+
 (defvar mml-syntax-table
   (let ((table (copy-syntax-table emacs-lisp-mode-syntax-table)))
     (modify-syntax-entry ?\\ "/" table)
@@ -271,16 +284,20 @@
     (insert (or (cdr (assq 'contents cont))))
     (insert "\n"))
    ((eq (car cont) 'multipart)
-    (let ((mml-boundary (mml-compute-boundary cont)))
-      (insert (format "Content-Type: multipart/%s; boundary=\"%s\"\n"
-		      (or (cdr (assq 'type cont)) "mixed")
-		      mml-boundary))
-      (insert "\n")
-      (setq cont (cddr cont))
-      (while cont
-	(insert "\n--" mml-boundary "\n")
-	(mml-generate-mime-1 (pop cont)))
-      (insert "\n--" mml-boundary "--\n")))
+    (let* ((type (or (cdr (assq 'type cont)) "mixed"))
+           (handler (assoc type mml-generate-multipart-alist)))
+      (if handler
+          (funcall (cdr handler) cont)
+        ;; No specific handler.  Use default one.
+        (let ((mml-boundary (mml-compute-boundary cont)))
+          (insert (format "Content-Type: multipart/%s; boundary=\"%s\"\n"
+                          type mml-boundary))
+          (insert "\n")
+          (setq cont (cddr cont))
+          (while cont
+            (insert "\n--" mml-boundary "\n")
+            (mml-generate-mime-1 (pop cont)))
+          (insert "\n--" mml-boundary "--\n")))))
    (t
     (error "Invalid element: %S" cont))))
 
> I would imagine that we would add some encoding handlers for MIME
> encryption that would force mml to encode using qp, no matter what.
> There's no such thing in there yet, but I don't think it would be
> difficult to add stuff like that.

I've got a solution which changes `mm-content-transfer-encoding',
`mm-body-encoding', and of course `quoted-printable-encode-region'
so that these functions use `safe' encodings if a special variable is
bound to a non-nil value.  Do you thing that's the way to go?

Re: MIME-PGP

[Lars Magne Ingebrigtsen]

Florian Weimer <fw@s.netic.de> writes:

> Great.  For the encoding case, I'd like to suggest the following hook
> (diff against pgnus 0.95):

Thanks for the patch; I've applied it to Pterodactyl Gnus v0.97.

> > I would imagine that we would add some encoding handlers for MIME
> > encryption that would force mml to encode using qp, no matter what.
> > There's no such thing in there yet, but I don't think it would be
> > difficult to add stuff like that.
> 
> I've got a solution which changes `mm-content-transfer-encoding',
> `mm-body-encoding', and of course `quoted-printable-encode-region'
> so that these functions use `safe' encodings if a special variable is
> bound to a non-nil value.  Do you thing that's the way to go?

Er; I no longer remember what we were discussing.  :-)  But, uhm,
probably. 

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