briar issueshttps://code.briarproject.org/briar/briar/-/issues2019-06-18T16:50:53Zhttps://code.briarproject.org/briar/briar/-/issues/1591RuntimeException after sending crash report2019-06-18T16:50:53ZakwizgranRuntimeException after sending crash report* Android version: 9
* Phone model: Honor 8A
* Briar version: current master (30e0be9f)
Steps to reproduce:
* Cause a crash (e.g. with the crash button in the settings screen)
* Send a crash report or dismiss the report dialog
* Expecte...* Android version: 9
* Phone model: Honor 8A
* Briar version: current master (30e0be9f)
Steps to reproduce:
* Cause a crash (e.g. with the crash button in the settings screen)
* Send a crash report or dismiss the report dialog
* Expected: The dialog disappears
* Actual: The dialog repeatedly reappears with new crashes, even after pressing the home button and relaunching Briar
Stacktrace:
```
java.lang.RuntimeException: Unable to start activity ComponentInfo{org.briarproject.briar.android.debug/org.briarproject.briar.android.navdrawer.NavDrawerActivity}: android.os.BadParcelableException: Parcelable protocol requires a Parcelable.Creator object called CREATOR on class android.support.v4.app.FragmentManagerState
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3364)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3548)
at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:86)
at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2155)
at android.os.Handler.dispatchMessage(Handler.java:109)
at android.os.Looper.loop(Looper.java:207)
at android.app.ActivityThread.main(ActivityThread.java:7539)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:524)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:958)
Caused by: android.os.BadParcelableException: Parcelable protocol requires a Parcelable.Creator object called CREATOR on class android.support.v4.app.FragmentManagerState
at android.os.Parcel.readParcelableCreator(Parcel.java:2849)
at android.os.Parcel.readParcelable(Parcel.java:2771)
at android.os.Parcel.readValue(Parcel.java:2674)
at android.os.Parcel.readArrayMapInternal(Parcel.java:3043)
at android.os.BaseBundle.initializeFromParcelLocked(BaseBundle.java:288)
at android.os.BaseBundle.unparcel(BaseBundle.java:232)
at android.os.BaseBundle.getBoolean(BaseBundle.java:898)
at android.app.Activity.restoreHasCurrentPermissionRequest(Activity.java:7768)
at android.app.Activity.performCreate(Activity.java:7436)
at android.app.Activity.performCreate(Activity.java:7431)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1286)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3343)
... 11 more
```Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1590IllegalStateException: Cannot invoke setValue on a background thread2019-06-18T11:58:53ZakwizgranIllegalStateException: Cannot invoke setValue on a background threadCrashed when sending a message to a new contact.
Stacktrace:
```
java.lang.IllegalStateException: Cannot invoke setValue on a background thread
at android.arch.lifecycle.LiveData.assertMainThread(LiveData.java:435)
at androi...Crashed when sending a message to a new contact.
Stacktrace:
```
java.lang.IllegalStateException: Cannot invoke setValue on a background thread
at android.arch.lifecycle.LiveData.assertMainThread(LiveData.java:435)
at android.arch.lifecycle.LiveData.setValue(LiveData.java:279)
at android.arch.lifecycle.MutableLiveData.setValue(MutableLiveData.java:33)
at org.briarproject.briar.android.attachment.AttachmentCreator.resetState(AttachmentCreator.java:183)
at org.briarproject.briar.android.attachment.AttachmentCreator.onAttachmentsSent(AttachmentCreator.java:164)
at org.briarproject.briar.android.conversation.ConversationViewModel.storeMessage(ConversationViewModel.java:295)
at org.briarproject.briar.android.conversation.ConversationViewModel.lambda$createMessage$8$ConversationViewModel(ConversationViewModel.java:286)
at org.briarproject.briar.android.conversation.-$$Lambda$ConversationViewModel$1LsoWDT2XwB7wPxBWawY1IIRFR0.run(Unknown Source:10)
at org.briarproject.bramble.TimeLoggingExecutor.lambda$execute$0$TimeLoggingExecutor(TimeLoggingExecutor.java:36)
at org.briarproject.bramble.-$$Lambda$TimeLoggingExecutor$Bqrtbsq_8LcRPoTWBOef6xh7gJg.run(Unknown Source:6)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:784)
```
This is my fault - I recommended moving the onAttachmentsSent() call to a place that's on the UI thread on my branch, forgetting that it's on the crypto executor on master.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1587Add version negotiation to sync protocol2019-06-18T11:58:45ZakwizgranAdd version negotiation to sync protocolAdd a record to the sync protocol that tells the remote peer which versions of the protocol the local peer supports. Send this record at the start of every session. Remember the last set of versions received from the remote peer and use ...Add a record to the sync protocol that tells the remote peer which versions of the protocol the local peer supports. Send this record at the start of every session. Remember the last set of versions received from the remote peer and use them to decide which records we can send.
Subtask of #1434.Android 1.3akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1585Add support for image attachments to messaging client2019-10-09T12:19:18ZakwizgranAdd support for image attachments to messaging clientAndroid 1.3akwizgranakwizgranhttps://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/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/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/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/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.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1565UX for handling duplicate handshake links2019-10-16T16:19:19ZakwizgranUX for handling duplicate handshake linksIf Mallory knows Bob's handshake link, she may send it to Alice pretending it's Mallory's own link, in order to discover whether Alice and Bob are contacts/pending contacts.
When adding a pending contact we should check whether a contac...If Mallory knows Bob's handshake link, she may send it to Alice pretending it's Mallory's own link, in order to discover whether Alice and Bob are contacts/pending contacts.
When adding a pending contact we should check whether a contact/pending contact with the same handshake public key exists. If so, we should ask the user whether the new pending contact and the existing contact/pending contact are the same person. If yes, we discard the new pending contact. If no, we tell the user that two contacts sent the same link, which could mean that one of them is trying to discover who the user's contacts are, and we warn the user not to tell either or them that someone else sent the same link. Then we discard the new pending contact.
If we support more than one link format in future, Mallory may change the format of Bob's link before sending it to Alice, so we should compare the parsed public keys or public key hashes rather than the unparsed links.
Subtask of #1230.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1564Publish hidden service for connecting to pending contact2019-06-10T13:48:57ZakwizgranPublish hidden service for connecting to pending contactSubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1562Improve handling of external intents2022-05-26T15:49:41ZTorsten GroteImprove handling of external intentsUse `ENTRY_ACTIVITY` from !1087 as a central router for external intents:
> Not signed into Briar. The password screen is shown, then after signing in the remote contact activity is shown, as expected. The contact's link field is empty....Use `ENTRY_ACTIVITY` from !1087 as a central router for external intents:
> Not signed into Briar. The password screen is shown, then after signing in the remote contact activity is shown, as expected. The contact's link field is empty. If I use the up button to navigate away from the remote contact screen or the pending contact list, the task is closed. I'd expect to navigate to the contact list when pressing the up button. If I don't use the up button to navigate away, then later reopen Briar from the foreground notification, a second Briar task is created. I assume the same would happen with private message notifications, etc - the issue being that the notification expects us to have a task that can be reused by clearing the stack down to NavDrawerActivity, but the existing task doesn't have that activity in its stack.
There's also some other issues with AddContactActivity to resolve:
> If an instance of AddContactActivity already exists it's brought to the foreground but the link isn't populated (I'm assuming this is because the new intent is delivered without calling onCreate() again).
>
> If I open the remote contact activity via the speed dial, then put Briar into the background via the home button and relaunch via the ongoing notification, the contact list appears as expected. But when I back out, the remote contact activity and another instance of the contact list are underneath.
>
> Similarly, if I open the remote contact activity with a share intent, then press the home button, relaunch via the ongoing notification, and back out of the contact list, the remote contact activity is underneath (but without the second instance of the contact list).
>
> Finally, if I open the remote contact activity with a share intent, then back out or press the up button, the task is cleared. If I relaunch via recent apps, the remote contact activity is shown again. Backing out or pressing the up button clears the task again, so I can't reach the rest of the app!
Android 1.2Torsten GroteTorsten Grote