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

[Patrick Ohly]

On Thu, 2016-10-06 at 02:26 +0200, deloptes wrote:
> Patrick Ohly wrote:
> 
> > +        // 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.
> 
> This seems to magically work

I don't like magic - at least not in software engineering ;-}

So let's try to understand this a bit better. Compared to my proposed
patch, you added "p=nextunfolded(p,aMimeMode,true)" before the
"continue".

Without it, we enter the next loop iteration:

c=*p; // c should be = now
if (isEndOfLineOrText(c) || (!escaped && aStructSep!=0 && (c==aStructSep || c==aAltSep))) break; // We haven't changed any of these, so it should continue.
escaped=(!escaped) && (c=='\\'); // No change either.
if (c=='=') {
  s=nextunfolded(p,aMimeMode,true); // Hmm, not quite the same...

Okay, I think I understand. The loop expects to start after skipping
over line folding, so when we enter it pointing towards the soft line
break =, it does the wrong thing. The additional nextunfolded() avoids
that.

> @@ -1937,6 +1938,23 @@ static void decodeValue(
>          uInt16 code;
>          const char *s;
>          char hex[2];
> +
> +       // The Nokia N9 vCalendar implementation sends ==0D=0A= 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 ==0D=0A=, otherwise the code below would insert additional
> +       // characters into the decoded text.
> +        if (strncmp(p,"==0D=0A=",8)==0) {
> +          p += strlen("==0D=0A")-1;
> +          // put the cursor at the next useful =
> +          p=nextunfolded(p,aMimeMode,true);
> +          continue;
> +        }
>          s=nextunfolded(p,aMimeMode,true);
>          if (*s==0) break; // end of string
>          hex[0]=*s; // first digit

I'll add that patch to the next test run. Thanks for testing and the
correction.

-- 
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.