briar issueshttps://code.briarproject.org/briar/briar/-/issues2019-05-14T11:16:36Zhttps://code.briarproject.org/briar/briar/-/issues/1566Investigate whether equivalent public keys can damage the security of handsha...2019-05-14T11:16:36ZakwizgranInvestigate whether equivalent public keys can damage the security of handshake modeSome ECDH public keys are equivalent, in the sense that multiplying them by the same scalar produces the same point. If an attacker sends us a handshake public key that's equivalent to a contact's handshake public key, we'll fail to dete...Some ECDH public keys are equivalent, in the sense that multiplying them by the same scalar produces the same point. If an attacker sends us a handshake public key that's equivalent to a contact's handshake public key, we'll fail to detect that it's the same key (see #1565) and derive the same handshake mode transport keys. The attacker won't be able to derive the keys, but we'll use the same keys for handshaking with the contact and trying to handshake with the attacker.
This shouldn't affect confidentiality, integrity or authenticity, as we use a unique random nonce with the stream header key, but it could affect protocol obfuscation by using the same tags for sending streams to the contact and the attacker.
Work out whether this attack is possible, and if so, whether we can detect and prevent it.
Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1565UX for handling duplicate handshake links2019-10-16T16:19:19ZakwizgranUX for handling duplicate handshake linksIf Mallory knows Bob's handshake link, she may send it to Alice pretending it's Mallory's own link, in order to discover whether Alice and Bob are contacts/pending contacts.
When adding a pending contact we should check whether a contac...If Mallory knows Bob's handshake link, she may send it to Alice pretending it's Mallory's own link, in order to discover whether Alice and Bob are contacts/pending contacts.
When adding a pending contact we should check whether a contact/pending contact with the same handshake public key exists. If so, we should ask the user whether the new pending contact and the existing contact/pending contact are the same person. If yes, we discard the new pending contact. If no, we tell the user that two contacts sent the same link, which could mean that one of them is trying to discover who the user's contacts are, and we warn the user not to tell either or them that someone else sent the same link. Then we discard the new pending contact.
If we support more than one link format in future, Mallory may change the format of Bob's link before sending it to Alice, so we should compare the parsed public keys or public key hashes rather than the unparsed links.
Subtask of #1230.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1564Publish hidden service for connecting to pending contact2019-06-10T13:48:57ZakwizgranPublish hidden service for connecting to pending contactSubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1563DozeView disappears when rotating screen after whitelisting Briar2020-11-15T18:27:59ZakwizgranDozeView disappears when rotating screen after whitelisting BriarSteps to reproduce:
* Use a device with Android 6+
* Ensure Briar isn't whitelisted for doze
* Create a new account
* In the power management setup screen, tap "Allow Connections" and accept the dialog
* Rotate the screen
* Expected: The...Steps to reproduce:
* Use a device with Android 6+
* Ensure Briar isn't whitelisted for doze
* Create a new account
* In the power management setup screen, tap "Allow Connections" and accept the dialog
* Rotate the screen
* Expected: The layout stays the same
* Actual: The "Allow Connections" button (with its check mark and help button) disappears
* Use the back button to return to the password setup screen
* Expected: The layout is the same as before
* Actual: The "Next" button changes to "Create Account"
The unexpected layout changes happen because we re-check whether we're whitelisted.
If the fragment instances are retained across rotations, perhaps the password and doze fragments could remember the whitelisting state when they were first created, and use that to control the text of the password fragment's "Next" / "Create Account" button and the visibilty of DozeView, so that they stay the same after we're whitelisted, while using the current whitelisting state to show/hide the "Allow Connections" button's check mark and enable/disable the power management fragment's "Create Account" button, which are the bits that are supposed to change when we're whitelisted.https://code.briarproject.org/briar/briar/-/issues/1562Improve handling of external intents2022-05-26T15:49:41ZTorsten GroteImprove handling of external intentsUse `ENTRY_ACTIVITY` from !1087 as a central router for external intents:
> Not signed into Briar. The password screen is shown, then after signing in the remote contact activity is shown, as expected. The contact's link field is empty....Use `ENTRY_ACTIVITY` from !1087 as a central router for external intents:
> Not signed into Briar. The password screen is shown, then after signing in the remote contact activity is shown, as expected. The contact's link field is empty. If I use the up button to navigate away from the remote contact screen or the pending contact list, the task is closed. I'd expect to navigate to the contact list when pressing the up button. If I don't use the up button to navigate away, then later reopen Briar from the foreground notification, a second Briar task is created. I assume the same would happen with private message notifications, etc - the issue being that the notification expects us to have a task that can be reused by clearing the stack down to NavDrawerActivity, but the existing task doesn't have that activity in its stack.
There's also some other issues with AddContactActivity to resolve:
> If an instance of AddContactActivity already exists it's brought to the foreground but the link isn't populated (I'm assuming this is because the new intent is delivered without calling onCreate() again).
>
> If I open the remote contact activity via the speed dial, then put Briar into the background via the home button and relaunch via the ongoing notification, the contact list appears as expected. But when I back out, the remote contact activity and another instance of the contact list are underneath.
>
> Similarly, if I open the remote contact activity with a share intent, then press the home button, relaunch via the ongoing notification, and back out of the contact list, the remote contact activity is underneath (but without the second instance of the contact list).
>
> Finally, if I open the remote contact activity with a share intent, then back out or press the up button, the task is cleared. If I relaunch via recent apps, the remote contact activity is shown again. Backing out or pressing the up button clears the task again, so I can't reach the rest of the app!
Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1561SimplexMessagingIntegrationTest.testWriteAndRead assertion error2019-06-03T14:58:32ZiwakehSimplexMessagingIntegrationTest.testWriteAndRead assertion error```testWriteAndRead``` (in o.bp.b.m.SimplexMessagingIntegrationTest) fails sometimes.
```
testWriteAndRead
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.juni...```testWriteAndRead``` (in o.bp.b.m.SimplexMessagingIntegrationTest) fails sometimes.
```
testWriteAndRead
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.briarproject.briar.messaging.SimplexMessagingIntegrationTest.testWriteAndRead(SimplexMessagingIntegrationTest.java:99)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
```
First those failures seemed random, but looking closer ```testWriteAndRead``` passes when the gradle daemon does the first run (e.g. after killing the daemon process) whereas consecutive runs fail with the above error (the assertion tests that the listener received a message).
Happens on the latest master (df5ac59fc91f498f9979d1ccf8cc0d69f99f8cf5) with gradle 5.4 and also with the previously used gradle 4.10.2 (dc649b195a24d871f7864a7c68fd291295297e8c).
Might be that the tearDown method needs to do more than just delete the test directory, but that's a wild first guess.Android 1.1akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1560test results of ForumSharingIntegrationTest depend on test execution order2019-06-10T13:47:58Ziwakehtest results of ForumSharingIntegrationTest depend on test execution orderI came across this by chance, but the changes (diff below) make the problem reproducible.
Steps to reproduce:
Running ```testInviteeLeavesAfterFinished``` before ```testSharerLeavesAfterFinished``` will lead to the following test failu...I came across this by chance, but the changes (diff below) make the problem reproducible.
Steps to reproduce:
Running ```testInviteeLeavesAfterFinished``` before ```testSharerLeavesAfterFinished``` will lead to the following test failure:
```java
java.lang.AssertionError: expected:<1> but was:<0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at org.briarproject.briar.sharing.ForumSharingIntegrationTest.testSharerLeavesBeforeResponse(ForumSharingIntegrationTest.java:396)
...
```
(just one example, there are more test orders to reproduce this)
code to reproduce:
```diff
index 987a78d20..2b042455f 100644
--- a/briar-core/src/test/java/org/briarproject/briar/sharing/ForumSharingIntegrationTest.java
+++ b/briar-core/src/test/java/org/briarproject/briar/sharing/ForumSharingIntegrationTest.java
@@ -43,6 +43,8 @@ import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertNull;
import static org.junit.Assert.assertTrue;
+import org.junit.FixMethodOrder;
+import org.junit.runners.MethodSorters;@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class ForumSharingIntegrationTest
extends BriarIntegrationTest<BriarIntegrationTestComponent> {
@@ -235,7 +237,7 @@ public class ForumSharingIntegrationTest
}
@Test
- public void testInviteeLeavesAfterFinished() throws Exception {
+ public void test1InviteeLeavesAfterFinished() throws Exception {
// initialize and let invitee accept all requests
listenToEvents(true);
@@ -292,7 +294,7 @@ public class ForumSharingIntegrationTest
}
@Test
- public void testSharerLeavesAfterFinished() throws Exception {
+ public void test2SharerLeavesAfterFinished() throws Exception {
// initialize and let invitee accept all requests
listenToEvents(true);
```
Suggestion: prepare each test in ForumSharingIntegrationTest without relying on any state created by other tests.Android 1.1akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1559Avoid using third parties' resources for testing and maybe enable offline tes...2020-11-15T18:28:22ZiwakehAvoid using third parties' resources for testing and maybe enable offline testing```testFeedImportAndRemoval``` uses a third party blog feed for testing.
1) Maybe, rather use briar's own resources instead of Schneier's blog, e.g. simply supply a static test feed on briarproject's server or use https://code.briarproj...```testFeedImportAndRemoval``` uses a third party blog feed for testing.
1) Maybe, rather use briar's own resources instead of Schneier's blog, e.g. simply supply a static test feed on briarproject's server or use https://code.briarproject.org/briar/briar.atom.
2) This way of testing will fail when the testing machine is offline, which is not the aim of the test. So, avoiding internet access here might be a better solution and would also support to introduce test cases for feed content that could trip briar functionality.https://code.briarproject.org/briar/briar/-/issues/1558ViewModelModule is breaking package encapsulation2021-04-30T13:38:33ZTorsten GroteViewModelModule is breaking package encapsulationThe ViewModelModule is breaking package encapsulation. Let's refactor the ViewModel bindings into the respective packages and cleaning them up.The ViewModelModule is breaking package encapsulation. Let's refactor the ViewModel bindings into the respective packages and cleaning them up.https://code.briarproject.org/briar/briar/-/issues/1557invalid checksum for j2objc-annotations-1.1.jar2019-05-14T10:18:23Ziwakehinvalid checksum for j2objc-annotations-1.1.jarWhen running gradle it complains about the following:
> A problem occurred configuring project ':bramble-core'.
> Checksum failed for com.google.j2objc:j2objc-annotations:1.1:j2objc-annotations-1.1.jar
Well, the checksum in all witness...When running gradle it complains about the following:
> A problem occurred configuring project ':bramble-core'.
> Checksum failed for com.google.j2objc:j2objc-annotations:1.1:j2objc-annotations-1.1.jar
Well, the checksum in all witness.gradle files (bramble-{android|java|core} and briar-{headless|android|core}) is
``40ceb7157feb263949e0f503fe5f71689333a621021aa20ce0d0acee3badaa0f``,
but two sample downloads from repo1.maven and jcenter have
``2994a7eb78f2710bd3d3bfb639b2c94e219cedac0d4d084d516e78c16dddecf6``
as sha256sum. The corresponding gpg signatures were correct.
Which special j2objc-annotations-1.1.jar is used in briar?
Or, do the checksums need adaption?Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1556Add support for handshake keys to KeyManager2019-06-03T14:59:09ZakwizgranAdd support for handshake keys to KeyManagerPart of #1232.Part of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1555Factor out BriarActionBarActivity for ActionBar handling2020-11-15T18:31:40ZTorsten GroteFactor out BriarActionBarActivity for ActionBar handlingFrom https://code.briarproject.org/briar/briar/merge_requests/1035#note_36028
Push action bar handling code up into a BriarActionBarActivity and make current activities using it inherit it.
```java
ActionBar ab = getSupportActionBar();...From https://code.briarproject.org/briar/briar/merge_requests/1035#note_36028
Push action bar handling code up into a BriarActionBarActivity and make current activities using it inherit it.
```java
ActionBar ab = getSupportActionBar();
if (ab != null) {
ab.setDisplayHomeAsUpEnabled(true);
}
```
`onOptionsItemSelected()`https://code.briarproject.org/briar/briar/-/issues/1554Allow pending contacts to be removed any time2019-05-24T14:50:04ZTorsten GroteAllow pending contacts to be removed any timeCurrently, we only allow the user to remove pending contacts when adding them remotely failed. However, the user might want to remove them even earlier, because they changed their mind about adding this contact for example.Currently, we only allow the user to remove pending contacts when adding them remotely failed. However, the user might want to remove them even earlier, because they changed their mind about adding this contact for example.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1553Option to revert screen filter setting2020-11-15T18:32:09ZakwizgranOption to revert screen filter settingA user asked for the ability to revert the decision to allow certain apps to draw on top of Briar.A user asked for the ability to revert the decision to allow certain apps to draw on top of Briar.https://code.briarproject.org/briar/briar/-/issues/1552RuntimeException: Use controllers to enable/disable2019-05-01T09:38:54ZakwizgranRuntimeException: Use controllers to enable/disable* Android version: 5.0
* Briar version: 1.1.6 (debug build, no commit hash)
* Phone model: Samsung SM-N900W8 (hlteub)
* User feedback: "Trabajo."
Stacktrace:
```
java.lang.RuntimeException: Use controllers to enable/disable
at o...* Android version: 5.0
* Briar version: 1.1.6 (debug build, no commit hash)
* Phone model: Samsung SM-N900W8 (hlteub)
* User feedback: "Trabajo."
Stacktrace:
```
java.lang.RuntimeException: Use controllers to enable/disable
at org.briarproject.briar.android.view.TextInputView.setEnabled(TextInputView.java:102)
at org.briarproject.briar.android.privategroup.conversation.GroupActivity.setGroupEnabled(GroupActivity.java:201)
at org.briarproject.briar.android.privategroup.conversation.GroupActivity.onCreate(GroupActivity.java:86)
at android.app.Activity.performCreate(Activity.java:6288)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1119)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2646)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2758)
at android.app.ActivityThread.access$900(ActivityThread.java:177)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1448)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:145)
at android.app.ActivityThread.main(ActivityThread.java:5942)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1399)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1194)
```
This report comes from a debug build with an unknown commit ID, so the bug may not exist on master. Feel free to remove the ticket from the milestone or close it if the stack trace doesn't seem to match the code on master.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1551Optional sent and read receipts2022-11-18T17:06:30ZakwizgranOptional sent and read receiptsSeveral users have asked for the ability to see when a contact has read a message, with the contact having a setting to control whether this information is sent.
A Google Play user asked for messages to show two timestamps: the time sen...Several users have asked for the ability to see when a contact has read a message, with the contact having a setting to control whether this information is sent.
A Google Play user asked for messages to show two timestamps: the time sent (on one side of the message bubble) and the time received (on the other side).
I think we've discussed this in the past but I can't find the ticket.https://code.briarproject.org/briar/briar/-/issues/1550Relay encrypted messages between contacts2020-11-15T18:44:35ZakwizgranRelay encrypted messages between contactsSeveral users have suggested that Briar should relay encrypted messages between contacts, so that users who can't communicate directly can pass messages through mutual contacts.
This would have implications for battery and bandwidth con...Several users have suggested that Briar should relay encrypted messages between contacts, so that users who can't communicate directly can pass messages through mutual contacts.
This would have implications for battery and bandwidth consumption. If message propagation was restricted then it would also have privacy implications (Alice could see that Bob and Carol were both sending messages at 3am, when nobody else was sending anything). If message propagation was unrestricted then the battery and bandwidth impact would be hard to control - this would affect scalability and enable flooding attacks. Fair queueing might help to mitigate flooding attacks (#511).
One user suggested that the privacy impact could be mitigated through fine-grained controls (e.g. Bob and Carol would only choose Alice to relay their messages if they didn't mind her knowing when they were communicating). I'm skeptical about whether most people can predict and manage their privacy needs at that granularity in advance, but I could be wrong.https://code.briarproject.org/briar/briar/-/issues/1549Release beta versions via F-Droid2020-11-15T18:45:20ZakwizgranRelease beta versions via F-DroidA user asked for beta versions to be released via F-Droid.
Currently we make releases in two stages. In the first stage (beta tag) the release is made available for direct download, via our F-Droid repo, and to Google Play beta testers....A user asked for beta versions to be released via F-Droid.
Currently we make releases in two stages. In the first stage (beta tag) the release is made available for direct download, via our F-Droid repo, and to Google Play beta testers. In the second stage (release tag) it's made available via the main F-Droid repo and to all Google Play users.
It would be nice if (a) beta releases weren't marked as recommended in our F-Droid repo, and (b) beta releases were made available, but not marked as recommended, in the main F-Droid repo.https://code.briarproject.org/briar/briar/-/issues/1548Chat with Tor Browser users via hidden service2020-11-15T18:45:55ZakwizgranChat with Tor Browser users via hidden serviceUser feedback: "It would be a realy cool feature for Briar if one could generate a .onion link that one can share over another channel (basically like OnionShare), that would then open a text chat in the Tor Browser to allow communicatio...User feedback: "It would be a realy cool feature for Briar if one could generate a .onion link that one can share over another channel (basically like OnionShare), that would then open a text chat in the Tor Browser to allow communication with other platforms than Android."https://code.briarproject.org/briar/briar/-/issues/1547Public roadmap2021-02-17T01:04:48ZakwizgranPublic roadmapUser feedback: "It would be nice if your web site listed planned versions and added features so users could know what capabilities are in the pipeline."
The closest we currently have is this:
https://code.briarproject.org/briar/briar/w...User feedback: "It would be nice if your web site listed planned versions and added features so users could know what capabilities are in the pipeline."
The closest we currently have is this:
https://code.briarproject.org/briar/briar/wikis/product-backlogCleopatraCleopatra