since `account.ceb` might have previously been created by a different application
(for example f-droid and user is on play now) or copied over via the file
manager Conversations might not have permission to write over an existing file.
we include the date so we always get a new file
fixes#105
This switches the SQL based backup format to something JSON based.
The SQL based format has always been prone to SQL injections that, for example, could delete other messages or preexisting accounts in the app. This hasn’t been a concern this far because why would anyone purposely try to restore a faulty backup? However the argument has been made that a user can be socially engineered to restore an exploited backup file.
Before version 2.12.8 a third party app could even trigger the restore process, leaving the backup password entry dialog the only hurdle.
On top of that it has been demonstrated that a backup file can be crafted in a way that puts preexisting credentials into a 'pending' message to an attacker ultimately leading to that information being leaked.
While destorying information has always been deemed an acceptable risk, leaking information is one step too far.
Starting with Conversations 2.12.9 Conversations will no longer be able to read v1 backup files. This means if you are restoring on a new device and you have a v1 backup file you must first install Conversations <= 2.12.8, restore the backup, and then upgrade to Conversations >= 2.12.9.
ceb2txt¹ has support for v2 backup files. Conceivably ceb2txt could be extended to convert between v1 and v2 file formats. (ceb2txt already recreates the database from v1 files; It is relatively straight forward to create v2 files from that database. Pull requests welcome.)
¹: https://github.com/iNPUTmice/ceb2txt/
On registration the app can pass in a 'Messenger' to get a direct response
instead of having to somehow wait for the broadcast receiver to fire.
The app name can be passed as a pending intent which allows the distributor
to validate the sender.
