Note: A message with a <subject/> and a <body/> or a <subject/> and a
<thread/> is a legitimate message, but it SHALL NOT be interpreted as a
subject change.
as per https://letsencrypt.org/2023/07/10/cross-sign-expiration.html
Letsencrypt is dropping support for Android <= 7 by removing cross signing.
to keep supporting older Android versions we need to bundle the root cert
ourselves. (Firefox for example does this too)
The KeyStore file is in BKS-V1 format. A good tools to edit the file is
https://keystore-explorer.org/
To keep the attack and bug surface as low as possible we only run the check
against the bundled keystore on Android <= 7
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.
fixes#38
exposing bookmarks like this was a mistake that Conversations 3 will not repeat
in the meantime we rename this to group chats which might be more broadly understood
when the phone is silent only the first ~three tones are played when
attempting to play out the tone over STREAM_VOICE_CALL
it’s unclear exactly why this is the case (in the past we went back and forth
between STREAM_VOICE_CALL and STREAM_MUSIC) exactly to fix issues around silent
mode.
Apparently we failed to test this past three sounds.
This commit changes the stream back to music - but not generally as this was in
the past - but only for when the phone is on silent
For a long time Quicksy had a privacy policy written by myself that explains
in plain English what data we store and how we use it.
https://quicksy.im/#privacy
Google doesn’t like that and prefers that we use some bullshit template that
is extremely vague, doesn’t explain anything and gives us permission to do
basically everything. (At least I think so. I don’t understand the text I
copy pasted)
Apparantly the text in the app is important as well (BARD didn’t explain
that very well when it reviewed our app) therfor we need a static text (not
allow translations)
Furthermore the data safety section on Google Play now claims we store the
users address book even though we don’t actually. But who cares; nobody reads
this and we just do this to make the machine happy. Cool!
the 2.11.0 release removed support for enabling sm:2
unfortunatly sm:2 was still detected as "server supports stream managment"
down the line leading to resend loops.
fixes#4426
