briar issueshttps://code.briarproject.org/groups/briar/-/issues2022-05-02T13:37:48Zhttps://code.briarproject.org/briar/briar-mailbox/-/issues/90Wait for hidden service to be reachable before showing QR code2022-05-02T13:37:48ZakwizgranWait for hidden service to be reachable before showing QR codeMailbox: PairingTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2265Replace ETA with max latency in retransmission logic2022-03-29T13:12:39ZakwizgranReplace ETA with max latency in retransmission logicThe sync protocol allows a message to be retransmitted if either the message's send time (also called expiry time in the database code) has been reached, or if the message's ETA via the currently available transport would be earlier than...The sync protocol allows a message to be retransmitted if either the message's send time (also called expiry time in the database code) has been reached, or if the message's ETA via the currently available transport would be earlier than the ETA of the previous copy. The ETA is based on the max latency of the transport.
This second (ETA) condition is met when the previous copy was sent via a higher-latency transport and a lower-latency transport is now available. But this logic has a weird edge case: immediately after sending a message via a higher-latency transport, the message can be sent via a lower-latency transport, as intended. But as the ETA of the first copy approaches, the message stops being sendable via the lower-latency transport.
This edge case is unlikely to matter when the lower latency is a tiny fraction of the higher latency (eg 30 seconds for Tor vs 28 days for removable drives). But it may become important when the lower latency is a significant fraction of the higher latency (eg 14 days for mailboxes vs 28 days for removable drives).
To remove the edge case we should store the max latency of the transport rather than the ETA, and allow the message to be retransmitted if either the send time has been reached (as now), or if the max latency of the currently available transport is less than the max latency of the transport used for the previous copy. This will require a DB migration.MailboxDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar-mailbox/-/issues/87Don't autostart mailbox when user had actively stopped it before2022-07-13T11:11:47ZTorsten GroteDon't autostart mailbox when user had actively stopped it beforeThe Stopped state can be saved in shared preferences on the Android side. When the app opens and find it was stopped, we don't start the mailbox automatically, but show its state as stopped.The Stopped state can be saved in shared preferences on the Android side. When the app opens and find it was stopped, we don't start the mailbox automatically, but show its state as stopped.Mailbox: Manage app lifecycleSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/86Show a different notification when mailbox needs linking2022-07-13T11:14:11ZTorsten GroteShow a different notification when mailbox needs linkingWe auto-start the mailbox on boot and start the lifecycle. The foreground service notification should say something like "Please finish mailbox setup" instead of mailbox running.We auto-start the mailbox on boot and start the lifecycle. The foreground service notification should say something like "Please finish mailbox setup" instead of mailbox running.Mailbox: Manage app lifecycleSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/85Allow wiping after pairing/linking has been aborted2022-07-13T11:02:42ZTorsten GroteAllow wiping after pairing/linking has been abortedWe'll autostart the foreground service and lifecycle once we see the DB. However, the DB also exists when the user went past onboarding and did not conclude initial setup. So we'll need to give a way to disable that autostart behavior wh...We'll autostart the foreground service and lifecycle once we see the DB. However, the DB also exists when the user went past onboarding and did not conclude initial setup. So we'll need to give a way to disable that autostart behavior when the mailbox isn't really used.Mailbox: Manage app lifecyclehttps://code.briarproject.org/briar/briar/-/issues/2251Show a warning on Android 4 that Briar will expire2022-01-18T15:03:58ZakwizgranShow a warning on Android 4 that Briar will expireShow a snackbar on Android 4, similar to the existing expiry snackbar for debug builds, warning the user that the app will expire on a certain date and they will need to upgrade to a newer device and create a new account.
If the explana...Show a snackbar on Android 4, similar to the existing expiry snackbar for debug builds, warning the user that the app will expire on a certain date and they will need to upgrade to a newer device and create a new account.
If the explanation is too long for a snackbar we may need to break it out into a separate onboarding dialog that's opened by tapping the snackbar.
The snackbar should be shown starting from a hardcoded activation date ~ 6 months after this ticket's released. The expiry date should be ~ 12 months after this ticket's released.
Subtask of #2221.MailboxDaniel LublinDaniel Lublin2022-01-17https://code.briarproject.org/briar/briar/-/issues/2250Refuse to start app on Android 4 beyond expiry date2022-01-18T15:03:45ZakwizgranRefuse to start app on Android 4 beyond expiry dateWhen the expiry date for Android 4 has been reached the app should refuse to start. This can use a similar mechanism to the existing ExpiredActivity for debug builds.
We might want to provide a button that deletes the user's account, if...When the expiry date for Android 4 has been reached the app should refuse to start. This can use a similar mechanism to the existing ExpiredActivity for debug builds.
We might want to provide a button that deletes the user's account, if that's easy to achieve, or just let the user know that their account will be deleted when they uninstall the app.
Subtask of #2221.MailboxDaniel LublinDaniel Lublin2022-01-17https://code.briarproject.org/briar/briar-mailbox/-/issues/81Upgrade ch.qos.logback dependency2022-02-25T14:53:57ZakwizgranUpgrade ch.qos.logback dependencyUpgrade ch.qos.logback to version 1.2.9 to fix a JNDI-related vulnerability.
https://logback.qos.ch/news.html
logback-android is unaffected as it doesn't support JNDI. How sensible.
https://github.com/tony19/logback-android/issues/230Upgrade ch.qos.logback to version 1.2.9 to fix a JNDI-related vulnerability.
https://logback.qos.ch/news.html
logback-android is unaffected as it doesn't support JNDI. How sensible.
https://github.com/tony19/logback-android/issues/230MailboxSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/79Status notification always showing same text2022-07-13T11:13:43ZSebastianStatus notification always showing same textThe status notification always shows
* **Briar Mailbox Running**
* Waiting fore messages...
I think it would maybe make sense to display something like "starting up" during startup which takes significant timeThe status notification always shows
* **Briar Mailbox Running**
* Waiting fore messages...
I think it would maybe make sense to display something like "starting up" during startup which takes significant timeMailbox: Manage app lifecycleSebastianSebastianhttps://code.briarproject.org/briar/briar/-/issues/2243Tests for OkHttp client calls2022-02-25T14:58:20ZakwizgranTests for OkHttp client callsCreate a basic unit or integration test for testing an OkHttp client call against a fake API endpoint provided by the test.
This will be the basis for testing methods that wrap OkHttp calls (eg #2183).Create a basic unit or integration test for testing an OkHttp client call against a fake API endpoint provided by the test.
This will be the basis for testing methods that wrap OkHttp calls (eg #2183).MailboxTorsten GroteTorsten Grote2022-01-17https://code.briarproject.org/briar/briar/-/issues/2242Migrate OkHttp to bramble-core2022-02-25T14:59:07ZakwizgranMigrate OkHttp to bramble-coreMailboxTorsten GroteTorsten Grote2022-01-03https://code.briarproject.org/briar/briar-mailbox/-/issues/76Wiping the mailbox can cause deadlock2022-03-30T12:50:04ZTorsten GroteWiping the mailbox can cause deadlockIt seems that there is the possibility for a deadlock when a database write is performed while the mailbox starts wiping.
Example:
```kotlin
class DeadlockTest : IntegrationTest() {
@Test
fun test() {
Thread {
...It seems that there is the possibility for a deadlock when a database write is performed while the mailbox starts wiping.
Example:
```kotlin
class DeadlockTest : IntegrationTest() {
@Test
fun test() {
Thread {
db.dropAllTablesAndClose()
}.start()
Thread {
addOwnerToken()
}.start()
}
}
```Mailbox: Manage app lifecycleSebastianSebastian2022-01-03https://code.briarproject.org/briar/briar-mailbox/-/issues/74Auto-start mailbox app on boot2022-05-24T12:05:36ZTorsten GroteAuto-start mailbox app on bootThis may not work on all versions of Android with all vendors.This may not work on all versions of Android with all vendors.Mailbox: Manage app lifecycleTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2234Abstract task for calling an API endpoint2022-06-17T13:34:16ZakwizgranAbstract task for calling an API endpointCreate an abstract task for calling an API endpoint. The task should block until the API call succeeds or permanently fails. Temporary failures should be retried automatically with backoff, and it should be possible to cancel the task be...Create an abstract task for calling an API endpoint. The task should block until the API call succeeds or permanently fails. Temporary failures should be retried automatically with backoff, and it should be possible to cancel the task between tries.Mailboxakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2230Add DB methods for tracking pending uploads2022-03-30T14:29:01ZakwizgranAdd DB methods for tracking pending uploadsAdd database methods for storing the contact ID and filename of pending mailbox uploads. It should be possible to query by contact ID (for use when a mailbox becomes reachable and we want to retry failed uploads) and to delete by contact...Add database methods for storing the contact ID and filename of pending mailbox uploads. It should be possible to query by contact ID (for use when a mailbox becomes reachable and we want to retry failed uploads) and to delete by contact ID and filename (for use when an upload succeeds).Mailbox: Manage mailbox connectionsTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2229Mailbox client superclass2022-06-20T11:20:55ZakwizgranMailbox client superclassMailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
We'll need different client implementations for our own mailbox (#2290) and contacts' mailboxes (#...Mailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
We'll need different client implementations for our own mailbox (#2290) and contacts' mailboxes (#2289), but there will be a shared interface and some shared code. This ticket covers the code shared between the client for our own mailbox and the client for a contact's mailbox.
Interface:
* The manager can create and destroy clients
* The manager can assign/deassign contacts for upload or download
* The client's upload and download workers can request connectivity checks
Implementation:
* At any given time the client may have multiple upload workers and/or a single download worker
* The client has a connectivity check method, which takes an observer as an argument
* The client stores the time of the latest successful connectivity check, a reference to the current connectivity check task, if any, and a list of observers waiting for the result of a connectivity check
When the client is destroyed:
* If a connectivity check task is running:
* Cancel the connectivity check task
* Destroy the upload workers, if any
* Destroy the download worker, if any
When the connectivity check method is called:
* Compare the current time to the time of the latest successful connectivity check
* If a connectivity check has recently succeeded:
* Notify the observer
* Else if a connectivity check task is running:
* Add the observer to the list of waiting observers
* Else:
* Add the observer to the list of waiting observers
* Start a connectivity check task
When a connectivity check task succeeds:
* Update the time of the latest successful connectivity check
* Notify any waiting observers
* Clear the list of waiting observersMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2228Mailbox client manager2022-08-16T14:20:43ZakwizgranMailbox client manager* Create a singleton mailbox client manager
* This component manages a set of mailbox clients (#2229): one client for each mailbox we know about
* The manager creates the clients when we come online and destroys them when we go offline
*...* Create a singleton mailbox client manager
* This component manages a set of mailbox clients (#2229): one client for each mailbox we know about
* The manager creates the clients when we come online and destroys them when we go offline
* The manager is responsible for assigning contacts to mailboxes for upload and/or download - so each client has a set of contacts assigned for upload and a (possibly different) set of contacts assigned for download
* These assignments can change based on pairing/unpairing a mailbox, learning which API versions our own mailbox supports, a contact being added/removed, or receiving new mailbox properties from a contact
* The assignments don't change based on connecting to a contact or disconnecting from a contact
* A contact's mailbox is "usable" if it supports an API version that we and the contact can both use, according to our hardcoded client-supported versions and the latest server-supported and client-supported versions received from the contact
* Our own mailbox is "usable" by a contact if it supports an API version that we and the contact can both use, according to our hardcoded client-supported versions, the latest server-supported versions fetched from our own mailbox, and the latest client-supported versions received from the contact
* If we have a mailbox, we always have a client for it regardless of whether our hardcoded client-supported versions are compatible with the latest server-supported versions fetched from the mailbox
* If a contact has a mailbox, we only have a client for it if it's usable
When we come online:
* For each contact:
* If the contact has a usable mailbox:
* Create a client for the contact's mailbox
* Assign the contact to the contact's mailbox for upload
* If we don't have a mailbox that's usable by the contact:
* Assign the contact to the contact's mailbox for download
* If we have our own mailbox:
* Create a client for our own mailbox
* For each contact:
* If our own mailbox is usable by the contact:
* Assign the contact to our own mailbox for download
* If the contact doesn't have a usable mailbox:
* Assign the contact to our own mailbox for upload
When we go offline:
* Destroy all clients
When we pair a mailbox:
* If we're online:
* Create a client for our own mailbox
* For each contact:
* If the contact has a usable mailbox:
* If our own mailbox is usable by the contact:
* Reassign the contact from the contact's mailbox to our own mailbox for download
* (The contact remains assigned to the contact's mailbox for upload)
* Else, if our own mailbox is usable by the contact:
* Assign the contact to our own mailbox for upload and download
When we unpair a mailbox:
* If we're online:
* For each contact:
* If the contact has a usable mailbox:
* If the contact is assigned to our own mailbox for download:
* Reassign the contact from our own mailbox to the contact's mailbox for download
* (The contact is already assigned to the contact's mailbox for upload)
* Destroy the client for our own mailbox
When a contact is added:
* Assumption: the contact has no mailbox properties yet, as the event informing us of the contact's first mailbox update is always delivered after the event informing us that the contact was added
* Wait until we receive the contact's first mailbox update before deciding how to assign the contact for upload and download
When a contact is removed:
* If we're online:
* If we have a client for the contact's mailbox:
* Destroy the client for the contact's mailbox
* If the contact is assigned to our own mailbox for download:
* Deassign the contact from our own mailbox for download
* If the contact is assigned to our own mailbox for upload:
* Deassign the contact from our own mailbox for upload
When we receive a mailbox update from a contact:
* If we're online:
* If the contact didn't previously have a usable mailbox and now has one:
* Create a client for the contact's mailbox
* If we have a mailbox that's usable by the contact:
* Reassign the contact from our own mailbox to the contact's mailbox for upload
* (The contact remains assigned to our own mailbox for download)
* Else:
* Assign the contact to the contact's mailbox for upload and download
* Else if the contact previously had a usable mailbox and no longer has one:
* If we have a mailbox that's usable by the contact:
* Reassign the contact from the contact's mailbox to our own mailbox for upload
* (The contact remains assigned to our own mailbox for download)
* Destroy the client for the contact's mailbox
* Else if the contact previously had a usable mailbox and now has a different mailbox that's also usable:
* Destroy the client for the contact's mailbox
* Create a new client for the contact's mailbox
* Assign the contact to the contact's mailbox for upload
* If we don't have a mailbox that's usable by the contact:
* Assign the contact to the contact's mailbox for downloadMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2226Error handling for mailbox uploads2022-04-19T16:11:45ZakwizgranError handling for mailbox uploadsWhen communicating via mailboxes, the max latency and thus the retransmission interval are long, so we need to be careful about any circumstances that could cause messages to be lost.
On the sender side, if an error (such as an IO error...When communicating via mailboxes, the max latency and thus the retransmission interval are long, so we need to be careful about any circumstances that could cause messages to be lost.
On the sender side, if an error (such as an IO error, app shutdown, app crash or device crash) occurs while we're writing messages and acks to a file, we need to ensure that those messages and acks can be sent again after recovering from the error.
We can do this by generating a unique ID for the sync session and recording the IDs of any messages sent or acked in that session. This state can be deleted when the session completes successfully. At the next startup, if we find this session state in the DB we know that the session didn't complete successfully, so we mark the messages and acks as unsent.
We also need to handle errors that occur after the file has been created but before it's been uploaded. We can do this by storing the contact ID and filename in the DB before starting the session and removing them when the upload completes successfully (#2230). Next time we come online, if we find any upload state in the DB we know that the corresponding uploads didn't complete successfully, so we queue the files for upload. We should use the DB for this, rather storing the files in a separate upload directory per contact, to avoid leaking metadata to the filesystem about which uploads are destined for which contacts.
We should store the contact ID and filename before starting the sync session, so that there's no gap where the DB doesn't contain a record of the incomplete session/upload. If a crash happens during the session we may end up marking the messages and acks in the session as unsent as well as queueing the (possibly incomplete) file for upload. This is acceptable - the receiver should be able to handle the (possibly incomplete) file and another file containing the same messages and acks. Similarly, if the upload completes successfully but a crash happens before we remove the contact ID and filename from the DB, it's acceptable to upload the file again at the next startup, as the receiver should be able to handle the duplicate file.
It's still possible for the file to be lost after a successful upload, but losses beyond that point are handled by different mechanisms (#2191, #2192, #2225).
Depends on #2230.Mailbox: Manage mailbox connectionsakwizgranakwizgran2022-01-03https://code.briarproject.org/briar/briar/-/issues/2225Error handling for mailbox downloads2021-12-10T14:45:35ZakwizgranError handling for mailbox downloadsWhen communicating via mailboxes, the max latency and thus the retransmission interval are very long, so we need to be careful about any circumstances that could cause messages to be lost.
On the receiver side, if an error (such as an I...When communicating via mailboxes, the max latency and thus the retransmission interval are very long, so we need to be careful about any circumstances that could cause messages to be lost.
On the receiver side, if an error (such as an IO error, app shutdown, app crash or device crash) occurs while we're reading messages from a file, we need to ensure that the file can be read again after recovering from the error. Reading the file twice isn't possible with the current protocol stack because the pseudo-random tag at the start of the file is recognised on the first read and can't be recognised again.
To fix this we should divide the process of recognising a tag into two steps. The first step looks up the tag and returns the keys needed for authenticating and decrypting the stream header. The second step marks the tag as recognised and updates the reordering window.
When processing a file downloaded from a mailbox, we should defer the second step until the file has been completely processed.Mailboxhttps://code.briarproject.org/briar/briar/-/issues/2221Retire support for Android 42023-06-19T14:03:17ZakwizgranRetire support for Android 4We'll eventually need to drop support for Android 4 in order to be able to upgrade OkHttp (#2156). I don't think we should just raise our minSdkVersion and leave Android 4 users running an out-of-date version of Briar indefinitely. Inste...We'll eventually need to drop support for Android 4 in order to be able to upgrade OkHttp (#2156). I don't think we should just raise our minSdkVersion and leave Android 4 users running an out-of-date version of Briar indefinitely. Instead, we should set an expiry date and warn users that the app will stop working at that date, like we do with debug builds.
We should define a retirement period that ends at the expiry date, and release the following changes before the start of the retirement period, allowing enough time for most users to upgrade before the period starts:
* At the start of the retirement period, show a warning on Android 4 that Briar will stop working at the expiry date
* Refuse to start the app on Android 4 beyond the expiry date
The changes can be based on the existing code for expiring debug builds.
When the retirement period ends we can raise our min API level to 21 and upgrade OkHttp (and perhaps the emoji library, which also requires API 21 for the latest version, unless we've already resolved #2212 by switching to AppCompat for emoji).
If we release the changes above by the end of 2021, allow six months for users to upgrade before the retirement period starts, and allow another six months for the retirement period, then we can drop support for Android 4 at the end of 2022. (We can do everything faster than that if necessary, but I don't see any urgency.)
*Update:*
With !1577 and !1578 merged to master, the warning will show up on Android 4 on 2022-07-31. Briar will refuse to start on Android 4 on 2023-01-31.MailboxTorsten GroteTorsten Grote2023-01-31