briar issueshttps://code.briarproject.org/groups/briar/-/issues2020-11-15T10:37:10Zhttps://code.briarproject.org/briar/briar/-/issues/929Non-blocking SettingsManager2020-11-15T10:37:10ZakwizgranNon-blocking SettingsManagerThe SettingsManager interface is inconvenient to use because it needs to be called on the DB thread. Make the interface non-blocking by loading settings at startup and writing them back to the DB in the background when they're updated.The SettingsManager interface is inconvenient to use because it needs to be called on the DB thread. Make the interface non-blocking by loading settings at startup and writing them back to the DB in the background when they're updated.https://code.briarproject.org/briar/briar/-/issues/917Testers did not understand who could be invited to private groups2020-11-19T15:34:00ZakwizgranTesters did not understand who could be invited to private groupsTesters asked whether they could invite users who weren't their contacts to a group, and whether an invited member could invite her contacts. They eventually worked out what was possible but were initially confused.
Related to #801, #81...Testers asked whether they could invite users who weren't their contacts to a group, and whether an invited member could invite her contacts. They eventually worked out what was possible but were initially confused.
Related to #801, #811 and #855.https://code.briarproject.org/briar/briar/-/issues/901Improve key binding in contact exchange protocol2020-11-19T15:35:33ZakwizgranImprove key binding in contact exchange protocolThe contact exchange protocol provides the following guarantees:
* Each party knows that the ephemeral and identity public keys she received are owned by the other party
* Each party knows that the ephemeral and identity public keys she ...The contact exchange protocol provides the following guarantees:
* Each party knows that the ephemeral and identity public keys she received are owned by the other party
* Each party knows that the ephemeral and identity public keys she received were used by the other party in the same run of the protocol - in other words it binds each party's ephemeral key pair to the same party's identity key pair and vice versa
* Each party knows that the ephemeral public key she received was used by the other party in the current run of the protocol - in other words it binds the parties' ephemeral key pairs to each other
To achieve this, each party uses her identity key pair to sign a nonce derived from the ephemeral shared secret, and authenticates the signed nonce using a symmetric key derived from the ephemeral shared secret.
Each party knows that the nonce she received is fresh, as it depends on her own ephemeral key pair, so the nonce itself proves that the other party owns the ephemeral public key received by the first party, while the signature proves that the other party owns the identity public key received by the first party.
The nonce is unique to this combination of ephemeral key pairs, so the signature represents a claim by the owner of the received identity public key that she took part in a protocol run involving both ephemeral key pairs. Authenticating the signed nonce with a symmetric key derived from the ephemeral shared secret represents a claim by the owner of the received ephemeral public keys that she took part in a protocol run involving both ephemeral key pairs and the identity key pair.
As far as I can tell, this construction is secure and achieves what we need, but it's unnecessarily convoluted. The binding and proof of ownership that's achieved by signing nonces could be achieved more straightforwardly by signing public keys:
* Each party signs both parties' ephemeral public keys and timestamps using her identity key pair
* Each party authenticates both parties' identity public keys, ephemeral public keys and timestamps, using a symmetric key derived from the ephemeral shared secret
If we're not concerned with deniability, each party can sign both parties' identity public keys, ephemeral public keys and timestamps. But as far as I can see, we get all the assurance we need without doing this.
Related to #902.https://code.briarproject.org/briar/briar/-/issues/826Online status in group memberlist2020-11-21T12:40:34ZTorsten GroteOnline status in group memberlistThe group member list shows the online status of contacts. As of MR !448, it only shows the online status of contacts, we actually share with to be consistent with the sharing information in the group's action bar.
This can be confusing...The group member list shows the online status of contacts. As of MR !448, it only shows the online status of contacts, we actually share with to be consistent with the sharing information in the group's action bar.
This can be confusing since some group members have online status and others don't.https://code.briarproject.org/briar/briar/-/issues/825Show an error message if no transports are available for adding contacts2020-11-21T12:41:36ZakwizgranShow an error message if no transports are available for adding contactshttps://code.briarproject.org/briar/briar/-/issues/786Handle whitespace consistently2022-11-18T17:24:07ZakwizgranHandle whitespace consistentlyText with leading or trailing whitespace is treated inconsistently:
* Nicknames: whitespace isn't trimmed, whitespace-only names are allowed
* Private messages: whitespace is trimmed, whitespace-only messages are allowed but become empt...Text with leading or trailing whitespace is treated inconsistently:
* Nicknames: whitespace isn't trimmed, whitespace-only names are allowed
* Private messages: whitespace is trimmed, whitespace-only messages are allowed but become empty after trimming
* Forum names: whitespace isn't trimmed, whitespace-only names are allowed
* Forum invitations: whitespace isn't trimmed, whitespace-only messages are allowed
* Forum posts: whitespace is trimmed, whitespace-only posts aren't allowed
* Private group names: whitespace isn't trimmed, whitespace-only names are allowed
* Private group invitations: whitespace isn't trimmed, whitespace-only messages are allowed
* Private group posts: whitespace is trimmed, whitespace-only posts aren't allowed
* Blog posts: whitespace is trimmed, whitespace-only posts are allowed but become empty after trimming
* Blog comments: whitespace isn't trimmed, whitespace-only comments are allowed
Let's do the following everywhere:
When entering text:
1. Trim leading and trailing whitespace
2. If the trimmed text is empty and the input is optional (for example a blog comment), pass null to the backend
3. If the trimmed text is empty and the input isn't optional (for example a blog post), don't accept the input
4. If the trimmed text is too long, don't accept the input
5. If the trimmed text isn't empty or too long, pass it to the backend
When validating messages (including author names and group names):
1. Reject null if the text isn't optional
2. Reject the text if it's empty or too long
3. Reject the text if it has leading or trailing whitespacehttps://code.briarproject.org/briar/briar/-/issues/776Merge redundant null safety annotations2020-11-21T16:19:21ZakwizgranMerge redundant null safety annotationsAfter some experience with the new null safety annotations, it seems we only want to express two conditions:
* Methods, parameters and fields are not null by default
* Methods and parameters are not null by default
Merge @MethodsNotNull...After some experience with the new null safety annotations, it seems we only want to express two conditions:
* Methods, parameters and fields are not null by default
* Methods and parameters are not null by default
Merge @MethodsNotNullByDefault with @ParametersNotNullByDefault, and remove @FieldsNotNullByDefault.https://code.briarproject.org/briar/briar/-/issues/773Tidy up message inheritance hierarchy2020-11-21T16:21:14ZakwizgranTidy up message inheritance hierarchyBlogPost extends ForumPost extends ThreadedMessage extends PrivateMessage... really?BlogPost extends ForumPost extends ThreadedMessage extends PrivateMessage... really?https://code.briarproject.org/briar/briar/-/issues/770Configure or patch Tor to minimise background traffic2020-11-16T11:09:52ZakwizgranConfigure or patch Tor to minimise background trafficSee whether there are any config settings or hardcoded constants that can be adjusted to reduce Tor's background traffic. Related to #44, #45, #479.See whether there are any config settings or hardcoded constants that can be adjusted to reduce Tor's background traffic. Related to #44, #45, #479.https://code.briarproject.org/briar/briar/-/issues/753Listener interfaces have mixed responsibilities2021-01-20T12:34:20ZakwizgranListener interfaces have mixed responsibilitiesThe UI makes heavy use of listener interfaces that inherit from either DestroyableContext or BaseFragmentListener. These are used for various purposes:
* Callbacks from a controller to the UI (e.g. `TransportStateListener#stateUpdate()`...The UI makes heavy use of listener interfaces that inherit from either DestroyableContext or BaseFragmentListener. These are used for various purposes:
* Callbacks from a controller to the UI (e.g. `TransportStateListener#stateUpdate()`)
* Injecting dependencies into fragments (`BaseFragmentListener#getActivityComponent()`)
* Manipulating other parts of the UI (e.g. `CreateGroupListener#showSoftKeyboard()`)
* Running tasks (`DestroyableContext#runOnUiThreadUnlessDestroyed()`, `BaseFragmentListener#runOnDbThread()` (deprecated))
These different purposes would ideally be separated into different interfaces. Maybe it would clarify things if communication from controllers back to the UI used the "listener" name and communication between fragments and their activities used some other name.
Listeners are usually provided by casting an Activity or Context (passed to `ActivityLifecycleController#onActivityCreate()` or `Fragment#onAttach()`) to an arbitrary listener interface. This is a bit of a hack - it would be nice if we could provide listeners in a type-safe way, for example by injection.
Related to #752.https://code.briarproject.org/briar/briar/-/issues/745Refactor redundant code in AndroidNotificationManagerImpl2020-11-21T16:26:13ZakwizgranRefactor redundant code in AndroidNotificationManagerImplAndroidNotificationManagerImpl contains blocks of nearly identical code for doing things like counting new messages per-group or per-contact, and blocking or unblocking notifications per-client. These could be refactored to reduce redund...AndroidNotificationManagerImpl contains blocks of nearly identical code for doing things like counting new messages per-group or per-contact, and blocking or unblocking notifications per-client. These could be refactored to reduce redundancy.
(ConnectionRegistryImpl also contains similar code for counting connections per-contact. Maybe this could be factored out into a separate `Counter<T>` class.)https://code.briarproject.org/briar/briar/-/issues/744Use global constants for View's alpha values2020-11-21T16:27:13ZErnir ErlingssonUse global constants for View's alpha valuesIn several places in the app we're decreasing the opacity of views to represent things such as disabled states. Unfortunately, we're doing this through hard-coded float values at each location. We should rather use global constants and m...In several places in the app we're decreasing the opacity of views to represent things such as disabled states. Unfortunately, we're doing this through hard-coded float values at each location. We should rather use global constants and make sure that every occurrence uses them -- this will make it easier for us to modify it in the future to fit any design pattern.https://code.briarproject.org/briar/briar/-/issues/743Create a controller for ConversationActivity to encapsulate the UI code2020-11-21T16:27:52ZErnir ErlingssonCreate a controller for ConversationActivity to encapsulate the UI codehttps://code.briarproject.org/briar/briar/-/issues/730Remove redundant setup code from jMock tests2020-11-21T16:29:33ZakwizgranRemove redundant setup code from jMock testsIt's safe to reuse a Mockery and mocked objects across multiple tests - if unexpected or missing invocations cause a test to fail, the expectations are reset before running the next test. Setup code can therefore be moved from the indivi...It's safe to reuse a Mockery and mocked objects across multiple tests - if unexpected or missing invocations cause a test to fail, the expectations are reset before running the next test. Setup code can therefore be moved from the individual tests to the class in many cases.https://code.briarproject.org/briar/briar/-/issues/729Blog posts should be created on the crypto executor2020-11-21T16:34:09ZakwizgranBlog posts should be created on the crypto executorWriteBlogPostActivity creates blog posts on the DB executor. They should be created on the crypto executor and stored on the DB executor using chaining.
(BlogManagerImpl similarly creates comments on the DB executor, but that would be m...WriteBlogPostActivity creates blog posts on the DB executor. They should be created on the crypto executor and stored on the DB executor using chaining.
(BlogManagerImpl similarly creates comments on the DB executor, but that would be much harder to disentangle.)https://code.briarproject.org/briar/briar/-/issues/728Don't change list indices during validation2020-11-23T11:39:37ZakwizgranDon't change list indices during validationSome validation hooks pop the message type off the list representing the message body before validating the remaining items. This is due to poorly written specs that didn't include the message type in the list. The list should be left un...Some validation hooks pop the message type off the list representing the message body before validating the remaining items. This is due to poorly written specs that didn't include the message type in the list. The list should be left unmodified for easier comparison with the corrected spec.https://code.briarproject.org/briar/briar/-/issues/711Improve encapsulation between ThreadItemAdapter and ThreadItemViewHolder2020-11-21T16:38:55ZTorsten GroteImprove encapsulation between ThreadItemAdapter and ThreadItemViewHolderAs discussed in [!350](https://code.briarproject.org/akwizgran/briar/merge_requests/350#note_13731), the new `ThreadItemAdapter` should need to be accessed so heavily in the `ThreadItemViewHolder` when it is bound to a view.As discussed in [!350](https://code.briarproject.org/akwizgran/briar/merge_requests/350#note_13731), the new `ThreadItemAdapter` should need to be accessed so heavily in the `ThreadItemViewHolder` when it is bound to a view.https://code.briarproject.org/briar/briar/-/issues/706Migrate crypto to libsodium2020-11-21T16:39:44ZakwizgranMigrate crypto to libsodiumUsing libsodium via JNI would give us constant-time implementations of Curve25519 and Ed25519 (see #236) and a fast implementation of Argon2 (see #170). Our crypto_secretbox implementation could be replaced, and we could use crypto_box i...Using libsodium via JNI would give us constant-time implementations of Curve25519 and Ed25519 (see #236) and a fast implementation of Argon2 (see #170). Our crypto_secretbox implementation could be replaced, and we could use crypto_box instead of ECIES for crash reports and feedback. BLAKE2s would remain in Java (libsodium only has BLAKE2b). If we replaced the Fortuna generator with libsodium's RNG, we could get rid of Bouncy Castle.
https://github.com/joshjdevl/libsodium-jnihttps://code.briarproject.org/briar/briar/-/issues/704Use constructor injection where possible2020-11-21T16:59:46ZakwizgranUse constructor injection where possibleClasses that don't require special constructors (pretty much everything except Activities, Fragments and Views) should use constructor injection rather than field injection. This allows us to make the fields final, so we don't have to wo...Classes that don't require special constructors (pretty much everything except Activities, Fragments and Views) should use constructor injection rather than field injection. This allows us to make the fields final, so we don't have to worry about whether they're been initialised or whether they should be volatile, and the class can be annotated @NotNullByDefault.https://code.briarproject.org/briar/briar/-/issues/702Improve encapsulation of ViewHolder classes2020-11-21T17:01:14ZakwizgranImprove encapsulation of ViewHolder classesEach BriarAdapter subclass has its own subclass of RecyclerView.ViewHolder. Some of these ViewHolder classes have public fields. Improve the encapsulation of these classes, either by adding accessor methods or by moving the code that acc...Each BriarAdapter subclass has its own subclass of RecyclerView.ViewHolder. Some of these ViewHolder classes have public fields. Improve the encapsulation of these classes, either by adding accessor methods or by moving the code that accesses the fields into the respective classes.