* bad boundary choice in forwarded multipart/signed multipart/mixed
@ 2010-04-29 15:11 Greg Troxel
2010-05-01 7:17 ` Andreas Seltenreich
0 siblings, 1 reply; 2+ messages in thread
From: Greg Troxel @ 2010-04-29 15:11 UTC (permalink / raw)
To: ding
[-- Attachment #2: Type: text/plain, Size: 1074 bytes --]
Using gnus from CVS about a month ago I forwarded one of my own signed
messages that itself contained a forwarded message, and a colleague
pointed out that the MIME boundary string had been reused. That
particular example can't be sent to this list, but I managed to
reproduce the problem with test messages.
The inner test message had boundary =-=-= originally. That got remapped
whent he message was forwarded, which I suppose is ok. But it got
remaped to ===-=-= and that's the same value that was chosen for the
outer message's multipart/signed.
The below was generated with current CVS head epg and gnus git as of:
commit 3aa91c009017b508c0f6298f7e8ee3a622bdccc2
Author: Katsumi Yamaoka <yamaoka@jpl.org>
Date: Tue Apr 27 06:38:57 2010 +0000
Don't load tm and apel XEmacs packages when compiling.
It looks like the key code is in mml.el in gnus, but I haven't
understood it yet.
Is perhaps the issue that the multipart/signed code is called without
the forwarded heder visible, and then the forwarded header is also
changed to the same value.
[-- Attachment #3: Type: message/rfc822, Size: 1745 bytes --]
[-- Attachment #3.1.1.1: Type: text/plain, Size: 49 bytes --]
forward of multipart/mixed as multipart/signed
[-- Attachment #3.1.1.2: Type: message/rfc822, Size: 88 bytes --]
[-- Attachment #3.1.2: Type: text/plain, Size: 31 bytes --]
Test multipart/mixed message.
[-- Attachment #3.1.3: foo.txt --]
[-- Type: text/plain, Size: 40 bytes --]
test attachment
--===-=-=--
--=-=-=--
[-- Attachment #3.1.4: Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: bad boundary choice in forwarded multipart/signed multipart/mixed
2010-04-29 15:11 bad boundary choice in forwarded multipart/signed multipart/mixed Greg Troxel
@ 2010-05-01 7:17 ` Andreas Seltenreich
0 siblings, 0 replies; 2+ messages in thread
From: Andreas Seltenreich @ 2010-05-01 7:17 UTC (permalink / raw)
To: Greg Troxel; +Cc: ding
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
Greg Troxel writes:
> The inner test message had boundary =-=-= originally. That got remapped
> whent he message was forwarded, which I suppose is ok.
Yeah, Gnus is a bit eager with regenerating MIME (you can tame it using
message-forward-show-mml).
> But it got remaped to ===-=-= and that's the same value that was
> chosen for the outer message's multipart/signed.
[...]
> It looks like the key code is in mml.el in gnus, but I haven't
> understood it yet.
My analysis so far:
(a) mml-multipart-number is let-bound on recursive descend of
mml-generate-mime. So mml-compute-boundary potentially generates
duplicate delimiters unless the collision test prevents it.
(b) The collision test code doesn't look at the content of
message/rfc822 [#mml] handles.
(c) If it would look at them, it wouldn't note a collision generated by
(a) since the handle still contains the untranslated
[#multipart]-tags instead of MIME.
I think (b) needs to be fixed anyway because a collision could occur
independently of (a). Now either fixing (a) or (c) should prevent the
generation of broken MIME. I guess squishing the bug the (b) + (c) way
is more adequate since it's less invasive. Will push in a jiffy.
Thanks for your elaborate report,
andreas
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 933 bytes --]
diff --git a/lisp/mml.el b/lisp/mml.el
index f262dc6..9dc0966 100644
--- a/lisp/mml.el
+++ b/lisp/mml.el
@@ -520,7 +520,10 @@ (defun mml-generate-mime-1 (cont)
;; `m-g-d-t' will be bound to "message/rfc822"
;; when encoding an article to be forwarded.
(mml-generate-default-type "text/plain"))
- (mml-to-mime))
+ (mml-to-mime)
+ ;; Update handle so mml-compute-boundary can
+ ;; detect collisions with the nested parts.
+ (setcdr (assoc 'contents cont) (buffer-string)))
(let ((mm-7bit-chars (concat mm-7bit-chars "\x1b")))
;; ignore 0x1b, it is part of iso-2022-jp
(setq encoding (mm-body-7-or-8))))
@@ -699,7 +702,7 @@ (defun mml-compute-boundary (cont)
(defun mml-compute-boundary-1 (cont)
(let (filename)
(cond
- ((eq (car cont) 'part)
+ ((member (car cont) '(part mml))
(with-temp-buffer
(cond
((cdr (assq 'buffer cont))
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-05-01 7:17 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-29 15:11 bad boundary choice in forwarded multipart/signed multipart/mixed Greg Troxel
2010-05-01 7:17 ` Andreas Seltenreich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).