[SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta)

[Patrick Ohly]

On Sun, 2016-10-02 at 00:31 +0200, deloptes wrote:
> The diff is the closest I could get to make it work acceptable for me - it
> at least does not mangles the text.

Unfortunately there is no script in the Synthesis engine that could fix
up the date before parsing. See doc/SySync_script_call_flow.pdf. That
means we are indeed stuck at trying to detect and deal with this problem
in the parser.

On the other hand, a naive global search/replace would also break the
(unlikely) occurrence of ==OD=0A= where it is part of some regular,
non-quoted-printable text. So doing it in the parser is the more stable
approach anyway.

Before I dive into trying to understand your change, let me walk through
the problem.

What we get from the N9 is something where the CRLF in a =CRLF soft line
break according to rfc1521.txt 5.1. are encoded again and an extra = for
the soft line break is added, leading to ==0D=0A= at the end of lines
instead of =CRLF (where CR and LF are single octets).

For example, a two-line description:
some long line which needs to be folded foo
bar

Becomes:
DESCRIPTION;ENCODING=QUOTED-PRINTABLE:some long line which needs to be folded foo=0D=0A==OD=0A=
bar

Correct would be:
DESCRIPTION;ENCODING=QUOTED-PRINTABLE:some long line which needs to be folded foo=0D=0A=
bar

The ==OD=0A= part is invalid because = must be followed by two hex
characters, and = itself needs to be encoded as =3D. That follows from
rule #2 in rfc1521.txt which explicitly excludes the = from the range of
characters which may be used without encoding.

That means that we can treat ==0D=0A= as an alias for = without
affecting other devices.

With that in mind, let me present a more localized change:
diff --git a/src/sysync/mimedirprofile.cpp b/src/sysync/mimedirprofile.cpp
index 84f0271..cdc32fb 100644
--- a/src/sysync/mimedirprofile.cpp
+++ b/src/sysync/mimedirprofile.cpp
@@ -1937,6 +1937,22 @@ static void decodeValue(
         uInt16 code;
         const char *s;
         char hex[2];
+
+        // The Nokia N9 vCalendar implementation sends ==0A=0D= at the end of
+        // the line when it should send just the =. Apparently the CRLF octets
+        // get inserted before quoted-printable encoding and then get encoded.
+        // Such a sequence is invalid because = cannot be used literally
+        // and must be followed by characters representing the hex value,
+        // i.e. == is already invalid.
+        //
+        // We must skip over the entire sequence and continue at the last
+        // = in ==0A=0D=, otherwise the code below would insert additional
+        // characters into the decoded text.
+        if (!strcmp(p, "==0A=0D=")) {
+          p += strlen("==0A=0D=") - 1;
+          continue;
+        }
+
         s=nextunfolded(p,aMimeMode,true);
         if (*s==0) break; // end of string
         hex[0]=*s; // first digit

Does that make sense? More importantly, does it work? I've not tried it
out myself yet with any peer which uses vCalendar 1.0 or vCard 2.1. My
phone that I used to test with no longer starts up without a SIM card,
so I need to find an unused one first.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.