Bug 13974 - Kaddressbook (export to vcf) incorrectly splits long lines
Summary: Kaddressbook (export to vcf) incorrectly splits long lines
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: KDE maintainers
QA Contact:
URL:
Whiteboard: MGA5TOO
Keywords: UPSTREAM
Depends on:
Blocks:
 
Reported: 2014-08-22 22:22 CEST by Juergen Harms
Modified: 2017-03-14 23:46 CET (History)
2 users (show)

See Also:
Source RPM: kdepim4-4.11.4-2.mga4.src.rpm
CVE:
Status comment:


Attachments
Addressbook item generated by EXPORT to a vCard file (327 bytes, text/plain)
2014-08-22 22:25 CEST, Juergen Harms
Details
Reference to RFC standardisation re line splitting (965 bytes, text/plain)
2014-08-22 22:40 CEST, Juergen Harms
Details

Description Juergen Harms 2014-08-22 22:22:15 CEST
Description of problem:

Kaddressbook allows to export addressbook data to files with vcard format (.vcf suffix). When it generates long lines, it does not correctly split such lines as specified by the standards:
  - according to the standard, it should do the split at a white-space. replacing the white-space by a CR+white-space sequence;
  - but it does not do such a replacement, rather it INSERTS a CR+white-space sequence at apparently arbitrary places in the data line

In the attached example, the UTF sequence representing the ü character
    =C3=A9
has been replaced by
    =C3<CR> =A9

This evidently will create serious problems in the programm that uses the .vcf file for input - it will upset the UTF encoding mechanism (or simply insert arbitrary white spaces).

I have only observed this problem in lines that contain UTF-encoded strings (all my other data lines are short and not subject to splitting) - possibly, but not likely, the problem is limited to encoded strings.


Version-Release number of selected component (if applicable):
kaddressbook-4.13.97-1.mga5


How reproducible:
always (if the addressbook contains long lines that need to be splitting)


Steps to Reproduce:

1. Open kaddressbook on an address book that contains some sufficiently lines

2. Do File -> Export -> Export vCard 2.1
   ( my details were "all Contacts", standard options as proposed, "Export to One file")

3. Check the contents of the so generated file


Kaddressbook is an ideal tool to create and manage address data, particularly where format conversion is necessary for synchronising between Linux and Android platforms - this bug is annoying (and difficult to discern as the origin for synchronisation failure).

I join attachments with an example of a vcard item that has been incorrectly split, and references to documents that specify the line splitting procedure.


Reproducible: 

Steps to Reproduce:
Comment 1 Juergen Harms 2014-08-22 22:25:53 CEST
Created attachment 5361 [details]
Addressbook item generated by EXPORT to a vCard file
Comment 2 Juergen Harms 2014-08-22 22:40:20 CEST
Created attachment 5362 [details]
Reference to RFC standardisation re line splitting
Comment 3 David Walser 2014-08-25 18:58:03 CEST
Please report this upstream to KDE if you haven't yet.

CC: (none) => balcaen.john, mageia
Assignee: bugsquad => lmenut

Comment 4 Juergen Harms 2014-08-25 21:56:25 CEST
Created https://bugs.kde.org/show_bug.cgi?id=338556
Comment 5 Samuel Verschelde 2015-05-19 20:29:44 CEST
Upstream bug still open. I suppose this bug is still present in Mageia 5.

Keywords: (none) => UPSTREAM
Whiteboard: (none) => MGA5TOO

Comment 6 Juergen Harms 2015-05-19 22:56:23 CEST
Yes, the bug still exists - not only for vCard 2.1, but also for the most recent format, vCard 4.0  (I did not try for 3.0)
Luc Menut 2016-08-25 16:47:34 CEST

Assignee: lmenut => kde

Comment 7 Nicolas Lécureuil 2017-03-14 23:46:49 CET
closing like the upstream bugreport.

Please reopen the upstream bugreport if this bug is still valid.

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.