Separate the sync layer from its clients. #112
This patch contains most of the work for #112. MessagingManager and ForumManager have been converted to BSP clients, and the sync layer's message and group formats no longer contain any client-specific data.
Each client has a MessageValidator that's called by the ValidationManager to validate messages belonging to the client. A new MessageValidatedEvent informs listeners when a message has been validated. This required some changes to the UI, especially the notification manager.
While working on the notification manager I realised it was calling Android API methods from background threads, which may be unsafe, and the notification logic was split across BriarService and AndroidNotificationManagerImpl. So I refactored those classes, along with AndroidExecutorImpl, which was using an unnecessary background thread.
Still to do:
* Synchronise blocks, not messages
* Add message type field to message header as per BSP spec
* Convert TransportPropertyManager into a BSP client
* Convert SubscriptionUpdates/Acks into forum client messages
See merge request !64
ENH: Replaces transport config with namespaced settings
This MR contains the following:
* Adds a new guice module: SettingsManager, that abstracts the settings interface from the underlying database
* Uses SettingsManager to replace the db.getConfig/mergeConfig calls in the Settings activity
* Replaces the getSettings and mergeSettings calls in the database modules to include a namespace parameter. Updates the corresponding queries in the Jdbc module
* Removes the TransportConfig module, as it is not used anymore
* Updates the DuplexPlugin interface, to reflect this change in schemas and calls
* Updates the calls in the corresponding plugins, for both briar-android and briar-desktop
* Updates the hardcoded plugins in the tests to reflect these changes and updates the unit tests.
See merge request !65
Do Bluetooth Adapter enabling/disabling in background thread
Also set the default preferences in a background thread when app starts.
Closes#184
See merge request !66
Offer option to uninstall Briar in a panic event (#211)
Due to the nature of how Android app uninstall works without root access, this requires manual confirmation after a panic event was triggered.
See merge request !63
Fix notifications for current conversation
* Remove notification about private messages when viewing the conversation
* Do not show a notification for a conversation the user is viewing
Closes#195
See merge request !61
Remove upstream jar files from all modules except briar-desktop
This also adds a script for running tests without the Android SDK installed
I've tried to find a better way to do this by conditionally including
the briar-android project in settings.gradle, but failed.
Please note that gradle needs to be installed to run the tests by
executing:
```
./run-tests-without-android.sh
```
See merge request !59
I've tried to find a better way to do this by conditionally including
the briar-android project in settings.gradle, but failed.
Please note that gradle needs to be installed to run the tests by
executing:
gradle test
Please note that this script uses the 'configuration on demand' feature
which is still incubating,
so not every test run is guaranteed to work correctly.
However, there have not been any problems so far.
Do not show messages as unread when the conversation is open
* Only show them as unread when they arrive out of order
* Mark all messages as read when sending a message
Closes#201
See merge request !62
Delete database as panic response even when signed out
The method `runOnDbThread()` depends on an executor
that's created by roboguice at startup.
It requires to be signed in, so use a different thread instead.
Closes#215
See merge request !60
The method `runOnDbThread()` depends on an executor
that's created by roboguice at startup.
It requires to be signed in, so use a different thread instead.
Add tests for metadata encoder and parser as well as UTF-8 tests for BDF reader and writer
This also includes a commit to fix issues found in the metadata encoder and parser.
See merge request !58
Use @Test annotation to test for exceptions being thrown (#213)
Please note that this commit only uses the @Test annotation
where exceptions are thrown at the end of the test,
because otherwise the test would not be executed completely.
Examples for this are in DatabaseComponentImplTest where many exceptions
are thrown in close succession or in ConnectionRegistryImplTest where an
exception is thrown in the middle of the test.
Closes#213
See merge request !57
Support for Destructive Panic Actions
This MR is based on and requires !52.
More details are available in the commit message.
All known issues have now been fixed by new upstream releases.
See merge request !54
Initial Support For PanicKit
This MR adds support for the PanicKit libary. It supports the basic default panic response (signing out) which does not require user interaction to work. For destructive panic responses, the user needs to "connect" the panic trigger app (e.g. Ripple) with Briar first. To secure this connection further, TrustedIntents have been added. Gradle Witness is being used to guarantee the integrity of external libraries.
Otherwise, this MR is pretty isolated and should not interfere with other parts of Briar. So merging it should be safe. However, the panic functionality still has rough edges and should not be relied on just now. It will mature along the the PanicKit library and the Ripple app.
Closes#204
See merge request !52
Please note that this commit only uses the @Test annotation
where exceptions are thrown at the end of the test,
because otherwise the test would not be executed completely.
Examples for this are in DatabaseComponentImplTest where many exceptions
are thrown in close succession or in ConnectionRegistryImplTest where an
exception is thrown in the middle of the test.
PanicKit does distinguish between two kinds of panic responses:
* default responses such as logging out which are non-destructive and
do not require user interaction, so that the basics work without
configuration
* destructive responses such as deleting user data. These require
some sort of authentication to make sure they are not triggered
by malicious apps
The second type of responses is implemented with this commit.
Authentication is done by comparing the package name
which is very weak. It requires the user to opt-in to
destructive responses and to configure from which app
to receive those (since there might be many different panic
trigger apps).
While possible to uninstall an app and install one with the same
package name afterwards, this always triggers notifications to
the user (if the attacker does not have root access).
Still that is no sufficient security for Briar's requirements,
so that TrustedIntents are used as well to make sure that the
app sending the destructive trigger is signed by a signing key
that we specified before. Currently, that is the one from the
GuardianProject and from IilabEngineering who does the Amnesty
International Panic App.
The responsibility of checking that the panic TRIGGER is
legitimate lies with the app responding to the trigger, so Briar
in this case. This commit checks whether the TRIGGER comes from
a trusted app before performing destructive actions,
but does perform the default action even when triggered from
untrusted apps.
Closes#210
Structured metadata. #112
Task #112 involves defining an interface between the sync protocol and its clients. To avoid the need for clients to keep their own databases, which could get out of step with the sync protocol's database, we're giving clients that ability to store metadata in the sync protocol's database.
Metadata can be associated with any message, channel, or client. Each metadata object is a simple map from strings to byte arrays. We'll provide a simple query interface to retrieve metadata and/or data by specifying a set of metadata keys. Basically we're building a shitty NoSQL database... erm, I mean, an enterprise-grade key-value store.
The basic metadata object is kind of Spartan, so this patch provides an encoder and parser for storing structured metadata. This gives clients an easy way to associate structured data with messages and channels, while leaving them the option of using their own encoding if they prefer.
This MR depends on !49.
See merge request !50
BdfList and BdfDictionary are no longer thread-safe, they require external locking. Metadata (which is the class that will be passed across API boundaries) is still thread-safe.
