briar issueshttps://code.briarproject.org/briar/briar/-/issues2018-06-12T11:32:20Zhttps://code.briarproject.org/briar/briar/-/issues/618BdfDictionary should have a defined iteration order2018-06-12T11:32:20ZakwizgranBdfDictionary should have a defined iteration orderThe iterators for BdfDictionary's keys, values and entries should return their elements in a defined order. Currently BdfDictionary uses the iterators inherited from Hashtable, which have no defined order, so deserialising and reserialis...The iterators for BdfDictionary's keys, values and entries should return their elements in a defined order. Currently BdfDictionary uses the iterators inherited from Hashtable, which have no defined order, so deserialising and reserialising a dictionary may produce output that's different from the input. This will be a problem whenever we want to hash or sign data that contains dictionaries.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/279Contact can't be removed if introduction client's local group doesn't exist2018-06-12T11:32:31ZakwizgranContact can't be removed if introduction client's local group doesn't existWhile testing the introduction UI, I tried to remove an old contact. The "Contact deleted" toast was shown but the contact wasn't removed because the introduction manager's RemoveContactHook threw an exception:
```
04-01 12:35:57.843...While testing the introduction UI, I tried to remove an old contact. The "Contact deleted" toast was shown but the contact wasn't removed because the introduction manager's RemoveContactHook threw an exception:
```
04-01 12:35:57.843 1951-8113/org.briarproject W/ConversationActivity: org.briarproject.api.db.NoSuchGroupException
org.briarproject.api.db.NoSuchGroupException
at org.briarproject.db.DatabaseComponentImpl.getMessageMetadata(DatabaseComponentImpl.java:412)
at org.briarproject.clients.ClientHelperImpl.getMessageMetadataAsDictionary(ClientHelperImpl.java:193)
at org.briarproject.introduction.IntroductionManagerImpl.removingContact(IntroductionManagerImpl.java:157)
at org.briarproject.contact.ContactManagerImpl.removeContact(ContactManagerImpl.java:152)
at org.briarproject.contact.ContactManagerImpl.removeContact(ContactManagerImpl.java:109)
at org.briarproject.android.contact.ConversationActivity$14.run(ConversationActivity.java:481)
at org.briarproject.android.BriarActivity$4.run(BriarActivity.java:154)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)
```Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/272MessageQueue deleted messages2018-06-12T11:32:31ZTorsten GroteMessageQueue deleted messagesAlice is receiving a message via the MessageQueue:
```
03-21 18:03:19.825 I/MessageQueueManagerImpl: Received message with position 5, expecting 5
03-21 18:03:19.825 I/MessageQueueManagerImpl: Message is in order, delivering
```
Th...Alice is receiving a message via the MessageQueue:
```
03-21 18:03:19.825 I/MessageQueueManagerImpl: Received message with position 5, expecting 5
03-21 18:03:19.825 I/MessageQueueManagerImpl: Message is in order, delivering
```
Then a new message is sent by Bob:
```
03-21 18:05:35.971 I/MessageQueueManagerImpl: Sending message with position 6
```
But Alice does not get the message, because the MessageQueue is deleting it:
```
03-21 18:05:36.605 I/MessageQueueManagerImpl: Received message with position 5, expecting 6
03-21 18:05:36.605 W/MessageQueueManagerImpl: Deleting message with duplicate position
```
Bob sends another message:
```
03-21 18:05:50.484 I/MessageQueueManagerImpl: Sending message with position 7
```
This time, Alice gets it, but it still comes in with the wrong position.
```
03-21 18:05:50.775 I/MessageQueueManagerImpl: Received message with position 6, expecting 6
03-21 18:05:50.775 I/MessageQueueManagerImpl: Message is in order, delivering
```Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/269Race condition between adding contacts and adding transports2018-06-12T11:32:32ZakwizgranRace condition between adding contacts and adding transports`KeyManagerImpl#addContact()` runs synchronously whereas `KeyManagerImpl#addTransport()` runs asynchronously. If a transport is added and then a contact is added immediately afterwards, it's possible for the contact not to get any transp...`KeyManagerImpl#addContact()` runs synchronously whereas `KeyManagerImpl#addTransport()` runs asynchronously. If a transport is added and then a contact is added immediately afterwards, it's possible for the contact not to get any transport keys.
This is very unlikely to affect real users because transports are added early in the startup process, but it's causing SimplexTransportIntegrationTest to fail intermittently, and should be fixed anyway on principle.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/266Message queues2018-06-12T11:32:32ZakwizgranMessage queuesWrite a generic one-to-one message queue implementation that clients can use to exchange ordered messages with a contact.Write a generic one-to-one message queue implementation that clients can use to exchange ordered messages with a contact.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/256Verify and bind long-term public keys when adding contacts2018-06-12T11:32:32ZakwizgranVerify and bind long-term public keys when adding contactsDesign a protocol for verifying and binding long-term public keys when adding contacts directly or via introductions.
The current Bluetooth protocol does this by generating two nonces from the ephemeral shared secret - each party sign...Design a protocol for verifying and binding long-term public keys when adding contacts directly or via introductions.
The current Bluetooth protocol does this by generating two nonces from the ephemeral shared secret - each party signs one of the nonces. We could use a similar approach for the new protocols, or an approach based on triple Diffie-Hellman.
Identities already have long-term signature keys but they don't have long-term DH keys, so if we use 3DH we either need to be sure it's safe to reuse the signature keys as DH keys, or we need to extend the identity object with a long-term DH key, signed with the long-term signature key. This has the disadvantage of committing us to a DH primitive for the long term.
Using signatures would make the key exchange undeniable, but it's debatable whether that matters in practice.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/254Crash when keys are rotated2018-06-12T11:32:32ZakwizgranCrash when keys are rotatedThis crash happens when leaving a test phone to do nothing (see https://code.briarproject.org/akwizgran/briar/merge_requests/74#note_2358):
```
java.lang.IllegalStateException: TimerTask is scheduled already
at...This crash happens when leaving a test phone to do nothing (see https://code.briarproject.org/akwizgran/briar/merge_requests/74#note_2358):
```
java.lang.IllegalStateException: TimerTask is scheduled already
at java.util.Timer.scheduleImpl(Timer.java:569)
at java.util.Timer.schedule(Timer.java:456)
at org.briarproject.system.SystemTimer.schedule(SystemTimer.java:21)
at org.briarproject.transport.TransportKeyManager.run(TransportKeyManager.java:260)
at java.util.Timer$TimerImpl.run(Timer.java:284)
```
Looks like the issue is that TransportKeyManager re-schedules the same TimerTask instance (i.e. itself) and the Timer impl doesn't allow that. TransportKeyManager's TimerTask implementation should be broken out into a private class so a different instance can be scheduled each time.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/252New polling logic for LAN2018-06-12T11:32:32ZakwizgranNew polling logic for LANSubtask of #116.Subtask of #116.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/251New polling logic for Bluetooth2018-06-12T11:32:32ZakwizgranNew polling logic for BluetoothSubtask of #116.Subtask of #116.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/250New polling logic for Tor2018-06-12T11:32:32ZakwizgranNew polling logic for TorSubtask of #116.Subtask of #116.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/243Rotating ReadForumPostActivity causes post to appear anonymous2018-06-12T11:32:33ZakwizgranRotating ReadForumPostActivity causes post to appear anonymousWhen viewing a pseudonymous forum post in ReadForumPostActivity, rotating the screen causes the post to appear anonymous.When viewing a pseudonymous forum post in ReadForumPostActivity, rotating the screen causes the post to appear anonymous.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/242Anonymous forum post crashes ReadForumPostActivity2018-06-12T11:32:33ZakwizgranAnonymous forum post crashes ReadForumPostActivityThe crash is caused by an IllegalStateException thrown when no author reference is retrieved from the ReferenceManager.The crash is caused by an IllegalStateException thrown when no author reference is retrieved from the ReferenceManager.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/241Don't show persistent notification on lock screen2018-06-12T11:32:33ZakwizgranDon't show persistent notification on lock screenAndroid 5 and 6 allow notifications to be shown on the lock screen. Configure Briar's persistent notification so it doesn't appear there.Android 5 and 6 allow notifications to be shown on the lock screen. Configure Briar's persistent notification so it doesn't appear there.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/238Allow messages to be deleted2018-06-12T11:32:33ZakwizgranAllow messages to be deletedAllow messages to be deleted from the database. If a message being deleted is shared, we need to keep enough information about it to avoid syncing it back to life.Allow messages to be deleted from the database. If a message being deleted is shared, we need to keep enough information about it to avoid syncing it back to life.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/235Potential deadlock in TransportKeyManager2018-06-12T11:32:33ZakwizgranPotential deadlock in TransportKeyManagerTransportKeyManager uses the single-threaded DatabaseExecutor to ensure its DB tasks write to the DB in the same order as they're queued. This makes it possible to keep TransportKeyManager's internal state consistent with the state of th...TransportKeyManager uses the single-threaded DatabaseExecutor to ensure its DB tasks write to the DB in the same order as they're queued. This makes it possible to keep TransportKeyManager's internal state consistent with the state of the DB without holding locks during DB calls.
To ensure that a StreamContext is never used twice, the two getStreamContext() methods wait for their DB tasks to complete before returning. This will cause deadlock: if the methods are called on the DatabaseExecutor thread, as their DB tasks will be queued behind them and will never complete.
One way to fix this would be for TransportKeyManager to keep its own single-threaded executor for running its DB tasks. KeyManagerImpl already has a Timer thread that could be converted into an executor.
Another possibility would be to return a Future<StreamContext>.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/234Remove consumers from BdfWriter2018-06-12T11:32:33ZakwizgranRemove consumers from BdfWriterMilestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/228Briar crashes when TorPlugin tries to create a connection2018-06-12T11:32:33Zstr4dBriar crashes when TorPlugin tries to create a connection```
java.lang.NullPointerException: Attempt to write to field 'java.io.OutputStream net.sourceforge.jsocks.Proxy.out' on a null object reference
at net.sourceforge.jsocks.SocksSocket.doDirect(SocksSocket.java:279)
at net.sourceforge...```
java.lang.NullPointerException: Attempt to write to field 'java.io.OutputStream net.sourceforge.jsocks.Proxy.out' on a null object reference
at net.sourceforge.jsocks.SocksSocket.doDirect(SocksSocket.java:279)
at net.sourceforge.jsocks.SocksSocket.<init>(SocksSocket.java:100)
at org.briarproject.plugins.tor.TorPlugin.createConnection(TorPlugin.java:536)
at org.briarproject.plugins.tor.TorPlugin$2.run(TorPlugin.java:515)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:818)
```
In the library sources that Gradle downloaded for me, it looks like the proxy field of the jsocks `SocksSocket` constructor is ignored completely, but the `doDirect()` internal function called by that constructor uses the unset `proxy` variable. This looks like an upstream bug. I don't know how this is working for anyone else, given that the jsocks library is verified by Gradle Witness.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/227Contact list not updating when contact is removed2018-06-12T11:32:33ZakwizgranContact list not updating when contact is removedMilestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/226Fix logic for disabling Bluetooth at shutdown2018-06-12T11:32:33ZakwizgranFix logic for disabling Bluetooth at shutdownIf Bluetooth is disabled when the app starts and the user or another app subsequently enables it, Briar will disable it when shutting down.
The current logic checks whether Bluetooth was disable at startup, and if si, disables it at s...If Bluetooth is disabled when the app starts and the user or another app subsequently enables it, Briar will disable it when shutting down.
The current logic checks whether Bluetooth was disable at startup, and if si, disables it at shutdown. What it should do instead is check whether Bluetooth was disabled startup *and* Briar enabled it at startup, and if so, disable it at shutdown.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/225Bluetooth plugin is broken on Android 62018-06-12T11:32:33ZakwizgranBluetooth plugin is broken on Android 6Android 6 no longer allows access to the local Bluetooth address. `BluetoothAdapter.getAddress()` now returns a fixed value. This will break our ability to give our address to contacts so they can connect without performing discovery.
...Android 6 no longer allows access to the local Bluetooth address. `BluetoothAdapter.getAddress()` now returns a fixed value. This will break our ability to give our address to contacts so they can connect without performing discovery.
https://developer.android.com/intl/ko/about/versions/marshmallow/android-6.0-changes.html#behavior-hardware-id
The plugin still uses BluetoothAdapter.getAddress(), it's only `TestingActivity` and `CrashReportActivity` that look at the value in `Settings.Secure`. we need to add a method (maybe in `AndroidUtils`?) for getting the value from the adapter, checking whether it's valid, getting the value from `Settings.Secure` if it's not, and throwing an exception if there's not a valid address there either.Milestone Bakwizgranakwizgran