Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-09-01T21:42:49Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33372Add support for disabling DNSPort2022-09-01T21:42:49ZNick MathewsonAdd support for disabling DNSPortThe DNSPort feature is useful for many users, but it requires libevent's dns server code. If somebody disables both DNSPort and relay mode, we can avoid having to build with libevent_extra, and only use libevent_core. Dropping libevent...The DNSPort feature is useful for many users, but it requires libevent's dns server code. If somebody disables both DNSPort and relay mode, we can avoid having to build with libevent_extra, and only use libevent_core. Dropping libevent_extra could save maybe 100k?https://gitlab.torproject.org/tpo/core/tor/-/issues/33861vanguards: circ_max_megabytes applied to all connection2022-09-01T21:42:49Zcypherpunksvanguards: circ_max_megabytes applied to all connection```
# This means that applications that require large data submission (eg
# SecureDrop or onionshare) should set this much higher
# (or set to 0 to disable):
circ_max_megabytes = 8
```
My site is less than 4MB so above config is okay.
...```
# This means that applications that require large data submission (eg
# SecureDrop or onionshare) should set this much higher
# (or set to 0 to disable):
circ_max_megabytes = 8
```
My site is less than 4MB so above config is okay.
I thought vanguards only applies this limit to:
1. My onion service <--- Tor user (incoming)
2. My onion service ---> Tor user (outgoing)
However your vanguards is breaking other connections such as:
1. apt with Tor[1]
2. wget download over Tor to clearnet site
3. curl POST something over Tor to clearnet site
Problem 1. I don't want to stop vanguards just for apt and other thing.
Problem 2. I don't want to increase circ_max value just for this.
So could you please add a switch to limit only my-onion-site related connection and ignore else?
say,
```
# If true, vanguards will not apply max_mega limit non-onion connections.
# If false(default) vanguards will apply max_mega limit to all Tor connections.
# If your circ_max_megabytes is already 0, this settings does nothing.
circ_max_mega_ignore_clearnet_destination = true
```https://gitlab.torproject.org/tpo/core/tor/-/issues/33603Catch common errors in tor bash scripts with `set -euo pipefail`2022-09-01T21:42:49ZteorCatch common errors in tor bash scripts with `set -euo pipefail`Let's gradually convert our scripts to use:
```
set -e
set -u
set -o pipefail
```
And maybe:
```
IFS=$'\n\t'
```
These settings help catch common errors in bash scripts at runtime:
http://redsymbol.net/articles/unofficial-bash-strict-m...Let's gradually convert our scripts to use:
```
set -e
set -u
set -o pipefail
```
And maybe:
```
IFS=$'\n\t'
```
These settings help catch common errors in bash scripts at runtime:
http://redsymbol.net/articles/unofficial-bash-strict-mode/
(Shellcheck helps us catch errors while writing scripts, but it can't help with runtime failures.)
Follow-up to legacy/trac#33451.https://gitlab.torproject.org/tpo/core/tor/-/issues/33589Copy Outreachy developer advice to the wiki or doc/HACKING2022-11-01T09:26:00ZteorCopy Outreachy developer advice to the wiki or doc/HACKINGWe gave Outreachy interns a bunch of info about how to get started developing Tor. And how we communicate.
We should use this info to update the wiki or doc/HACKING.We gave Outreachy interns a bunch of info about how to get started developing Tor. And how we communicate.
We should use this info to update the wiki or doc/HACKING.https://gitlab.torproject.org/tpo/core/tor/-/issues/32815Move all directory authority options into the dirauth man page section2021-09-16T14:11:41ZteorMove all directory authority options into the dirauth man page sectionSome of the *AuthoritativeDir* and MinUptimeHidServDirectoryV2 options are not under Directory Authority Server Options in the man page. We should move them under the section, so it's clear which options are disabled in when directory au...Some of the *AuthoritativeDir* and MinUptimeHidServDirectoryV2 options are not under Directory Authority Server Options in the man page. We should move them under the section, so it's clear which options are disabled in when directory authority mode is disabled.https://gitlab.torproject.org/tpo/core/tor/-/issues/31737Change handling of relative paths in %include directives?2022-09-01T21:42:48ZNick MathewsonChange handling of relative paths in %include directives?Right now, relative paths in %include directives are handled relative to Tor's working directory, which doesn't make a lot of sense. Handling them relative to the configuration file might make more sense?
We'd want to figure out a way ...Right now, relative paths in %include directives are handled relative to Tor's working directory, which doesn't make a lot of sense. Handling them relative to the configuration file might make more sense?
We'd want to figure out a way to handle this that won't break existing users.https://gitlab.torproject.org/tpo/core/tor/-/issues/30420Should we recommend that relay operators turn on tcp bbr?2022-10-24T20:49:11ZRoger DingledineShould we recommend that relay operators turn on tcp bbr?The internet seems to have a growing number of howto's for switching your kernel to use the "bbr" congestion control mode of tcp:
https://github.com/google/bbr
https://en.wikipedia.org/wiki/TCP_congestion_control#TCP_BBR
Thought 1: doin...The internet seems to have a growing number of howto's for switching your kernel to use the "bbr" congestion control mode of tcp:
https://github.com/google/bbr
https://en.wikipedia.org/wiki/TCP_congestion_control#TCP_BBR
Thought 1: doing an experiment where various fractions of Tor relays switch to this congestion control mode would be neat. Maybe it's the sort of thing that Shadow could help with, since switching the real Tor network is both cumbersome and dangerous.
(Though, since Shadow builds its own tcp implementation, it would need to have an implementation of the bbr variation in order to do a test with it. And it would need to have realistic *non* Tor background flows to test the comparison. What a great use case for driving forward Shadow innovation to be able to capture this test. Cc'ing Rob.)
Thought 2: If God wanted us to be using tcp bbr, we'd be using it by default already. And we're not, so we should learn why that is. For example, the wikipedia page indicates that it's not good at fairness in some situations -- and since Tor relays are often guests on their network, we might not want to give people more reasons to get angry at them.https://gitlab.torproject.org/tpo/core/tor/-/issues/16894Check all logging output is appropriately escaped / escaped_safe_str_client2022-02-07T19:38:03ZteorCheck all logging output is appropriately escaped / escaped_safe_str_clientSecurity bugs like legacy/trac#16891 show up every so often, where sensitive input is logged, rather than being obscured. Similarly, client input is sometimes logged unsanitised (I fixed one of these in the directory request logging code...Security bugs like legacy/trac#16891 show up every so often, where sensitive input is logged, rather than being obscured. Similarly, client input is sometimes logged unsanitised (I fixed one of these in the directory request logging code about 9-12 months ago.)
It would be great if someone could review all the strings that are logged by Tor, and categorise them into:
* static or calculated internally: trusted, log as-is
* externally provided: unsanitised, use escaped()
* sensitive client information: use escaped_safe_str_client()
Do we want this in 0.2.7, or should we leave it until 0.2.8?