Christian, iCal's format is no different with respect to encodings than text/plain. There's a reason why MIME allows for explicitely declaring the charset, evo should not fail to observe that, and it should not fail to remove invalid UTF-8 sequences in data it accepts from outside (said invalid sequence removal should of course happen after any inbound transcoding). Given this, I'm starting to wonder at this point whether carefully-crafted messages mightn't be created for the purpose of doing user-level remote execution using Evo as the entry point (given that Ubuntu deploys evo by default, this might raise an eyebrow). I have no beginning of proof, of course, and actually have doubts on the feasibility, but still, this leaves a pretty bad feeling.
I won't start a revert war on the BTS, however, I would like you to explain to me how, given this http://www.debian.org/Bugs/Developer.en.html#severities: grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. (my emphasis), the original severity was too much. Case in point: I do not use ext3fs. I couldn't care less if e2fstools had a data-loss bug. Should I start to go around and downgrade any such (hypothetic) grave or critical bugs, on the grounds that "the on-disk ext3 format has weaknesses"? [*] Silently loosing years worth of (potentially business) data during a trivial copy operation is not something I expect from a package supposedly worthy of entering stable Debian. I would agree with severity: important (or maybe normal even) if the failure caused a single "invalid data encountered -- copy aborted midway" message box. -- Cyrille [*] no relationship to my actual file system usage. Illustrative purpose only. Filmed overseas. Professional driver. Closed course.
