Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:34:16Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28481Tor's startup time is getting slower on Android2020-06-13T15:34:16ZTracTor's startup time is getting slower on AndroidWhen upgrading Briar's Tor binaries from 0.2.9.16 to 0.3.4.8, we noticed a difference in Tor's startup time on older Android phones.
Measuring the startup time of several recent Tor versions revealed an interesting pattern. The time tha...When upgrading Briar's Tor binaries from 0.2.9.16 to 0.3.4.8, we noticed a difference in Tor's startup time on older Android phones.
Measuring the startup time of several recent Tor versions revealed an interesting pattern. The time that elapses between starting the Tor process and the creation of the authentication cookie file hasn't changed across versions, but the time between the creation of the cookie file and the response to the AUTHENTICATE command has changed substantially. (Briar sends the AUTHENTICATE command as soon as the cookie file's created.)
I measured five runs of each version on a Motorola Moto G 4G running Android 5.1. Here are the min and max times in seconds for each version:
|= Tor version =|= Min =|= Max =|
|---------------|-------|-------|
|0.2.9.16|3.5|4.3|
|0.2.9.17|3.5|4.2|
|0.3.0.1-alpha|4.8|13.0|
|0.3.1.1-alpha|9.9|16.2|
|0.3.2.1-alpha|15.3|19.9|
|0.3.3.1-alpha|15.8|18.5|
|0.3.4.1-alpha|16.1|18.4|
|0.3.4.8|16.2|20.9|
|0.3.4.9|16.1|23.7|
The min and max have both increased substantially since 0.2.9, and the distribution has widened. This is having a noticeable impact on how long it takes for Briar to connect to contacts when the app's started.
I'll repeat these experiments on Linux x64 to see whether this is Android-specific.
**Trac**:
**Username**: akwizgranTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26549Revision counter for v3 ephemeral hidden service is lost2020-06-13T15:27:20ZTracRevision counter for v3 ephemeral hidden service is lostWhen a controller is using a client to provide two or more v3 ephemeral hidden services, with the private keys managed by the controller, and there's a client session where the controller activates one of the hidden services but not the ...When a controller is using a client to provide two or more v3 ephemeral hidden services, with the private keys managed by the controller, and there's a client session where the controller activates one of the hidden services but not the others, the revision counters for the other hidden services are lost. This prevents the other services from being activated in future sessions because their descriptors are rejected by the HSDirs.
This happens because increment_descriptor_revision_counter() in hs_service.c calls update_revision_counters_in_state(), which loops over all the services currently being provided by the client, saves their counters, and removes any other counters from the state file. Thus if any hidden service is activated during a session, the revision counters of any services not activated during that session are lost.
Steps to reproduce:
* Use `ADD_ONION NEW:ED25519-V3 ...` to create two hidden services
* Save the private keys
* Shut down and restart tor
* Use `ADD_ONION ED25519-V3:<private_key_1> ...` to activate the first service
* Shut down and restart tor
* Use `SETEVENTS HS_DESC` to register for HS descriptor events
* Use `ADD_ONION ED25519-V3:<private_key_1> ...` to activate the first service
* The descriptor should be published successfully
* Use `ADD_ONION ED25519-V3:<private_key_2> ...` to activate the second service
* The controller receives `HS_DESC_FAILED` events with `REASON=UPLOAD_REJECTED`
It looks like this bug is related to #25552. I don't know whether the solution to that ticket will fix it.
**Trac**:
**Username**: akwizgranTor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26523HSPOST command doesn't parse HSADDRESS argument2020-06-13T15:27:14ZTracHSPOST command doesn't parse HSADDRESS argumentThe HSPOST command ignores the HSADDRESS argument unless a SERVER argument precedes it, and incorrectly parses the argument (the argument name and = sign are treated as part of the address).
The command returns a synchronous 250 OK resp...The HSPOST command ignores the HSADDRESS argument unless a SERVER argument precedes it, and incorrectly parses the argument (the argument name and = sign are treated as part of the address).
The command returns a synchronous 250 OK response for v2 descriptors, but not for v3 descriptors.
**Trac**:
**Username**: akwizgranTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13447Don't build introduction circuits until we know we can build circuits2020-06-13T14:39:32ZTracDon't build introduction circuits until we know we can build circuitsWhen the network is disabled and re-enabled via DisableNetwork, Tor will try to build new introduction circuits as soon as the network is re-enabled. The circuits will fail and Tor will wait for five minutes (INTRO_CIRC_RETRY_PERIOD) bef...When the network is disabled and re-enabled via DisableNetwork, Tor will try to build new introduction circuits as soon as the network is re-enabled. The circuits will fail and Tor will wait for five minutes (INTRO_CIRC_RETRY_PERIOD) before trying again.
This patch sets can_complete_circuit to 0 when the network is disabled, and doesn't try to build intro circuits while can_complete_circuit is 0, so when the network is re-enabled Tor will wait for a circuit to be successfully built before trying to build intro circuits.
This should improve the performance of hidden services that use DisableNetwork to respond to connectivity changes, such as services running on mobile devices.
**Trac**:
**Username**: akwizgranTor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18502Orbot tries to kill Tor processes it doesn't own2019-09-24T08:51:35ZTracOrbot tries to kill Tor processes it doesn't ownOrbot fails to start when Briar is running because Orbot tries and fails to kill Briar's Tor process, leading to the following error in Orbot:
```
Waiting for control port...
Unable to start Tor: java.lang.Exception: Cannot kill: /data/...Orbot fails to start when Briar is running because Orbot tries and fails to kill Briar's Tor process, leading to the following error in Orbot:
```
Waiting for control port...
Unable to start Tor: java.lang.Exception: Cannot kill: /data/data/org.torproject.android/app_bin/tor
Set background service to FOREGROUND
TorService is shutting down
An error occurred stopping Tor: Cannot kill: /data/data/org.torproject.android/app_bin/tor
Something bad happened. Check the log
```
It looks like TorService#killAllDaemons() is taking its name a bit too literally. If Orbot had been running as root it would have succeeded in killing Briar's Tor process.
**Trac**:
**Username**: akwizgranNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/11414jtorctl: Make TorControlConnection thread-safe2014-08-11T20:35:30ZTracjtorctl: Make TorControlConnection thread-safeThis patch makes TorControlConnection thread-safe. In particular it prevents concurrent calls to sendAndWaitForResponse() from leaking threads.
**Trac**:
**Username**: akwizgranThis patch makes TorControlConnection thread-safe. In particular it prevents concurrent calls to sendAndWaitForResponse() from leaking threads.
**Trac**:
**Username**: akwizgranNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/11415jtorctl: Throw checked exceptions instead of unchecked exceptions2014-08-11T20:35:07ZTracjtorctl: Throw checked exceptions instead of unchecked exceptionsjtorctl throws unchecked RuntimeExceptions if it receives an error response or malformed response from Tor - users of the library have to catch these without being warned by the API. This patch converts jtorctl's RuntimeException subclas...jtorctl throws unchecked RuntimeExceptions if it receives an error response or malformed response from Tor - users of the library have to catch these without being warned by the API. This patch converts jtorctl's RuntimeException subclasses into IOException subclasses. This is safer for users of the library and better conveys what's happened (an IO error).
**Trac**:
**Username**: akwizgranNathan FreitasNathan Freitas