The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:07:03Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4803Log message contains typo2020-06-27T14:07:03ZRobert RansomLog message contains typo```
Dec 29 20:12:55.079 [warn] Before Tor can create a control socket in "/var/run/tor/control", the directory "/var/run/tor" needs to exist, and to be accessible only by the user and group account that is running Tor. (On some Unix sys...```
Dec 29 20:12:55.079 [warn] Before Tor can create a control socket in "/var/run/tor/control", the directory "/var/run/tor" needs to exist, and to be accessible only by the user and group account that is running Tor. (On some Unix systems, anybody who can list a socket can conect to it, so Tor is being careful.)
```
`s/conect/connect/`Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3311Log message indicating HS descriptor uploads have been started is misleading2020-06-27T14:08:14ZRobert RansomLog message indicating HS descriptor uploads have been started is misleading```
May 28 02:19:04.211 [info] upload_service_descriptor(): Sending publish request for hidden service o6nqpitsgxepq4se
May 28 02:19:04.214 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubb...```
May 28 02:19:04.211 [info] upload_service_descriptor(): Sending publish request for hidden service o6nqpitsgxepq4se
May 28 02:19:04.214 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 7631 seconds to hidden service directory 'aminGL' on 80.217.179.115:9001.
...
May 28 02:19:04.260 [info] upload_service_descriptor(): Successfully uploaded v2 rend descriptors!
May 28 02:19:09.554 [info] connection_dir_client_reached_eof(): Uploaded rendezvous descriptor (status 200 ("Service descriptor (v2) stored"))
...
May 28 02:19:18.274 [info] connection_dir_client_reached_eof(): Received http status code 503 ("Currently not acting as v2 hidden service directory") from server '91.208.34.24:443'. I'll try again soon.
```Tor: 0.2.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3325Log message when a client tries to connect to an invalid hostname is incorrect2020-06-27T14:08:13ZRobert RansomLog message when a client tries to connect to an invalid hostname is incorrectIn `connection_ap_handshake_rewrite_and_attach`:
```
addresstype = parse_extended_hostname(socks->address,
remapped_to_exit || options->AllowDotExit);
if (addresstype == BAD_HOSTNAME) {
log_warn(LD_APP, ...In `connection_ap_handshake_rewrite_and_attach`:
```
addresstype = parse_extended_hostname(socks->address,
remapped_to_exit || options->AllowDotExit);
if (addresstype == BAD_HOSTNAME) {
log_warn(LD_APP, "Invalid onion hostname %s; rejecting",
safe_str_client(socks->address));
```
`parse_extended_hostname` also returns `BAD_HOSTNAME` for `.exit` hostnames when AllowDotExit is off.
Also, `parse_extended_hostname`'s documentation comment does not mention `BAD_HOSTNAME`.Tor: 0.2.3.x-finalRobert RansomRobert Ransomhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40134Log messages from client NAT check failures are confusing2022-05-31T22:11:07ZDavid Fifielddcf@torproject.orgLog messages from client NAT check failures are confusingWhen [`CheckIfRestrictedNAT`](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/common/nat/nat.go?h=v2.1.0#n34) fails with an error, it logs a message like `Error: no response from server`. But in context, the message...When [`CheckIfRestrictedNAT`](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/common/nat/nat.go?h=v2.1.0#n34) fails with an error, it logs a message like `Error: no response from server`. But in context, the messages confusingly appear to refer to the broker rendezvous, not the STUN server connection:
```
Target URL: snowflake-broker.torproject.net.global.prod.fastly.net
Front URL: cdn.sstatic.net
Error: no response from server
Error: no response from server
Error: no response from server
```
In this situation, communication with the broker has succeeded and a proxy has been assigned, but the client is having trouble checking its own NAT type. These log messages should say "STUN" or "NAT" somewhere in them, and ideally also the address of the server that failed (possibly subject to safe-log scrubbing).
Refactoring suggestion: instead of having a log call at every return of `isRestrictedMapping`, you can use [`fmt.Errorf("...: %w")`](https://pkg.go.dev/errors) to wrap the underlying error with additional context, and just return the error. That way, the logging can be consolidated in [`updateNATType`](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/lib/snowflake.go?h=v2.1.0#n239), which is also where the STUN server address can be added and displayed.itchyonionitchyonionhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3336Log option does not recognize ‘heartbeat’ as a log domain2020-06-27T14:08:12ZRobert RansomLog option does not recognize ‘heartbeat’ as a log domain```
setconf Log="[rend,heartbeat]debug notice stdout"
```
```
Jun 02 06:28:04.000 [warn] No such logging domain as heartbeat
Jun 02 06:28:04.000 [warn] Couldn't parse log levels in Log option 'Log [rend,heartbeat]debug notice stdout'
Ju...```
setconf Log="[rend,heartbeat]debug notice stdout"
```
```
Jun 02 06:28:04.000 [warn] No such logging domain as heartbeat
Jun 02 06:28:04.000 [warn] Couldn't parse log levels in Log option 'Log [rend,heartbeat]debug notice stdout'
Jun 02 06:28:04.000 [warn] Controller gave us config lines that didn't validate: Failed to validate Log options. See logs for details.
```Tor: 0.2.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/26703Lower log level of "Scheduler type KIST has been enabled"2020-06-27T13:52:57ZpastlyLower log level of "Scheduler type KIST has been enabled"I like seeing it, but that doesn't mean everyone should have to see it. Tor doesn't log about EWMA vs RR.I like seeing it, but that doesn't mean everyone should have to see it. Tor doesn't log about EWMA vs RR.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17950Make address family search more accurate2020-06-27T13:59:52ZteorMake address family search more accurateTor searches local interfaces for IPv4/IPv6 addresses, but it often retrieves all addresses, then filters for IPv4/IPv6.
We could make this more efficient for some of the interface address functions:
* getifaddrs doesn't take an address...Tor searches local interfaces for IPv4/IPv6 addresses, but it often retrieves all addresses, then filters for IPv4/IPv6.
We could make this more efficient for some of the interface address functions:
* getifaddrs doesn't take an address family, but we can check the address families of the returned addresses
* ioctl(.,SIOCGIFCONF,.) only supports AF_INET6 on AIX, or on HP-UX and Solaris with SIOCGLIFCONF, and otherwise only returns IPv4 addresses
* GetAdaptersAddresses (Win32) takes an address family as its first argument
* tor_getsockname/get_interface_address6_via_udp_socket_hack takes an address family as its first argument
A design for this could be:
* pass the address family to get_interface_addresses_raw
* pass the address family to the API-specific functions that take an address family, or when converting the address to a smartlist, include/exclude addresses matching the specified address familiesTor: 0.2.8.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/17952Make address family search via ioctl more accurate on obscure platforms2020-07-17T11:11:50ZteorMake address family search via ioctl more accurate on obscure platformsThe following address family search functions only return an IPv6 address on some platforms:
* ioctl(.,SIOCGIFCONF,.) only returns IPv4 addresses, except:
* on HP-UX and Solaris, which support AF_INET6 with SIOCGLIFCONF
* see http:...The following address family search functions only return an IPv6 address on some platforms:
* ioctl(.,SIOCGIFCONF,.) only returns IPv4 addresses, except:
* on HP-UX and Solaris, which support AF_INET6 with SIOCGLIFCONF
* see http://www.manpages.info/sunos/if_tcp.7.html
* on AIX, using the sa_len field in struct sockaddr to distinguish between IPv4 and IPv6 addresses
* on MVS and z/OS, which support AF_INET6 with SIOCGIFCONF6 / __net_ifconf6header_s
* see http://www-01.ibm.com/support/docview.wss?uid=isg1PK22885 for details
* on these platforms, we should try AF_INET, then AF_INET6, and then both addresses should be returnedTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17951Make address family search via UDP socket hack more accurate2020-06-27T13:59:51ZteorMake address family search via UDP socket hack more accurateThe following address family search functions don't always return an IPv6 address:
* get_interface_address6_via_udp_socket_hack takes an address family as its first argument
* when get_interface_address6_list is passed AF_UNSPEC, it s...The following address family search functions don't always return an IPv6 address:
* get_interface_address6_via_udp_socket_hack takes an address family as its first argument
* when get_interface_address6_list is passed AF_UNSPEC, it should be call get_interface_address6_via_udp_socket_hack with AF_INET, and then AF_INET6, and then both addresses should be returnedTor: 0.2.8.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/31891make autostyle doesn't work when building outside the source tree2020-06-27T13:49:15ZTaylor Yumake autostyle doesn't work when building outside the source treeIt looks like `make autostyle` doesn't work correctly if building outside the source tree. (Here I'm building in a subdirectory of the source tree.)
```
$ make -k autostyle
abs_top_srcdir="/Users/tlyu/src/tor/build-norust/.." python3 ../...It looks like `make autostyle` doesn't work correctly if building outside the source tree. (Here I'm building in a subdirectory of the source tree.)
```
$ make -k autostyle
abs_top_srcdir="/Users/tlyu/src/tor/build-norust/.." python3 ../scripts/maint/update_versions.py
Traceback (most recent call last):
File "../scripts/maint/update_versions.py", line 98, in <module>
with open("configure.ac") as f:
FileNotFoundError: [Errno 2] No such file or directory: 'configure.ac'
make: *** [update-versions] Error 1
python3 scripts/maint/annotate_ifdef_directives.py ../src/lib/*/*.[ch] ../src/core/*/*.[ch] ../src/feature/*/*.[ch] ../src/app/*/*.[ch] ../src/test/*.[ch] ../src/test/*/*.[ch] ../src/tools/*.[ch]
/Users/tlyu/src/brew/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python: can't open file 'scripts/maint/annotate_ifdef_directives.py': [Errno 2] No such file or directory
make: *** [autostyle-ifdefs] Error 2
python3 scripts/maint/rectify_include_paths.py
/Users/tlyu/src/brew/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python: can't open file 'scripts/maint/rectify_include_paths.py': [Errno 2] No such file or directory
make: *** [rectify-includes] Error 2
make: Target `autostyle' not remade because of errors.
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6781Make cell statistics useful in simulations again2021-06-18T18:25:22ZRob JansenMake cell statistics useful in simulations againOnce upon a time, when I set "CellStatistics 1" in my torrc files, each relay in my TestingTorNetwork would track and write statistics to disk. Since writing these every 24 hours was too long for my simulations, I just needed to patch WR...Once upon a time, when I set "CellStatistics 1" in my torrc files, each relay in my TestingTorNetwork would track and write statistics to disk. Since writing these every 24 hours was too long for my simulations, I just needed to patch WRITE_STATS_INTERVAL to a smaller value (once per minute). Every new interval, a new entry would be appended to the stats files. These statistics are very useful in determining how our test network looks and how it compares to live Tor.
Somewhere along the line (in 0.2.3.x-alpha I think, but I can't find the ticket), the behavior changed so that each new entry replaces the existing file, presumably under the assumption that by that time the stats from the last entry were already sent to the authority and were no longer needed. Of course they weren't in my simulations, and only getting the last minute of statistics from each relay isn't nearly as useful.
Whats the best solution here? Is there another #define that I should patch so my relays upload stats every minute instead of the current rate? That will cause extra network load. Should we allow the option of appending statistics instead of replacing?
Ideally, I wouldn't have to patch anything and this would all be handled automatically if TestingTorNetwork is 1.https://gitlab.torproject.org/tpo/core/tor/-/issues/16822make certificate lifetime accessible through Tor's ControlPort2022-06-17T18:46:01Zpropermake certificate lifetime accessible through Tor's ControlPortI am referring to the following. Sometimes user Tor logs contain something like this.
```
Sep 03 10:32:59.000 [warn] Certificate already expired. Either their clock is set wrong, or your clock is wrong.
Sep 03 10:32:59.000 [warn] (certi...I am referring to the following. Sometimes user Tor logs contain something like this.
```
Sep 03 10:32:59.000 [warn] Certificate already expired. Either their clock is set wrong, or your clock is wrong.
Sep 03 10:32:59.000 [warn] (certificate lifetime runs from Aug 16 00:00:00 2014 GMT through Jul 29 23:59:59 2015 GMT. Your time is Sep 03 10:32:59 2015 UTC.)
```
This information is interesting in context for anonymity distributions and secure network time synchronization, usability and whatnot. Used by Tails' [tordate](https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh) or Whonix's [anondate](https://www.whonix.org/wiki/Dev/TimeSync#anondate).
However, these tools rely on parsing Tor's log, which is [fragile](https://labs.riseup.net/code/issues/8977).
It would be nice, if something like
* `certificate/valid-after`
* and `certificate/valid-until`
where accessible through Tor's ControlPort.https://gitlab.torproject.org/tpo/core/tor/-/issues/7356Make channel state test macros2020-06-27T14:05:18ZAndrea ShepardMake channel state test macrosWe check for conditions like if (!(circ->n_chan->state == CHANNEL_STATE_CLOSING || circ->n_chan->state == CHANNEL_STATE_CLOSED || circ->n_chan->state == CHANNEL_STATE_ERROR)) a lot; there should be more concise test macros.We check for conditions like if (!(circ->n_chan->state == CHANNEL_STATE_CLOSING || circ->n_chan->state == CHANNEL_STATE_CLOSED || circ->n_chan->state == CHANNEL_STATE_ERROR)) a lot; there should be more concise test macros.Tor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/chutney/-/issues/25829Make chutney ignore "Valid-After times do not match"2020-06-27T13:18:46ZteorMake chutney ignore "Valid-After times do not match"We need to ignore this Tor warning in chutney:
Warning: Unable to add signatures to consensus: Valid-After times do not match when adding detached signatures to consensus Number: 2
It's not a bug, it only happens occasionally, and...We need to ignore this Tor warning in chutney:
Warning: Unable to add signatures to consensus: Valid-After times do not match when adding detached signatures to consensus Number: 2
It's not a bug, it only happens occasionally, and only in tor 0.3.3 and later.https://gitlab.torproject.org/tpo/core/tor/-/issues/6153Make circ_times static, and abstract most of its accessors.2020-06-27T14:06:13ZNick MathewsonMake circ_times static, and abstract most of its accessors.The circ_times structure is exported as a global from circuitbuild.c. It really shouldn't be. It has 3 kinds of external users FWICT:
* Things that pass it as an argument to circuit_build_*().
* Two functions in circuituse.c that wa...The circ_times structure is exported as a global from circuitbuild.c. It really shouldn't be. It has 3 kinds of external users FWICT:
* Things that pass it as an argument to circuit_build_*().
* Two functions in circuituse.c that want to know the current timeout values.
For the former we could use an accessor function, or we could have the functions in circuitbuild.c use the static object if they receive NULL. For the latter, we could have a function that returns the current timeouts.
Making this change would also let us more completely avoid looking at circ_times when LearnCircuitBuildTimeout is 0.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17638Make ersatz_socketpair work on IPv6-only systems:2020-06-27T14:00:14ZteorMake ersatz_socketpair work on IPv6-only systems:Some systems don't have IPv4 localhost (some IPv6-only systems):
ersatz_socketpair currently uses AF_INET. If that fails with EPROTONOSUPPORT (or WSAEPROTONOSUPPORT on Windows), let's have it try AF_INET6.
Some systems don't even have I...Some systems don't have IPv4 localhost (some IPv6-only systems):
ersatz_socketpair currently uses AF_INET. If that fails with EPROTONOSUPPORT (or WSAEPROTONOSUPPORT on Windows), let's have it try AF_INET6.
Some systems don't even have IPv6 localhost (some FreeBSD jails). Instead, they have a non-127/8, non-::1 IP address used as the default:
ersatz_socketpair currently uses INADDR_LOOPBACK. On IPv6, it should use ::1 (or a constant or function returning it). If that fails with E(address not found) (or WSAE(address not found) on Windows), that's actually what we want - we don't want to accidentally expose a socketpair on a routable address.
We should also remove the check in the ersatz_socketpair unit test that bails out on EPROTONOSUPPORT.
Patch on a version before 22dba27d8dd5 (23 Nov 2004) / svn:r2943.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20667Make FetchUselessDescriptors fetch all consensus flavours2020-06-27T13:57:47ZteorMake FetchUselessDescriptors fetch all consensus flavours`FetchUselessDescriptors 1` used to imply `UseMicrodescriptors 0`, but due to legacy/trac#6769, it doesn't in 0.3.0 and later.
Therefore, clients that want to download a full consensus have to explictly set `UseMicrodescriptors 0`.
~~W...`FetchUselessDescriptors 1` used to imply `UseMicrodescriptors 0`, but due to legacy/trac#6769, it doesn't in 0.3.0 and later.
Therefore, clients that want to download a full consensus have to explictly set `UseMicrodescriptors 0`.
~~We should document this in the man page and probably the changelog summary, as~~ it is a breaking change for many configs that used to obtain a full consensus.
~~(Alternately,~~ we could fix this bug by FetchUselessDescriptors download a full consensus, even on clients, and document that behaviour.)
Discovered when running a test bandwidth authority - see legacy/trac#20621.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24904Make geoip use channel_is_client so it ignores flapping relays2021-09-16T14:31:18ZteorMake geoip use channel_is_client so it ignores flapping relaysIn channel_do_open_actions(), we probably want to use channel_is_client() rather than connection_or_digest_is_known_relay().
```
/* only report it to the geoip module if it's not a known router */
if (!connection_or_digest_is_kn...In channel_do_open_actions(), we probably want to use channel_is_client() rather than connection_or_digest_is_known_relay().
```
/* only report it to the geoip module if it's not a known router */
if (!connection_or_digest_is_known_relay(chan->identity_digest)) {
if (channel_get_addr_if_possible(chan, &remote_addr)) {
```
Bugfix on legacy/trac#23533, 0.3.0.1-alpha.
We should make sure legacy/trac#24898 is fixed in any version we backport this to.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridge-port-scan/-/issues/2Make HTML use our torproject.org CSS style2022-01-20T21:31:11ZPhilipp Winterphw@torproject.orgMake HTML use our torproject.org CSS styleOur static CSS files are available here: https://gitlab.torproject.org/tpo/web/lego/-/tree/master/assets
The site is in https://bridges.torproject.org/scanOur static CSS files are available here: https://gitlab.torproject.org/tpo/web/lego/-/tree/master/assets
The site is in https://bridges.torproject.org/scanSponsor 30 - Objective 2.2https://gitlab.torproject.org/tpo/anti-censorship/docker-obfs4-bridge/-/issues/1Make image more configurable2021-04-12T14:58:25ZPhilipp Winterphw@torproject.orgMake image more configurableSome operators want to set more advanced tor config options like:
* `BandwidthRate` and `BandwidthBurst`
* `BridgeDistribution`
* ...?
We should make it possible to pass these to the docker image. Instead of predicting what options our ...Some operators want to set more advanced tor config options like:
* `BandwidthRate` and `BandwidthBurst`
* `BridgeDistribution`
* ...?
We should make it possible to pass these to the docker image. Instead of predicting what options our operators would like, it would be great if we could pass arbitrary config options to the image. Once this is done, let's not forget to update our [docker bridge setup guide](https://community.torproject.org/relay/setup/bridge/docker/).