Re: Request for UI and String freeze break for DoS bug
In my opinion, I prefer an English string displayed than a difficult to solve crash. Most users I think are not going to be able to handle OOM condition by typing on a terminal or modifying gconf values. Just my 2 cents of Euro ;-) El vie, 17-11-2006 a las 11:59 +0530, Srinivasa Ragavan escribió: f 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? Please let me know, if you any questions. Thanks Srini. -- Francisco Javier F. Serrador Coordinador de localización GNOME Contacto: serrador at #i18n irc.gnome.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request for UI and String freeze break for DoS bug
Hi Javier, If I get you right, you mean a configuration option in Preferences to set the message limit, instead of a ENV variable. Am I right? I think it should be fairly possible. It is just a matter of time. I'm not sure, If I can push that before 2.8.2, but definitely possible for further releases on stable, if the release team approves them too :). Thanks Srini. On Fri, 2006-11-17 at 10:42 +0100, Francisco Javier F. Serrador wrote: In my opinion, I prefer an English string displayed than a difficult to solve crash. Most users I think are not going to be able to handle OOM condition by typing on a terminal or modifying gconf values. Just my 2 cents of Euro ;-) El vie, 17-11-2006 a las 11:59 +0530, Srinivasa Ragavan escribió: f 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? Please let me know, if you any questions. Thanks Srini. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request for UI and String freeze break for DoS bug
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. 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!) 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, 3. fix the typo at em_format_format_tex(emf, stream, part), 4. promise to try to work out the underlying issue 1) for the next major release (evo 2.10), i'd probably vote for getting this in, though i'm not really happy. :-/ cheers, andre -- mailto:[EMAIL PROTECTED] | failed! http://www.iomc.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request for UI and String freeze break for DoS bug
Yep, translators usually are proud of being the first to reach 100% translated string completion, but, users who get a completely localized application also expect that it does not crash :). We target users, (and clients), and users do not know how to set env variables, and if you force them to do so, they will use other application. We need string freeze to avoid getting a ton of new strings some days before release, but not to prevent critical bug fixes as this from being resolved. If this specific bug were less severe I will do not agree to break the string freeze. El vie, 17-11-2006 a las 16:50 +0530, Srinivasa Ragavan escribió: If I get you right, you mean a configuration option in Preferences to set the message limit, instead of a ENV variable. Am I right? I think it should be fairly possible. It is just a matter of time. I'm not sure, If I can push that before 2.8.2, but definitely possible for further releases on stable, if the release team approves them too :). ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request for UI and String freeze break for DoS bug
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
Re: seahorse 0.8 and HEAD
Francisco Javier F. Serrador skrev: Ok, done. New stats will be procesed in some hours. Great. Thanks! Is it also possible to update progress.g.o to display HEAD? http://progress.gnome.org/module/seahorse Regards, Daniel ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: seahorse 0.8 and HEAD
That's Danilo's realm. I sure he will do it as soon as he read the list. El vie, 17-11-2006 a las 17:00 +0100, Daniel Nylander escribió: Francisco Javier F. Serrador skrev: Ok, done. New stats will be procesed in some hours. Great. Thanks! Is it also possible to update progress.g.o to display HEAD? http://progress.gnome.org/module/seahorse Regards, Daniel ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request for UI and String freeze break for DoS bug
Done. I have added a patch to bugzilla which provides an option to set the limit in Edit-Preferences instead of ENV variable. Thanks Srini. On Fri, 2006-11-17 at 15:14 +0100, Francisco Javier F. Serrador wrote: Yep, translators usually are proud of being the first to reach 100% translated string completion, but, users who get a completely localized application also expect that it does not crash :). We target users, (and clients), and users do not know how to set env variables, and if you force them to do so, they will use other application. We need string freeze to avoid getting a ton of new strings some days before release, but not to prevent critical bug fixes as this from being resolved. If this specific bug were less severe I will do not agree to break the string freeze. El vie, 17-11-2006 a las 16:50 +0530, Srinivasa Ragavan escribió: If I get you right, you mean a configuration option in Preferences to set the message limit, instead of a ENV variable. Am I right? I think it should be fairly possible. It is just a matter of time. I'm not sure, If I can push that before 2.8.2, but definitely possible for further releases on stable, if the release team approves them too :). ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
cvs assistance needed (probably)
hello, I'm a member of polish gnome translation team. Polish translation got a massive update for 2.16.1, but now it appears that we have nobody with cvs access among us. It seems that our coordinator (Artur Flinta) is off-line at the moment and most probably will be offline for all this week-end. He started a cvs account grant procedure for me, but at the moment we have no response from [EMAIL PROTECTED] So I would like to know possibly exact deadline date for translation cvs commit and if there is somebody who would help us with the commit in case we don't contact Artur before the deadline. (I know that this idea is rather unusual, but maybe as an exception, someone of You will help us ;-)) thanks in advance, -- AviaryPL l10n team e-mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[gcmd-dev] GNOME Commander translations
Hi folks, As we are getting closer to the next release of GNOME Commander - version 1.2.2, we need updated translations (http://progress.gnome.org/module/gnome-commander) before the release that is going to happen till the end of November. It would be great if translations could be updated before the launch. Thanks, Piotr ___ gcmd-devel mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/gcmd-devel
Re: cvs assistance needed (probably)
Last time I knew the was a long line of people waiting to get the access. I can't help you directly (don't have access), sorry... Leonardo Fontenelle ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
