briar issueshttps://code.briarproject.org/briar/briar/-/issues2018-06-12T11:32:19Zhttps://code.briarproject.org/briar/briar/-/issues/632BadTokenException if RSS error dialog is show after activity is destroyed2018-06-12T11:32:19ZakwizgranBadTokenException if RSS error dialog is show after activity is destroyedI got this crash when trying to add an RSS feed with a mistyped hostname. I backed out of the feed import activity rather than waiting for the connection to fail, and the app tried to show the error dialog after the activity had been des...I got this crash when trying to add an RSS feed with a mistyped hostname. I backed out of the feed import activity rather than waiting for the connection to fail, and the app tried to show the error dialog after the activity had been destroyed.
```
09-01 22:49:07.851 15929-15929/org.briarproject E/ACRA: ACRA caught a BadTokenException for org.briarproject
android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@13b88199 is not valid; is your activity running?
at android.view.ViewRootImpl.setView(ViewRootImpl.java:579)
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:282)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:85)
at android.app.Dialog.show(Dialog.java:298)
at org.briarproject.android.blogs.RssFeedImportActivity$5.run(RssFeedImportActivity.java:172)
```Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/631Inject fragments earlier in their lifecycle2018-12-19T11:24:56ZakwizgranInject fragments earlier in their lifecycleFragments are injected in `Fragment#onActivityCreated()`, which is called after `Fragment#onCreate()` and `Fragment#onCreateView()`, meaning injected fields can't be used in those methods. It would sometimes be useful to have access to i...Fragments are injected in `Fragment#onActivityCreated()`, which is called after `Fragment#onCreate()` and `Fragment#onCreateView()`, meaning injected fields can't be used in those methods. It would sometimes be useful to have access to injected fields earlier in the fragment's lifecycle.
Injection happens at this point because BaseActivity creates its ActivityComponent in `Activity#onCreate()`. Would it be possible for BaseFragment to create a FragmentComponent in `Fragment#onCreate()` (or even `Fragment#onAttach()`) to avoid this dependency on the activity to perform injection?Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/630Introduction Protocol does not abort once in FINISHED state2018-06-12T11:32:19ZTorsten GroteIntroduction Protocol does not abort once in FINISHED stateWhile writing introduction protocol attacks for #627 I noticed that introducees do not handle `ABORT` messages once they are in the `FINISHED` state.
This can lead to a situation where the protocol is aborted by Bob due to an invalid MA...While writing introduction protocol attacks for #627 I noticed that introducees do not handle `ABORT` messages once they are in the `FINISHED` state.
This can lead to a situation where the protocol is aborted by Bob due to an invalid MAC, but Alice has not only added Bob already, but also notified the UI of the successful addition of Bob. Do we also forcefully remove a contact that has already been added *and* activated? If so, do we need to introduce a new event to inform the user about that.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/629Test whether Tor hidden service patch is still needed2018-07-31T16:17:46ZakwizgranTest whether Tor hidden service patch is still needed~~Repeat the Tor performance experiments from #115 using Tor 0.2.6.7 with the old and new code to determine the impact of improvements to Tor itself, specifically issue #8239 (https://trac.torproject.org/projects/tor/ticket/8239).~~
Rep...~~Repeat the Tor performance experiments from #115 using Tor 0.2.6.7 with the old and new code to determine the impact of improvements to Tor itself, specifically issue #8239 (https://trac.torproject.org/projects/tor/ticket/8239).~~
Repeat the Tor performance experiments from #115 using Tor 0.2.9.15, with and without our hidden service patch, to see whether our patch still affects performance. Test the patch from issue #19522 (https://trac.torproject.org/projects/tor/ticket/19522) to see whether it would be a suitable alternative to our patch.
If our patch is still needed, update it to address the reviewers' comments from https://trac.torproject.org/projects/tor/ticket/18620. That ticket should be closed, as v2 hidden services are being deprecated. If we need a new patch for v3 hidden services we should open a new ticket.
See discussion on #115. ~~Subtask of #152.~~Android 1.1akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/628Bring protocols into line with spec2018-04-16T16:24:37ZakwizgranBring protocols into line with spec* BQP should ignore records with unknown versions/record types
* BSP should ignore records with unknown versions/record types
* BSP should use "record" rather than "packet"
* Max message body length should be 2^15 bytes (32 KiB)
* Max gr...* BQP should ignore records with unknown versions/record types
* BSP should ignore records with unknown versions/record types
* BSP should use "record" rather than "packet"
* Max message body length should be 2^15 bytes (32 KiB)
* Max group descriptor length should be 2^15 bytes (32 KiB)
* Message ID should hash group ID, timestamp, body as separate argumentsMilestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/627Tests for Introduction Security Properties2018-06-12T11:32:19ZTorsten GroteTests for Introduction Security PropertiesWhen testing the introduction protocol, it makes sense to use a real MAC and signature, otherwise we're just testing that verification detects an invalid signature/MAC, rather than testing that modifying the response makes the signature/...When testing the introduction protocol, it makes sense to use a real MAC and signature, otherwise we're just testing that verification detects an invalid signature/MAC, rather than testing that modifying the response makes the signature/MAC invalid.
It would be good to have tests for the security properties we're trying to provide:
1. If the introducer replaces the ephemeral public key, transport properties and/or timestamp and doesn't modify the ack, the protocol is aborted because the MAC fails
2. If the introducer replaces the ephemeral public key (and optionally the transport properties and/or timestamp) and modifies the ack to use a nonce and MAC key that match the new ephemeral public key, the protocol is aborted because the signature is invalid
Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/625Avoid repeated author status lookups2018-06-12T11:32:19ZakwizgranAvoid repeated author status lookupsWhen loading all post headers in a forum or blog, the author status is looked up for each post individually. The number of lookups could be reduced, especially for blogs, by first creating a set of authors and then looking up each author...When loading all post headers in a forum or blog, the author status is looked up for each post individually. The number of lookups could be reduced, especially for blogs, by first creating a set of authors and then looking up each author's status once.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/623Clean up progress bar handling in BlogActivity2018-06-12T11:32:19ZakwizgranClean up progress bar handling in BlogActivityBlogActivity uses a ViewPager with two FragmentStatePagerAdapters, one of which contains a single BlogFragment (which in turn contains its own RecyclerView adapter) and the other a series of BlogPostFragments. The two adapters allow the ...BlogActivity uses a ViewPager with two FragmentStatePagerAdapters, one of which contains a single BlogFragment (which in turn contains its own RecyclerView adapter) and the other a series of BlogPostFragments. The two adapters allow the blog to be viewed either as a feed or one post at a time.
The BlogFragment uses the RecyclerView's progress bar, whereas the BlogPostFragments rely on a progress bar in the BlogActivity. This complicates the interaction between the components and leads to a small bug when the BlogPostFragments are loading their posts: the progress bar is hidden when the first fragment finishes loading, even if the currently visible fragment is still loading.
Clean this up by moving the progress bar into the BlogPostFragment.
We should investigate other code that uses `BaseFragmentListener#show/hideLoadingScreen()` for similar problems. We may be able to simplify the interaction between components by making each component responsible for showing its own progress bar.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/622Transactional database interface2018-06-12T11:32:19ZakwizgranTransactional database interfaceCurrently the DB is guarded by a read-write lock: read-only transactions acquire the read lock and read-write transactions acquire the write lock. This ensures that we never get lock timeouts from the DB, so clients don't need to worry a...Currently the DB is guarded by a read-write lock: read-only transactions acquire the read lock and read-write transactions acquire the write lock. This ensures that we never get lock timeouts from the DB, so clients don't need to worry about rolling back and retrying transactions if there's a lock timeout. However, if a transaction performs long-running work such as verifying a signature, other transactions are prevented from accessing the database in the meantime.
We can avoid this by creating a transactional interface to the database, which encapsulates each transaction in a task object. Users of the database submit tasks, and the database is responsible for rolling back and retrying any tasks that time out. This allows us to remove the global read-write lock.
```
interface TransactionTask {
boolean run(Transaction txn) throws DbException;
}
```
The task's `run()` method performs DB operations using the provided transaction and returns true if the transaction should be committed or false if it should be aborted. If the `run()` method throws an exception, the transaction is aborted.
The DB has a method for running database tasks:
```
boolean runTask(TransactionTask task) throws DbException;
```
The database's `runTask()` method starts a transaction, passes it to the task, and commits or aborts it as required. The method returns true if the transaction was committed, false if it was aborted, or rethrows an exception thrown by the task.
We can remove the DB's `startTransaction()` and `endTransaction()` methods, along with the transaction's `setComplete()` method, since the DB itself will handle starting, committing and aborting transactions. It will no longer be necessary to specify whether a transaction is read-only or read-write.
Depends on #319.https://code.briarproject.org/briar/briar/-/issues/621NavDrawerActivity reads disk on UI thread, violating strict mode2018-06-12T11:32:19ZakwizgranNavDrawerActivity reads disk on UI thread, violating strict mode```
08-28 22:33:05.384 D/StrictMode(24991): StrictMode policy violation; ~duration=36 ms: android.os.StrictMode$StrictModeDiskReadViolation: policy=31 violation=2
08-28 22:33:05.384 D/StrictMode(24991): at android.os.StrictMode...```
08-28 22:33:05.384 D/StrictMode(24991): StrictMode policy violation; ~duration=36 ms: android.os.StrictMode$StrictModeDiskReadViolation: policy=31 violation=2
08-28 22:33:05.384 D/StrictMode(24991): at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1151)
08-28 22:33:05.384 D/StrictMode(24991): at android.app.SharedPreferencesImpl.awaitLoadedLocked(SharedPreferencesImpl.java:202)
08-28 22:33:05.384 D/StrictMode(24991): at android.app.SharedPreferencesImpl.getBoolean(SharedPreferencesImpl.java:259)
08-28 22:33:05.384 D/StrictMode(24991): at org.briarproject.android.NavDrawerActivity.welcomeMessageCheck(NavDrawerActivity.java:137)
08-28 22:33:05.384 D/StrictMode(24991): at org.briarproject.android.NavDrawerActivity.onCreate(NavDrawerActivity.java:124)
```Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/619Transaction is set complete unconditionally2018-06-12T11:32:19ZakwizgranTransaction is set complete unconditionallyValidationManagerImpl line 323:
```
} finally {
if (!txn.isComplete()) txn.setComplete();
db.endTransaction(txn);
}
```
This will commit the transaction even if an exception is thrown, which is probably not the intended be...ValidationManagerImpl line 323:
```
} finally {
if (!txn.isComplete()) txn.setComplete();
db.endTransaction(txn);
}
```
This will commit the transaction even if an exception is thrown, which is probably not the intended behaviour. Fix this and check for the same pattern being used elsewhere.Milestone Eakwizgranakwizgranhttps://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/617Protocol versioning2018-05-03T16:43:58ZakwizgranProtocol versioningAll protocols should include version information, and implementations should respond appropriately to versions they don't know how to handle.All protocols should include version information, and implementations should respond appropriately to versions they don't know how to handle.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/616Continue button is off-screen when adding a contact2018-06-12T11:32:20ZakwizgranContinue button is off-screen when adding a contactThe new explanatory graphics for adding a contact are great, but on a small screen (Sony Xperia Tipo, 320x480) the continue button is now off-screen. If I wasn't familiar with that screen I might not realise the button existed.
![devi...The new explanatory graphics for adding a contact are great, but on a small screen (Sony Xperia Tipo, 320x480) the continue button is now off-screen. If I wasn't familiar with that screen I might not realise the button existed.
![device-2016-08-25-122749](/uploads/b7524cb8d0aa65be698a4e329ac1946e/device-2016-08-25-122749.png)Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/615Forums: Keyboard stays open2018-06-12T11:32:20ZMegaloxForums: Keyboard stays openI wanted to reply but decided against and left the forums via backarrow. The keyboard stayed open.
![forum_keyboard_bug](/uploads/c417c600e6239e19fb00398080363f01/forum_keyboard_bug.jpg)I wanted to reply but decided against and left the forums via backarrow. The keyboard stayed open.
![forum_keyboard_bug](/uploads/c417c600e6239e19fb00398080363f01/forum_keyboard_bug.jpg)Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/614DevReporter does not close streams2018-06-12T11:32:20ZTorsten GroteDevReporter does not close streams```
08-24 13:33:16.448 E/StrictMode: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
java.lang.Throwable: Explicit t...```
08-24 13:33:16.448 E/StrictMode: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
java.lang.Throwable: Explicit termination method 'close' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:184)
at java.io.FileInputStream.<init>(FileInputStream.java:80)
at org.briarproject.reporting.DevReporterImpl.sendReports(DevReporterImpl.java:89)
at org.briarproject.plugins.tor.TorPlugin$1.run(TorPlugin.java:324)
```
Line 89 refers here to:
```java
in = new FileInputStream(f);
```Milestone Dakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/613Use metadata queries to look up introduction session state2018-04-28T00:17:21ZakwizgranUse metadata queries to look up introduction session stateSubtask of #376.Subtask of #376.Android 1.0Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/612Use metadata queries to look up invitation session state2018-06-11T10:24:35ZakwizgranUse metadata queries to look up invitation session stateSubtask of #376.Subtask of #376.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/611Body cache in ConversationActivity isn't thread-safe2018-06-12T11:32:20ZakwizgranBody cache in ConversationActivity isn't thread-safeChanges to ConversationActivity in June broke the thread-safety of the body cache. If it's going to be accessed from the UI and DB threads it should be a `final ConcurrentHashMap<MessageId, byte[]>` rather than a `volatile HashMap<Messag...Changes to ConversationActivity in June broke the thread-safety of the body cache. If it's going to be accessed from the UI and DB threads it should be a `final ConcurrentHashMap<MessageId, byte[]>` rather than a `volatile HashMap<MessageId, byte[]>`.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/610Result handlers can return results to destroyed activities/fragments2018-06-12T11:32:20ZakwizgranResult handlers can return results to destroyed activities/fragments@grote spotted this problem in !276, but it could happen anywhere a `ResultHandler` or `ResultExceptionHandler` is used. The activity or fragment that created the handler may be destroyed before the result or exception is handled.@grote spotted this problem in !276, but it could happen anywhere a `ResultHandler` or `ResultExceptionHandler` is used. The activity or fragment that created the handler may be destroyed before the result or exception is handled.Milestone ETorsten GroteTorsten Grote