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 > _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n