search

tutao / tutanota

Tuta is an email service with a strong focus on security and privacy that lets you encrypt emails, contacts and calendar entries on all your devices.
https://tuta.com
GNU General Public License v3.0
6.02k stars 518 forks source link

iCal parser error with invalid continuation lines #3379

Open jowlo opened 3 years ago

jowlo commented 3 years ago

The iCal format is a mess, but as a user i still want to import my calendars that i exported from my previous calendar application.

Context

The issue with this file is that continuation lines do not start with a whitespace, see the LOCATION property below. This is not according to standard, but a lot of other calendar applications accept this anyways (incl outlook).

BEGIN:VCALENDAR
PRODID:-//BUSINESS-CALENDAR//APPGENIX-SOFTWARE//
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:Test
X-WR-TIMEZONE:Europe/Amsterdam
BEGIN:VEVENT
SUMMARY:test
DTSTART;TZID=Europe/Amsterdam:20210814T120000
DTEND;TZID=Europe/Amsterdam:20210814T130000
DTSTAMP:20210813T050843Z
UID:1234uid@uid.com
SEQUENCE:0
CREATED:20210813T050843Z
DESCRIPTION:
LAST-MODIFIED:20210813T050843Z
LOCATION: This is some
location that is not
correctly indented
STATUS:CONFIRMED
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

I propose to join a line to the previous one if the line does not contain a colon, because we will not be able to parse them anyway since we are expecting PROP:VALUE format. This would be the best place to do so imo

https://github.com/tutao/tutanota/blob/ffe396613752e7697e3232592372f39bfb0e5aa9/src/calendar/export/CalendarParser.js#L210-L213

I think it would be better to have slightly ugly imports than to not have imports at all in this case.

bedhub commented 3 years ago

What if a such a wrong folded line contains a colon in its content? Maybe we need something like "is not a property line".

I think it might also be fine to just ignore those lines instead so the LOCATION would be just "This is some".

jowlo commented 3 years ago

What if a such a wrong folded line contains a colon in its content? Maybe we need something like "is not a property line".

Yes, but i think that is pretty hard to define. That's why the standard has defined lines with starting spaces as continuation lines.

My rationale here was just that when we try to parse every line (after joining together those that start with a whitespace) we throw an error if there is no colon. Everything that does not have a colon is a "not a property line" effectively. So as of now we cannot deal with this at all and to be a bit more lenient, we could just add that info to whatever field comes before that. We could also just ignore those lines.

In case there is a colon, we will not be able to parse those and i think we will

It seems that Outlook is handling it the same way. I am a bit divided between following the standard and making it easier for users to import their calendars...