Server-side code for accepting crash reports and feedback
* Moved some shared code for copying InputStreams to OutputStreams into a utility class
* Modified the dev report sender to send one report per connection
* Easier to handle on the server side
* If the connection fails after sending any reports, they don't need to be resent
* Tor will reuse the circuit, so it's cheap
* Added server-side code for accepting dev reports
* We need to protect the server's resources from DoS attacks
* Reports can't be larger than 1 MB
* Connections are limited to an average rate of one per minute
* The rate limiter uses a token bucket to allow bursts of up to 1,000 connections
* If the rate limit is exceeded, connection attempts will fail - clients will retry next time they sign in
* The limits can be raised when we move to a bigger server (and when we have some users)
See merge request !288
Update Tor assets if they're older than the APK
Extract the Tor binary, GeoIP database and config file from the APK if they haven't been extracted since the APK was last updated.
On the Galaxy Nexus, skipping extraction of the binary if it's already up to date shaves about 1.5 seconds off the Tor plugin's startup time.
Closes#582.
Depends on !272.
See merge request !273
Don't connect to Tor if it's already running
For some time now we've had a reliable way of shutting down the Tor process (the __OwningControllerProcess command line argument combined with the TAKEOWNERSHIP command), but TorPlugin#start() still assumes that Tor may already be running. This allows another app to bind the Tor control and SOCKS ports and collect confidential data from Briar (#578). It also allows two Briar instances running on the same device to try to communicate with the same Tor process, which prevents proper shutdown (#572).
This patch prevents the Tor plugin from starting unless it's able to start its own Tor process with the expected control and SOCKS ports. If two Briar instances are running on the same device, only one of them will be able to use Tor. The other should fail to start its Tor plugin and then function normally without Tor access, including normal shutdown.
Fixes#572, #578. Open another ticket if you want two Briar instances on the same device to have their own Tor processes. :-)
See merge request !272
BQP with QR codes
This MR implements BQP for key agreement over short-range transports. It also implements the Android UI for using BQP with QR codes.
Closes#117.
See merge request !84
When more than one invitation socket is opened, Alice should pick which one to use and Bob should use whichever one Alice picks. This fixes a race condition where each party picked a different socket and closed the other.
If two contacts publish their descriptors simultaneously, they may both stop polling without retrieving each other's descriptors. Continue polling for 2 intervals after publishing the descriptor.
New polling logic for LAN. #252
Same approach as !104. Modified the poller to cancel any scheduled poll when pollNow() is called and randomise the next polling interval so plugins that call pollNow() at the same time don't end up polling in sync.
Depends on !104. Fixes#252.
See merge request !105
New polling logic for Bluetooth. #251
Increase the polling interval exponentially each time polling is unsuccessful, up to a maximum of 60 minutes. The interval is reset to 2 minutes whenever a connection is made and whenever Bluetooth is re-enabled.
This should reduce battery usage when there are no contacts nearby.
Fixes#251.
See merge request !104
The polling interval increases exponentially each time polling is unsuccessful, up to a maximum of 60 minutes. The interval is reset to 2 minutes whenever a connection is made and whenever Bluetooth is re-enabled.
