Re: Request for UI and String freeze break for DoS bug

[Srinivasa Ragavan <sragavan novell com>]

On Fri, 2006-11-17 at 14:57 +0100, Andre Klapper wrote:
> hi srini,
> 
> Am Freitag, den 17.11.2006, 11:59 +0530 schrieb Srinivasa Ragavan:
> > If you receive a mail that has inline text of more than few MBs [Vary
> > depending on your RAM/Swap size] it just hogs your desktop and Evolution
> > is totally unusable after that.
> > 
> > http://bugzilla.gnome.org/show_bug.cgi?id=337439 has the details about
> > the bug. I have put a patch, which now shows a warning about the issue
> > and gives a option to view the message unformatted/plain text or with an
> > external viewer.
> > 
> > I have attached a screen shot at the bugzilla. It will go to HEAD, but
> > it will be nice, If I can push this to 2.8.2 which is due Monday. Can
> > this be committed to STABLE?
> 
> i agree that this is a serious security issue, as evolution tries to be
> smart and immediately starts rendering the same message again after
> restarting the application. users currently don't have a chance to get
> evolution running again without changing gconf keys.
I can move this to a Evolution Preference. Definitely not a issue at
all.
> 
> however, as discussed on irc, this is a hackish workaround, but not a
> fix for the underlying issue of the problem that "view->message source"
> uses gtkhtml (otherwise the output of this command could be used to be
> displayed in the message preview pane/message window instead of adding a
> GtkTextArea), and another underlying issue of your workaround, namely
> that GtkTextArea dies when increasing the size of that text widget
> (according to srini), so i either have to scroll around like mad to read
> that message source, or i have to open an external application.
> 
> so, if you
> 1. can explain whether this DoS issue can only happen to emails? if
>    so, please change the string "Evolution cannot render this as it
>    is too large to handle. You can view it unformatted or with an
>    external viewer." to something like "Evolution cannot render
>    this email as it is too large to handle. You can view it
>    unformatted or with an external text editor." to make the
>    translators' lifes a bit easier (think of different genders and
>    personal pronouns of the term "email" in other languages!)
Sure. I can rephrase it.

> 2. explain whether there's any difference between "unformatted" and
>    "message source" from a user's point of view (not from a
>    developer's point of view, i don't care about MIME parsers)?
>    if there isn't, please change the three affected messages by only
>    using the term "message source" as already used by evolution in
>    its menu, instead of introducing another term,
Message source means the whole message. Where as here we speak of parts.
Assume I have a mail 10MB of text with 3 inline images of 4 MB each.
Evolution cannot render the text message partof 10 MB. In the message
view, you still see the 3 images and at the top, the warning with the
unformatted content [UNFORMATTED meaning if you have a message like "hai
my web site is http://novell.com"; you wont see the UNDERLINE below the
url and lot more like this]. If you ask message source, it means the
HEADERS, PARTIDs and txt. You cannot refer the one as another.


> 3. fix the typo at "em_format_format_tex(emf, stream, part)",
Done.
> 4. promise to try to work out the underlying issue 1) for the next
>    major release (evo 2.10),

You mean the memory built up in GtkHTML? I wish I can fix it. I went for
this workaround after spending sufficient time try fixing it. I tried my
best to avoid the DoS attack. I'm not sure whether I can fix the memory
built-up by 2.10. 

Thanks
Srini.
> 
> i'd probably vote for getting this in, though i'm not really happy. :-/
> 
> cheers,
> andre
>