Bug 136118

The preview is not controlled by evolution. While sending attachments, the sender can specify automatic preview, and if that is set, overriding is not possible at all. Ideal workaround is to hide the message preview and start evo. But im not sure where the problem is.

Can you attach a stack trace, so that we can look at where the problem is.

Created attachment 59674 [details]
some group 4 tiff files

Find attached some group 4 compressed monochrome tiff files (also konwn as fax files).

Switching off the preview window doesn't help. I created a new email and added a tiff attachment and Evolution locked up in the same way. Is there some list of MIME types I can edit to exclude preview of Tiffs? 

Apart from the tiff issue, there are some serious design issues here relating to how what I presume is an an external program can lock up Evolution so completely and revder it so completely useless.

hmm, i couldnt get the problem. Can you mail that tiff file. sragavan@novell.com.

It could be a UI issue or a server issue or a middleman stuff. But seeing would help it.

Created attachment 59689 [details]
same text comments repeated in a file

Another bad design feature - After Evolution locked up when I tried to attach a tiff file with message preview turned off, I killed Evolution using the Gnome "Force misbehaving applet to quit" applet. Evolvtion then does not start up. I then killed the Gnome session using CNTRL ALT BACKSPACE, and logged in again - Evolution still does not start up. I then rebooted and then Evolution did start up. Presumably some process that is not killed off by killing the session is running, or some lock file is left that is only re-set on reboot. This is again a very bad design feature. Imagine having to reboot an application server on which hundreds of users are running sessions with thin clients every time any one user kills an Evolution client. The robustness of the Evolution application or lack of is very poor.

The other thing as I mentioned before is that after Evolution locks up on an email with a tiff attachment, it is impossible to make Evolution start up again without deleting the mailbox with the offending email, and rebooting. This is probably because on starting up, Evolution tries to preview the same email. Would it not be sensible to make it start up without a preview or a focus on any email to avoid a lockout problem like this?

see attachment id=59674 I sent earlier. The problem seems to happen only with tiff group 3 or 4 compressed files.

The CPR_OS keyword is for use with NW only.

Siva, I almost forgot to reply. To be frank, while trying to save the file, my firefox hung. After that my nautilus Hung. Then somehow i started evolution, it too hung. It seems to be more with  the base lib. I would prefer to fix it from that level. Disabling preview is not a solution at all. It will be against the protocol, if we override 'show attachment automatically'.

I dont think this is Evo specific. Moving to needinfo

No, as I said earlier, this doesn't seem to be Evolution specific, but it sure does lock up Evolution pretty solidly - a case of attachments in a commonly used file format acting as a very effective DOS attack which locks up Evolution completely and renders it completely unusable. 

Group 3 and 4 tiff files (aka Fax files) are common for scanned documents and electronic fax documents, so any business user will need to handle this type of file - although not necessarily with the offending preview library.

It also affects KDE and Gnome if file previews are turned on. It will presumably affect all other programs which use the library with the bug in it. 

This is a serious bug which needs to be fixed to make SuSE Linux usable in a business context. The only way of making Evolution usable after the "Group 3/4 tiff file attachment DOS attack" is to rename them mail folder with the Tiff file in it to something else, then open Evolution and carefully avoiding the tiff file (to avoid locking up again), move all the other emails another folder, then delete the renamed folder with the tiff file.

I think that if the offending library cannot be fixed, it should simply be removed, since it is not necessary to use it to view tiffs - KFax works just fine without locking up, and it is better to not preview tiff files rather than have Evolution, KDE or Gnome lock up every time a preview is attempted.
 
I also question the policy of not allowing disabling of preview of some MIME types in Evolution. This "DOS attack" is a very good example of why it is a bad policy - a security hole in any external preview library will be exploited without the user being able to do anything to prevent it. This makes Evolution as serious a security problem as MS Outlook. Surely it would not be too difficult to have a settings menu item that would open a window that would allow selection of which MIME filetypes will be previewed and the application that will be opened, or at least a file with MIMEtypes which can be manually edited or updated with YOU security updates to disable opening with embedded applications with security vulnerabilities.

As a interim fix, and until you have a proper fix, can't you simply just disable previewing of tiff files in Evolution for now since it doesn't work anyway?

A Interm fix is fine. But im just wondering what it takes to move to imlib module as a showstopper and raise a flag for it. it makes every one happy. Evo can do this. You expect nautilus to have preview OFF for tiff, the same applies for firefox too. The list grows big. Just move to imlib module and let them aware of the issue. This interim fix is not right since this is a DOS attack If some one attaches a html mail with inline image, it cant hide the preview then. Let us try to solve the main issue. Hope you understand the point I say.

pete: This seems to be a issue in imlib that needs to be solved. Or else, every single app will become a vulnerable entity. Can you put it across the right team. Sorry I dont know the right team.

Re-assigning to Phillip Thomas.  Phillip, you are listed as the maintainer for imlib.  Please let me know if I am mistaken.

Yes, that's correct. I'll look into this as soon as I have finished other, more important work.

*** Bug 136122 has been marked as a duplicate of this bug. ***

Having been open for so long tells me this can't be a blocker.

ok, as there is no progress since years I close this old bug