Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:44:35Zhttps://gitlab.torproject.org/legacy/trac/-/issues/15434Tor dies if you send it a HUP before it read its config, and doesn't take PTs...2020-06-13T14:44:35ZTvdWTor dies if you send it a HUP before it read its config, and doesn't take PTs with itWhen sending tor a HUP before it has read its config, it will die, without killing its PTs. Starting tor again will then result in more PT crashes, as the ports will already be used by previous instances.
```
10149 ? Sl 0:00 ...When sending tor a HUP before it has read its config, it will die, without killing its PTs. Starting tor again will then result in more PT crashes, as the ports will already be used by previous instances.
```
10149 ? Sl 0:00 /usr/bin/obfs4proxy managed
10581 ? Sl 0:01 /usr/bin/tor -f /etc/tor/torrc-node1
10582 ? S 0:00 \_ /usr/bin/python /usr/bin/obfsproxy managed
10583 ? Z 0:00 \_ [obfs4proxy] <defunct>
10584 ? S 0:00 \_ /usr/bin/python /usr/bin/fteproxy --managed --mode server
```Tor: 0.2.7.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/15419chutney: on failure, explain which connection failed2020-06-13T13:29:17Zteorchutney: on failure, explain which connection failedWhen there's a failure in the chutney data transmission tests, it would be really, really helpful to know which connection failed. The debug flag doesn't quite do this yet, but it's pretty close.
This is particularly important now that ...When there's a failure in the chutney data transmission tests, it would be really, really helpful to know which connection failed. The debug flag doesn't quite do this yet, but it's pretty close.
This is particularly important now that chutney supports three different types of connectivity tests (in the same network):
* client -> exit
* bridge client -> exit
* [bridge] client -> hidden service
Over two different protocols:
* IPv4
* IPv6 (currently bridges only)https://gitlab.torproject.org/legacy/trac/-/issues/15418chutney: add debug command-line flag2020-06-13T13:29:17Zteorchutney: add debug command-line flagchutney has a debug variable `debug_flag` in `Traffic.py`.
This would be much easier to use if it was set from the command-line, or even automatically activated (at some level) on transmission failure.chutney has a debug variable `debug_flag` in `Traffic.py`.
This would be much easier to use if it was set from the command-line, or even automatically activated (at some level) on transmission failure.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15353Some chutney tests fail when localhost is the only available IP2020-06-13T13:29:16ZteorSome chutney tests fail when localhost is the only available IPWhen I turn off the Wifi / Internet connection on my Mac (OS X 10.10.2), the chutney Exit tests fail with 'no exit to that port', but the hidden service tests are fine.
This is probably a misconfiguration around the localhost exit ports...When I turn off the Wifi / Internet connection on my Mac (OS X 10.10.2), the chutney Exit tests fail with 'no exit to that port', but the hidden service tests are fine.
This is probably a misconfiguration around the localhost exit ports (all ports should be allowed, or, at the very least, the ports chutney uses should be allowed).
I'll see if I can find time to track this down and fix it, but it's low priority, as most people run chutney on a computer with an IP address apart from localhost.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/14164Controller method to get our own descriptor2020-06-13T14:41:41ZtoralfController method to get our own descriptorI'm wondering why this pythin snippet
```
def main():
ControlPort = 9051
ProcessName = 'tor'
with Controller.from_port(port = ControlPort) as controller:
controller.authenticate()
#print " Tor version %s" % controller.get_...I'm wondering why this pythin snippet
```
def main():
ControlPort = 9051
ProcessName = 'tor'
with Controller.from_port(port = ControlPort) as controller:
controller.authenticate()
#print " Tor version %s" % controller.get_version()
try:
desc = controller.get_microdescriptor()
print " flags : %s" % desc.flags()
print " measured bandwidth : %i" % desc.measured()
except Exception as exc:
print exc
#pass
```
gives
```
Tor was unable to provide the descriptor for 'F1BE15429B3CE696D6807F4D4A58B1BFEC45C822'
```
Does this means that stems asks tor and tor doesn't know itself ?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/14013base16_decode() API is inconsistent and error-prone2020-06-13T14:57:28ZNick Mathewsonbase16_decode() API is inconsistent and error-proneOur other baseXYZ_decode() functions return the number of bytes written to the output. But base16_decode() returns 0 on success and -1 on failure, so unless you checked the input length, you have a risk of leaving the output buffer part...Our other baseXYZ_decode() functions return the number of bytes written to the output. But base16_decode() returns 0 on success and -1 on failure, so unless you checked the input length, you have a risk of leaving the output buffer partially full.
Calls where we messed up:
* connction_dir_retry_bridges()
* decoding the K_FINGERPRINT entry in router_parse_entry_from_string()
* add_fingerprint_to_dir()
* entry_Guards_parse_state()
* getinfo_helper_networkstatus()
* authority_cert_parse_from_string()
As far as I can tell, none of these is disastrous, or leaks stack information to an attacker. But wow, it sure would be good to fix them.
Proposed fix for backporting:
* Add a memset(0) to base*_en/decode, so they never leave stuff unassigned.
Proposed fix for master:
* Make the return value for base16_decode consistent with the others.
* Fix everything that checks for whether base16_decode() to check an actual return value.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13753Validate is_canonical more thoroughly2020-06-13T14:40:17ZNick MathewsonValidate is_canonical more thoroughlyWe use is_canonical to tell whether we should extend a circuit over a channel... but we should also double-check it as we are extending that circuit, to make sure we didn't mess up.
Also, we should audit the code that sets is_canonical.We use is_canonical to tell whether we should extend a circuit over a channel... but we should also double-check it as we are extending that circuit, to make sure we didn't mess up.
Also, we should audit the code that sets is_canonical.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/10218Provide "users-per-transport-per-country" statistics for obfsbridges2020-06-13T18:13:36ZGeorge KadianakisProvide "users-per-transport-per-country" statistics for obfsbridgesIn our `bridge-stats` file we currently have `bridge-ips` which tracks the number of connections per-country, and `bridge-ip-transports` which counts the number of connections per-transport.
Still, these two data points don't allow you ...In our `bridge-stats` file we currently have `bridge-ips` which tracks the number of connections per-country, and `bridge-ip-transports` which counts the number of connections per-transport.
Still, these two data points don't allow you to infer the users-per-transport-per-country; which would give us useful information in case of blocked transports in specific jurisdictions, etc.
gamambel today suggested that we add such functionality, which seems like a marvelous idea.
`wfn` and `grindhold` seem interested in coding this. As discussed in IRC, interesting functions here are:`geoip_get_transport_history()` `geoip_format_bridge_stats()` `validate_bridge_stats()`.
We should also define a nice format for this new line in `bridge-stats`. A not nice format is:
`bridge-ip-transports-per-country cn::obfs2:42,obfs3:46 ir::obfs2:10,obfs3:666`
we might be able to find a better one (or even one that is used currently somewhere else in tor).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9729Make bridges publish additional ORPort addresses in their descriptor2020-06-13T14:31:56ZTracMake bridges publish additional ORPort addresses in their descriptorI run Tor 0.2.4.17-rc as a bridge configured with multiple IPv4 addresses and one ORPort line for each, like so:
ORPort <n1>:443
ORPort <n2>:443
...
ORPort <nN>:443
When starting tor, the log will show that only <n1> is self-tested and...I run Tor 0.2.4.17-rc as a bridge configured with multiple IPv4 addresses and one ORPort line for each, like so:
ORPort <n1>:443
ORPort <n2>:443
...
ORPort <nN>:443
When starting tor, the log will show that only <n1> is self-tested and a bridge descriptor is published:
[notice] Now checking whether ORPort <n1>:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Tor should publish bridge descriptors for all the available addresses and the bridge authorities should probably put them into pools of different confidentiality levels.
For clarity, the documentation should explain Tor's bandwidth allocation as configured with Relay(Bandwidth|Burst)Rate (per address or total).
**Trac**:
**Username**: sqrt2Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/8001obfsproxy makes tor warn when one bridge is down2020-06-13T14:26:37ZRoger Dingledineobfsproxy makes tor warn when one bridge is downWhen you run the fancy new flashproxy/obfsproxy bundle:
https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles
you get
```
Jan 19 15:09:17.120 [Warning] Proxy Client: unable to connect to 208.79.90.242:55564 ("...When you run the fancy new flashproxy/obfsproxy bundle:
https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles
you get
```
Jan 19 15:09:17.120 [Warning] Proxy Client: unable to connect to 208.79.90.242:55564 ("server rejected connection")
```
That's because that bridge is down currently.
When a bridge fails, we should probably only [warn] if no bridges have succeeded.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6837More fine-grained modular decomposition2020-06-13T14:22:44ZNick MathewsonMore fine-grained modular decompositionWe should chop up our huger C files into smaller ones, based on actual module boundaries.
This will make it harder for us to merge pending branches that touch that code, but those are at a low ebb right now, so it's a good time.
The to...We should chop up our huger C files into smaller ones, based on actual module boundaries.
This will make it harder for us to merge pending branches that touch that code, but those are at a low ebb right now, so it's a good time.
The top 10 offenders in our current codebase are:
```
4614 src/or/rendservice.c
4839 src/or/channel.c
5200 src/or/connection.c
5386 src/or/or.h
5648 src/common/util.c
5666 src/or/directory.c
5688 src/or/routerparse.c
5771 src/or/routerlist.c
7223 src/or/control.c
8006 src/or/config.c
```
(updated May 2017)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6313Many of Tor's complex functions should be refactored2020-06-13T14:20:57ZNick MathewsonMany of Tor's complex functions should be refactoredSee some discussion on #6177.
I'm attaching a list of the most complex functions in Tor (by cyclomatic complexity).
Possibly cyclomatic-complexity-per-line would be another good thing to look at.See some discussion on #6177.
I'm attaching a list of the most complex functions in Tor (by cyclomatic complexity).
Possibly cyclomatic-complexity-per-line would be another good thing to look at.Tor: unspecified