this temporarily disconnects all accounts until the user opens the app again.
essentially this akin to an 'Exit' button
Users previously had the option to 'disable' accounts but this provides a
faster way to "free up resources" until the next time the app is opened.
Dino (and this is probably correct behaviour) expects a fingerprint in the
content-add message. (and not a stub transport as indicated in the examples).
however if we start to include them we also need to encrypt and verify them
properly.
Movim does not like slashes (/) in jingle session ids.
When proposing a session called 'wBKabx1kRIfkgNxAShip/w' Movim will
accept (proceed) a session called 'wBKabx1kRIfkgNxAShip' which the initiator of course does not know about. (Conversations will get stuck at ringing/discovering devices)
This is likely because a click on 'Reply' (accept call) in Movim opens upa pop up window where both the full jid as well as the session id are transmitted as part of the URL.
(Full jids can contain more than on slash btw)
Movim has trailing whitespace around some of their media attributes
<source ssrc="1892824964" xmlns="urn:xmpp:jingle:apps:rtp:ssma:0">
<parameter name="msid" value="{a98821d7-b298-4130-925a-ff6c510734c0} {f45dfc5c-2fa7-42b4-85e5-935e786b3feb} " xmlns="urn:xmpp:jingle:apps:rtp:ssma:0"/>
<parameter name="cname" value="{63b1042b-5cb5-4411-b2a5-bdff92ae45be}" xmlns="urn:xmpp:jingle:apps:rtp:ssma:0"/>
</source>
our WebRTC doesn’t like that. We trim the value even though this seems to be a Movim bug.
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.
kosyak