briar issueshttps://code.briarproject.org/groups/briar/-/issues2022-01-18T15:03:45Zhttps://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-31https://code.briarproject.org/briar/briar-mailbox/-/issues/72Database has duplicate contacts in Integration tests2022-02-25T14:52:22ZSebastianDatabase has duplicate contacts in Integration testsThe db doesn't check if a contact with the same id already exists when adding a contact. The way we're using this in integration tests at the moment, it leads to duplicate contacts in the db. Possible solutions are cleaning up properly i...The db doesn't check if a contact with the same id already exists when adding a contact. The way we're using this in integration tests at the moment, it leads to duplicate contacts in the db. Possible solutions are cleaning up properly in a `@AfterEach`, clearing the database, or checking for duplicates during `addContact()`.MailboxTorsten GroteTorsten Grote2021-11-29https://code.briarproject.org/briar/briar-mailbox/-/issues/71Check Java code style using CI2022-02-25T14:55:02ZSebastianCheck Java code style using CIMailboxSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/70API endpoint for checking mailbox status2022-02-25T14:55:02ZakwizgranAPI endpoint for checking mailbox statusImplement an API endpoint at `/status` that just returns 200 OK. This can replace the existing endpoint at `/`.Implement an API endpoint at `/status` that just returns 200 OK. This can replace the existing endpoint at `/`.MailboxSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/69Test everything is working on API 162022-12-15T13:02:58ZSebastianTest everything is working on API 16There's also other API levels like 17/18 that could cause issues due to different Java version. We need to make sure to test with Java 6.There's also other API levels like 17/18 that could cause issues due to different Java version. We need to make sure to test with Java 6.MailboxSebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/68Try to upgrade h22022-02-25T14:51:53ZSebastianTry to upgrade h2MailboxSebastianSebastian2021-12-13https://code.briarproject.org/briar/briar-mailbox/-/issues/67Create read{} and write{} shortcut methods for database transactions2022-02-25T14:55:02ZSebastianCreate read{} and write{} shortcut methods for database transactionsMailboxSebastianSebastian