Red Hat Bugzilla – Bug 478331
Insane libical defaults
Last modified: 2009-06-10 14:28:11 EDT
Description of problem:
dnl test/regression.c (and maybe others) needs this defined
AC_DEFINE(ICAL_ERRORS_ARE_FATAL,1,[Define to make icalerror_* calls abort instead of internally signalling an error])
AC_DEFINE(NO_WARN_DEPRECATED,1,[Define to 1 if you DO NOT WANT to see deprecated messages])
AC_DEFINE(NO_WARN_ICAL_MALFORMEDDATA_ERROR_HACK,1,[Define to 1 if you DO NO WANT to see the warning messages related to ICAL_MALFORMEDDATA_ERROR and parsing .ics zoneinfo files]
This was seen in configure in. Note that all three are set to what is generally the opposite of what would one expect. Especially the first one is particularly destructive and have caused problems to Evolution  as well as to Sunbird . I'm wondering if there's a real-world example where this would be a suitable setting.
 bug #477343
Steps to Reproduce:
Invoke any error with incorrect or unsupported ical file, see your application senselessly crash.
This is definitely something that needs to be solved upstream; so pardon me for bothering you, but I assume you are in touch with upstream, unlike me.
The comment above states that it is utilized by a regression test, but our run of regression tests is commented out anyways. I guess the problem with the first define would be solved just by adding proper error handling to the test, while the rest by eliminating tests that test deprecated interfaces. I may be wrong though.
This has been discussed recently on freeassociation-devel (archive link not working) and freeassociation-libical. While Allen Winter from KDE PIM was slightly in favour of having the fatal behaviour because it had exposed bugs in his code, Suman Manjunath of Evolution and the Libical developers seemed bent on disabling it for non-development scenarios.
Apparently, Bongo also had disabled it long time ago in their forked copy of Libical:
2003-09-23 Hans Petter Jansson <firstname.lastname@example.org>
* configure.in: Remove flex check. Set ICAL_ERRORS_ARE_FATAL to 0.
Personally I am inclined to patch it out in the Fedora packages util the upstream tarballs start reflecting this change. However it would be good to discuss this with the other people linking to Libical. eg., KDE PIM.
Allen ping'd me to request not to be hasty changing anything (and upon further reflection, would tend to agree).
I would recommend, that folks wanting change here would be best served to continue working with libical upstream, rather than downstreams (like us) changing behavior.
While the discussion continues upstream, one approach would be to use libical's fatal behaviour in Rawhide and switch it off in the stable releases. Applications which are not comfortable with libical's behaviour can override it using:
int ical_errors_are_fatal = 1 /* or 0 */;
Reading Suman Manjunath's mails it appears that Evolution upstream has decided to set to 0.
Could you please give me an approximate timeframe when would it be possible to switch this off, so I can decide whether it makes sense to wait for the fix, or switch sunbird do bundled libical?
I got another report about sunbird needlessly crashing due to this and am feeling guilty, because I switched sunbird to external libical w/o upstream patch (upstreamable patch on its way now) :(
(In reply to comment #4)
I was actually looking for some sort of response from you and Rex (or someone from the KDE team). Of the packages that I own, osmo uses libical but so far I have not yet encountered any problem with it. So here is my plan as mentioned in comment 3:
+ Disable fatal behaviour in Fedora 9 and Fedora 10.
+ Enable fatal behaviour on Rawhide to help developers uncover hiden bugs.
And as I mentioned earlier, applications using libical can always tweak the settings by using ical_errors_are_fatal and friends.
Is this okay with you? Would it help if I tagged and built some packages according to the above plan for Fedora 9 and Fedora 10 for you to try out?
Upstream consensus (from following the ml) I thought was to leave things as-is, and for apps that want to guaranty their own behavior, to do so by setting ical_errors_are_fatal themselves (as mentioned already).
Varying from upstream defaults here simply makes me uncomfortable.
To me the entire discussion looks inconclusive. Initially driven by Suman's mail it looked as if upstream was inclined to follow Evolution's request to turn off the fatal behaviour. Then some KDE guys, first Allen Winter and then Will Stephenson from KDE PIM and Kontact objected to this. Will ended up by proposing this solution depending on whether or not this is a stable distribution.
Right now upstream is undecided on what to do, hence the status quo prevails, while both Evolution and Kontact seem to have gone their own way by tweaking the defaults.
What worries me is that how will we react if KDE PIM applications like Kontact start crashing on stable releases like Fedora 9 and 10? Won't this turn users away till the bug gets fixed? Sure it helps in locating bugs, but users of a stable release might be more disappointed to find their application crash than they would be to know that they found a bug.
Lubomir, what do you think?
Meanwhile I will just drop a mail on fedora-devel-list to get more people (eg., Evolution owner) involved.
The right thing to do is make this behaviour runtime switchable with some kind of LIBICAL_DEBUG environment variable. Normal users don't get random crashes, but developers and testers can still turn it on without have to recompile the entire library.
This could be seen as a denial of service vulnerability.
libical-0.41-2.fc9 has been submitted as an update for Fedora 9.
libical-0.41-2.fc10 has been submitted as an update for Fedora 10.
libical-0.41-2.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing-newkey update libical'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-0357
libical-0.41-2.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update libical'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-0467
FYI, kdepim has always defaulted its internal libical to "errors are fatal".
(In reply to comment #13)
> FYI, kdepim has always defaulted its internal libical to "errors are fatal".
As I already noted here, this was discussed on the upstream mailing list where Allen Winter was also involved.
libical-0.41-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
libical-0.41-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
This is still affecting EPEL - should I file a separate bug, or reopen this one?
P.S. This makes Lightning unusable as it crashes at any attempt to dismiss or postpone a reminder window for a calendar from Exchange via DavMail...
EPEL is shipping libical-0.43-4 on EL-4 & EL-5 (at least in updates-testing).
If it's fixed on Rawhide, it is also fixed on EPEL then.