Bug 332340

Summary:	VCard import: CRLF in encoded lines breaks parsing of contact information
Product:	[Applications] kdepimlibs	Reporter:	Frank Steinmetzger <dev+kde>
Component:	kabc	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED FIXED
Severity:	critical	CC:	kollix
Priority:	NOR
Version:	4.12.2
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:	http://commits.kde.org/kdepimlibs/ebc15a8af0882a05dd383deb142c3528f04d9c80	Version Fixed In:	4.13
Sentry Crash Report:
Attachments:	Example VCF with problematic contact information Contact with garbled content in the field after a wrapped and encoded VCF field

Description Frank Steinmetzger 2014-03-19 23:14:58 UTC

I recently exported the contacts from an android device into a single vcard file. I then created a new read-only address book based directly on that file. I noticed immediately that some contacts were missing, and others had wrong contents in some fields.

The effects were, for instance, truncated Notes fields, a messed up company name and a truncated URL field (only showed "http://", the rest was missing). Digging deeper, I found out that the problem are DOS-Style newlines, i.e. <CR><LF>, in encoded fields (lines with =65=A3= and so on instead of clear text). After I changed the file to Unix-newlines (just <LF>) using vim, all contacts and their fields were imported properly.

The URL example I mentioned was at first strange – the URL was short, not wrapped and also not encoded. But the previous line in the VCF had the postal address was wrapped and encoded that way because it contained non-ASCII characters. After I removed the address from the file, the URL field was imported properly.

This was just an attempt of a manual “contact sync” between phone and KDE until I get a local sync server running. But this has the potential of a cascading data loss on both ends of the sync, hence I marked this as critical.

Reproducible: Always

Steps to Reproduce:
1. Have a VCard file with DOS-type newlines (CRLF).
2. Have a field encoded with hex values and wrapped
Actual Results:
The field that comes after the wrapped and encoded line is not imported properly. It may be garbled, truncated or not show up at all, which may even lead to the contact being discarded by the importer.

All data was imported correctly once the linebreaks were converted to Unix-style (LF).

Expected Results:
All fields should be imported correctly regardless of file formatting.

The VCF in question was produced by the stock android contacts app. I tried looking for duplicates, but am not sure.
#320196 talks about VCF export.

Thanks for your consideration.

Comment 1 Martin Koller 2014-03-20 19:50:01 UTC

can you attach such an example vcard which fails, please.

Comment 2 Frank Steinmetzger 2014-03-21 10:57:55 UTC

Created attachment 85661 [details]
Example VCF with problematic contact information

Here is an anonymised version of the file, boiled down to some of the problematic entries. There are five entries in the file, but only three show up by default in my address book. The two last ones in the file, which originally were the doctors with the long string of opening hours in the Notes field, don't appear unless the Notes field is either removed or edited to circumvent the bug in question.
I added some information into the contacts' Notes field on where to look and what to do.


On a side-note (and not really related): I noticed that the Skype-entry was missing from a contact. I looked at my internal address book and there it was present. So I exported that contact to find out the difference. As it turns out, KDE uses the field name "X-SKYPE", whereas Android uses "X-SKYPE-USERNAME" (or maybe the other way around, I don't remember). I know it's an X- entry and so basically it's non-standard anyway, but who is "more wrong" here?

Comment 3 Frank Steinmetzger 2014-03-21 10:59:59 UTC

Created attachment 85662 [details]
Contact with garbled content in the field after a wrapped and encoded VCF field

Here's also a small screenshot showing one of the problems, just in case you cannot reproduce that particular issue.

Comment 4 Martin Koller 2014-03-26 08:32:09 UTC

Thanks for the attached vcard.
The problem is in the vcard parser and "soft line breaks" in 
Quoted-Printable encoded lines.
http://tools.ietf.org/html/rfc1521#page-18
Will have a look

Comment 5 Martin Koller 2014-04-09 10:21:12 UTC

Git commit ebc15a8af0882a05dd383deb142c3528f04d9c80 by Martin Koller.
Committed on 09/04/2014 at 10:18.
Pushed by mkoller into branch 'KDE/4.13'.

Fix handling of \r\n in quoted-printable soft-broken lines

When a vcard has quoted-printable encoded lines with a soft line-break,
the fetch for the next line did not handle the \r\n line handling
as is done in the outer loop
FIXED-IN: 4.13
REVIEW: 117097

M  +2    -0    kabc/vcardparser/testroundtrip.qrc
A  +56   -0    kabc/vcardparser/tests/vcard10.vcf
A  +52   -0    kabc/vcardparser/tests/vcard10.vcf.ref
M  +4    -0    kabc/vcardparser/vcardparser.cpp

http://commits.kde.org/kdepimlibs/ebc15a8af0882a05dd383deb142c3528f04d9c80