briar issueshttps://code.briarproject.org/groups/briar/-/issues2018-06-12T11:32:17Zhttps://code.briarproject.org/briar/briar/-/issues/681Convert forum post bodies to strings, remove content type2018-06-12T11:32:17ZakwizgranConvert forum post bodies to strings, remove content typeMilestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/674Ending a transaction can throw an exception in a finally block2018-06-12T11:32:18ZakwizgranEnding a transaction can throw an exception in a finally blockWe use the following pattern to commit or roll back a transaction:
```
Transaction txn = db.startTransaction();
try {
db.doSomething(txn);
txn.setComplete();
} finally {
db.endTransaction(txn);
}
```
`DatabaseComponent#endTr...We use the following pattern to commit or roll back a transaction:
```
Transaction txn = db.startTransaction();
try {
db.doSomething(txn);
txn.setComplete();
} finally {
db.endTransaction(txn);
}
```
`DatabaseComponent#endTransaction()` can throw a `DbException`, and Android Studio warns about the potential for the exception to be thrown in a finally block.
We should move the exception-throwing code from `endTransaction()` into a new `commitTransaction()` method, which replaces `Transaction#setComplete()` and is called inside the try block. The new contract of `endTransaction()` should be to abort the transaction if it has not already been committed, and release the database lock in either case.
```
Transaction txn = db.startTransaction();
try {
db.doSomething(txn);
db.commitTransaction(txn);
} finally {
db.endTransaction(txn);
}
```Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/673PrivateGroupManager facade2018-06-12T11:32:18ZakwizgranPrivateGroupManager facadeCreate a PrivateGroupManager interface in briar-api, with a stub implementation in briar-core, to allow development of the UI. The interface can be based on the existing ForumManager, with supporting classes for message headers, etc, as ...Create a PrivateGroupManager interface in briar-api, with a stub implementation in briar-core, to allow development of the UI. The interface can be based on the existing ForumManager, with supporting classes for message headers, etc, as required.
Subtask of #127.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/670Uncaught exceptions do not print a stack trace in IntroductionIntegrationTest2018-06-12T11:32:18ZSantiago Torres-AriasUncaught exceptions do not print a stack trace in IntroductionIntegrationTestErrors and uncaught exceptions do not print a stack trace unless a try/catch block is added for NPE. This is a followup for the discussion in !237Errors and uncaught exceptions do not print a stack trace unless a try/catch block is added for NPE. This is a followup for the discussion in !237Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/669Integration tests need to know the client ID of MessageStateChangedEvents2018-06-12T11:32:18ZakwizgranIntegration tests need to know the client ID of MessageStateChangedEventsRecent refactoring of the validation manager removed the client ID from MessageStateChangedEvents, because these events are only used by tests and a lot of code in the validation manager and DB existed just to attach client IDs to these ...Recent refactoring of the validation manager removed the client ID from MessageStateChangedEvents, because these events are only used by tests and a lot of code in the validation manager and DB existed just to attach client IDs to these events. This has made the tests fail unpredictably.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/659Protocol for private group invitations2018-06-12T11:32:18ZakwizgranProtocol for private group invitationsThis could be similar to the blog and forum invitation protocols, but there's an opportunity to make it simpler, as only the creator of the group can send invitations. When a member has been added or removed, the creator should send an a...This could be similar to the blog and forum invitation protocols, but there's an opportunity to make it simpler, as only the creator of the group can send invitations. When a member has been added or removed, the creator should send an announcement to the group (see #658).
Related to #456. Subtask of #127.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/658Protocol for private group messaging2018-06-12T11:32:18ZakwizgranProtocol for private group messagingThis can be similar to the forum protocol, plus messages for announcing when members join and leave. We may not need a message for announcing that the group has been dissolved, as that may be part of the invitation protocol.
Posts will ...This can be similar to the forum protocol, plus messages for announcing when members join and leave. We may not need a message for announcing that the group has been dissolved, as that may be part of the invitation protocol.
Posts will need to be compared with the current membership list to ensure they're signed by members, taking into account the possibility of posts and membership messages arriving out of order.
Subtask of #127.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/643Allow messages to be deleted in the delivery hook2018-06-12T11:32:19ZakwizgranAllow messages to be deleted in the delivery hookIf a client deletes a message in the delivery hook, the validation manager treats the message as invalid. Clients may want to delete messages they've finished handlng without having them invalidated, so we should provide some other way f...If a client deletes a message in the delivery hook, the validation manager treats the message as invalid. Clients may want to delete messages they've finished handlng without having them invalidated, so we should provide some other way for the delivery hook to signal that a message is invalid, such as throwing an InvalidMessageException.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/642Remove loading screen callbacks from BaseFragmentListener2018-06-12T11:32:19ZakwizgranRemove loading screen callbacks from BaseFragmentListenerFragments should be responsible for their own progress bars.Fragments should be responsible for their own progress bars.Milestone Ehttps://code.briarproject.org/briar/briar/-/issues/627Tests for Introduction Security Properties2018-06-12T11:32:19ZTorsten GroteTests for Introduction Security PropertiesWhen testing the introduction protocol, it makes sense to use a real MAC and signature, otherwise we're just testing that verification detects an invalid signature/MAC, rather than testing that modifying the response makes the signature/...When testing the introduction protocol, it makes sense to use a real MAC and signature, otherwise we're just testing that verification detects an invalid signature/MAC, rather than testing that modifying the response makes the signature/MAC invalid.
It would be good to have tests for the security properties we're trying to provide:
1. If the introducer replaces the ephemeral public key, transport properties and/or timestamp and doesn't modify the ack, the protocol is aborted because the MAC fails
2. If the introducer replaces the ephemeral public key (and optionally the transport properties and/or timestamp) and modifies the ack to use a nonce and MAC key that match the new ephemeral public key, the protocol is aborted because the signature is invalid
Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/625Avoid repeated author status lookups2018-06-12T11:32:19ZakwizgranAvoid repeated author status lookupsWhen loading all post headers in a forum or blog, the author status is looked up for each post individually. The number of lookups could be reduced, especially for blogs, by first creating a set of authors and then looking up each author...When loading all post headers in a forum or blog, the author status is looked up for each post individually. The number of lookups could be reduced, especially for blogs, by first creating a set of authors and then looking up each author's status once.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/623Clean up progress bar handling in BlogActivity2018-06-12T11:32:19ZakwizgranClean up progress bar handling in BlogActivityBlogActivity uses a ViewPager with two FragmentStatePagerAdapters, one of which contains a single BlogFragment (which in turn contains its own RecyclerView adapter) and the other a series of BlogPostFragments. The two adapters allow the ...BlogActivity uses a ViewPager with two FragmentStatePagerAdapters, one of which contains a single BlogFragment (which in turn contains its own RecyclerView adapter) and the other a series of BlogPostFragments. The two adapters allow the blog to be viewed either as a feed or one post at a time.
The BlogFragment uses the RecyclerView's progress bar, whereas the BlogPostFragments rely on a progress bar in the BlogActivity. This complicates the interaction between the components and leads to a small bug when the BlogPostFragments are loading their posts: the progress bar is hidden when the first fragment finishes loading, even if the currently visible fragment is still loading.
Clean this up by moving the progress bar into the BlogPostFragment.
We should investigate other code that uses `BaseFragmentListener#show/hideLoadingScreen()` for similar problems. We may be able to simplify the interaction between components by making each component responsible for showing its own progress bar.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/622Transactional database interface2018-06-12T11:32:19ZakwizgranTransactional database interfaceCurrently the DB is guarded by a read-write lock: read-only transactions acquire the read lock and read-write transactions acquire the write lock. This ensures that we never get lock timeouts from the DB, so clients don't need to worry a...Currently the DB is guarded by a read-write lock: read-only transactions acquire the read lock and read-write transactions acquire the write lock. This ensures that we never get lock timeouts from the DB, so clients don't need to worry about rolling back and retrying transactions if there's a lock timeout. However, if a transaction performs long-running work such as verifying a signature, other transactions are prevented from accessing the database in the meantime.
We can avoid this by creating a transactional interface to the database, which encapsulates each transaction in a task object. Users of the database submit tasks, and the database is responsible for rolling back and retrying any tasks that time out. This allows us to remove the global read-write lock.
```
interface TransactionTask {
boolean run(Transaction txn) throws DbException;
}
```
The task's `run()` method performs DB operations using the provided transaction and returns true if the transaction should be committed or false if it should be aborted. If the `run()` method throws an exception, the transaction is aborted.
The DB has a method for running database tasks:
```
boolean runTask(TransactionTask task) throws DbException;
```
The database's `runTask()` method starts a transaction, passes it to the task, and commits or aborts it as required. The method returns true if the transaction was committed, false if it was aborted, or rethrows an exception thrown by the task.
We can remove the DB's `startTransaction()` and `endTransaction()` methods, along with the transaction's `setComplete()` method, since the DB itself will handle starting, committing and aborting transactions. It will no longer be necessary to specify whether a transaction is read-only or read-write.
Depends on #319.https://code.briarproject.org/briar/briar/-/issues/618BdfDictionary should have a defined iteration order2018-06-12T11:32:20ZakwizgranBdfDictionary should have a defined iteration orderThe iterators for BdfDictionary's keys, values and entries should return their elements in a defined order. Currently BdfDictionary uses the iterators inherited from Hashtable, which have no defined order, so deserialising and reserialis...The iterators for BdfDictionary's keys, values and entries should return their elements in a defined order. Currently BdfDictionary uses the iterators inherited from Hashtable, which have no defined order, so deserialising and reserialising a dictionary may produce output that's different from the input. This will be a problem whenever we want to hash or sign data that contains dictionaries.Milestone Bakwizgranakwizgranhttps://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 Grote