briar issueshttps://code.briarproject.org/groups/briar/-/issues2018-06-12T11:32:17Zhttps://code.briarproject.org/briar/briar/-/issues/701Refactor message serialisation code out of briar-api2018-06-12T11:32:17ZakwizgranRefactor message serialisation code out of briar-apiThe SharingMessage, BlogSharingMessage and ForumSharingMessage classes in briar-api contain a mixture of interface declaration, serialisation code and factory code. Most of this code should be refactored into briar-core.The SharingMessage, BlogSharingMessage and ForumSharingMessage classes in briar-api contain a mixture of interface declaration, serialisation code and factory code. Most of this code should be refactored into briar-core.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/612Use metadata queries to look up invitation session state2018-06-11T10:24:35ZakwizgranUse metadata queries to look up invitation session stateSubtask of #376.Subtask of #376.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/369Remove UiCallback interface2018-06-11T10:16:35ZakwizgranRemove UiCallback interfaceThis interface is an ancient throwback. Plugins that need to call back into the UI should use specialised callback interfaces provided by their factories.This interface is an ancient throwback. Plugins that need to call back into the UI should use specialised callback interfaces provided by their factories.https://code.briarproject.org/briar/briar/-/issues/25Replace JNotify with WatchService2018-05-31T09:01:35ZakwizgranReplace JNotify with WatchServiceDesktophttps://code.briarproject.org/briar/briar/-/issues/772Set up Maven repo2018-05-23T10:30:01ZakwizgranSet up Maven repoInitially this will just serve the Bramble jars so that Briar can depend on them. Eventually we should serve reproducible builds of all our dependencies from this repo, with no external dependencies.
Subtask of #136.Initially this will just serve the Bramble jars so that Briar can depend on them. Eventually we should serve reproducible builds of all our dependencies from this repo, with no external dependencies.
Subtask of #136.akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/164Research reproducible builds with Gradle2018-05-11T14:21:26ZakwizgranResearch reproducible builds with GradleFor dependencies that don't require patches against upstream, it would be nice to manage the dependencies through Gradle rather than keeping the jars in our repo. But our long-term plan is to have reproducible builds, so every dependency...For dependencies that don't require patches against upstream, it would be nice to manage the dependencies through Gradle rather than keeping the jars in our repo. But our long-term plan is to have reproducible builds, so every dependency should either be built from source or use an upstream binary with a reproducible build process. Find out whether this is possible with Gradle dependencies.https://code.briarproject.org/briar/briar/-/issues/783Make build process meet f-droid norms (no binaries)2018-05-11T14:19:12ZGreg TroxelMake build process meet f-droid norms (no binaries)(This ticket is not about actually getting briar into f-droid.)
Currently, the build downloads binaries, at least tor. My understanding is that f-droid, as part of reproducible builds, wants apps to build from source.
In addition to ...(This ticket is not about actually getting briar into f-droid.)
Currently, the build downloads binaries, at least tor. My understanding is that f-droid, as part of reproducible builds, wants apps to build from source.
In addition to f-droid issues, not being able to build tor from source easily makes it harder to debug #769.https://code.briarproject.org/briar/briar/-/issues/1152Tests for briar-android use stale bramble-android artifact2018-05-11T13:47:26ZakwizgranTests for briar-android use stale bramble-android artifactThe tests for the briar-android module use a cached version of the bramble-android AAR, which may be stale. They should use the AAR created by the bramble-android module during the same build.
On my system the cached AAR is loaded from ...The tests for the briar-android module use a cached version of the bramble-android AAR, which may be stale. They should use the AAR created by the bramble-android module during the same build.
On my system the cached AAR is loaded from `~/.gradle/caches`.
The issue is visible when changing between branches where the Dagger modules exposed by bramble-android have changed. For example, try adding an argument to `AndroidPluginModule#providePluginConfig()`, running the tests, then switching to a branch that doesn't have the change and running the tests again.
Running `gradle clean` doesn't help, perhaps because the cached AAR is outside the build directory.
!666 was an attempt to fix this, but it doesn't seem to have worked.
We've had issues in the past with Briar releases including stale versions of Bramble. Could that have been caused by the same issue?akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/175Sync blocks rather than messages2018-05-11T13:29:53ZakwizgranSync blocks rather than messagesAt this stage we only need to support single-block messages.At this stage we only need to support single-block messages.https://code.briarproject.org/briar/briar/-/issues/249Support multi-block messages2018-05-11T13:29:32ZakwizgranSupport multi-block messagesDepends on #175.Depends on #175.https://code.briarproject.org/briar/briar/-/issues/617Protocol versioning2018-05-03T16:43:58ZakwizgranProtocol versioningAll protocols should include version information, and implementations should respond appropriately to versions they don't know how to handle.All protocols should include version information, and implementations should respond appropriately to versions they don't know how to handle.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/237Create client for negotiating supported clients2018-04-29T16:28:05ZakwizgranCreate client for negotiating supported clientsIn future we'll add support for new clients (blogs, group messaging) and we'll need to know which contacts support those clients. Create a BSP client supported by all versions of Briar that syncs a list of supported clients with each con...In future we'll add support for new clients (blogs, group messaging) and we'll need to know which contacts support those clients. Create a BSP client supported by all versions of Briar that syncs a list of supported clients with each contact. The list should include a device ID for future multi-device support.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1163Check whether our key agreement procotols assume contributory behaviour2018-04-28T13:38:03ZakwizgranCheck whether our key agreement procotols assume contributory behaviourWe're migrating to Curve25519 for key agreement, and RFC 7748 [warns](https://tools.ietf.org/html/rfc7748#section-7) that protocols based on Curve25519 should not assume contributory behaviour:
> Protocol designers using Diffie-Hellman ...We're migrating to Curve25519 for key agreement, and RFC 7748 [warns](https://tools.ietf.org/html/rfc7748#section-7) that protocols based on Curve25519 should not assume contributory behaviour:
> Protocol designers using Diffie-Hellman over the curves defined in this document must not assume "contributory behaviour". Specially, contributory behaviour means that both parties' private keys contribute to the resulting shared key. Since curve25519 and curve448 have cofactors of 8 and 4 (respectively), an input point of small order will eliminate any contribution from the other party's private key. This situation can be detected by checking for the all-zero output, which implementations MAY do, as specified in Section 6. However, a large number of existing implementations do not do this.
The Curve25519 website also has a [warning](https://cr.yp.to/ecdh.html#validate):
> There are some unusual non-Diffie-Hellman elliptic-curve protocols that need to ensure ``contributory'' behavior. In those protocols, you should reject the 32-byte strings that, in little-endian form, represent 0, 1, 325606250916557431795983626356110631294008115727848805560023387167927233504 (which has order 8), 39382357235489614581723060781553021112529911719440698176882885853963445705823 (which also has order 8), 2^255 - 19 - 1, 2^255 - 19, 2^255 - 19 + 1, 2^255 - 19 + 325606250916557431795983626356110631294008115727848805560023387167927233504, 2^255 - 19 + 39382357235489614581723060781553021112529911719440698176882885853963445705823, 2(2^255 - 19) - 1, 2(2^255 - 19), and 2(2^255 - 19) + 1. But these exclusions are unnecessary for Diffie-Hellman.
It's not clear to me whether the special public keys listed in the second quote will produce the all-zero output as described in the first quote. This is something we can confirm, and we can check for the all-zero output in our usage of Curve25519. But for defence in depth we should also check whether our key agreement protocols (BQP, the contact exchange protocol and the introduction protocol) assume contributory behaviour.
One thing we need to clarify is whether hashing both public keys into the shared secret (which we already do) is enough to ensure contributory behaviour.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/613Use metadata queries to look up introduction session state2018-04-28T00:17:21ZakwizgranUse metadata queries to look up introduction session stateSubtask of #376.Subtask of #376.Android 1.0Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/377Replace BDF data structures with classes in introduction client2018-04-28T00:17:04ZakwizgranReplace BDF data structures with classes in introduction clientThe introduction client uses BdfDictionary and BdfList for its internal data structures, rather than just for serialisation. This tends to push type checking from compile time to run time. Create classes to represent the client's interna...The introduction client uses BdfDictionary and BdfList for its internal data structures, rather than just for serialisation. This tends to push type checking from compile time to run time. Create classes to represent the client's internal state.Android 1.0Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/108Set up offline build box2018-04-28T00:16:04ZakwizgranSet up offline build boxThe build box should be air-gapped as it will have access to the APK signing key, which can never be changed.The build box should be air-gapped as it will have access to the APK signing key, which can never be changed.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/376Refactor clients based on ProtocolEngine2018-04-28T00:12:24ZakwizgranRefactor clients based on ProtocolEngineThe ProtocolEngine interface allows certain tasks to be performed in response to local actions and incoming messages: updating local state, sending messages, broadcasting events and deleting the incoming message. Clients based on Protoco...The ProtocolEngine interface allows certain tasks to be performed in response to local actions and incoming messages: updating local state, sending messages, broadcasting events and deleting the incoming message. Clients based on ProtocolEngine that need to perform other tasks are forced to store a task label in the local state, then retrieve it and perform the task outside the engine. This defeats the purpose of the engine interface, which is meant to encapsulate the protocol logic.
Alter or remove the ProtocolEngine interface so clients have the flexibility they need.Android 1.0Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1190Shut down cleanly when phone is shutting down or memory is low2018-04-23T10:44:40ZakwizgranShut down cleanly when phone is shutting down or memory is lowListen for `ACTION_SHUTDOWN` and `QUICKBOOT_POWEROFF` broadcasts and try to shut down the background service cleanly before the phone powers off.
Similarly, try to shut down the service cleanly before the process is killed if `BriarServ...Listen for `ACTION_SHUTDOWN` and `QUICKBOOT_POWEROFF` broadcasts and try to shut down the background service cleanly before the phone powers off.
Similarly, try to shut down the service cleanly before the process is killed if `BriarService#onLowMemory()` is called.Android Beta 2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/112Separate data sync protocol (BSP) from clients2018-04-16T16:24:37ZakwizgranSeparate data sync protocol (BSP) from clientsThe current clients of the data sync protocol are:
* Transport properties
* Private messages
* Forums
The current clients of the data sync protocol are:
* Transport properties
* Private messages
* Forums
Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/174Rename classes, methods, fields with BSP nomenclature2018-04-16T16:24:37ZakwizgranRename classes, methods, fields with BSP nomenclatureThis is going to touch a lot of code, but shouldn't make any functional changes.
Subtask of #112.This is going to touch a lot of code, but shouldn't make any functional changes.
Subtask of #112.Milestone Aakwizgranakwizgran