briar issueshttps://code.briarproject.org/groups/briar/-/issues2019-10-16T16:19:19Zhttps://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/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/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/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/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/1546Support Bluetooth discovery for connecting to contacts2022-01-26T13:50:35ZakwizgranSupport Bluetooth discovery for connecting to contactsOn Android 8+ apps don't have access to the device's own Bluetooth address, so we can't share our address with contacts. When adding contacts we use discovery to work around this (#1147). Users have reported that Bluetooth works when add...On Android 8+ apps don't have access to the device's own Bluetooth address, so we can't share our address with contacts. When adding contacts we use discovery to work around this (#1147). Users have reported that Bluetooth works when adding contacts, but not when subsequently trying to communicate.
Learning our Bluetooth address from contacts would raise some tricky security and privacy issues, such as revealing to existing contacts, by adding a Bluetooth address to our transport properties, that we've just added a contact via Bluetooth.
After adding a contact we could store the contact's address for subsequent connection attempts, but that would only let us connect to contacts who were added via Bluetooth. To let us connect to any nearby contact we need to make the device discoverable and perform discovery.
Making the device temporarily discoverable requires user confirmation each time. Making the device permanently discoverable has privacy implications, and doesn't work on all devices (e.g. the Sony Xperia Tipo). Discovering nearby devices may require a lot of power and may interfere with wifi (#699). BLE discovery uses less power and doesn't require user confirmation, but not all devices can be discovered via BLE (#303).
A possible solution would be to make the device temporarily discoverable, and perform discovery, when the user enables the Bluetooth transport (#185). Then we could provide some way of manually triggering discovery, such as a "nearby contacts" tab with a "scan" button. This would limit the discoverability window, and the battery and interference impact of running discovery, to periods when the user had explicitly shown an interest in connecting to nearby contacts. Confirmation dialogs would only be shown in response to user actions.
This falls short of the goal of effortless connectivity, but it may be the best we can achieve within the constraints of the platform.https://code.briarproject.org/briar/briar/-/issues/1545Account lost when upgrading2020-11-16T10:37:22ZakwizgranAccount lost when upgradingA user reported that their account was lost when upgrading to Briar 1.1.5 via F-Droid.
1.1.5 was the first version available via the main F-Droid repo since 1.0.1, so it's possible this is a duplicate of #1219. I'll close this ticket if...A user reported that their account was lost when upgrading to Briar 1.1.5 via F-Droid.
1.1.5 was the first version available via the main F-Droid repo since 1.0.1, so it's possible this is a duplicate of #1219. I'll close this ticket if we don't get any more reports.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1538Generate and store handshake key pair at startup if necessary2019-05-16T13:02:40ZakwizgranGenerate and store handshake key pair at startup if necessarySubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1537Implement contact manager methods for pending contacts2019-05-13T09:04:51ZakwizgranImplement contact manager methods for pending contactsSubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1536Find out whether intent extras or instance state bundles are persisted by the OS2019-04-22T13:30:11ZakwizgranFind out whether intent extras or instance state bundles are persisted by the OSSince roughly Android 5, the recent apps list has been persisted across reboots. Find out whether intent extras or instance state bundles for the activities in the recent apps list are persisted. If so, this might leak confidential infor...Since roughly Android 5, the recent apps list has been persisted across reboots. Find out whether intent extras or instance state bundles for the activities in the recent apps list are persisted. If so, this might leak confidential information to disk.Android 1.1https://code.briarproject.org/briar/briar/-/issues/1535Tryin to import SharedPreferences into AccountManagerImpl2019-04-19T14:54:16ZnicedeveloperTryin to import SharedPreferences into AccountManagerImplTryin to import SharedPreferences into AccountManagerImpl in package package org.briarproject.bramble.account;
SharedPreferences highlights RedTryin to import SharedPreferences into AccountManagerImpl in package package org.briarproject.bramble.account;
SharedPreferences highlights Redhttps://code.briarproject.org/briar/briar/-/issues/1534No Blog notifications2019-04-18T08:01:37ZGhost UserNo Blog notificationsI've been using briar for a bit as my primary RSS feed reader. It's worked very well, until a few weeks ago (can't pinpoint exactly when) when the blog stopped updating itself in the background or otherwise didn't notify me of new entrie...I've been using briar for a bit as my primary RSS feed reader. It's worked very well, until a few weeks ago (can't pinpoint exactly when) when the blog stopped updating itself in the background or otherwise didn't notify me of new entries like it did. I've checked my notification settings, and it is supposed to notify, and I've had the battery settings set to "Not Optimized" since installation.
What can I do to help diagnose this issue?Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1532Upgrade obfs4proxy to 0.0.102020-09-23T14:08:29ZakwizgranUpgrade obfs4proxy to 0.0.10Version 0.0.10 of obfs4proxy has some changes that might make it harder to distinguish meek_lite from ordinary TLS connections.
https://lists.torproject.org/pipermail/tor-dev/2019-April/013776.htmlVersion 0.0.10 of obfs4proxy has some changes that might make it harder to distinguish meek_lite from ordinary TLS connections.
https://lists.torproject.org/pipermail/tor-dev/2019-April/013776.htmlAndroid 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1530images doesn't get sent even after changing 'hasSupport' to true2019-04-10T13:58:50Zaleximages doesn't get sent even after changing 'hasSupport' to trueWhen attempting to send an image, an overlay comes with
> "Images unavailable" "Your contact's Briar does not yet support image attachments. Once they upgrade you'll see a different icon."
Then, I changed the constant `FEATURE_FLAG_IM...When attempting to send an image, an overlay comes with
> "Images unavailable" "Your contact's Briar does not yet support image attachments. Once they upgrade you'll see a different icon."
Then, I changed the constant `FEATURE_FLAG_IMAGE_ATTACHMENTS` to `TRUE` in TestingConstants.java
With no luck, So I changed the following code -> (in android/conversation/conversationActivity.java - Line 267)
```
observeOnce(viewModel.hasImageSupport(), this, hasSupport -> {
if (hasSupport != null && hasSupport) {
// remove cast when removing FEATURE_FLAG_IMAGE_ATTACHMENTS
((TextAttachmentController) sendController)
.setImagesSupported();
}
});
```
to
```
((TextAttachmentController) sendController).setImagesSupported();
```
also, as another attempt with the same manner, I left the code as is but I changed the value of `hasSupport=true` manually ;
After that , whenever sending an image, nothing goes and only 'null' is sent.
knowing that the same version of the build is used in both android devises.
Is it a bug ? or i am lacking something important ?
in both cases i'd love hearing from you.
By the way, thank you for this great application !https://code.briarproject.org/briar/briar/-/issues/1529Introduction accept/decline buttons don't work for second attempt2019-04-05T12:56:47ZakwizgranIntroduction accept/decline buttons don't work for second attemptSteps to reproduce:
* Add devices A and B as contacts
* Add devices B and C as contacts
* B offers to introduce A to C
* A accepts
* C declines
* B offers to introduce A to C again (A and C must receive the new offers before their screen...Steps to reproduce:
* Add devices A and B as contacts
* Add devices B and C as contacts
* B offers to introduce A to C
* A accepts
* C declines
* B offers to introduce A to C again (A and C must receive the new offers before their screens turn off)
* Expected: A and C can use the accept and decline buttons
* Actual: The accept and decline buttons are unresponsive until the screen has been turned off and on (sometimes it's necessary to leave and re-enter the conversation)
I suspect this is a view recycling issue - IIRC we disable the buttons after they've been pressed once, to avoid issues with multiple taps. If the view gets recycled, I guess the buttons are still disabled.
I saw this while testing !1067, but I don't think it was introduced by that branch - I've seen it before but never came up with steps to reproduce it. It might also happen for forum/blog/group invitations.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1528Database has no tables after reinstalling via ADB2020-03-10T15:03:26ZakwizgranDatabase has no tables after reinstalling via ADBAfter reinstalling Briar via ADB, I saw the startup failure notification and the log showed that the settings table didn't exist:
```
org.briarproject.bramble.api.db.DbException: org.h2.jdbc.JdbcSQLException: Table "SETTINGS" not found;...After reinstalling Briar via ADB, I saw the startup failure notification and the log showed that the settings table didn't exist:
```
org.briarproject.bramble.api.db.DbException: org.h2.jdbc.JdbcSQLException: Table "SETTINGS" not found; SQL statement:
SELECT settingKey, value FROM settings WHERE namespace = ? [42102-192]
at org.briarproject.bramble.db.JdbcDatabase.getSettings(JdbcDatabase.java:2169)
at org.briarproject.bramble.db.JdbcDatabase.open(JdbcDatabase.java:355)
at org.briarproject.bramble.db.H2Database.open(H2Database.java:65)
at org.briarproject.bramble.db.DatabaseComponentImpl.open(DatabaseComponentImpl.java:112)
at org.briarproject.bramble.lifecycle.LifecycleManagerImpl.startServices(LifecycleManagerImpl.java:108)
at org.briarproject.briar.android.BriarService.lambda$onCreate$0(BriarService.java:132)
at org.briarproject.briar.android.-$$Lambda$BriarService$Ihm6XxaER2EMRlAKzUA1GpEtxZU.run(Unknown Source:4)
at java.lang.Thread.run(Thread.java:764)
```
A similar problem was previously mentioned [here](https://code.briarproject.org/briar/briar/issues/1367#note_31102), but most of that discussion referred to a different problem that's now been fixed.
The problem occurred after installing a debug build (0f614e84) on the Nexus 5X via ADB, launching the build, performing some actions such as adding and removing a contact, signing out, and installing a new build (d40cfd30) via ADB. When I launched the new build, the startup failure notification was shown.
Subsequent lauches showed the same error. The db.mv.db file exists, with a size of 28672 bytes, and Briar can open it, but the DB contains no tables ("SHOW TABLES" returns the expected table names on an unaffected device, but no table names on this device). It seems like nothing was written to the DB file during the first session, after the point where the DB file was created.
Two other devices (Moto G 4G and Moto E3) that were used for testing the same builds didn't show the bug, so I don't think it's caused by these particular builds.Android 1.2akwizgranakwizgran