GNOME Bugzilla – Bug 710823
libofx can supply broken UTF-8 for account id, breaks gnucash file
Last modified: 2018-06-29 23:20:23 UTC
Due to a buffer of hardcoded length, it might happen that libofx will cut the ACCTID attribute contents in the middle of a multi-byte character and then supply such a broken string to GnuCash. If the user then chooses an account for it, the passed string will get saved into the .gnucash file and it won't be possible to load it anymore (without any indication telling what was actually wrong and when).
Two questions: Do you have an (artificial) example file that demonstrates this problem? Also, is this still a problem in gnucash-2.5.6 or only in 2.4.x? Also, can you check with the latest libofx (0.9.9) whether this is still a problem? On the other hand, I fully agree the fixed buffers of libofx are a severe problem for issues similar to the one described here. There haven't been many changes in libofx that might have fixed this issue, but maybe in gnucash. Also, the ACCTID attribute to my knowledge isn't used in gnucash, is it?
Created attachment 258183 [details] A minimal OFX demonstrating broken UTF-8 in ACCTID This file itself doesn't have any non-conforming UTF-8 sequences but libofx generates illegal output with it, breaking gnucash file in the end.
ACCTID is used to match the source account, and it's also stored in the gnucash file itself after one selects the corresponding account during the import. I've tried ofxdump from libofx 0.9.9 and it behaves exactly like earlier versions: outputs broken utf-8 sequences to console; I haven't tried recompiling GnuCash against it but it shouldn't make any difference I believe. I wonder what happens if the ofx file itself would have garbled characters inside. I'm afraid GnuCash will happily eat it, and will write a damaged xml file during saving, so sanitising just before serialisation looks really necessary, who knows what other failure scenarios are not covered by the existing checks.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report. r23598 prevents the bad UTF-8 from being written to the XML file, r23599 makes sure that every string coming in from libofx is cleaned up. Backporting proved infeasible.
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=710823. Please update any external references or bookmarks.