briar issueshttps://code.briarproject.org/groups/briar/-/issues2018-06-12T11:32:20Zhttps://code.briarproject.org/briar/briar/-/issues/605Add database method for retrieving a contact by local and remote author IDs2018-06-12T11:32:20ZakwizgranAdd database method for retrieving a contact by local and remote author IDsMilestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/601Remove content type from forum posts2018-06-12T11:32:20ZakwizgranRemove content type from forum postsThe content type field is unused and we don't yet have a plan for when it will be used. Remove it until it's needed.The content type field is unused and we don't yet have a plan for when it will be used. Remove it until it's needed.https://code.briarproject.org/briar/briar/-/issues/600Remove content type from private messages2018-06-12T11:32:20ZakwizgranRemove content type from private messagesThe content type field is unused and we don't yet have a plan for when it will be used. Remove it until it's needed.The content type field is unused and we don't yet have a plan for when it will be used. Remove it until it's needed.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/599Fetch RSS feeds via Tor2018-06-12T11:32:20ZakwizgranFetch RSS feeds via TorUse the localhost Socks proxy to fetch the feeds. The proxy port is currently set in briar-android and would need to be moved to core or api.
The `FeedManager` should listen to `TransportEnabledEvent`s and enable the feed fetching sch...Use the localhost Socks proxy to fetch the feeds. The proxy port is currently set in briar-android and would need to be moved to core or api.
The `FeedManager` should listen to `TransportEnabledEvent`s and enable the feed fetching scheduler when Tor is started first. For simplicity, it should not turn off the scheduler when Tor gets turned off, but let the fetch job fail cleanly when Tor is not running.
We should use stream isolation to ensure the lookups for different feeds happen over different circuits. This is done by specifying a different SOCKS username and password for each feed (any username and password can be used, they just need to be different - generating them on the fly would be fine).Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/598Remove unused code and layouts for old blog implementation2018-06-12T11:32:20ZakwizgranRemove unused code and layouts for old blog implementationIf we decide we need them in future, they'll still be in git.If we decide we need them in future, they'll still be in git.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/595Clients should decide whether to share messages2018-06-12T11:32:20ZakwizgranClients should decide whether to share messagesThe validation manager currently sets all messages as shared after delivering them. Clients should specify which messages to share, for example by returning a boolean from the delivery hook or calling DatabaseComponent#setMessageShared()...The validation manager currently sets all messages as shared after delivering them. Clients should specify which messages to share, for example by returning a boolean from the delivery hook or calling DatabaseComponent#setMessageShared() from within the delivery hook.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/592Scrub addresses before logging them2018-06-12T11:32:20ZakwizgranScrub addresses before logging themMAC, IP and onion addresses should be scrubbed before logging to ensure we don't leave any sensitive information in plaintext on the device or send it in crash reports or feedback.
We need to keep enough information for the addresses ...MAC, IP and onion addresses should be scrubbed before logging to ensure we don't leave any sensitive information in plaintext on the device or send it in crash reports or feedback.
We need to keep enough information for the addresses to be useful for debugging, without harming user privacy. Perhaps something like the following:
* MAC addresses (including Bluetooth): keep the first and last octets, replace the rest with XX
* Link-local and site-local IPv4 addresses: keep the full address
* Other IPv4 addresses: keep the first and last octets, replace the rest with XX
* IPv6 addresses: not intentionally used by Briar, replace the whole thing with XX
* Onion addresses: keep the first three characters, replace the rest with XXMilestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/591Add New Message Types to BlogValidator2018-06-12T11:32:20ZTorsten GroteAdd New Message Types to BlogValidatorSub-Ticket of #494 and #437.Sub-Ticket of #494 and #437.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/589When a message is shared, share its transitive dependencies2018-06-12T11:32:20ZakwizgranWhen a message is shared, share its transitive dependenciesLike other recursive operations on the dependency graph, this should not be done in a single transaction. So we'll need to find and resume any unfinished operations at startup, by looking for shared messages with unshared dependencies.Like other recursive operations on the dependency graph, this should not be done in a single transaction. So we'll need to find and resume any unfinished operations at startup, by looking for shared messages with unshared dependencies.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/586Store latest timestamp and unread count in group metadata for invitations2018-06-12T11:32:21ZakwizgranStore latest timestamp and unread count in group metadata for invitationsThe contact list loads all invitation messages just to get the latest timestamp and unread message count for each conversation. This is a very expensive provess that involves loading the session state for every message, which in the wors...The contact list loads all invitation messages just to get the latest timestamp and unread message count for each conversation. This is a very expensive provess that involves loading the session state for every message, which in the worst case iterates over all sessions. Store this information in the group metadata and expose it through the SharingManager interface.
The timestamp should relate to the latest message that would be visible in the UI, i.e. invitations and responses.
Related to #373.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/585Store latest timestamp and unread count in group metadata for introductions2018-06-12T11:32:21ZakwizgranStore latest timestamp and unread count in group metadata for introductionsThe contact list loads all introduction messages just to get the latest timestamp and unread message count for each conversation. This is a very expensive provess that involves loading the session state for every introduction message, wh...The contact list loads all introduction messages just to get the latest timestamp and unread message count for each conversation. This is a very expensive provess that involves loading the session state for every introduction message, which in the worst case iterates over all sessions. Store this information in the group metadata and expose it through the IntroductionManager interface.
Related to #373.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/584Store latest timestamp and unread count in group metadata for private messaging2018-06-12T11:32:21ZakwizgranStore latest timestamp and unread count in group metadata for private messagingThe contact list loads all private message headers just to get the latest timestamp and unread message count for each conversation. Store this information in the group metadata and expose it through the MessagingManager interface.
Rel...The contact list loads all private message headers just to get the latest timestamp and unread message count for each conversation. Store this information in the group metadata and expose it through the MessagingManager interface.
Related to #373.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/575Fix SharerLeavesBeforeResponse Test2018-06-12T11:32:21ZTorsten GroteFix SharerLeavesBeforeResponse TestThis test was broken by a51d2f47af7674fef8c97aac631608daee675ae6This test was broken by a51d2f47af7674fef8c97aac631608daee675ae6Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/573Setup Onion Service for Crash Reports and Feedback2018-06-12T11:32:21ZTorsten GroteSetup Onion Service for Crash Reports and FeedbackLooks like the onion service we had running is down now:
```
08-02 20:04:51.596 W/DevReporterImpl: Could not connect to developers
Host unreachable
at ne...Looks like the onion service we had running is down now:
```
08-02 20:04:51.596 W/DevReporterImpl: Could not connect to developers
Host unreachable
at net.sourceforge.jsocks.socks.Socks5Message.read(Socks5Message.java:162)
at net.sourceforge.jsocks.socks.Socks5Message.<init>(Socks5Message.java:123)
at net.sourceforge.jsocks.socks.Socks5Message.<init>(Socks5Message.java:108)
at net.sourceforge.jsocks.socks.Socks5Proxy.formMessage(Socks5Proxy.java:253)
at net.sourceforge.jsocks.socks.Proxy.exchange(Proxy.java:458)
at net.sourceforge.jsocks.socks.Proxy.connect(Proxy.java:343)
at net.sourceforge.jsocks.socks.SocksSocket.<init>(SocksSocket.java:109)
at org.briarproject.reporting.DevReporterImpl.connectToDevelopers(DevReporterImpl.java:50)
at org.briarproject.reporting.DevReporterImpl.sendReports(DevReporterImpl.java:84)
at org.briarproject.plugins.tor.TorPlugin$1.run(TorPlugin.java:371)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
at java.lang.Thread.run(Thread.java:856)
```
I know that some of my testers already used the crash reporter. I had to tell them that I am not sure that these reports are already read by someone.Milestone Cakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/569Convert HTML to plain text safely and readably2018-06-12T11:32:21ZakwizgranConvert HTML to plain text safely and readablyFor RSS import we need to convert HTML blog posts into plain text while preserving readability, and without allowing any unsafe content to be rendered. For RSS import we need to convert HTML blog posts into plain text while preserving readability, and without allowing any unsafe content to be rendered. Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/566Raise minimum Android version to 42018-06-12T11:32:21ZakwizgranRaise minimum Android version to 4* Raise minimum API version to 14
* Remove any code and resources that only apply to older versions
* Close as rejected any tickets that only apply to older versions
* Raise minimum API version to 14
* Remove any code and resources that only apply to older versions
* Close as rejected any tickets that only apply to older versions
Milestone Dhttps://code.briarproject.org/briar/briar/-/issues/558Use namespaced strings for transport IDs2018-06-12T11:32:22ZakwizgranUse namespaced strings for transport IDsAdd a namespace to the strings used to identify transports. The IDs could follow the same convention as Java packages, e.g. `org.briarproject.bramble.bluetooth`. This would allow independent developers to assign IDs without collisions.
...Add a namespace to the strings used to identify transports. The IDs could follow the same convention as Java packages, e.g. `org.briarproject.bramble.bluetooth`. This would allow independent developers to assign IDs without collisions.
Potential downside: more data to store in QR codes.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/557Use namespaced strings for client IDs2018-06-12T11:32:22ZakwizgranUse namespaced strings for client IDsInstead of random unique IDs, use namespaced strings to identify clients. The IDs could follow the same convention as Java packages, e.g. `org.briarproject.briar.messaging`. This would allow independent developers to assign IDs without c...Instead of random unique IDs, use namespaced strings to identify clients. The IDs could follow the same convention as Java packages, e.g. `org.briarproject.briar.messaging`. This would allow independent developers to assign IDs without collisions.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/554Audit uses of ResultHandler2018-06-12T11:32:22ZakwizgranAudit uses of ResultHandler* Controllers should depend on ResultHandler/ResultExceptionHandler, not UiResultHandler/UiResultExceptionHandler, to allow us to use synchronous handlers when unit testing controllers
* Handlers shouldn't return true if everything went...* Controllers should depend on ResultHandler/ResultExceptionHandler, not UiResultHandler/UiResultExceptionHandler, to allow us to use synchronous handlers when unit testing controllers
* Handlers shouldn't return true if everything went fine or false if there was an exception - use ResultExceptionHandler if the UI needs to know about failures, and ResultExceptionHandler\<Void\> if it doesn'tMilestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/552Check thread safety of MessageTree2018-06-12T11:32:22ZakwizgranCheck thread safety of MessageTreeMilestone E