briar issueshttps://code.briarproject.org/groups/briar/-/issues2023-01-19T13:02:32Zhttps://code.briarproject.org/briar/briar/-/issues/2360Mailbox Problem notification causes crash on Android 42023-01-19T13:02:32ZTorsten GroteMailbox Problem notification causes crash on Android 4When Briar can't connect to the mailbox for some time, we show a notification, so the user is aware of this problem.
On Android 4, this needs a special icon. Vector drawables are not supported.When Briar can't connect to the mailbox for some time, we show a notification, so the user is aware of this problem.
On Android 4, this needs a special icon. Vector drawables are not supported.Mailbox: Status UI for Briar appIvanaIvanahttps://code.briarproject.org/briar/briar-desktop/-/issues/374Date in message cards not localized properly2022-09-14T07:10:38ZSebastianDate in message cards not localized properlyThe date formatted below the message texts in the chat history (and also in the date/time for last message in contact list) is not localized for the language selected in the settings, instead the system's default locale is being used.
I...The date formatted below the message texts in the chat history (and also in the date/time for last message in contact list) is not localized for the language selected in the settings, instead the system's default locale is being used.
I think the problem is in `TimeUtils.kt` where we need to apply `localizedBy(Locale)` to the formatter.Mikolai GütschowMikolai Gütschowhttps://code.briarproject.org/briar/briar-desktop/-/issues/373TestLanTcpPlugin that supports BRP2022-09-24T21:38:08ZSebastianTestLanTcpPlugin that supports BRPWhen running two or more connected instances of the application for interactive testing, it is a bit annoying that it can take very long for the contacts to be actually connected and able to exchange messages. I had thought enabling the ...When running two or more connected instances of the application for interactive testing, it is a bit annoying that it can take very long for the contacts to be actually connected and able to exchange messages. I had thought enabling the LAN plugin would help, but since the LAN plugin does not support BRP, adding contacts at a distance does not work via that plugin. Now I had the idea that we might add a new plugin TestLanTcpPlugin that allows rendezvous via LAN and would only be used in test setups such as this.
I'm wondering how much effort this would be.
I can see `supportsRendezvous()` probably needs to return `true` and then `createRendezvousEndpoint()` would need to be implemented. Not sure how much of `TorPlugin`s implement could be reused there. @akwizgran do you an assessment how much trouble this all would be?https://code.briarproject.org/briar/briar/-/issues/2359Reduce traffic activity by sending BSP VERSIONS Records less often2023-02-07T15:54:53ZThomasReduce traffic activity by sending BSP VERSIONS Records less oftenI am working on a PoC for a LoRa Transport. Even with all messages and acknowledges being exchanged, I see Traffic every X seconds. From a BSP perspective this is being sent: `00 04 00 01 00`
Its basically saying: This is protocol versio...I am working on a PoC for a LoRa Transport. Even with all messages and acknowledges being exchanged, I see Traffic every X seconds. From a BSP perspective this is being sent: `00 04 00 01 00`
Its basically saying: This is protocol version 0, I am supporting only protocol version 0.
I get this same message every X seconds. Yes, the traffic is encrypted (randomized), still I think this makes the traffic easier to categorize using timing-attacks and it takes bandwidth.
I argue this should only be sent:
- during contact exchange
- if it changed and the other contact hasn't acknowledged the change or sent BSP Frames themselves with the new version
Ideally the old Version is still valid and the change doesn't have to be propagated by creating new Streams - the client can transmit it once before it sends another BSP Packet.
This mainly affects Simplex Connections (https://code.briarproject.org/briar/briar/-/blob/master/bramble-core/src/main/java/org/briarproject/bramble/sync/SimplexOutgoingSession.java#L95). It could also be changes on Duplex Connections (https://code.briarproject.org/briar/briar/-/blob/master/bramble-core/src/main/java/org/briarproject/bramble/sync/DuplexOutgoingSession.java#L136) but I don't know the real-life impact there since it won't be regularly re-sent on established connections.
My workaround for the PoC will be to just comment-out this specific line of code.https://code.briarproject.org/briar/briar/-/issues/2358Rotating screen while "Your Mailbox has been unlinked" dialogue box is displ...2023-01-19T13:04:56ZIvanaRotating screen while "Your Mailbox has been unlinked" dialogue box is displayed causes blank screenSteps to reproduce:
I used the Xiaomi MI11 Lite 5G device, and the Pixel 2 and was able to reproduce on both
- I link the Briar app on either device with a mailbox on another device
- Then I unlink the mailbox using the mailbox device...Steps to reproduce:
I used the Xiaomi MI11 Lite 5G device, and the Pixel 2 and was able to reproduce on both
- I link the Briar app on either device with a mailbox on another device
- Then I unlink the mailbox using the mailbox device, so that the Briar app is unable to reach it.
- Then I tap Unlink on the bottom of the mailbox status screen in the Briar app
- unlinking seems to run OK, and there is the progress wheel, and after that there is the dialogue box "Your mailbox has been unlinked.. Next time you have access to yoru ailbox device, please open the Mailbox app and tap the Unlink button to complete the process..." The only option a user has on this dialogue is to tap Got it.
- But if the screen is rotate at this point, BEFORE taping the Got it, then what we see if this:
![20220825_122023](/uploads/598074b5521d980a4cc7d44ff149a39a/20220825_122023.jpg)
Having problems wiht Android Studio which currently get frozen if i try to take a screenshot - so here's the photo of the screen taken with another phone.
If I tap the Back arrow in the top left corner of this blankscreen, then what I see is the mailbox status screen again.... Whereas the unlinking has been already done, so this screen should not be disaplyed again.
If I go back from that screen, I see Briar settings screen, and if I go into mailbox option, I see that the mailbox linking can be done again.
This happens both with do-not-keep-acitivities on and offIvanaIvanahttps://code.briarproject.org/briar/briar-mailbox/-/issues/159Stuck on init fragment when navigating away quickly during start2023-01-19T13:07:29ZSebastianStuck on init fragment when navigating away quickly during startSteps to reproduce:
* Open app, before the first screen appears, navigate away using the (O) button, back to the home screen,
* wait a few seconds,
* go back to app, doesn't matter if via app launcher or recent apps list
You should be s...Steps to reproduce:
* Open app, before the first screen appears, navigate away using the (O) button, back to the home screen,
* wait a few seconds,
* go back to app, doesn't matter if via app launcher or recent apps list
You should be stuck at the init fragment that shows the green mailbox logo and "Briar Mailbox"SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/372Tooltip does not work on all icon buttons (hidpi issue?)2022-08-18T21:00:24ZSebastianTooltip does not work on all icon buttons (hidpi issue?)While testing !221 I noticed that on my hidpi Linux device, the tooltips for the icon buttons don't work there, while they do work on a regular machine. Maybe it has to do with the high density resolution, no idea, but that is the only t...While testing !221 I noticed that on my hidpi Linux device, the tooltips for the icon buttons don't work there, while they do work on a regular machine. Maybe it has to do with the high density resolution, no idea, but that is the only thing I know is different on that machine.https://code.briarproject.org/briar/briar/-/issues/2357Upload APK signatures and checksums during build2022-08-17T12:15:10ZakwizgranUpload APK signatures and checksums during buildakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2356Investigate flaky unit tests2022-08-17T11:54:27ZakwizgranInvestigate flaky unit testsBefore !1697 was merged, we saw a couple of pipelines failing in the same place:
https://code.briarproject.org/briar/briar/-/jobs/21288
https://code.briarproject.org/briar/briar/-/jobs/21301
The same tests failed after merging to mast...Before !1697 was merged, we saw a couple of pipelines failing in the same place:
https://code.briarproject.org/briar/briar/-/jobs/21288
https://code.briarproject.org/briar/briar/-/jobs/21301
The same tests failed after merging to master:
https://code.briarproject.org/briar/briar/-/jobs/21335
Somehow two unit tests seem to have become flaky:
https://code.briarproject.org/briar/briar/-/blob/bcc7a4b93b28b0e252082bdcf4eb6175fd2d66d3/bramble-core/src/test/java/org/briarproject/bramble/db/DatabaseComponentImplTest.java#L297
https://code.briarproject.org/briar/briar/-/blob/bcc7a4b93b28b0e252082bdcf4eb6175fd2d66d3/bramble-core/src/test/java/org/briarproject/bramble/db/DatabaseComponentImplTest.java#L1900akwizgranakwizgranhttps://code.briarproject.org/briar/briar-desktop/-/issues/371Use constants as (screen) padding values throughout the code base2022-08-17T07:59:49ZMikolai GütschowUse constants as (screen) padding values throughout the code basesimilar to "dimens.xml" for Android
See [here](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/221#note_69460)similar to "dimens.xml" for Android
See [here](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/221#note_69460)https://code.briarproject.org/briar/briar-desktop/-/issues/370Accessibility for chat history2022-08-28T19:18:41ZSebastianAccessibility for chat historyI tried out using VoiceOver on the chat history and noticed that it reads out message text and date/time.
It does not read out whether a message is delivered or not.
It also does not read out the fact that a message is one own's messag...I tried out using VoiceOver on the chat history and noticed that it reads out message text and date/time.
It does not read out whether a message is delivered or not.
It also does not read out the fact that a message is one own's message or the contact's message.
I think both things should probably be added.Mikolai GütschowMikolai Gütschowhttps://code.briarproject.org/briar/briar/-/issues/2355Upgrade to Tor 0.4.5.142022-09-05T12:25:37ZakwizgranUpgrade to Tor 0.4.5.14https://gitlab.torproject.org/tpo/core/tor/-/raw/release-0.4.5/ReleaseNoteshttps://gitlab.torproject.org/tpo/core/tor/-/raw/release-0.4.5/ReleaseNotesAndroid 1.4Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar-mailbox/-/issues/158CLI does not respond to Ctrl+C any longer2022-11-30T08:03:07ZSebastianCLI does not respond to Ctrl+C any longerCtrl+C is supposed to shutdown the CLI app and we also want to shutdown the lifecycle cleanly before exiting. To achieve this, we register a shutdown hook before starting the lifecycle which gets called in response to the signal.
Note: ...Ctrl+C is supposed to shutdown the CLI app and we also want to shutdown the lifecycle cleanly before exiting. To achieve this, we register a shutdown hook before starting the lifecycle which gets called in response to the signal.
Note: it looks like the shutdown hooks do not (and did never) run when the mailbox cli is run using gradle, i.e. `./gradlew run --args=-v` won't trigger the shutdown hooks when a shutdown signal is received. So we need to build the jar using `./gradlew x86LinuxJar` and run it using `java -jar mailbox-cli/build/libs/mailbox-cli-linux-x86_64.jar` to observe if things are working or not.
Currently, pressing Ctrl+C leads to a deadlock. This is what is happening:
* Ctrl+C initiates a shutdown of the VM
* The shutdown hooks get started, including the one we registered before starting the lifecycle
* our shutdown hook calls `LifecycleManager#stopServices()`
* `stopServices()` calls `exitProcess(0)` in its finally block
* This leads to deadlock.
The cause for the deadlock is described in the documentation of [Runtime#exit](https://docs.oracle.com/javase/7/docs/api/java/lang/Runtime.html#exit(int)):
> Terminates the currently running Java virtual machine by initiating its shutdown sequence. [...]
>
> The virtual machine's shutdown sequence consists of two phases. In the first phase all registered shutdown hooks, if any, are started in some unspecified order and allowed to run concurrently until they finish. In the second phase all uninvoked finalizers are run if finalization-on-exit has been enabled. Once this is done the virtual machine halts.
>
> If this method is invoked after the virtual machine has begun its shutdown sequence then if shutdown hooks are being run this method will block indefinitely. If shutdown hooks have already been run and on-exit finalization has been enabled then this method halts the virtual machine with the given status code if the status is nonzero; otherwise, it blocks indefinitely.
The important part being:
> If this method is invoked after the virtual machine has begun its shutdown sequence then if shutdown hooks are being run this method will block indefinitely
And that is precisely what we are doing. Actually we're calling `Runtime.exit()` from within a shutdown hook which matches the conditions described above and causes indefinite blocking.
This got introduced with !99 and [we discussed this here](https://code.briarproject.org/briar/briar-mailbox/-/merge_requests/99#note_68524). I have the feeling it might not be the best idea after all to let the lifecycle manager exit the VM. Maybe it's better to let the individual starting points that use the lifecycle be responsible for that, i.e. the CLI, the Android app and the unit tests should handle that in some way that makes sense and works nicely in the respective scenario. I think a call to `Runtime.exit()` within the lifecycle manager is just a too drastic measure which is difficult to make work in all scenarios and we're making our life a lot harder by trying to make the starting points work around the fact that the lifecycle manager is calling exit() itself.
If we use the mailbox in integration tests, this will be a problem too, because the test frameworks cannot gracefully handle components that exit the VM either. I recently added an option to disable this exiting behavior on the branch for integration tests with briar: https://code.briarproject.org/briar/briar-mailbox/-/commit/a488bb20ef18784214ed903a3535db280a950830 and if I pass `false` as `exitAfterStopping` in the CLI the exiting using CTRL+C also works as expected again. So maybe that is a middle ground where we can have the exiting in the lifecycle where we wanted it to be as a result of the discussion where it should be for the Android app, and yet still be able to disable this for both the CLI and integration tests.SebastianSebastianhttps://code.briarproject.org/briar/briar-mailbox/-/issues/157Tapping the Unlink (briar side) and Stop (mailbox side) at the same time - ma...2023-02-21T20:12:48ZIvanaTapping the Unlink (briar side) and Stop (mailbox side) at the same time - mailbox stuck in StoppingMailbox**Steps to reproduce**
- On two devices that are linked (I used Nokia 3.2 Android 10 for Briar and HTC E9 Android 5 for Mailbox) I open the mailbox status screen on each device.
- Then on briar I tap the unlink button and immediatley a...**Steps to reproduce**
- On two devices that are linked (I used Nokia 3.2 Android 10 for Briar and HTC E9 Android 5 for Mailbox) I open the mailbox status screen on each device.
- Then on briar I tap the unlink button and immediatley after (almost at the same time) I tap the Stop button on the mailbox side.
**Expected results**
This is a bit of a corner case, and not very likely to happen, but in case it does, the expected result should be graceful handling of this situation - either the wiping complete screen should be seen on the mailbox side, or mailbox stopped.
**Actual result**
Mailbox gets stuck in the Stopping Mailbox state[unlink_and_stop_button_together.txt](/uploads/01bc05f817f642e8fb97117654f106bb/unlink_and_stop_button_together.txt)
![Screenshot_20220810_130437](/uploads/c315d676d6aa79c1cde95cb8ba3f9255/Screenshot_20220810_130437.png)IvanaIvanahttps://code.briarproject.org/briar/briar-mailbox/-/issues/156WipeComplete screen shows same message for both local and remote wiping2023-02-08T17:17:54ZSebastianWipeComplete screen shows same message for both local and remote wipingIn either case, the message says: 'Next time you have access to your Briar device, please open the Mailbox settings screen in the Briar app, then tap the \"Unlink\" button to complete the process'. That could potentially be confusing for...In either case, the message says: 'Next time you have access to your Briar device, please open the Mailbox settings screen in the Briar app, then tap the \"Unlink\" button to complete the process'. That could potentially be confusing for the user in the case of a remote wipe as this step is no longer possible and actually already happened.
Test instructions: with Briar and Mailbox successfully linked, wipe once locally and once remotely from Briar (link the apps again after the first wiping). Check that when wiping locally (i.e. from the Mailbox app's status screen), the confirmation screen shows an explainer text to wipe on Briar later on too. When wiping remotely (from Briar's mailbox status screen) check that the confirmation screen on the Mailbox app does not contain the explainer.Mailbox: UnpairingIvanaIvanahttps://code.briarproject.org/briar/briar-mailbox/-/issues/155Remote wiping when Mailbox screen asleep => Wiping Complete screen presents t...2023-01-19T13:07:59ZIvanaRemote wiping when Mailbox screen asleep => Wiping Complete screen presents twice**Steps to reproduce**
Briar device: Samsung A01S Core, Android 10
Mailbox device: Motorola E2, Android 6
do not keep activities = On for both devices, but results are the same iwth do not keep activities = OFF on mailbox
- when Briar...**Steps to reproduce**
Briar device: Samsung A01S Core, Android 10
Mailbox device: Motorola E2, Android 6
do not keep activities = On for both devices, but results are the same iwth do not keep activities = OFF on mailbox
- when Briar and Mailbox are connected, wait for the Mailbox device screen to be askeep (ie to turn black)
- then tap Unlink on Briar side
- When the process finishes, and the Briar settings screen presents again, tap the Mailbox device screen to activate it
**Expected results:**
- Wiping complete screen presents on mailbox device.
- On taping the Finish button, the mailbox exits.
**Actual results**
- Wiping complete screen does present, but when the user taps the Finish button, instead of the mailbox app exiting, the same screen presents again, via a couple of other briefly visible screens. See video attached.
- The video screen is black initially because I started recording via Android Studio when I tapped Unlink on the Briar screen. The mailbox device screen was asleep at that time, and when the wiping finishes on Briar side, I tap the mailbox device to reactivate that screen...
![device-2022-08-09-124536](/uploads/2ad5c1e1aaf6460ddb4554b62e27ad94/device-2022-08-09-124536.mp4)https://code.briarproject.org/briar/briar/-/issues/2354After remote wiping - add a small confirmation message that wiping was succes...2022-08-18T09:42:16ZIvanaAfter remote wiping - add a small confirmation message that wiping was successfulAfter remote wiping of the mailbox app, there is no any kind of confirmation message to the user that the wiping was successful.
After discussion in the MM testing channel today, it was concluded that a message may be nice, and maybe t...After remote wiping of the mailbox app, there is no any kind of confirmation message to the user that the wiping was successful.
After discussion in the MM testing channel today, it was concluded that a message may be nice, and maybe the toast message would be the easiest to do.
Reporting this ticket to keep track of this issueMailbox: Unpairingakwizgranakwizgranhttps://code.briarproject.org/briar/briar-mailbox/-/issues/154Last connection on the mailbox status screen not updating as minutes pass by2023-08-28T16:00:11ZIvanaLast connection on the mailbox status screen not updating as minutes pass bySteps to reproduce
- do not keep activities = ON
- on any two device where Briar and Mailbox are linked check the values for last connection.
- this can be after initial linking, or after the screens have fallen asleep and been woken ...Steps to reproduce
- do not keep activities = ON
- on any two device where Briar and Mailbox are linked check the values for last connection.
- this can be after initial linking, or after the screens have fallen asleep and been woken up, or after the link Check Connection on Briar is tapped
- What happens is that initially both values are set to 'now' and the Briar device then updates its 'last connection' value as minutes roll by, but the mailbox device does not.
- Here are the photos to illustrate
- Whilst I was typing this and taking the photos, the difference has become 7 mins...
- after the mailbox screen falls asleep and is reactivate by the user - the value is reset to the correct value - ie the same as on the Briar app
- Andanother microscoping inconsistency with briar screens - on mailbox Last connection says 1 min. ago, on Briar it says 1 min ago. Ie in one place we have a full stop after the short 'min', and in the other place we do not. This really is splitting hairs, but I thought as we will be looking into it anyway, we may as well make it consistent. It should take only a milisecond to do it.
![20220808_145527](/uploads/5d30834bc307c2391773262381aaee21/20220808_145527.jpg)
![20220808_145620](/uploads/030d1fd2ad075b07f3fbef23471a3564/20220808_145620.jpg)
![20220808_145714](/uploads/610ee7753f5ae0066fa0694ddcd70742/20220808_145714.jpg)https://code.briarproject.org/briar/briar/-/issues/2353High data (traffic) usage2022-08-15T13:02:20ZArcibald RajsHigh data (traffic) usageHi all.
Briar is awesome app... almost awesome.
There is no server, but as I can see - every installed instance become some kind of server / transport node. Right?
I have 3 - 4 contacts. There are situations where I don't communicat...Hi all.
Briar is awesome app... almost awesome.
There is no server, but as I can see - every installed instance become some kind of server / transport node. Right?
I have 3 - 4 contacts. There are situations where I don't communicate with them, but Briar swallow almost 2 GB of data in background in less then 24h!!! I try to disable background data in app settings, but that don't help me.
This can be a really big problem if somebody is in roaming or have limited package, as me and my friends.
Anybody have similiar experience? Any suggestion how to limit this consumption?
Regards.https://code.briarproject.org/briar/briar/-/issues/2352Don't upload to mailbox when directly connected to contact2022-08-17T10:03:32ZakwizgranDon't upload to mailbox when directly connected to contactWhile we're directly connected to a contact we should stop creating files to send to the contact via our own mailbox or the contact's mailbox. Files that have already been created should be uploaded, and downloads should continue as norm...While we're directly connected to a contact we should stop creating files to send to the contact via our own mailbox or the contact's mailbox. Files that have already been created should be uploaded, and downloads should continue as normal.
The mailbox upload worker (#2291) is probably the best place to add this.Mailbox: Manage mailbox connectionsakwizgranakwizgran