bug#15984: 24.3; Problem with combining characters in attachment filename

[Eli Zaretskii <eliz@gnu.org>]

> From: nisse@lysator.liu.se (Niels Möller)
> Date: Thu, 28 Nov 2013 09:08:54 +0100
> 
> I'm reading email with Gnus. I received an email with an attachment
> containing the headers
> 
>   Content-Type: application/pdf;
>    name="Brev =?UTF-8?B?YWt0aWVhzIhnYXIgMTMxMTI3LnBkZg==?="
>   Content-Transfer-Encoding: base64
>   Content-Disposition: attachment;
>    filename*0*=UTF-8''%42%72%65%76%20%61%6B%74%69%65%61%CC%88%67%61%72%20%31;
>    filename*1*=%33%31%31%32%37%2E%70%64%66
> 
> Apparently sent by a Mac user,
> 
>   User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
> 
> The attachement was displayed in the *Article* buffer as
> 
>   [2. application/pdf; Brev aktiea?gar 131127.pdf]...
> 
> I was running emacs-24.3 in a tty, in a latin-1 locale, on a sparc
> Solaris system. (In a latin-1 tty, emacs ought to display "ä" instead of
> "a?", but that's a less severe and possibly unrelated problem).

If ä was supposed to be produced by character compositions, then Emacs
cannot do that on a TTY, because compositions require drawing one
glyph over the other (with certain offsets).

If you expected Emacs to perform normalization in this case, then I
don't think we do this automatically (or at all).

> When I tried to save the attachment by pressing "o" on that button
> (gnus-mime-save-part), emacs immediately crashed with a segmentation
> violation signal. Since emacs very rarely crashes, I was a bit
> surprised. I just restarted emacs and Gnus and tried again, and it
> crashed again. So at least for me, the problem is reproducible.

Can you send that message as a binary attachment?

> And a crash triggered by untrusted data in a received email is always
> scary. After fixing the bug, exploit possibilities ought to be analyzed.

I suggest to try a recent development trunk, several similar crashes
were fixed a few months ago.  If that doesn't help, please reproduce
the problem in a non-optimized non-stripped build, and show the
variables from char_table_ref that are involved in the crash.  (I'm
guessing char_table_ref got a bogus character code.)