briar issueshttps://code.briarproject.org/groups/briar/-/issues2018-06-12T11:32:19Zhttps://code.briarproject.org/briar/briar/-/issues/635Touching the author of the currently open blog opens another copy2018-06-12T11:32:19ZakwizgranTouching the author of the currently open blog opens another copyTouching the author of the currently open blog opens another activity showing the same blog.
There are two ways we could handle this: replace the current activity if the author is the same, or replace the current activity in all cases (...Touching the author of the currently open blog opens another activity showing the same blog.
There are two ways we could handle this: replace the current activity if the author is the same, or replace the current activity in all cases (so that pressing the back button once takes us back to the combined feed, however many blogs we've browsed through). I can see arguments for either solution and I don't mind which one we choose.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/634Blog title is not set when opening a blog by touching the author2018-06-12T11:32:19ZakwizgranBlog title is not set when opening a blog by touching the authorWhen navigating to a blog by touching the author, the title of the activity is "Briar" rather than the title of the blog.
![device-2016-09-02-120010](/uploads/c8b993bcfc6cf786f6c8ea9b86854518/device-2016-09-02-120010.png)When navigating to a blog by touching the author, the title of the activity is "Briar" rather than the title of the blog.
![device-2016-09-02-120010](/uploads/c8b993bcfc6cf786f6c8ea9b86854518/device-2016-09-02-120010.png)Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/633Blog posts from other users sometimes have bold nicknames2018-06-12T11:32:19ZakwizgranBlog posts from other users sometimes have bold nicknamesThis is a screenshot from the Sony Xperia Tipo (nickname Sony, Moto is the nickname of a contact).
![device-2016-09-02-120010](/uploads/271d983a3dda8e15532f93bdf503db6a/device-2016-09-02-120010.png)This is a screenshot from the Sony Xperia Tipo (nickname Sony, Moto is the nickname of a contact).
![device-2016-09-02-120010](/uploads/271d983a3dda8e15532f93bdf503db6a/device-2016-09-02-120010.png)Milestone ETorsten GroteTorsten Grotehttps://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/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/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/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/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 Grotehttps://code.briarproject.org/briar/briar/-/issues/607Don't clear lists in onPause()2018-06-12T11:32:20ZakwizgranDon't clear lists in onPause()Various activities and fragments clear their lists in onPause() and asynchronously repopulate them in onResume(). This results in the appearance of the list briefly changing as the user navigates away.
For lists where items are never ...Various activities and fragments clear their lists in onPause() and asynchronously repopulate them in onResume(). This results in the appearance of the list briefly changing as the user navigates away.
For lists where items are never removed, we can leave the list populated in onPause() and asynchronously add any new items in onResume(). This will allow the views for existing items to be recycled.
For lists where items can be removed while the activity/fragment is paused, we'll need another solution. Clearing and then asynchronously repopulating the list in onResume() may result in the old contents being briefly visible, then disappearing, then the new contents appearing. Asynchronously loading the new contents in onResume() and then replacing the old contents (using a batched update to avoid flicker) may be acceptable as long as we gracefully handle any attempts to interact with items that are due to be removed.
See discussion on !276.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/605Add database method for retrieving a contact by local and remote author IDs2018-06-12T11:32:20ZakwizgranAdd database method for retrieving a contact by local and remote author IDsMilestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/601Remove content type from forum posts2018-06-12T11:32:20ZakwizgranRemove content type from forum postsThe content type field is unused and we don't yet have a plan for when it will be used. Remove it until it's needed.The content type field is unused and we don't yet have a plan for when it will be used. Remove it until it's needed.