briar issueshttps://code.briarproject.org/groups/briar/-/issues2019-11-06T09:47:39Zhttps://code.briarproject.org/briar/briar/-/issues/1584Race condition in IntroductionIntegrationTest2019-11-06T09:47:39ZakwizgranRace condition in IntroductionIntegrationTestIntroductionIntegrationTest sometimes fails randomly (see https://code.briarproject.org/briar/briar/-/jobs/3638). Looks like the same underlying cause as #1560.IntroductionIntegrationTest sometimes fails randomly (see https://code.briarproject.org/briar/briar/-/jobs/3638). Looks like the same underlying cause as #1560.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1583Remote contact layout is too tall for small screens2019-09-27T14:58:54ZakwizgranRemote contact layout is too tall for small screensThe layouts for LinkExchangeFragment and NicknameFragment don't work well on small screens: for LinkExchangeFragment the Continue button is mostly offscreen, and for NicknameFragment the nickname field and Add Contact button are entirely...The layouts for LinkExchangeFragment and NicknameFragment don't work well on small screens: for LinkExchangeFragment the Continue button is mostly offscreen, and for NicknameFragment the nickname field and Add Contact button are entirely offscreen, making it unclear what the user's meant to do next.
Screenshots come from the Huawei Ascend Y330 (480x800 px).
![device-2019-06-08-101532](/uploads/83053a95ddee99302b91b0b79c659113/device-2019-06-08-101532.png)
![device-2019-06-08-101545](/uploads/33ff8c3896463d1be367479d956b781b/device-2019-06-08-101545.png)
Possible workarounds:
* Scroll to the bottom of each fragment when it's opened
* Remove the illustration from NicknameActivity or make it smaller
* Move the stepper to the bottom, below the button (I know we decided it was better at the top, and apart from this issue I'd prefer to keep it there)
* Divide the workflow into three steps rather than two: send link, enter link, and enter nickname (this has disadvantages for the flows where the user opens the activity by sharing a link from another app, or with a link already in the clipboard)Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1582Pending contact snackbar and add contact FAB are sometimes displaced2022-04-19T11:29:51ZakwizgranPending contact snackbar and add contact FAB are sometimes displacedThe pending contact snackbar sometimes appears in the wrong place, with a blank space below it and overlapping the FAB. After the snackbar is hidden, the FAB doesn't always return to the right position.
![device-2019-06-07-162517](/uplo...The pending contact snackbar sometimes appears in the wrong place, with a blank space below it and overlapping the FAB. After the snackbar is hidden, the FAB doesn't always return to the right position.
![device-2019-06-07-162517](/uploads/9109a6a1d3e0fbeccdb1e25d1c5796b7/device-2019-06-07-162517.png)
![device-2019-06-07-162537](/uploads/01cc37afca368254ff312281f3f8d992/device-2019-06-07-162537.png)
I've seen the first problem on the Huawei Ascend Y330 (Android 4.2.2) and the Vivo Y11 (Android 4.4.4). I've seen the second problem on those phones and also the Honor 8A (Android 9).https://code.briarproject.org/briar/briar/-/issues/1581Add pending contact via ENTER or IME action2020-11-15T18:20:32ZTorsten GroteAdd pending contact via ENTER or IME actionWhen entering the nickname for a pending contact pressing enter or the Go IME action in the soft keyboard should be equivalent to pressing the button.When entering the nickname for a pending contact pressing enter or the Go IME action in the soft keyboard should be equivalent to pressing the button.https://code.briarproject.org/briar/briar/-/issues/1580Warn when adding pending contact with Tor disabled2019-06-18T09:54:35ZTorsten GroteWarn when adding pending contact with Tor disabledAdding contacts remotely won't work with the Tor plugin not running. We should notify contacts when that is the case, so they can go online or enable Tor.Adding contacts remotely won't work with the Tor plugin not running. We should notify contacts when that is the case, so they can go online or enable Tor.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1579Replace pending contact remove button with icon2019-06-08T09:44:58ZTorsten GroteReplace pending contact remove button with iconIt should use the same icon as the rss feeds.It should use the same icon as the rss feeds.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1578Improve structure of Briar Headless API documentation2021-03-22T10:52:52ZNicoImprove structure of Briar Headless API documentationCurrently, the documentation for the API is directly written into [its readme file](https://code.briarproject.org/briar/briar/blob/release-1.1.7/briar-headless/README.md). That's fine for the beginning, [I was even able to build a first ...Currently, the documentation for the API is directly written into [its readme file](https://code.briarproject.org/briar/briar/blob/release-1.1.7/briar-headless/README.md). That's fine for the beginning, [I was even able to build a first prototype with it](https://nico.dorfbrunnen.eu/posts/2019/briar-first-demo/).
However, I suggest to improve the structure of the documentation by moving it into a separate repository. My suggestion was to create a Hugo page with a docs theme (or some other static site generator) at docs.briarproject.org.
@grote's response to this was (loosely translated by me): "Best to make the documentation directly into the code with swagger"
My response to this now: OK, we can do this, but I don't know how much sense it makes to put a lot of basic explanations into code. E.g. all the valuable information collected in https://code.briarproject.org/briar/briar/issues/1577.
**Update:** I agree with Torsten that it's best to generate the documentation from code. That's what I do with [`briar_wrapper`](https://code.briarproject.org/briar/python-briar-wrapper), too, at https://wrapper.docs.briarproject.org/ and the API's docs can be hosted at https://api.docs.briarproject.org/, imho.CleopatraCleopatrahttps://code.briarproject.org/briar/briar/-/issues/1577Some questions about Headless API2020-10-31T12:52:40ZNicoSome questions about Headless API@grote asked me to read carefully over the [Briar Headless API documentation](https://code.briarproject.org/briar/briar/blob/release-1.1.7/briar-headless/README.md) in order to find things that needs more explanation. And I do have some ...@grote asked me to read carefully over the [Briar Headless API documentation](https://code.briarproject.org/briar/briar/blob/release-1.1.7/briar-headless/README.md) in order to find things that needs more explanation. And I do have some questions that I'll copy-paste from our chat into separate discussion boxes below. With these questions, I hope to make clear in how far the documentation needs to be improved in order to make it easier for third-party developers to implement the API.Headless MVPNicoNicohttps://code.briarproject.org/briar/briar/-/issues/1576IllegalStateException when sharing remote contact link2019-06-10T16:33:49ZakwizgranIllegalStateException when sharing remote contact linkThe following crash happens when sharing a remote contact link from another app while signed out:
```
java.lang.IllegalStateException
at org.briarproject.bramble.db.H2Database.createConnection(H2Database.java:94)
at org....The following crash happens when sharing a remote contact link from another app while signed out:
```
java.lang.IllegalStateException
at org.briarproject.bramble.db.H2Database.createConnection(H2Database.java:94)
at org.briarproject.bramble.db.JdbcDatabase.startTransaction(JdbcDatabase.java:547)
at org.briarproject.bramble.db.JdbcDatabase.startTransaction(JdbcDatabase.java:96)
at org.briarproject.bramble.db.DatabaseComponentImpl.startTransaction(DatabaseComponentImpl.java:160)
at org.briarproject.bramble.db.DatabaseComponentImpl.transactionWithResult(DatabaseComponentImpl.java:207)
at org.briarproject.bramble.contact.ContactManagerImpl.getHandshakeLink(ContactManagerImpl.java:138)
at org.briarproject.briar.android.contact.add.remote.AddContactViewModel.lambda$loadHandshakeLink$0$AddContactViewModel(AddContactViewModel.java:62)
```
The cause is similar to #1482: we're accessing the DB before knowing whether we're signed in.
The solution we created for #1482 requires us to defer all database work until onResume(), and check isSignedIn() before doing any database work. The fact that we've seen a second bug so soon after fixing the first may suggest that it's going to be hard to remember those constraints in every case.
Another possible workaround would be for H2Database#createConnection() to throw a DbClosedException rather than an IllegalStateException if there's no DB key.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1575exclude the redundant rome-utils jar from being packaged2019-08-20T09:03:04Ziwakehexclude the redundant rome-utils jar from being packagedPlease, see comment below.Please, see comment below.https://code.briarproject.org/briar/briar/-/issues/1574Consider separating the package structures for bramble-java and bramble-core2020-11-15T18:21:38ZiwakehConsider separating the package structures for bramble-java and bramble-coreConsider using a separate package for ```bramble-java``` (e.g. ```org.briarproject.bramble.java.*```)
Currently, ```bramble-java``` provides the same packages as ```bramble-core```.
Some ```bramble-java``` classes extend package-private...Consider using a separate package for ```bramble-java``` (e.g. ```org.briarproject.bramble.java.*```)
Currently, ```bramble-java``` provides the same packages as ```bramble-core```.
Some ```bramble-java``` classes extend package-private classes from ```bramble-core``` (mostly in bluetooth). Hmm ....
When briar is going to use java >= 9 and provides modules this needs to be addressed anyway.
(I believe briar should be around for many, many new java versions to come ;-)https://code.briarproject.org/briar/briar-gtk/-/issues/1Bundle OpenJDK 11 with Flatpak2020-04-12T14:43:19ZNicoBundle OpenJDK 11 with FlatpakWe currently use OpenJDK 10 which [is deprecated](https://github.com/flathub/org.freedesktop.Sdk.Extension.openjdk10/commit/217c14bce098842e4abe8a6f24c97251e176348b). Switching to [OpenJDK 11](https://github.com/flathub/org.freedesktop.S...We currently use OpenJDK 10 which [is deprecated](https://github.com/flathub/org.freedesktop.Sdk.Extension.openjdk10/commit/217c14bce098842e4abe8a6f24c97251e176348b). Switching to [OpenJDK 11](https://github.com/flathub/org.freedesktop.Sdk.Extension.openjdk11) is not possible at the moment because building fails with the following error:
```bash
flatpak build-init --arch=x86_64 /home/dev/.cache/gnome-builder/projects/briar-gtk/flatpak/staging/x86_64-master app.briar.gtk org.gnome.Sdk org.gnome.Platform 3.28
flatpak-builder --arch=x86_64 --ccache --force-clean --state-dir /home/dev/.cache/gnome-builder/flatpak-builder --download-only --disable-updates --stop-at=briar-gtk /home/dev/.cache/gnome-builder/projects/briar-gtk/flatpak/staging/x86_64-master /home/dev/Work/Briar/briar-gtk/app.briar.gtk.json
Emptying app dir '/home/dev/.cache/gnome-builder/projects/briar-gtk/flatpak/staging/x86_64-master'
Downloading sources
Stopping at module briar-gtk
flatpak-builder --arch=x86_64 --ccache --force-clean --disable-updates --disable-download --state-dir /home/dev/.cache/gnome-builder/flatpak-builder --stop-at=briar-gtk /home/dev/.cache/gnome-builder/projects/briar-gtk/flatpak/staging/x86_64-master /home/dev/Work/Briar/briar-gtk/app.briar.gtk.json
Initializing build dir
error: Requested extension org.freedesktop.Sdk.Extension.openjdk11 not installed
Error: Child process exited with code 1
flatpak build-init --arch=x86_64 /home/dev/.cache/gnome-builder/projects/briar-gtk/flatpak/staging/x86_64-master app.briar.gtk org.gnome.Sdk org.gnome.Platform 3.28
flatpak-builder --arch=x86_64 --ccache --force-clean --disable-updates --disable-download --state-dir /home/dev/.cache/gnome-builder/flatpak-builder --stop-at=briar-gtk /home/dev/.cache/gnome-builder/projects/briar-gtk/flatpak/staging/x86_64-master /home/dev/Work/Briar/briar-gtk/app.briar.gtk.json
Emptying app dir '/home/dev/.cache/gnome-builder/projects/briar-gtk/flatpak/staging/x86_64-master'
Initializing build dir
error: Requested extension org.freedesktop.Sdk.Extension.openjdk11 not installed
Error: Child process exited with code 1
flatpak build-init --arch=x86_64 /home/dev/.cache/gnome-builder/projects/briar-gtk/flatpak/staging/x86_64-master app.briar.gtk org.gnome.Sdk org.gnome.Platform 3.28
flatpak-builder --arch=x86_64 --ccache --force-clean --disable-updates --disable-download --state-dir /home/dev/.cache/gnome-builder/flatpak-builder --stop-at=briar-gtk /home/dev/.cache/gnome-builder/projects/briar-gtk/flatpak/staging/x86_64-master /home/dev/Work/Briar/briar-gtk/app.briar.gtk.json
Emptying app dir '/home/dev/.cache/gnome-builder/projects/briar-gtk/flatpak/staging/x86_64-master'
Initializing build dir
error: Requested extension org.freedesktop.Sdk.Extension.openjdk11 not installed
Error: Child process exited with code 1
```
When trying to install OpenJDK 11 manually, it says it *is* already installed:
```bash
$ flatpak install org.freedesktop.Sdk.Extension.openjdk11
Looking for matches…
Remotes found with refs similar to ‘org.freedesktop.Sdk.Extension.openjdk11’:
1) ‘flathub’ (system)
2) ‘flathub’ (user)
3) ‘gnome’ (user)
Which do you want to use (0 to abort)? [0-3]: 1
Skipping: org.freedesktop.Sdk.Extension.openjdk11/x86_64/18.08 is already installed
$ flatpak install org.freedesktop.Sdk.Extension.openjdk11
Looking for matches…
Remotes found with refs similar to ‘org.freedesktop.Sdk.Extension.openjdk11’:
1) ‘flathub’ (system)
2) ‘flathub’ (user)
3) ‘gnome’ (user)
Which do you want to use (0 to abort)? [0-3]: 2
Skipping: org.freedesktop.Sdk.Extension.openjdk11/x86_64/18.08 is already installed
```
Installing from GNOME is not an option because it bundles an older version:
```bash
$ flatpak install org.freedesktop.Sdk.Extension.openjdk11
Looking for matches…
Remotes found with refs similar to ‘org.freedesktop.Sdk.Extension.openjdk11’:
1) ‘flathub’ (system)
2) ‘flathub’ (user)
3) ‘gnome’ (user)
Which do you want to use (0 to abort)? [0-3]: 3
Found ref ‘runtime/org.freedesktop.Sdk.Extension.openjdk9/x86_64/1.6’ in remote ‘gnome’ (user).
Use this ref? [Y/n]: y
ID Arch Branch Remote Download
1. org.freedesktop.Sdk.Extension.openjdk9 x86_64 1.6 gnome < 365.4 MB
Proceed with these changes to the user installation? [Y/n]: n
```
Related issue on another project of mine: https://gitlab.com/fdroid/fdroid-repomaker-flatpak/issues/17
Related issue on upstream repo: https://github.com/flathub/org.freedesktop.Sdk.Extension.openjdk11/issues/8GTK 0.1.0-alpha1NicoNicohttps://code.briarproject.org/briar/briar/-/issues/1573LanTcpPlugin broadcasts a TransportDisabledEvent if it fails to bind key agre...2022-07-20T10:38:40ZakwizgranLanTcpPlugin broadcasts a TransportDisabledEvent if it fails to bind key agreement socket`TcpPlugin#tryToClose(ServerSocket)` broadcasts a TransportDisabledEvent, apparently as a convenience because the enabled/disabled state of the plugin is defined by whether a server socket is bound and the socket can be closed in several...`TcpPlugin#tryToClose(ServerSocket)` broadcasts a TransportDisabledEvent, apparently as a convenience because the enabled/disabled state of the plugin is defined by whether a server socket is bound and the socket can be closed in several places. But LanTcpPlugin calls this method if it fails to bind a server socket for key agreement, wrongly broadcasting an event.
TorPlugin copies TcpPlugin's tryToClose() method. We should probably clean that up too, as TorPlugin will soon have other server sockets for rendezvous connections and we don't want to broadcast an event when they're closed.
Related to #1572.https://code.briarproject.org/briar/briar/-/issues/1572Transport icons use inconsistent information to determine plugin state2020-06-30T15:21:35ZakwizgranTransport icons use inconsistent information to determine plugin stateThe transport icons in the nav drawer use two sources of information to determine which transports are active: `Plugin#isRunning()` and TransportEnabled/DisabledEvents. But these sources can be inconsistent. For example, `BluetoothPlugin...The transport icons in the nav drawer use two sources of information to determine which transports are active: `Plugin#isRunning()` and TransportEnabled/DisabledEvents. But these sources can be inconsistent. For example, `BluetoothPlugin#isRunning()` returns true if the adapter is enabled, regardless of whether contact connections are enabled, but the plugin doesn't broadcast TransportEnabledEvents unless contact connections are enabled. This leads to the following bug:
* Start Briar with default settings and the Bluetooth adapter enabled
* The Bluetooth icon is active because isRunning() returns true
* Disable the Bluetooth adapter
* The Bluetooth icon is inactive because a TransportDisabledEvent was broadcast
* Re-enable the Bluetooth adapter
* The Bluetooth icon remains inactive because no TransportEnabledEvent was broadcast
Arguably the real issue here is that plugins (or the manager) should provide an isEnabled() method that follows the enabled/disabled events. This could easily be implemented in the manager, and could also be used to suppress redundant enabled/disabled events, such as those broadcast when toggling the Bluetooth adapter state without contact connections enabled.
Related to discussion of plugin states on #185.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1571Add rendezvous connection support to connection manager2019-06-04T14:26:56ZakwizgranAdd rendezvous connection support to connection managerSubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1570Add contact manager and database methods for converting a pending contact2019-06-03T14:58:45ZakwizgranAdd contact manager and database methods for converting a pending contactSubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1569Connection manager could fail to close connection2020-11-15T18:24:37ZakwizgranConnection manager could fail to close connectionWhen the connection manager disposes of the incoming side of a duplex connection, it interrupts the outgoing sync session (if any) so the outgoing session can finish cleanly. If this happens before the outgoing session is created, it won...When the connection manager disposes of the incoming side of a duplex connection, it interrupts the outgoing sync session (if any) so the outgoing session can finish cleanly. If this happens before the outgoing session is created, it won't be interrupted.
If the incoming side of the connection is being disposed of because of an exception then the transport connection will be closed, so the outgoing session should eventually catch an exception when it tries to write to the connection. But if the incoming side of the connection is being disposed of because the end of the stream was reached then the transport connection will be left half-open, so the outgoing session could keep running indefinitely. This might also happen in the case of an exception if there's nothing to send and the transport doesn't require keepalives, which is the case for Bluetooth.
This could result in a dangling connection that's only usable in one direction. As far as I can tell it won't prevent a new connection from being made, or cause issues like !921, because the registration and unregistration of duplex connections is based on the lifetime of the incoming session, not the outgoing session.
The opposite can also happen: if the connection manager disposes of the outgoing side of the connection before the incoming session is created, the incoming session won't be interrupted. This can only happen if an exception has been thrown (in which case the transport connection will be closed, which *should* cause the incoming session to catch an exception eventually), or if the outgoing session has finished cleanly, which only happens if it's interrupted due to the incoming side of the connection being disposed of. So the only possible cause of a bug like !921 in this case would be if closing the connection didn't cause the incoming session to catch an exception (flaky Bluetooth stacks, I'm looking at you).
Labelling this as a bug because it's unintended behaviour, although it's not clear if we need to fix it.https://code.briarproject.org/briar/briar/-/issues/1568Test the effects of dormant mode when operating as a Tor client2020-11-15T18:26:32ZakwizgranTest the effects of dormant mode when operating as a Tor clientTest whether a Briar peer that's not running a hidden service or holding a wake lock can operate as a Tor client (i.e. connect to contacts' hidden services and fetch RSS feeds), and whether this is affected by Tor's dormant mode.Test whether a Briar peer that's not running a hidden service or holding a wake lock can operate as a Tor client (i.e. connect to contacts' hidden services and fetch RSS feeds), and whether this is affected by Tor's dormant mode.https://code.briarproject.org/briar/briar/-/issues/1567Create poller for rendezvous connections2019-06-10T13:49:06ZakwizgranCreate poller for rendezvous connectionsSubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1566Investigate whether equivalent public keys can damage the security of handsha...2019-05-14T11:16:36ZakwizgranInvestigate whether equivalent public keys can damage the security of handshake modeSome ECDH public keys are equivalent, in the sense that multiplying them by the same scalar produces the same point. If an attacker sends us a handshake public key that's equivalent to a contact's handshake public key, we'll fail to dete...Some ECDH public keys are equivalent, in the sense that multiplying them by the same scalar produces the same point. If an attacker sends us a handshake public key that's equivalent to a contact's handshake public key, we'll fail to detect that it's the same key (see #1565) and derive the same handshake mode transport keys. The attacker won't be able to derive the keys, but we'll use the same keys for handshaking with the contact and trying to handshake with the attacker.
This shouldn't affect confidentiality, integrity or authenticity, as we use a unique random nonce with the stream header key, but it could affect protocol obfuscation by using the same tags for sending streams to the contact and the attacker.
Work out whether this attack is possible, and if so, whether we can detect and prevent it.
Subtask of #1232.Android 1.2akwizgranakwizgran