Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:08:41Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2536Disable outgoing token bucket and reduce token bucket refill interval2020-06-27T14:08:41ZKarsten LoesingDisable outgoing token bucket and reduce token bucket refill intervalFlorian Tschorsch and Björn Scheuermann have written a patch to a) disable the outgoing token bucket to avoid the "double door effect" and b) reduce the token bucket refill interval from 1 second to, say, 100 milliseconds or less.
Sebas...Florian Tschorsch and Björn Scheuermann have written a patch to a) disable the outgoing token bucket to avoid the "double door effect" and b) reduce the token bucket refill interval from 1 second to, say, 100 milliseconds or less.
Sebastian and I discussed the patch with Florian and Björn. See the latest version of the patch in branch tokenbucket in my public repository.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3794tor-chroot scripts2020-06-27T14:07:52ZJacob Appelbaumtor-chroot scriptsI've written some scripts that help chroot a Tor - it's useful for chrooting a git build of Tor or for using the Tor binaries that are provided by Debian.
I'd like them to go into contrib/ so that they don't bit rot in a lonely repo; a ...I've written some scripts that help chroot a Tor - it's useful for chrooting a git build of Tor or for using the Tor binaries that are provided by Debian.
I'd like them to go into contrib/ so that they don't bit rot in a lonely repo; a lot of this was inspired by sjm's work on the topic but I had to cobble it together via email, wiki and other web servers.
How can I get the code into contrib?Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4187A verified unverified-consensus should be renamed to cached-consensus2020-06-27T14:07:38ZanonymA verified unverified-consensus should be renamed to cached-consensusIf Tor with a fresh $DATA_DIR gets a consensus and cannot verify, Tor writes it as $DATA_DIR/unverified-consensus. If Tor then is restarted and suddenly can verify unverified-consensus for whatever reason, Tor will start using it and nev...If Tor with a fresh $DATA_DIR gets a consensus and cannot verify, Tor writes it as $DATA_DIR/unverified-consensus. If Tor then is restarted and suddenly can verify unverified-consensus for whatever reason, Tor will start using it and never write a cached-consensus. While this doesn't cause Tor to misbehave AFAICT, the name of unverified-consensus is misleading since it in fact isn't unverified any longer.
Steps to reproduce:
1. rm $DATA_DIR/*-consensus
2. date --set="Jan 1 00:00:00 UTC 2013" # or whenever all current authority certs are expired
3. start tor
4. verify that Tor is *not* working and that you got $DATA_DIR/unverified-consensus
5. stop tor
6. set correct system time
7. start tor
8. verify that Tor *is* working and that there's no $DATA_DIR/cached-consensus, only $DATA_DIR/unverified-consensusTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4676Eliminate "family" field in tor_addr_t2020-06-27T14:07:10ZNick MathewsonEliminate "family" field in tor_addr_tThe tor_addr_t structure has a "family" member that stores AF_INET, AF_INET6, or AF_UNSPEC. So in theory we'd need only 3 bits for it... but in practice, it bumps up the size of the structure by 4-8 bytes, because of alignment issues.
...The tor_addr_t structure has a "family" member that stores AF_INET, AF_INET6, or AF_UNSPEC. So in theory we'd need only 3 bits for it... but in practice, it bumps up the size of the structure by 4-8 bytes, because of alignment issues.
This excess space matters, because we allocate a whole lot of tor_addr_ts. For example, we allocate one for every exit policy entry.
We can save space here by using the "v4-mapped address" trick of RFC4291, and using ::ffff:1.2.3.4 as the representation of 1.2.3.4. For AF_UNSPEC, we can just choose a sentinel value.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5683add libtool support to tor2020-06-27T14:06:26ZTracadd libtool support to torUsing libtool standardizes building shared or static libraries in a portable manner.
**Trac**:
**Username**: rsavoyeUsing libtool standardizes building shared or static libraries in a portable manner.
**Trac**:
**Username**: rsavoyeTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6236Remove duplicate code between parse_{c,s}method_line2021-09-16T14:36:00ZGeorge KadianakisRemove duplicate code between parse_{c,s}method_line`parse_{c,s}method_line` share lots of duplicate code. We must find a way to merge the two functions, or hide the duplicate code into functions.`parse_{c,s}method_line` share lots of duplicate code. We must find a way to merge the two functions, or hide the duplicate code into functions.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7176Adapt and update AccessLabs' patches for reduced Tor memory consumption for e...2020-06-27T14:05:27ZcypherpunksAdapt and update AccessLabs' patches for reduced Tor memory consumption for embedded devicesThese are a set of patches written by Access Labs. They claim that these patches reduce memory usage on small low memory devices.
The patches are in several different areas:
* using anonymous mmap() for storing large chunks of data (i...These are a set of patches written by Access Labs. They claim that these patches reduce memory usage on small low memory devices.
The patches are in several different areas:
* using anonymous mmap() for storing large chunks of data (instead of tempfiles)
* persisting the keys into /etc/tor/keys, rather than putting them in /var (tmpfs on OpenWRT)
* using fixed values for should_rebuild_md_cache() && router_should_rebuild_store()
* reducing the age of microdesc (changing the compile time defines)
* using gzipped files for storing cache
I am including the files here as one ticket item rather than 5, but it might make sense to break them up into separate issues.
The source for these changes is the TorWRT package from Access Labs: https://accesslabs.org/wiki/TorWRTTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7553[simple patch] Expose ISO_STREAM via isolation flag config option2021-08-18T23:05:58Zcypherpunks[simple patch] Expose ISO_STREAM via isolation flag config optionThis patch exposes ISO_STREAM as a torrc isolation flag _IsolateStream_, along with what I think is a very convincing warning in the manpage against general use. So why this option?
1. It's quite useful for managing a pool of long runn...This patch exposes ISO_STREAM as a torrc isolation flag _IsolateStream_, along with what I think is a very convincing warning in the manpage against general use. So why this option?
1. It's quite useful for managing a pool of long running connections, etc.
1. I remember some project (a part of Tails? Whonix? not sure) rigging up something inferior by generating unique Socks credentials for each request, which is messy and doesn't work for TransPort.
1. Since ISO_STREAM is already used internally, nothing beyond adding the config option was needed for this super simple patch.
Testing with wget check.tpo showed it to work as expected here.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12169Improve speed by fixing tor_memeq performance, bottleneck(s)2020-06-27T14:02:57ZNick MathewsonImprove speed by fixing tor_memeq performance, bottleneck(s)According to some legacy/trac#11332 results, tor_memeq shows up a bit high in our profiles. We can speed it up a bit, and remove one critical-path case of it.
Branches to follow.
Not sure if this is 0.2.5 or not.According to some legacy/trac#11332 results, tor_memeq shows up a bit high in our profiles. We can speed it up a bit, and remove one critical-path case of it.
Branches to follow.
Not sure if this is 0.2.5 or not.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14039Many unnecessary CPU wakeups per second2020-06-27T14:02:03ZTracMany unnecessary CPU wakeups per secondPowerTOP shows Tor waking up 10 times per second even when it’s doing nothing. This is bad for power usage on a laptop because it prevents the CPU from entering its deepest sleep states. It looks like the reason is the default TokenBuc...PowerTOP shows Tor waking up 10 times per second even when it’s doing nothing. This is bad for power usage on a laptop because it prevents the CPU from entering its deepest sleep states. It looks like the reason is the default TokenBucketRefillInterval of 100 msec (legacy/trac#3630). Perhaps this logic can be refactored so that `refill_timer` is only activated when there are buckets to be refilled.
**Trac**:
**Username**: anderskTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15015tor --verify-config should not bind to ports2021-09-16T14:35:00Zcypherpunkstor --verify-config should not bind to portshttps://lists.torproject.org/pipermail/tor-talk/2015-February/036973.html
maybe we can also get rid of the 'requires root privileges' - thing?
https://lists.torproject.org/pipermail/tor-talk/2015-February/036970.htmlhttps://lists.torproject.org/pipermail/tor-talk/2015-February/036973.html
maybe we can also get rid of the 'requires root privileges' - thing?
https://lists.torproject.org/pipermail/tor-talk/2015-February/036970.htmlTor: 0.3.4.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/15019Most FooStatistics entries in the man page don't mention ExtraInfo descriptors2021-07-22T16:25:47ZRoger DingledineMost FooStatistics entries in the man page don't mention ExtraInfo descriptors```
ConnDirectionStatistics 0|1
When this option is enabled, Tor writes statistics on the
bidirectional use of connections to disk every 24 hours. (Default:
0)
HiddenServiceStatistics 0|1
...```
ConnDirectionStatistics 0|1
When this option is enabled, Tor writes statistics on the
bidirectional use of connections to disk every 24 hours. (Default:
0)
HiddenServiceStatistics 0|1
When this option is enabled, a Tor relay writes obfuscated
statistics on its role as hidden-service directory, introduction
point, or rendezvous point to disk every 24 hours. If
ExtraInfoStatistics is also enabled, these statistics are further
published to the directory authorities. (Default: 0)
ExtraInfoStatistics 0|1
When this option is enabled, Tor includes previously gathered
statistics in its extra-info documents that it uploads to the
directory authorities. (Default: 1)
```
Most of the man page entries for FooStatistics are like ConnDirectionStatistics -- they just talk about writing to disk. Then tucked away elsewhere is this ExtraInfoStatistics thing that says "previously gathered statistics".
It sounds like we should make much clearer that some of these go into the extrainfo descriptor and get published to the outside world?
And are there some of them that *don't* get published to the outside world? It's not immediately obvious from looking at the code.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16372tor uses getaddrinfo even if DisableNetwork is set2021-07-22T16:25:48Zteortor uses getaddrinfo even if DisableNetwork is setIf DisableNetwork is set, but tor is passed a textual (?) address in a `*Port` config line, it uses `getaddrinfo` to lookup the address. This can access the network and cause config parsing to hang. (See legacy/trac#16366.)
The document...If DisableNetwork is set, but tor is passed a textual (?) address in a `*Port` config line, it uses `getaddrinfo` to lookup the address. This can access the network and cause config parsing to hang. (See legacy/trac#16366.)
The documentation for DisableNetwork could be clearer about this - that tor *will* make certain network-related calls as part of its config process, even if DisableNetwork is set.
If the config uses names that need to be looked up using the network, this also means the external network needs to be up for config parsing to succeed. (Which seems like an unexpected dependency.)
So DisableNetwork may not be able to be used as described (implied?) - for a controller to setup the config while the network is down, then re-enable tor networking when the network comes up.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18105Replace getsockname with tor_getsockname2020-06-27T13:59:45ZteorReplace getsockname with tor_getsocknameThere's a lot of duplicate code in Tor that calls getsockname, then stuffs the address in a tor_addr_t.
Let's cleanup that code by replacing it with tor_getsockname where that makes sense.
For example, in legacy/trac#18100, we left beh...There's a lot of duplicate code in Tor that calls getsockname, then stuffs the address in a tor_addr_t.
Let's cleanup that code by replacing it with tor_getsockname where that makes sense.
For example, in legacy/trac#18100, we left behind duplicate code in destination_from_socket, because it was a backport, and the changes required to deduplicate it were complex.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18918Clarify directory and ORPort checking functions2021-09-16T14:34:12ZteorClarify directory and ORPort checking functionsThe OR and dir checking functions in router.c are somewhat confusing. We could document them better, or modify their names, or restructure.
In legacy/trac#18616, we added:
* decide_to_advertise_begindir
We already had:
* check_whether_...The OR and dir checking functions in router.c are somewhat confusing. We could document them better, or modify their names, or restructure.
In legacy/trac#18616, we added:
* decide_to_advertise_begindir
We already had:
* check_whether_orport_reachable
* check_whether_dirport_reachable
* router_has_bandwidth_to_be_dirserver
* router_should_be_directory_server
* dir_server_mode
* decide_to_advertise_dirport
* consider_testing_reachabilityTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19429Clean up our OpenSSL 1.1 support.2021-09-16T14:33:30ZYawning AngelClean up our OpenSSL 1.1 support.In an ideal world, we should support OpenSSL 1.1 built with the deprecated APIs entirely disabled. Additionally while the code that uses the new opaque wrappers for the RSA stuff is functional and maintainable, it would be cleaner if we...In an ideal world, we should support OpenSSL 1.1 built with the deprecated APIs entirely disabled. Additionally while the code that uses the new opaque wrappers for the RSA stuff is functional and maintainable, it would be cleaner if we provided our own wrappers for a more unified codepath.
Neither of these are high priority as the current code works, the changes suggested would just make things better.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20522Enable DISABLE_DISABLING_ED255192020-06-27T13:57:57ZteorEnable DISABLE_DISABLING_ED25519Split from legacy/trac#18319
At some point, we should require relays that once had an ed25519 key associated with their RSA key to always have that key, rather than allowing them to drop back to a version that didn't support ed25519.
(...Split from legacy/trac#18319
At some point, we should require relays that once had an ed25519 key associated with their RSA key to always have that key, rather than allowing them to drop back to a version that didn't support ed25519.
(This means they need to use a new RSA key to downgrade to an older version of tor without ed25519, which is consistent with the pinning in legacy/trac#18319.)
This means either:
1a. waiting until 0.2.5 is no longer recommended, or
1b. look at historical metrics data to see how often relays run a recent version for a while, then drop back to an older one. If the answer is "almost never" then we can just turn it on now.
To implement this change, replace `#undef DISABLE_DISABLING_ED25519` with `#define DISABLE_DISABLING_ED25519`.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20887DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d instead2021-09-16T14:33:04ZteorDIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d insteadA FreeBSD relay operator reports the message:
```
[WARN] Being a directory cache (default) with less than DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume most of the available resources, consider disabling this ...A FreeBSD relay operator reports the message:
```
[WARN] Being a directory cache (default) with less than DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume most of the available resources, consider disabling this functionality by setting the DirCache option to 0
```
So we should print the macro value the same way we do every other value, using "%d" in the string, and passing it as an argument.
(This macro changed name in legacy/trac#20684.)Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22653upgrading Tor-0.2.9.10 to Tor-0.3.0.8 or Tor-0.3.1.3_alpha fails to build cir...2020-06-27T13:56:24ZTracupgrading Tor-0.2.9.10 to Tor-0.3.0.8 or Tor-0.3.1.3_alpha fails to build circuitsMy GNU/Linux Gentoo compiles Tor manually instead of Tor-browser. I use pluggable transports **obfs4** and **bridge**.
Tor-0.2.9.10 worked like a charm with current torrc. When upgrading to Tor-0.3.0.8 with the same torrc configuration,...My GNU/Linux Gentoo compiles Tor manually instead of Tor-browser. I use pluggable transports **obfs4** and **bridge**.
Tor-0.2.9.10 worked like a charm with current torrc. When upgrading to Tor-0.3.0.8 with the same torrc configuration, it no longer builds circuits.
My /etc/tor/torrc configuration:
```
User tor
PIDFile /var/run/tor/tor.pid
AvoidDiskWrites 1
DirReqStatistics 0
DataDirectory /var/lib/tor/data
Log notice syslog
Log notice file /var/lib/tor/notice.log
StrictNodes 1
GeoIPExcludeUnknown 1
ExcludeNodes {vn},{pk}
NodeFamily {vn},{pk}
EnforceDistinctSubnets 1
UseEntryGuards 1
PathsNeededToBuildCircuits 0.95
UseBridges 1
UpdateBridgesFromAuthority 1
ClientTransportPlugin obfs4 exec /opt/bin/obfs4proxy --enableLogging --logLevel ERROR
Bridge obfs4 12.34.56.78 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA cert=BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB iat-mode=0
...
Bridge obfs4 12.34.56.78 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA cert=BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB iat-mode=0
DNSPort auto
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
AutomapHostsSuffixes .exit,.onion
TransPort auto
```
Tor 0.2.9.10 log:
```
Jun 18 19:27:42.000 [notice] Tor 0.2.9.10 (git-1f6c8eda0073f464) opening new log file.
Jun 18 19:27:42.352 [warn] You have asked to exclude certain relays from all positions in your circuits. Expect hidden services and other Tor features to be broken in un\
predictable ways.
Jun 18 19:27:42.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Jun 18 19:27:42.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Jun 18 19:27:42.000 [notice] Bootstrapped 0%: Starting
Jun 18 19:27:43.000 [notice] new bridge descriptor 'acanthdisorienta' (cached): $AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA~acanthdisorienta at 12.34.56.78
Jun 18 19:27:43.000 [notice] new bridge descriptor 'acanthdisorienta' (cached): $AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA~acanthdisorienta at 12.34.56.78
Jun 18 19:27:44.000 [notice] new bridge descriptor 'acanthdisorienta' (cached): $AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA~acanthdisorienta at 12.34.56.78
Jun 18 19:27:44.000 [notice] Delaying directory fetches: Pluggable transport proxies still configuring
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 6)
Jun 18 19:27:46.000 [notice] Bootstrapped 5%: Connecting to directory server
Jun 18 19:27:46.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Jun 18 19:27:48.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection
Jun 18 19:27:48.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus
Jun 18 19:27:48.000 [notice] Bootstrapped 25%: Loading networkstatus consensus
Jun 18 19:27:52.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Jun 18 19:27:53.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Jun 18 19:27:54.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jun 18 19:27:54.000 [notice] Bootstrapped 100%: Done
```
Tor-0.3.0.8 log
```
Jun 18 17:07:10.000 [notice] Tor 0.3.0.8 (git-802d30d9b71a6d54) opening new log file.
Jun 18 17:07:10.861 [warn] You have asked to exclude certain relays from all positions in your circuits. Expect hidden services and other Tor features to be broken in un\
predictable ways.
Jun 18 17:07:10.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Jun 18 17:07:11.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Jun 18 17:07:11.000 [notice] Bootstrapped 0%: Starting
Jun 18 17:07:12.000 [notice] Starting with guard context "bridges"
Jun 18 17:07:12.000 [notice] new bridge descriptor 'acanthdisorienta' (cached): $37AB6046C23F2385102D0D380AD827070E26E528~acanthdisorienta at 12.34.56.78
Jun 18 17:07:12.000 [notice] Delaying directory fetches: Pluggable transport proxies still configuring
Jun 18 17:09:14.000 [notice] Bootstrapped 5%: Connecting to directory server
Jun 18 17:09:14.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Jun 18 17:09:15.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection
Jun 18 17:09:16.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus
Jun 18 17:09:16.000 [warn] Proxy Client: unable to connect to 12.34.56.78:443 ("general SOCKS server failure")
Jun 18 17:11:24.000 [warn] Proxy Client: unable to connect to 12.34.56.78:34095 ("general SOCKS server failure")
Jun 18 17:11:24.000 [warn] Proxy Client: unable to connect to 12.34.56.78:60491 ("general SOCKS server failure")
Jun 18 17:11:24.000 [warn] Proxy Client: unable to connect to 12.34.56.78:50211 ("general SOCKS server failure")
...
Jun 18 17:31:24.000 [warn] Proxy Client: unable to connect to 12.34.56.78:34095 ("general SOCKS server failure")
Jun 18 17:53:40.000 [notice] new bridge descriptor 'acanthdisorienta' (fresh): $37AB6046C23F2385102D0D380AD827070E26E528~acanthdisorienta at 12.34.56.78
Jun 18 17:53:40.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for some of our primary entry guards
Jun 18 17:09:16.000 [warn] Proxy Client: unable to connect to 12.34.56.78:443 ("general SOCKS server failure")
Jun 18 17:11:24.000 [warn] Proxy Client: unable to connect to 12.34.56.78:34095 ("general SOCKS server failure")
Jun 18 17:11:24.000 [warn] Proxy Client: unable to connect to 12.34.56.78:60491 ("general SOCKS server failure")
Jun 18 17:11:24.000 [warn] Proxy Client: unable to connect to 12.34.56.78:50211 ("general SOCKS server failure")
```
**Trac**:
**Username**: t0rTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22685policy for acceptable licenses from contributors2020-06-27T13:56:23ZTaylor Yupolicy for acceptable licenses from contributorsWe should have a policy statement about what licenses we will accept for contributions to Core Tor. Maybe it should go into `CodingStandards.md` or similar.
It seems like we currently want BSD-licensed code (3-clause?) and maybe don't ...We should have a policy statement about what licenses we will accept for contributions to Core Tor. Maybe it should go into `CodingStandards.md` or similar.
It seems like we currently want BSD-licensed code (3-clause?) and maybe don't want copylefted stuff?
Maybe also clarify that patches to an existing file are assumed to be copyright-assigned to us or licensed under the same license as the original file.
Bonus points if there's a well-written rationale for our licensing choices. (But maybe that should be a separate ticket.)Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22701Missing makefile dependencies make parallel builds fail2020-06-27T13:56:22ZteorMissing makefile dependencies make parallel builds failI think we're missing some dependencies in the src/ext/ed25519/ref10 makefile on Tor 0.3.0.8. I bet it still exists in 0.3.1.
I repeated the same make command, and it worked fine, because the files were there.
I'm hoping someone else k...I think we're missing some dependencies in the src/ext/ed25519/ref10 makefile on Tor 0.3.0.8. I bet it still exists in 0.3.1.
I repeated the same make command, and it worked fine, because the files were there.
I'm hoping someone else knows how to fix it:
```
$ make -j8 all check
make all-am
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_0.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_1.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_add.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_cmov.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_copy.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_frombytes.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_invert.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_isnegative.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_isnonzero.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_mul.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_neg.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_pow22523.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_sq.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_sq2.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_sub.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_tobytes.o
make[1]: Entering directory '/home/privcount/tor-privcount'
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_mul.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_add.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_double_scalarmult.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_frombytes.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_madd.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_msub.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p1p1_to_p2.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p1p1_to_p3.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p2_0.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_pow22523.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_double_scalarmult.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p2_dbl.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p3_0.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p1p1_to_p2.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p2_0.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p3_dbl.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p2_dbl.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p3_to_cached.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p3_to_p2.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p3_tobytes.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p3_0.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p3_dbl.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_precomp_0.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_scalarmult_base.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_sub.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_tobytes.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_p3_to_cached.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_scalarmult_base.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_sub.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-ge_tobytes.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-keypair.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-keypair.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-open.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-open.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-sc_muladd.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-sc_muladd.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-sc_reduce.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-sign.o
mv: cannot stat 'src/ext/ed25519/ref10/.deps/src_ext_ed25519_ref10_libed25519_ref10_a-open.Tpo': No such file or directory
Makefile:5665: recipe for target 'src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-open.o' failed
make: *** [src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-open.o] Error 1
make: *** Waiting for unfinished jobs....
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-sc_reduce.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-sign.o
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-keyconv.o
mv: mv: cannot stat 'src/ext/ed25519/ref10/.deps/src_ext_ed25519_ref10_libed25519_ref10_a-keypair.Tpo': No such file or directorycannot stat 'src/ext/ed25519/ref10/.deps/src_ext_ed25519_ref10_libed25519_ref10_a-sign.Tpo'
: No such file or directory
Makefile:5651: recipe for target 'src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-keypair.o' failed
make: *** [src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-keypair.o] Error 1
Makefile:5707: recipe for target 'src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-sign.o' failed
make: *** [src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-sign.o] Error 1
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-blinding.o
CC src/ext/ed25519/donna/src_ext_ed25519_donna_libed25519_donna_a-ed25519_tor.o
CC src/ext/keccak-tiny/src_ext_keccak_tiny_libkeccak_tiny_a-keccak-tiny-unrolled.o
...
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22907Investigate using cargo-vendor for offline dependencies2020-06-27T13:56:08ZIsis LovecruftInvestigate using cargo-vendor for offline dependenciesPeople on the cargo team recommended we look into using https://github.com/alexcrichton/cargo-vendor to facilitate our offline builds. (See also legacy/trac#22830)People on the cargo team recommended we look into using https://github.com/alexcrichton/cargo-vendor to facilitate our offline builds. (See also legacy/trac#22830)Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/22921Tor 0.3.0.9 and 0.3.1.4-alpha on FreeBSD: Failed to find node for hop 0 of ou...2020-06-27T13:56:07ZNeel Chauhanneel@neelc.orgTor 0.3.0.9 and 0.3.1.4-alpha on FreeBSD: Failed to find node for hop 0 of our path. Discarding this circuit.When I run Tor on FreeBSD on a dedicated server, I get errors like this:
Jul 14 13:38:46.000 [warn] Failed to find node for hop 0 of our path. Discarding this circuit.
The versions of Tor affected are 0.3.0.9 and 0.3.1.4-alpha. The 0.2...When I run Tor on FreeBSD on a dedicated server, I get errors like this:
Jul 14 13:38:46.000 [warn] Failed to find node for hop 0 of our path. Discarding this circuit.
The versions of Tor affected are 0.3.0.9 and 0.3.1.4-alpha. The 0.2.9.x branches and earlier don't have this issue.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23094prop224: Optimize hsdir_index calculation2020-06-27T13:55:59ZGeorge Kadianakisprop224: Optimize hsdir_index calculationLet's include `hsdir_index_t` in the node_t instead of a pointer that we allocate, since that structure is always present anyway.
See here for more details:
https://oniongit.eu/dgoulet/tor/merge_requests/6#note_412Let's include `hsdir_index_t` in the node_t instead of a pointer that we allocate, since that structure is always present anyway.
See here for more details:
https://oniongit.eu/dgoulet/tor/merge_requests/6#note_412Tor: 0.3.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/23107prop224: Optimize hs_circ_service_get_intro_circ() digest calculation2020-06-27T13:55:58ZGeorge Kadianakisprop224: Optimize hs_circ_service_get_intro_circ() digest calculationOur prop224 function for getting an intro circ given its intro object re-calculates the relay identity fpr all the time:
```
if (ip->base.is_only_legacy) {
uint8_t digest[DIGEST_LEN];
if (BUG(crypto_pk_get_digest(ip->legacy_key...Our prop224 function for getting an intro circ given its intro object re-calculates the relay identity fpr all the time:
```
if (ip->base.is_only_legacy) {
uint8_t digest[DIGEST_LEN];
if (BUG(crypto_pk_get_digest(ip->legacy_key, (char *) digest) < 0)) {
goto end;
}
circ = hs_circuitmap_get_intro_circ_v2_service_side(digest);
```
We could shove that in the `hs_service_intro_point_t` object as well to cut some digest calculations.Tor: 0.3.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/23147prop288: Merge privcount-in-tor data collector backend implementation2020-06-27T13:55:56ZNick Mathewsonprop288: Merge privcount-in-tor data collector backend implementationI've got implementations that match the current prop280, but we'll need to make some additional fixes, including:
* Whatever changes we make in prop280.
* Actually initializing the privcount subsytem
* Collecting initial statis...I've got implementations that match the current prop280, but we'll need to make some additional fixes, including:
* Whatever changes we make in prop280.
* Actually initializing the privcount subsytem
* Collecting initial statistics.
The current implementations are in `privcount_nm_v2_032` and `privcount_nm_v2_shake_032`.Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23354Remove deterministic download schedule code and configs2021-09-16T14:32:00ZteorRemove deterministic download schedule code and configsUnder exponential backoff, download schedules contain the ~~maximum time we will wait, even if the random amount is larger.~~ initial time we will wait, and everything else is random exponential from that point onwards.
~~But in most ca...Under exponential backoff, download schedules contain the ~~maximum time we will wait, even if the random amount is larger.~~ initial time we will wait, and everything else is random exponential from that point onwards.
~~But in most cases, the random amount is much smaller than the maximum, so we could replace the item with the actual maximum, or delete it from the schedule altogether. (On the public network, the maximum is 4x the last entry, on test networks, it's 3x.)~~
So once we're sure that we will never revert to deterministic schedules, we should make each schedule into a single initial value, and remove the deterministic code.
We should make these changes based on the schedules in legacy/trac#23347.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23512Bandwidth stats info leak upon close of circuits with queued cells2020-06-27T13:55:38ZGeorge KadianakisBandwidth stats info leak upon close of circuits with queued cellsWe received a tor bug bounty report from `jaym` about a congestion attack variant that can cause bandwidth stats watermark.
The bug uses the fact that Tor increments the _read bytes counter_ before adding the cell to the output buffer:...We received a tor bug bounty report from `jaym` about a congestion attack variant that can cause bandwidth stats watermark.
The bug uses the fact that Tor increments the _read bytes counter_ before adding the cell to the output buffer: If the circuit gets killed before the cell gets relayed to the next hop, then the _write bytes counter_ will never be updated, making the _read bytes counter_ having a higher value than the _write bytes counter_. The attacker could exploit this assymetry to find relays using their bandwidth graph.
The attacker can kill the circuit using the OOM killer by saturating its output queue with cells until `circuits_handle_oom()` gets called and kills the circuit.
We should figure out whether this attack is practical (the paper claims it is) and whether it's worthwhile fixing it. Just fixing this issue won't solve the general issue of congestion attacks, and it might even allow other kinds of attacks.
The most practical fix right now seem to be to hack circuit_handle_oom()` to actually decrement the read counters before killing a circuit. However, that's a very specific fix that might solve this very specific bug, but leave the rest of the bug class open.
Another approach would be removing the bandwidth graphs, or aggregating them over a greater period of time, or adding noise. We should consider these approaches carefully since bandwidth graphs see great use by academic papers and also by relay operators (to gauge their contribution).Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23650Tor source code has many typos2020-06-27T13:55:29ZcypherpunksTor source code has many typos```
$ go get -u github.com/client9/misspell/cmd/misspell
$ misspell .
.gitlab-ci.yml:23:14: "suspectible" is a misspelling of "susceptible"
changes/bug23580:2:49: "mentionning" is a misspelling of "mentioning"
contrib/operator-tools/linu...```
$ go get -u github.com/client9/misspell/cmd/misspell
$ misspell .
.gitlab-ci.yml:23:14: "suspectible" is a misspelling of "susceptible"
changes/bug23580:2:49: "mentionning" is a misspelling of "mentioning"
contrib/operator-tools/linux-tor-prio.sh:90:59: "trafic" is a misspelling of "traffic"
configure.ac:535:10: "targetting" is a misspelling of "targeting"
doc/HACKING/GettingStartedRust.md:119:17: "targetting" is a misspelling of "targeting"
doc/HACKING/Tracing.md:9:17: "seperated" is a misspelling of "separated"
m4/pkg.m4:56:20: "occurence" is a misspelling of "occurrence"
scripts/maint/redox.py:104:35: "alledgedly" is a misspelling of "allegedly"
src/common/compat_openssl.h:15:10: "compatability" is a misspelling of "compatibility"
src/common/address.c:1126:23: "comapre" is a misspelling of "compare"
src/common/compat.c:2447:3: "successfull" is a misspelling of "successful"
src/common/crypto_ed25519.c:228:28: "occured" is a misspelling of "occurred"
src/common/crypto_ed25519.c:262:18: "successfuly" is a misspelling of "successfully"
src/common/crypto_ed25519.c:526:30: "sucess" is a misspelling of "success"
src/common/crypto_ed25519.c:716:13: "cannonical" is a misspelling of "canonical"
src/common/crypto_ed25519.c:756:50: "neccessary" is a misspelling of "necessary"
scripts/maint/updateFallbackDirs.py:214:52: "multipled" is a misspelling of "multiplied"
scripts/maint/updateFallbackDirs.py:550:34: "bandwdith" is a misspelling of "bandwidth"
scripts/maint/updateFallbackDirs.py:1553:35: "bandwdith" is a misspelling of "bandwidth"
src/common/crypto.c:1527:3: "sucess" is a misspelling of "success"
src/common/crypto.c:2835:35: "foward" is a misspelling of "forward"
src/common/crypto.c:2848:5: "comparision" is a misspelling of "comparison"
src/common/timers.c:66:39: "inefficent" is a misspelling of "inefficient"
src/common/tortls.c:1941:34: "intial" is a misspelling of "initial"
src/ext/curve25519_donna/README:9:0: "dependancies" is a misspelling of "dependencies"
doc/tor.1.txt:2416:26: "simultanous" is a misspelling of "simultaneous"
doc/tor.1.txt:2831:4: "decribing" is a misspelling of "describing"
src/ext/ed25519/donna/README.md:59:25: "aginst" is a misspelling of "against"
src/ext/ed25519/donna/README.md:76:25: "aginst" is a misspelling of "against"
src/ext/ed25519/donna/ed25519_tor.c:135:45: "implementaion" is a misspelling of "implementation"
src/common/util.c:3048:18: "sucess" is a misspelling of "success"
src/common/util.c:3899:46: "accomodate" is a misspelling of "accommodate"
src/common/util.c:3929:10: "processs" is a misspelling of "processes"
src/or/bridges.c:354:40: "adress" is a misspelling of "address"
src/or/circpathbias.c:1470:3: "transfered" is a misspelling of "transferred"
src/or/circpathbias.c:1530:3: "transfered" is a misspelling of "transferred"
src/or/circuitlist.c:739:24: "rendevous" is a misspelling of "rendezvous"
src/or/circuitlist.c:741:24: "rendevous" is a misspelling of "rendezvous"
src/or/circuitstats.c:167:58: "paramter" is a misspelling of "parameter"
src/or/circuitstats.c:194:55: "paramter" is a misspelling of "parameter"
src/or/circuitstats.c:221:55: "paramter" is a misspelling of "parameter"
src/or/circuitstats.c:253:55: "paramter" is a misspelling of "parameter"
src/or/circuitstats.c:277:60: "paramter" is a misspelling of "parameter"
src/or/circuitstats.c:309:55: "paramter" is a misspelling of "parameter"
src/or/circuitstats.c:356:61: "paramter" is a misspelling of "parameter"
src/or/circuitstats.c:386:58: "paramter" is a misspelling of "parameter"
src/or/connection.c:4129:46: "owernship" is a misspelling of "ownership"
src/or/connection.c:4139:46: "owernship" is a misspelling of "ownership"
src/or/config.c:2901:28: "occurances" is a misspelling of "occurrences"
src/or/dirserv.c:46:13: "reponsible" is a misspelling of "responsible"
src/or/dirserv.c:1089:18: "bandwith" is a misspelling of "bandwidth"
src/or/dirserv.h:126:45: "encrytped" is a misspelling of "encrypted"
src/or/dirvote.c:666:48: "accidently" is a misspelling of "accidentally"
src/or/control.c:4695:5: "Succeded" is a misspelling of "Succeeded"
src/or/dns.c:22:38: "rela" is a misspelling of "real"
src/or/hs_cache.c:693:28: "explicitely" is a misspelling of "explicitly"
src/or/hs_cache.c:778:28: "explicitely" is a misspelling of "explicitly"
src/or/hs_client.c:540:5: "Explicitely" is a misspelling of "Explicitly"
src/or/hs_config.c:553:38: "transfered" is a misspelling of "transferred"
src/or/directory.c:1155:27: "determins" is a misspelling of "determines"
src/or/directory.c:1166:27: "determins" is a misspelling of "determines"
src/or/directory.c:3433:54: "successfuly" is a misspelling of "successfully"
src/or/directory.c:4072:7: "prefered" is a misspelling of "preferred"
src/or/directory.c:4984:19: "seperator" is a misspelling of "separator"
src/or/hs_intropoint.c:427:43: "occured" is a misspelling of "occurred"
src/or/hs_common.c:1645:32: "prefered" is a misspelling of "preferred"
src/or/hs_common.c:1646:28: "prefered" is a misspelling of "preferred"
src/or/hs_descriptor.c:748:12: "occured" is a misspelling of "occurred"
src/or/hs_descriptor.c:805:40: "occured" is a misspelling of "occurred"
src/or/hs_descriptor.c:1602:22: "accomodate" is a misspelling of "accommodate"
src/or/onion_fast.c:26:19: "targetted" is a misspelling of "targeted"
src/or/reasons.c:431:39: "bandwidht" is a misspelling of "bandwidth"
src/or/rendcache.c:46:60: "unsuable" is a misspelling of "unusable"
src/or/rendcache.c:51:32: "realy" is a misspelling of "really"
src/or/rendcache.h:39:35: "occured" is a misspelling of "occurred"
src/or/hs_service.c:73:59: "seperated" is a misspelling of "separated"
src/or/hs_service.c:140:22: "transfered" is a misspelling of "transferred"
src/or/hs_service.c:254:49: "accomodate" is a misspelling of "accommodate"
src/or/hs_service.c:267:49: "accomodate" is a misspelling of "accommodate"
src/or/hs_service.c:284:49: "accomodate" is a misspelling of "accommodate"
src/or/hs_service.c:301:49: "accomodate" is a misspelling of "accommodate"
src/or/hs_service.c:1269:45: "fomr" is a misspelling of "from"
src/or/hs_service.c:1299:3: "Populare" is a misspelling of "Popular"
src/or/hs_service.c:3008:5: "succesful" is a misspelling of "successful"
src/or/rendclient.c:572:58: "choosen" is a misspelling of "chosen"
ReleaseNotes:1348:36: "detailled" is a misspelling of "detailed"
ReleaseNotes:5106:11: "occured" is a misspelling of "occurred"
ReleaseNotes:5579:23: "targetted" is a misspelling of "targeted"
ReleaseNotes:6756:6: "embarassing" is a misspelling of "embarrassing"
ReleaseNotes:6780:18: "documenation" is a misspelling of "documentation"
ReleaseNotes:8923:10: "absense" is a misspelling of "absence"
ReleaseNotes:10036:44: "arbitary" is a misspelling of "arbitrary"
ReleaseNotes:15225:33: "occassionally" is a misspelling of "occasionally"
ReleaseNotes:15344:36: "maintainance" is a misspelling of "maintenance"
src/or/rendservice.h:111:28: "simultanious" is a misspelling of "simultaneous"
src/or/policies.c:2369:11: "rougly" is a misspelling of "roughly"
src/or/rephist.c:2734:12: "Incrememnts" is a misspelling of "Increments"
src/or/shared_random.c:1074:8: "substract" is a misspelling of "subtract"
src/or/shared_random_state.c:1100:23: "transfered" is a misspelling of "transferred"
src/or/shared_random_state.c:1119:23: "transfered" is a misspelling of "transferred"
src/or/shared_random_state.c:1224:3: "transfered" is a misspelling of "transferred"
src/or/rendservice.c:1335:16: "sucess" is a misspelling of "success"
src/or/rendservice.c:3169:5: "Substract" is a misspelling of "Subtract"
src/or/rendservice.c:4085:17: "choosen" is a misspelling of "chosen"
src/or/routerlist.c:366:24: "downlaods" is a misspelling of "downloads"
src/or/routerlist.c:2636:52: "authorites" is a misspelling of "authorities"
src/or/transports.c:593:7: "futher" is a misspelling of "further"
src/or/or.h:3089:35: "artifically" is a misspelling of "artificially"
src/or/or.h:3347:19: "paramaters" is a misspelling of "parameters"
src/or/or.h:4100:33: "alwasy" is a misspelling of "always"
src/test/test.c:177:21: "procede" is a misspelling of "proceed"
src/test/test_conscache.c:44:40: "planetas" is a misspelling of "planets"
src/test/test_connection.c:782:41: "varaible" is a misspelling of "variable"
src/test/test_cell_formats.c:480:15: "acutally" is a misspelling of "actually"
src/test/test_channelpadding.c:445:22: "recieve" is a misspelling of "receive"
src/test/test_channelpadding.c:515:22: "recieve" is a misspelling of "receive"
src/test/test_channelpadding.c:814:43: "suport" is a misspelling of "support"
src/test/test_channelpadding.c:825:40: "suport" is a misspelling of "support"
src/test/test_hs.c:1012:33: "transfered" is a misspelling of "transferred"
src/test/test_entrynodes.c:1997:49: "confirmd" is a misspelling of "confirmed"
src/test/test_config.c:326:19: "shoudl" is a misspelling of "should"
src/test/test_config.c:1394:41: "succeds" is a misspelling of "succeeds"
src/test/test_hs_descriptor.c:416:5: "Seperate" is a misspelling of "Separate"
src/test/test_extorport.c:246:58: "ther" is a misspelling of "there"
src/test/test_hs_intropoint.c:142:18: "extentions" is a misspelling of "extensions"
src/test/test_hs_intropoint.c:555:4: "Successfuly" is a misspelling of "Successfully"
src/test/test_dir.c:1273:19: "comapre" is a misspelling of "compare"
src/test/test_hs_service.c:663:66: "successfuly" is a misspelling of "successfully"
src/test/test_microdesc.c:574:6: "expolding" is a misspelling of "exploding"
src/test/test_shared_random.c:427:44: "seperately" is a misspelling of "separately"
src/test/test_shared_random.c:637:52: "agains" is a misspelling of "against"
src/test/test_options.c:908:54: "existant" is a misspelling of "existent"
src/test/test_options.c:920:54: "existant" is a misspelling of "existent"
src/test/test_options.c:932:55: "existant" is a misspelling of "existent"
src/test/test_options.c:944:55: "existant" is a misspelling of "existent"
src/test/test_options.c:1114:52: "existant" is a misspelling of "existent"
src/trunnel/hs/cell_introduce1.trunnel:17:36: "explicitely" is a misspelling of "explicitly"
src/test/test_util.c:706:43: "millenia" is a misspelling of "millennia"
src/test/test_util.c:742:43: "millenia" is a misspelling of "millennia"
src/test/test_util.c:878:43: "millenia" is a misspelling of "millennia"
src/test/test_util.c:924:43: "millenia" is a misspelling of "millennia"
src/test/test_util.c:5348:41: "exersize" is a misspelling of "exercise"
ChangeLog:3045:36: "detailled" is a misspelling of "detailed"
ChangeLog:6513:11: "occured" is a misspelling of "occurred"
ChangeLog:7256:23: "targetted" is a misspelling of "targeted"
ChangeLog:8399:18: "documenation" is a misspelling of "documentation"
ChangeLog:9684:6: "embarassing" is a misspelling of "embarrassing"
ChangeLog:9785:38: "occured" is a misspelling of "occurred"
ChangeLog:12576:32: "acknowleged" is a misspelling of "acknowledge"
ChangeLog:13883:10: "absense" is a misspelling of "absence"
ChangeLog:16384:50: "occured" is a misspelling of "occurred"
ChangeLog:16798:44: "arbitary" is a misspelling of "arbitrary"
ChangeLog:19826:22: "concensus" is a misspelling of "consensus"
ChangeLog:23213:33: "occassionally" is a misspelling of "occasionally"
ChangeLog:23678:36: "maintainance" is a misspelling of "maintenance"
```Tor: 0.3.4.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/236930.3.1.7: Assertion threadpool failed in cpuworker_queue_work2020-06-27T13:55:26ZTrac0.3.1.7: Assertion threadpool failed in cpuworker_queue_workOn Ubuntu 14.04 I installed Tor version 0.3.1.7 (git-5fa14939bca67c23)
Upon starting tor as a service, it soon crashes. The following are the log entries:
```
Sep 29 02:26:03.000 [notice] Tor 0.3.1.7 (git-5fa14939bca67c23) opening log ...On Ubuntu 14.04 I installed Tor version 0.3.1.7 (git-5fa14939bca67c23)
Upon starting tor as a service, it soon crashes. The following are the log entries:
```
Sep 29 02:26:03.000 [notice] Tor 0.3.1.7 (git-5fa14939bca67c23) opening log file.
Sep 29 02:26:03.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Sep 29 02:26:03.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Sep 29 02:26:03.000 [warn] Could not open "/usr/share/doc/tor/tor-exit-notice.html": Permission denied
Sep 29 02:26:03.000 [warn] DirPortFrontPage file '/usr/share/doc/tor/tor-exit-notice.html' not found. Continuing anyway.
Sep 29 02:26:03.000 [notice] Bootstrapped 0%: Starting
Sep 29 02:26:04.000 [notice] Starting with guard context "default"
Sep 29 02:26:04.000 [notice] Opening Socks listener on /var/run/tor/socks
Sep 29 02:26:04.000 [notice] Opening Control listener on /var/run/tor/control
Sep 29 02:26:04.000 [notice] Bootstrapped 5%: Connecting to directory server
Sep 29 02:26:04.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Sep 29 02:26:04.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection
Sep 29 02:26:05.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus
Sep 29 02:26:05.000 [notice] Bootstrapped 25%: Loading networkstatus consensus
Sep 29 02:26:08.000 [err] tor_assertion_failed_(): Bug: ../src/or/cpuworker.c:499: cpuworker_queue_work: Assertion threadpool failed; aborting. (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: Assertion threadpool failed in cpuworker_queue_work at ../src/or/cpuworker.c:499. Stack trace: (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/bin/tor(log_backtrace+0x42) [0x5624134a32b2] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x94) [0x5624134bb904] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/bin/tor(cpuworker_queue_work+0x65) [0x56241345f395] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/bin/tor(consdiffmgr_add_consensus+0x2f3) [0x562413450fe3] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/bin/tor(networkstatus_set_current_consensus+0x9f1) [0x562413395971] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/bin/tor(connection_dir_reached_eof+0xc09) [0x5624134678d9] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/bin/tor(+0x105e6b) [0x562413440e6b] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/bin/tor(+0x4e921) [0x562413389921] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x754) [0x7eff0e3a9f24] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/bin/tor(do_main_loop+0x24d) [0x56241338aa4d] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/bin/tor(tor_main+0x1c35) [0x56241338e215] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/bin/tor(main+0x19) [0x5624133863c9] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7eff0d556f45] (on Tor 0.3.1.7 )
Sep 29 02:26:08.000 [err] Bug: /usr/bin/tor(+0x4b41b) [0x56241338641b] (on Tor 0.3.1.7 )__
```
**Trac**:
**Username**: alifTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23750Isolate libevent usage to a few locations2021-09-16T14:31:39ZNick MathewsonIsolate libevent usage to a few locationsWith legacy/trac#21841, we restricted openssl header usage to a small number of modules. We should do the same with libevent.With legacy/trac#21841, we restricted openssl header usage to a small number of modules. We should do the same with libevent.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23873Remove the return value of node_get_prim_orport()2021-09-16T14:31:39ZteorRemove the return value of node_get_prim_orport()~~Also, we don't clear the address and port when we fail.~~
~~This probably doesn't matter right now, but it matters as soon as we try to change node_get_prim_orport().~~
We don't check it, so let's remove it, and check for the null ad...~~Also, we don't clear the address and port when we fail.~~
~~This probably doesn't matter right now, but it matters as soon as we try to change node_get_prim_orport().~~
We don't check it, so let's remove it, and check for the null address instead.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23883document how to get Travis CI running on your fork of tor2021-07-22T16:22:27ZTaylor Yudocument how to get Travis CI running on your fork of torTor: 0.3.4.x-finalAlex XuAlex Xuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23909dirauths write corrupted keypin journal2020-06-27T13:55:15ZSebastian Hahndirauths write corrupted keypin journalWhen starting my dirauth, I see this line:
[warn] Loaded 56168 entries from keypin journal. Found 5 corrupt lines, 0 duplicates, and 15814 conflicts.
I assume the corrupted lines happen because the file is not atomically written, so if...When starting my dirauth, I see this line:
[warn] Loaded 56168 entries from keypin journal. Found 5 corrupt lines, 0 duplicates, and 15814 conflicts.
I assume the corrupted lines happen because the file is not atomically written, so if the disk runs full (which occasionally happened in the past due to bwauth issues) we're corrupting the log.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24011Attempt to open a stream on first hop of circuit2020-06-27T13:55:11ZteorAttempt to open a stream on first hop of circuitI'm seeing these warnings in chutney on recent tor releases.
They seem to have appeared in the last week or two.
Did we merge something that tries to block single-hop exits recently?
Or any changes to circuit creation code?
Because I t...I'm seeing these warnings in chutney on recent tor releases.
They seem to have appeared in the last week or two.
Did we merge something that tries to block single-hop exits recently?
Or any changes to circuit creation code?
Because I think it might be buggy.
```
Warning: Attempt by 127.0.0.1:59488 to open a stream on first hop of circuit. Closing. Number: 1
Warning: circuit_receive_relay_cell (backward) failed. Closing. Number: 1
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24065Decide on initial optimisation strategy for Android performance work2020-06-27T13:55:08ZAlexander Færøyahf@torproject.orgDecide on initial optimisation strategy for Android performance workBased on the results from the initial set of measurements, we should figure out where we should start doing optimization work.
This is the master ticket for this: concrete optimisation plans should be added as child tickets with the s8-...Based on the results from the initial set of measurements, we should figure out where we should start doing optimization work.
This is the master ticket for this: concrete optimisation plans should be added as child tickets with the s8-perf and/or the s8-battery keyword and s8-YYYYMM keyword for when we expect to finish working on the optimisation.Tor: 0.3.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24113We stop trying to download an md after 8 failed tries2020-06-27T13:55:06ZGeorge KadianakisWe stop trying to download an md after 8 failed triesThe config var `TestingMicrodescMaxDownloadTries` specifies the amount of times we are willing to try to download an md before we give up. It's set to 8 on the real network and 80 on the testnet.
This interacts badly with legacy/trac#21...The config var `TestingMicrodescMaxDownloadTries` specifies the amount of times we are willing to try to download an md before we give up. It's set to 8 on the real network and 80 on the testnet.
This interacts badly with legacy/trac#21969 since if we fail to fetch a primary guard md more than 8 times we will give up on it and refuse to bootstrap.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24127Profile a 0.3.2.x fast relay2020-06-27T13:55:05ZDavid Gouletdgoulet@torproject.orgProfile a 0.3.2.x fast relayFollowing legacy/trac#23722, this is to try to learn if we have any regression or obvious performance issue from profiling in 032.Following legacy/trac#23722, this is to try to learn if we have any regression or obvious performance issue from profiling in 032.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24350A fresh compiled tor does not honor MaxCircuitDirtiness2020-06-27T13:54:54ZTracA fresh compiled tor does not honor MaxCircuitDirtinessI am having a strange behavior when compiling tor, it does not take into account the **MaxCircuitDirtiness** I have set in the configuration... nor the default value that is supposed to be 10 minutes.
In fact, it changes identity **ever...I am having a strange behavior when compiling tor, it does not take into account the **MaxCircuitDirtiness** I have set in the configuration... nor the default value that is supposed to be 10 minutes.
In fact, it changes identity **every 5 minutes**!
I tried both the Ubuntu version (0.2.9.11) and the last official one from tor (0.3.1.18)
What is even stranger it that with the Ubuntu repo binary, it works fine.
Steps to reproduce:
* Start a Live Ubuntu 16.04.3 (x64 in my case) [so that the behavior is easy to reproduce]
Execute that script (as root... no problem we are in a Live session, all is gone in the end), it will install the necessary packages to compile (otherwise configure will complain on libevent-dev, then on libssl-dev), download sources and compile both versions.
```
cd /tmp
echo 'deb-src http://archive.ubuntu.com/ubuntu/ xenial-updates universe' >>'/etc/apt/sources.list'
apt-get update
apt-get install -y libevent-core-2.0-5 libevent-extra-2.0-5 libevent-openssl-2.0-5 libevent-pthreads-2.0-5 libevent-dev libssl-doc zlib1g-dev libssl-dev
gpg --keyserver keyserver.ubuntu.com --recv-keys 64792D67
gpg --no-default-keyring -a --export 64792D67 | gpg --no-default-keyring --keyring ~/.gnupg/trustedkeys.gpg --import -
apt-get source tor
cd "tor-0.2.9.11"
./configure
make
cd /tmp
wget https://www.torproject.org/dist/tor-0.3.1.8.tar.gz
tar xvzf tor-0.3.1.8.tar.gz
cd "tor-0.3.1.8"
./configure
make
```
You will have some warnings like:
```
ar: `u' modifier ignored since `D' is the default (see `U')
```
I am assuming these warnings are benign looking a 'u' and 'D' options in the man of ar.
You will get both versions of tor compiled as documented by the README.
Save them before rebooting.
Now whichever version you try, here is the output tracking the change of IP:
Set **MaxCircuitDirtiness** to 30 minutes for example with:
```
sudo echo "MaxCircuitDirtiness 1800" >>/etc/tor/torrc
```
Then test the ip we have through tor
```
$ while :; do line="$( date +%H:%M ) == $( curl -s http://whatismyip.akamai.com/ )"; echo "$line"; sleep 60; done
19:27 == 185.100.84.82
19:28 == 185.100.84.82
19:29 == 185.100.84.82
19:30 == 185.100.84.82
19:31 == 185.100.84.82
19:32 == 204.85.191.30
19:34 == 204.85.191.30
19:35 == 204.85.191.30
19:36 == 204.85.191.30
19:37 == 204.85.191.30
19:38 == 192.160.102.168
19:39 == 192.160.102.168
19:40 == 192.160.102.168
19:41 == 192.160.102.168
19:42 == 192.160.102.168
19:43 == 163.172.101.137
19:44 == 163.172.101.137
19:45 == 163.172.101.137
19:46 == 163.172.101.137
19:47 == 163.172.101.137
19:48 == 62.210.105.116
```
(This is done inside a VM with transparent proxying to Tor, see "middlebox").
We can see that it is changing ip **exactly** every 5 minutes.
When doing the same exit ip test with the stock binary version of Ubuntu that you get with:
```
sudo apt-get install tor
```
... all works well, it changes ip every 30 minutes as the configuration says.
**Questions:**
So... is there a magic trick to compile so that MaxCircuitDirtiness is taken into account ? If so, that would be a **documentation enhancement request**. I am thinking something like a flag: compile for "debug"/compile for "production" -didn't find that in the documentation!
Should I ask instead on the Ubuntu Launchpad (apparently they are clever enough to have figured out a way to make it work!)
We can however notice a difference between the versions we compiled and the binary from Ubuntu repo: **size**!
That is (I am guessing) because the tor we compiled has all the symbols.
But if you do (which is undocumented!):
```
strip --strip-unneeded tor
```
you get about the same size of stock binary. Anyway, I don't think having the symbols should change behaviors -except in case you have very very little RAM, which is not my case!-
MaxCircuitDirtiness is not such a big issue per se, but I am afraid that if we have those kind of "silent tricky bugs" (nothing in the log of tor) when compiling ourselves, there might be other more serious bugs that could compromise anonymity.
**Trac**:
**Username**: ZakharTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24378Prune the list of supported consensus methods2020-06-27T13:54:53ZteorPrune the list of supported consensus methodsWe currently have 13 supported consensus methods.
In 0.3.3, it is likely that prop282 will add 1 more, and prop283 will add 2 more.
Maybe we should prune this list eventually, because it will let us simplify our code, and make votes sm...We currently have 13 supported consensus methods.
In 0.3.3, it is likely that prop282 will add 1 more, and prop283 will add 2 more.
Maybe we should prune this list eventually, because it will let us simplify our code, and make votes smaller, less expensive to calculate, and reduce authority RAM requirements (due to fewer microdescs).
It has almost no impact on consensus size.
Here's how we could work out what to prune:
By mandatory feature:
We are currently locked into using consensus method 16 or later in the public network, because 0.2.9 and later require ntor keys, and 0.2.9 clients use microdescriptors by default.
We may add more mandatory features in 0.3.3 and 0.3.4.
By supported tor version:
On May 1, 2018, we will stop supporting 0.2.5, and only support 0.2.9 and later. This means that all supported non-alpha versions will support consensus methods 25 and later. (Or, if we count 0.2.9 alpha versions, it's 22 and later.)Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24484free(NULL) always works (nowadays) so stop acting like it might not2020-06-27T13:54:48ZTaylor Yufree(NULL) always works (nowadays) so stop acting like it might notsrc/common/util.h has the following text in a comment:
```
* Unlike the free() function, tor_free() will still work on NULL pointers,
* and it sets the pointer value to NULL after freeing it.
```
`free(NULL)` has been required to be a...src/common/util.h has the following text in a comment:
```
* Unlike the free() function, tor_free() will still work on NULL pointers,
* and it sets the pointer value to NULL after freeing it.
```
`free(NULL)` has been required to be a no-op since C89 at least. Some pre-ANSI platforms might have had a libc `free()` that didn't allow a null pointer, but we mostly don't care about those.
We should stop propagating this common misconception that `free(NULL)` might undefined on modern platforms. We should remove that text from the comment and remove the conditional from the implementation.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24544Fix more prop224 spec inconsistencies2020-06-27T13:54:46ZGeorge KadianakisFix more prop224 spec inconsistenciesinkylatenoth pointed various inconsistencies between spec and code:
https://lists.torproject.org/pipermail/tor-dev/2017-October/012527.html
A few of them have been addressed by Filipo in legacy/trac#24342, but not all of them.
We shoul...inkylatenoth pointed various inconsistencies between spec and code:
https://lists.torproject.org/pipermail/tor-dev/2017-October/012527.html
A few of them have been addressed by Filipo in legacy/trac#24342, but not all of them.
We should address the rest of them.Tor: 0.3.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/24587Reset bootstrapping state on shutdown2020-06-27T13:54:43ZNick MathewsonReset bootstrapping state on shutdownTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24659Wrap our sha2 interface in Rust which implements the appropriate traits2020-06-27T13:54:39ZIsis LovecruftWrap our sha2 interface in Rust which implements the appropriate traitsWe should wrap our usage of hash digest functions (and XOFs) in Rust types which implement the appropriate traits, yet still exposes the same API functionality we currently have in C. To keep this task small, I think we should start off ...We should wrap our usage of hash digest functions (and XOFs) in Rust types which implement the appropriate traits, yet still exposes the same API functionality we currently have in C. To keep this task small, I think we should start off with just the sha2 code for now. (Later, it's probably some copy-paste and a bit of refactoring to provide the same interface for other digests, and similar for XOFs.)
This ticket is probably slightly blocked on legacy/trac#24658, and in turn is blocking legacy/trac#23886.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/24660Wrap our PRNG interface(s) in Rust with appropriate traits2020-06-27T13:54:39ZIsis LovecruftWrap our PRNG interface(s) in Rust with appropriate traitsSimilar to legacy/trac#24659, we should provide a way to wrap our C code for getting randomness in Rust, while implementing the appropriate traits (from `rand`) so that we're able to switch in Rust implementations if we want later.
This...Similar to legacy/trac#24659, we should provide a way to wrap our C code for getting randomness in Rust, while implementing the appropriate traits (from `rand`) so that we're able to switch in Rust implementations if we want later.
This is also blocking legacy/trac#23886.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/24688timing wheels should use 32-bit math on 32-bit platforms2020-06-27T13:54:38ZNick Mathewsontiming wheels should use 32-bit math on 32-bit platformsI think this might help our 32-bit performance a bit.
Not putting this in needs_review yet, since it needs more analysis.
```
diff --git a/src/common/timers.c b/src/common/timers.c
index 93cde7de5fbd4b..3c806b7f4b422a 100644
--- a/src/...I think this might help our 32-bit performance a bit.
Not putting this in needs_review yet, since it needs more analysis.
```
diff --git a/src/common/timers.c b/src/common/timers.c
index 93cde7de5fbd4b..3c806b7f4b422a 100644
--- a/src/common/timers.c
+++ b/src/common/timers.c
@@ -66,6 +66,11 @@ struct timeout_cb {
* above TIMEOUT_MAX can also be super-inefficent. Choosing 5 here sets
* timeout_max to 2^30 ticks, or 29 hours with our value for USEC_PER_TICK */
#define WHEEL_NUM 5
+#if SIZEOF_VOID_P == 4
+/* On 32-bit platforms, we want to override wheel_bit, so that timeout.c will
+ * use 32-bit math. */
+#define WHEEL_BIT 5
+#endif
#include "src/ext/timeouts/timeout.c"
static struct timeouts *global_timeouts = NULL;
```Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24714rename conn->timestamp_lastwritten to conn->timestamp_lastwritable2021-09-16T14:31:18ZRoger Dingledinerename conn->timestamp_lastwritten to conn->timestamp_lastwritable"lastwritten" sure sounds like we actually flushed something or we actually added a new thing to write.
But actually,
```
time_t timestamp_lastwritten; /**< When was the last time libevent said we
* co..."lastwritten" sure sounds like we actually flushed something or we actually added a new thing to write.
But actually,
```
time_t timestamp_lastwritten; /**< When was the last time libevent said we
* could write? */
```
It seems that we changed our definition of this word somewhere along the line, but we left the old word in place. How confusing.
We might want to change lastread to lastreadable too.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24734Remove the return value of fascist_firewall_choose_address_node()2020-06-27T13:54:36ZteorRemove the return value of fascist_firewall_choose_address_node()Let's check for the null address instead.Let's check for the null address instead.Tor: 0.3.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24740Tor launches two requests for authority certificates on first bootstrap2020-06-27T13:54:35ZteorTor launches two requests for authority certificates on first bootstrapWhen tor first bootstraps, it launches two requests for authority certificates:
* one is the hinted request that goes to the directory it downloaded the consensus from (ticket?)
* one is a scheduled request that goes to a random director...When tor first bootstraps, it launches two requests for authority certificates:
* one is the hinted request that goes to the directory it downloaded the consensus from (ticket?)
* one is a scheduled request that goes to a random directory
We should delay the first scheduled request slightly (5s?) to allow the first request to complete.
This might be as easy as changing the first number in the authority certificate schedule from 0 to 5.
I thought we avoided fetching certificates if another fetch was in progress: clearly that doesn't happen, and maybe we don't want it to, because we don't want to wait a whole 10 seconds for it to timeout.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24763Tor make check FAIL: src/test/test (on OSX)2020-06-27T13:54:34ZTracTor make check FAIL: src/test/test (on OSX)I try to make tor from source following this https://trac.torproject.org/projects/tor/wiki/doc/MacBuild#ObtainingaRecentlibevent.
1) reinstall libevent
2) reinstall openssl
3) download tor-0.3.2.8-rc source
4) ./configure --prefix=/us...I try to make tor from source following this https://trac.torproject.org/projects/tor/wiki/doc/MacBuild#ObtainingaRecentlibevent.
1) reinstall libevent
2) reinstall openssl
3) download tor-0.3.2.8-rc source
4) ./configure --prefix=/usr/local/tor --with-openssl-dir=/usr/local/ssl --with-libevent-dir=/usr/local/lib && make
5) make check
After this I get:
```
FAIL: src/test/test
```
Why it could be?
Maybe because hardware acceleration is disabled in openssl configuration? Or it doesn't matter especially for tor?
**Trac**:
**Username**: lL__Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24770Change the circuit build time defaults to reduce network load2020-06-27T13:54:33ZteorChange the circuit build time defaults to reduce network loadUsing `cbttestfreq=600` seems to reduce load, as does `cbtmintimeout=5000`. See legacy/trac#24716 for details.
Let's think about what the defaults should be.Using `cbttestfreq=600` seems to reduce load, as does `cbtmintimeout=5000`. See legacy/trac#24716 for details.
Let's think about what the defaults should be.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24840Hidden service xxx exceeded launch limit with 10 intro points in the last 35 ...2020-06-27T13:54:29ZTracHidden service xxx exceeded launch limit with 10 intro points in the last 35 seconds. Intro circuit launches are limited to 10 per 300 secondsI've checked this ticket: https://trac.torproject.org/projects/tor/ticket/22159
It marked fixed at branch 0.3.1, My tor version is 0.3.2.6-alpha-dev.
It looks like there's still a problem.
This the log:
Jan 09 10:51:21.015 [notice] Tor ...I've checked this ticket: https://trac.torproject.org/projects/tor/ticket/22159
It marked fixed at branch 0.3.1, My tor version is 0.3.2.6-alpha-dev.
It looks like there's still a problem.
This the log:
Jan 09 10:51:21.015 [notice] Tor 0.3.2.6-alpha-dev running on Windows 7 [server] with Libevent 2.1.5-beta, OpenSSL 1.0.1s, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
...
Jan 09 10:51:21.031 [notice] Opening Socks listener on 127.0.0.1:9050
Jan 09 10:51:21.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster.
Jan 09 10:51:22.000 [notice] Bootstrapped 0%: Starting
Jan 09 10:51:24.000 [notice] Starting with guard context "default"
Jan 09 10:51:24.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Jan 09 10:51:28.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Jan 09 10:51:30.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Jan 09 10:51:30.000 [warn] Your Guard radia4 ($xxxxxxxx) is failing an extremely large amount of circuits. This could indicate a route manipulation attack, extreme network overload, or a bug. Success counts are 37/297. Use counts are 76/83. 250 circuits completed, 1 were unusable, 213 collapsed, and 2 timed out. For reference, your timeout cutoff is 60 seconds.
Jan 09 10:51:31.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jan 09 10:51:31.000 [notice] Bootstrapped 100%: Done
Jan 09 10:51:56.000 [warn] Hidden service xxxxxxx exceeded launch limit with 10 intro points in the last 35 seconds. Intro circuit launches are limited to 10 per 300 seconds.
Jan 09 10:51:56.000 [warn] Service configured in "D:\\xxxxx\\Data":
Jan 09 10:51:56.000 [warn] Intro point 0 at [scrubbed]: circuit is open
Jan 09 10:51:56.000 [warn] Intro point 1 at [scrubbed]: circuit is connecting to server
Jan 09 10:51:56.000 [warn] Intro point 2 at [scrubbed]: circuit is connecting to server
I can't run for a long time on the same server?
Thanks
**Trac**:
**Username**: sx5486510Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24854Extract the authority list from config.c2020-07-28T16:25:42ZteorExtract the authority list from config.cThere is a list of default_authorities in src/or/config.c.
We want it in a separate file at src/or/auth_dirs.inc.
This should be implemented like the default_fallbacks array, which includes the fallback list from src/or/fallback_dirs.in...There is a list of default_authorities in src/or/config.c.
We want it in a separate file at src/or/auth_dirs.inc.
This should be implemented like the default_fallbacks array, which includes the fallback list from src/or/fallback_dirs.inc.
We will need to implement two branches for backporting:
* a branch on maint-0.2.9 for 0.2.9 and later. It has IPv6 addresses.
* ~~a branch on maint-0.2.5 for 0.2.5. It has no IPv6 addresses.~~
(Then, after we have moved it into a separate file, we want to automatically generate the file, in a new format. See the rest of the children of legacy/trac#24818.)Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24891build system --disable-unittests has no effect2020-06-27T13:54:26Zstarlightbuild system --disable-unittests has no effectWhile I applaud the explosion of unit test code in recent versions, I do not possess the hardware resources or time for running them and am unlikely to ever do so. To the extent that one would run tests, it's no problem at all to explic...While I applaud the explosion of unit test code in recent versions, I do not possess the hardware resources or time for running them and am unlikely to ever do so. To the extent that one would run tests, it's no problem at all to explicitly build them as needed.
Please cause the --disable-unittests option of `configure` to function as one would expect. Building test code takes a long time and I see no obvious Makefile hack to turn it off.Tor: 0.3.4.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/24910Make rep_hist_note_circuit_handshake_* use channel_is_client()2021-09-16T14:31:19ZteorMake rep_hist_note_circuit_handshake_* use channel_is_client()This is in arma's commit f5ff9f23 in his bug24898-more branch.This is in arma's commit f5ff9f23 in his bug24898-more branch.Tor: 0.3.4.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/24914Maybe make relay_digest_matches() not use tor_malloc()2020-06-27T13:54:24ZDavid Gouletdgoulet@torproject.orgMaybe make relay_digest_matches() not use tor_malloc()The `relay_digest_matches()` is used in `relay_crypt()` and it is called for a huge portion of cells that come through the relay.
Roughly speaking, if a relay is at 10MB/s and with cells of size 514 bytes, we are talking about a bit les...The `relay_digest_matches()` is used in `relay_crypt()` and it is called for a huge portion of cells that come through the relay.
Roughly speaking, if a relay is at 10MB/s and with cells of size 514 bytes, we are talking about a bit less than 20k cells *per* second meaning more than a million `tor_malloc(20)` per minute. This is the place:
```
backup_digest = crypto_digest_dup(digest);
```
I think we should find a way to avoid this especially in the fast path of tor in order to avoid memory fragmentation as much as possible.
We could either use the stack, a static value or `memarea` subsystem.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24977Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, ...2021-09-30T13:50:08ZGeorge KadianakisNon-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))This one is back, since pre-release days of hsv3. Something makes it such that the hsdir index is not well set for some relays.
I got this to happen on my hsv3 service a few weeks ago. I got it a few times on the same second for the sam...This one is back, since pre-release days of hsv3. Something makes it such that the hsdir index is not well set for some relays.
I got this to happen on my hsv3 service a few weeks ago. I got it a few times on the same second for the same node, and then it got fixed... There were no other references to that node (or its fpr) before that.
```
Jan 04 21:30:54.000 [warn] tor_bug_occurred_(): Bug: src/or/hs_common.:1277: node_has_hsdir_index: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN)) failed. (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN)) failed in node_has_hsdir_index at src/or/hs_common.c:1277. Stack trace: (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(log_backtrace+0x42) [0x7f6079a21db2] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(tor_bug_occurred_+0xb7) [0x7f6079a3cc57] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(hs_get_responsible_hsdirs+0x4f9) [0x7f6079a046c9] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(hs_service_run_scheduled_events+0x1a5b) [0x7f6079a11c5b] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(+0x4b9f1) [0x7f60798ed9f1] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(+0x6b4f0) [0x7f607990d4f0] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f6078f253dc] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(do_main_loop+0x244) [0x7f60798f0eb4] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(tor_main+0x1c25) [0x7f60798f46f5] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(main+0x19) [0x7f60798ec629] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f60781182b1] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(_start+0x2a) [0x7f60798ec67a] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [info] hs_get_responsible_hsdirs(): Node $EEC47B34F9403AA7F765D070BB3011E50A373C21~ivanmk2 at 185.22.173.162 was found without hsdir index.
Jan 04 21:30:55.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
```Tor: 0.3.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/24989Count hsdir requests against maxcircuitspending2020-06-27T13:54:20ZMike PerryCount hsdir requests against maxcircuitspendingIn legacy/trac#13837, we split off hsdir purposes from general. In the process, it means that we stopped counting hsdir circuits towards the global pending rate limit in count_pending_general_client_circuits(). That function was already ...In legacy/trac#13837, we split off hsdir purposes from general. In the process, it means that we stopped counting hsdir circuits towards the global pending rate limit in count_pending_general_client_circuits(). That function was already trying to avoid counting hs circuits, but since nothing else globally limits the number of pending hs circuits, we probably should keep rate limiting hsdirs there, too.Tor: 0.3.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25024Add optional spell check to makefile to check for typos in tor source code.2020-06-27T13:54:19ZTracAdd optional spell check to makefile to check for typos in tor source code.We should add a spell check to tor makefile somewhat like [https://github.com/client9/misspell] This ticket is an extension to legacy/trac#23650 [https://trac.torproject.org/projects/tor/ticket/23650]
**Trac**:
**Username**: fristonioWe should add a spell check to tor makefile somewhat like [https://github.com/client9/misspell] This ticket is an extension to legacy/trac#23650 [https://trac.torproject.org/projects/tor/ticket/23650]
**Trac**:
**Username**: fristonioTor: 0.3.4.x-finalAlison MacrinaAlison Macrinahttps://gitlab.torproject.org/tpo/core/tor/-/issues/25081use get_uptime() consistently2020-06-27T13:54:16ZRoger Dingledineuse get_uptime() consistentlyWe have this nice function get_uptime() that shields the global variable `stats_n_seconds_working` from the rest of the Tor files.
But then we undermine that by saying
```
extern long stats_n_seconds_working;
```
in main.h and we just s...We have this nice function get_uptime() that shields the global variable `stats_n_seconds_working` from the rest of the Tor files.
But then we undermine that by saying
```
extern long stats_n_seconds_working;
```
in main.h and we just start using that variable directly all over.
There are a few lonely users of get_uptime().
We should move everybody over to using get_uptime, and get rid of the scary extern.
(Also check out how we're *writing* to the extern variable, in hibernate.c. There's no way that could confuse anybody down the road!)Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25150Avoid malloc/free on each server-side ntor handshake2020-06-27T13:54:13ZNick MathewsonAvoid malloc/free on each server-side ntor handshakeNow that we require c99, we can use variable-length array here instead of a malloc/free pair.Now that we require c99, we can use variable-length array here instead of a malloc/free pair.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25162Perhaps, use zstd's "static-only" functions2020-06-27T13:54:13ZNick MathewsonPerhaps, use zstd's "static-only" functionsI think maybe we can make this safe if we explicitly check that the compile version matches the runtime version. (Thanks to Hello71 for the tip)I think maybe we can make this safe if we explicitly check that the compile version matches the runtime version. (Thanks to Hello71 for the tip)Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25182systemd unit file starts Tor before IPv6 address is available2020-06-27T13:54:12ZSteven Murdochsystemd unit file starts Tor before IPv6 address is availableOn Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address a...On Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address assigned and hence Tor fails to start.
As a work-around I copied `/lib/systemd/system/tor*` to `/etc/systemd/system/` and added `RestartSec=10` to the `[Service]` section of `tor@default.service` and `tor@.service`. This slows down the restart such that by the second time tor starts, there is an IPv6 address available.
See log file below.
```
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.587 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.591 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1313]: Configuration was valid
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Scheduler type KIST has been enabled.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on [2001:630:212:2a8:a6bf:1ff:fe25:b961]:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Could not bind to 2001:630:212:2a8:a6bf:1ff:fe25:b961:9001: Cannot assign requested address
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [err] Reading config failed--see warnings above.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit tor@default.service has failed
-- Unit tor@default.service has failed.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Unit entered failed state.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Failed with result 'exit-code'.
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25185Create utilities for using Rust static strings in C2020-06-27T13:54:11ZIsis LovecruftCreate utilities for using Rust static strings in CThis is a continuation of legacy/trac#25127, to provide some utilities for working with static strings across the FFI boundary without accidentally introducing leaks.This is a continuation of legacy/trac#25127, to provide some utilities for working with static strings across the FFI boundary without accidentally introducing leaks.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/25188Spec bug in formal definition of Document in dir-spec.txt2020-06-27T13:54:11ZTracSpec bug in formal definition of Document in dir-spec.txtI was attempting to write a parser that reads vote/consensus documents using the the formal definition [here](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n210). However, I noticed an ambiguity.
Using only the formal defi...I was attempting to write a parser that reads vote/consensus documents using the the formal definition [here](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n210). However, I noticed an ambiguity.
Using only the formal definition, the following:
```
directory-signature 13241234321 12343234
-----BEGIN SIGNATURE-----
00thisisvalidbase64data12345
-----END SIGNATURE-----
```
Could be potentially parsed as
```
Document(
Item(
KeywordLine(
Keyword(KeywordChar+("directory-signature")),
WS,
ArgumentChar+("13241234321 12343234"),
NL
)
),
Item(
KeywordLine(
Keyword(KeywordChar+("-----BEGIN")),
WS,
ArgumentChar+("SIGNATURE-----"),
NL
)
),
Item(
KeywordLine(
Keyword(KeywordChar+("00thisisvalidbase64data12345"))
WS,
ArgumentChar+("SIGNATURE-----"),
NL
)
),
Item(
KeywordLine(
Keyword(KeywordChar+("-----END")),
WS,
ArgumentChar+("SIGNATURE-----"),
NL
)
),
)
```
When the correct parsing would be
```
Document(
Item(
KeywordLine(
Keyword(KeywordChar+("directory-signature")),
WS,
ArgumentChar+("13241234321 12343234"),
NL
),
Object(
BeginLine(
"-----BEGIN ",
Keyword(KeywordChar+("SIGNATURE")),
"-----",
NL
),
Base64-encoded-data("00thisisvalidbase64data12345"),
EndLine(
"-----END ",
Keyword(KeywordChar+("SIGNATURE")),
"-----",
NL
),
),
),
)
```
A potential change to the spec (assuming that keywords will never start with "-") that would prevent would be to replace
```
Keyword = KeywordChar+
KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
```
with
```
Keyword = KeywordStartChar KeywordChar*
KeywordStartChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9'
KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
```
**Trac**:
**Username**: witchof0x20Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25237spec: Document our circuit close reasons2020-06-27T13:54:09ZDavid Gouletdgoulet@torproject.orgspec: Document our circuit close reasonsIn `or.h`, we define the reason to close a circuit:
```
/* Reasons why we (or a remote OR) might close a circuit. See tor-spec.txt for
* documentation of these. */
#define END_CIRC_REASON_MIN_ 0
#define END_CIRC_REASON_NONE ...In `or.h`, we define the reason to close a circuit:
```
/* Reasons why we (or a remote OR) might close a circuit. See tor-spec.txt for
* documentation of these. */
#define END_CIRC_REASON_MIN_ 0
#define END_CIRC_REASON_NONE 0
#define END_CIRC_REASON_TORPROTOCOL 1
#define END_CIRC_REASON_INTERNAL 2
#define END_CIRC_REASON_REQUESTED 3
...
```
Even though it says "See tor-spec.txt", those values aren't defined at all in tor-spec.txt, only the stream reasons are.
This is a bit annoying because these values don't have any documentation on why and when they should be used.Tor: 0.3.4.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/25261Tor connection.c file have multiple transports.h includes.2020-06-27T13:54:08ZTracTor connection.c file have multiple transports.h includes.There are two imports to transports.h in connection.c
https://gitweb.torproject.org/tor.git/tree/src/or/connection.c#n101
https://gitweb.torproject.org/tor.git/tree/src/or/connection.c#n104
**Trac**:
**Username**: fristonioThere are two imports to transports.h in connection.c
https://gitweb.torproject.org/tor.git/tree/src/or/connection.c#n101
https://gitweb.torproject.org/tor.git/tree/src/or/connection.c#n104
**Trac**:
**Username**: fristonioTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25268cmux: Remove round robin code and make EWMA mandatory2020-06-27T13:54:08ZDavid Gouletdgoulet@torproject.orgcmux: Remove round robin code and make EWMA mandatorySince 0.2.4.x stable, Tor has been using EWMA circuit policy which is enabled by the consensus param: `CircuitPriorityHalflifeMsec=30000`
The `circuitmux.c` code still does quite a bit to maintain the round robin circuit policy that was...Since 0.2.4.x stable, Tor has been using EWMA circuit policy which is enabled by the consensus param: `CircuitPriorityHalflifeMsec=30000`
The `circuitmux.c` code still does quite a bit to maintain the round robin circuit policy that was used prior to EWMA. It hasn't been used since 024 (except in Chutney, see legacy/trac#25265).
A lot of that code is called for every cell tor receives so it is part of our fast path. Removing this round robin code would help in performance and remove complexity from the code.
However, that round robin functionality is used as a fallback if the EWMA policy was either not set or couldn't pick an active circuit (I'm not sure that is possible if we have active circuits).
Thus, the side effect of removing this code is that we'll now enforce a cmux to have a policy set and make the `pick_active_circuit()` callback mandatory. That is OK because we've been enforcing that since 024.
It would also probably mean that we need to put in a default value in tor code for `CircuitPriorityHalflifeMsec` so that if the consensus doesn't specify it, we fallback to a usable value instead of being able to disable EWMA.
This piece of work will help out with improving performance of the cmux subsystem with legacy/trac#25152 and make sure we stick to only the required code for this fast pathTor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25271Remove duplicate #include onion_ntor.h from src/test//test.c2020-06-27T13:54:08ZIsis LovecruftRemove duplicate #include onion_ntor.h from src/test//test.cThere's two of them. It set off an immediate gut reaction to Ctrl-K the line.There's two of them. It set off an immediate gut reaction to Ctrl-K the line.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25276Compilation fails: ‘tor_zstd_format_version’ [-Werror=unused-function]2020-06-27T13:54:08ZffmanceraCompilation fails: ‘tor_zstd_format_version’ [-Werror=unused-function]I am getting this error when compiling a clear version of master branch.
```
CC src/common/src_common_libor_crypto_testing_a-crypto.o
src/common/compress_zstd.c:63:1: error: ‘tor_zstd_format_version’ defined but not used [-Werro...I am getting this error when compiling a clear version of master branch.
```
CC src/common/src_common_libor_crypto_testing_a-crypto.o
src/common/compress_zstd.c:63:1: error: ‘tor_zstd_format_version’ defined but not used [-Werror=unused-function]
tor_zstd_format_version(char *buf, size_t buflen, unsigned version_number)
^~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[1]: *** [Makefile:5893: src/common/src_common_libor_crypto_testing_a-compress_zstd.o] Error 1
```
The error seems to come from commit [b56fd17d0003b0b66570a7d99aadbe901144f75d](https://gitweb.torproject.org/tor.git/commit/?id=b56fd17d0003b0b66570a7d99aadbe901144f75d). Travis CI report [here](https://travis-ci.org/torproject/tor/builds/342171373?utm_source=github_status&utm_medium=notification).Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25279Stem test-full fails on master branch2020-06-27T13:54:07ZffmanceraStem test-full fails on master branchI am getting some errors when executing "make test-full" on a clear version of master branch.
```
test_parsing_with_example [FAILURE]
test_parsing_with_unknown_options [FAILU...I am getting some errors when executing "make test-full" on a clear version of master branch.
```
test_parsing_with_example [FAILURE]
test_parsing_with_unknown_options [FAILURE]
test_query 1 ms [SUCCESS]
test_query_on_failure 0 ms [SUCCESS]
test_saving_manual_as_config [FAILURE]
test_saving_manual_as_sqlite [FAILURE]
.
.
.
test_connections_by_ss [FAILURE]
.
.
.
[UNIT TEST] test_saving_manual_as_config (test.unit.manual.TestManual) ... ERROR
[UNIT TEST] test_saving_manual_as_sqlite (test.unit.manual.TestManual) ... ERROR
[RUN_PTRACE] test_connections_by_ss (test.integ.util.connection.TestConnection) ... ERROR
```
I think it is not a regression since maint-0.3.3 because it is failing on one of my bug branch (before release maint-0.3.3).
Nick suggested it could be a sandbox/libc problem.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25284hidden-service-dir description in dir-spec should reference HSDir protovers2021-09-30T13:50:08Zteorhidden-service-dir description in dir-spec should reference HSDir protoversSince 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified...Since 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified, it defaults to version 2 descriptors"Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25290refactor to use should_record_bridge_info() more2021-09-16T14:31:19ZRoger Dingledinerefactor to use should_record_bridge_info() moreWe have this function
`should_record_bridge_info`
which simply checks
`options->BridgeRelay && options->BridgeRecordUsageByCountry`.
But in geoip_note_client_seen(), where we just added the DoS mitigation stuff, we don't use the functio...We have this function
`should_record_bridge_info`
which simply checks
`options->BridgeRelay && options->BridgeRecordUsageByCountry`.
But in geoip_note_client_seen(), where we just added the DoS mitigation stuff, we don't use the function, instead choosing to check the variables directly. We make the same choice in the options_need_geoip_info() function.
We should refactor things so we use the function in all cases.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25291get rid of redundant should_record_bridge_info() call in options_act()2020-06-27T13:54:07ZRoger Dingledineget rid of redundant should_record_bridge_info() call in options_act()In options_act() we have
```
if ((!old_options || !old_options->EntryStatistics) &&
options->EntryStatistics && !should_record_bridge_info(options)) {
```
But right above that we have
```
/* Only collect other relay-only...In options_act() we have
```
if ((!old_options || !old_options->EntryStatistics) &&
options->EntryStatistics && !should_record_bridge_info(options)) {
```
But right above that we have
```
/* Only collect other relay-only statistics on relays. */
if (!public_server_mode(options)) {
options->CellStatistics = 0;
options->EntryStatistics = 0;
```
So the only way EntryStatistics could be non-zero at that lower point is if public_server_mode() is true.
So the check to !should_record_bridge_info() will always be true, and is redundant to check.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25295Torsocks only accepts IPv4 replies but Tor prefers IPv6Automap by default2021-07-05T17:47:56ZTracTorsocks only accepts IPv4 replies but Tor prefers IPv6Automap by defaultAt the moment, MapAddress .exit entries won't resolve through torsocks for me, because tor gives an IPv6 reply, and torsocks is only designed for IPv4 replies.
Torsocks gives the characteristic error `[socks5] Resolve destination buffer...At the moment, MapAddress .exit entries won't resolve through torsocks for me, because tor gives an IPv6 reply, and torsocks is only designed for IPv4 replies.
Torsocks gives the characteristic error `[socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:681)` when tor replies with an IPv6 address, which it does every single time for mapaddress .exit entries for me.
**Trac**:
**Username**: fuzzyTewTor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25296update PerConnBWRate/Burst manpage entries to not mention consensus2021-07-22T16:21:38Zcypherpunksupdate PerConnBWRate/Burst manpage entries to not mention consensuscontext:
https://lists.torproject.org/pipermail/tor-relays/2018-February/014585.html
The manpage says that relays will use the value in consensus but the consensus does not longer include these values.
This patch removes "You should ne...context:
https://lists.torproject.org/pipermail/tor-relays/2018-February/014585.html
The manpage says that relays will use the value in consensus but the consensus does not longer include these values.
This patch removes "You should never need to change this value, since a network-wide value is published in the consensus and your relay will use that value."
and is the minimal change, but it would be better to add more information that says if tor has some built-in mechanism to avoid that a single client uses all bw.
Also: How does tor tell non-relays from relays apart?
```
@@ -243,13 +243,11 @@
[[PerConnBWRate]] **PerConnBWRate** __N__ **bytes**|**KBytes**|**MBytes**|**GBytes**|**TBytes**|**KBits**|**MBits**|**GBits**|**TBits**::
If set, do separate rate limiting for each connection from a non-relay.
- You should never need to change this value, since a network-wide value is
- published in the consensus and your relay will use that value. (Default: 0)
+ (Default: 0)
[[PerConnBWBurst]] **PerConnBWBurst** __N__ **bytes**|**KBytes**|**MBytes**|**GBytes**|**TBytes**|**KBits**|**MBits**|**GBits**|**TBits**::
If set, do separate rate limiting for each connection from a non-relay.
- You should never need to change this value, since a network-wide value is
- published in the consensus and your relay will use that value. (Default: 0)
+ (Default: 0)
[[ClientTransportPlugin]] **ClientTransportPlugin** __transport__ socks4|socks5 __IP__:__PORT__::
**ClientTransportPlugin** __transport__ exec __path-to-binary__ [options]::
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25310Document our policy for Rust dependencies2021-07-22T16:21:38ZIsis LovecruftDocument our policy for Rust dependenciesWe should document what our (experimental, subject to change) policies are w.r.t. new Rust dependencies in tor, somewhere in the `doc/HACKING/` directory.We should document what our (experimental, subject to change) policies are w.r.t. new Rust dependencies in tor, somewhere in the `doc/HACKING/` directory.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25319commit 4438ef32 breaks tor macOS cross builds2020-06-27T13:54:05ZGeorg Koppencommit 4438ef32 breaks tor macOS cross buildsThe macOS cross build we do for Tor Browser is broken after removing a bunch of redundant #includes (i.e. 4438ef3288256e1f1ba706c157206a2ac190781d):
```
CC src/test/src_test_test-test_address_set.o
In file included from src/test/...The macOS cross build we do for Tor Browser is broken after removing a bunch of redundant #includes (i.e. 4438ef3288256e1f1ba706c157206a2ac190781d):
```
CC src/test/src_test_test-test_address_set.o
In file included from src/test/test_address.c:15:
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:300:19: error: field has incomplete type 'struct sockaddr'
struct sockaddr ifru_addr;
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:300:10: note: forward declaration of 'struct sockaddr'
struct sockaddr ifru_addr;
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:301:19: error: field has incomplete type 'struct sockaddr'
struct sockaddr ifru_dstaddr;
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:300:10: note: forward declaration of 'struct sockaddr'
struct sockaddr ifru_addr;
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:302:19: error: field has incomplete type 'struct sockaddr'
struct sockaddr ifru_broadaddr;
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:300:10: note: forward declaration of 'struct sockaddr'
struct sockaddr ifru_addr;
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:346:18: error: field has incomplete type 'struct sockaddr'
struct sockaddr ifra_addr;
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:300:10: note: forward declaration of 'struct sockaddr'
struct sockaddr ifru_addr;
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:347:18: error: field has incomplete type 'struct sockaddr'
struct sockaddr ifra_broadaddr;
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:300:10: note: forward declaration of 'struct sockaddr'
struct sockaddr ifru_addr;
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:348:18: error: field has incomplete type 'struct sockaddr'
struct sockaddr ifra_mask;
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:300:10: note: forward declaration of 'struct sockaddr'
struct sockaddr ifru_addr;
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:431:26: error: field has incomplete type 'struct sockaddr_storage'
struct sockaddr_storage addr; /* in/out */
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:431:9: note: forward declaration of 'struct sockaddr_storage'
struct sockaddr_storage addr; /* in/out */
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:432:26: error: field has incomplete type 'struct sockaddr_storage'
struct sockaddr_storage dstaddr; /* out */
^
/var/tmp/dist/macosx-toolchain/SDK//usr/include/net/if.h:431:9: note: forward declaration of 'struct sockaddr_storage'
struct sockaddr_storage addr; /* in/out */
^
8 errors generated.
Makefile:9761: recipe for target 'src/test/src_test_test-test_address.o' failed
make[1]: *** [src/test/src_test_test-test_address.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/var/tmp/build/tor-master'
make: *** [all] Error 2
Makefile:3394: recipe for target 'all' failed
```Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25353Configure fails with some OpenSSL 1.1.0 built with no-deprecated.2020-06-27T13:54:03ZTracConfigure fails with some OpenSSL 1.1.0 built with no-deprecated.On my machine with OpenSSL 1.1.0, Tor's `configure` script fails to detect OpenSSL and gives me the following error:
```
configure: Now, we'll look for OpenSSL >= 1.0.1
checking for openssl directory... configure: WARNING: Could not fin...On my machine with OpenSSL 1.1.0, Tor's `configure` script fails to detect OpenSSL and gives me the following error:
```
configure: Now, we'll look for OpenSSL >= 1.0.1
checking for openssl directory... configure: WARNING: Could not find a linkable openssl. If you have it installed somewhere unusual, you can specify an explicit path using --with-openssl-dir
configure: error: Missing libraries; unable to proceed.
```
This seems to be due to the fact that `configure` checks for OpenSSL >= 1.0.1 with `TLSv1_1_method()`, which is deprecated in favor of `TLS_method()` in OpenSSL 1.1.0.
On my configuration of OpenSSL 1.1.0, deprecated functions are not available by default (not without first enabling the `OPENSSL_API_COMPAT` compatibility #define), hence the failure.
I'd gladly provide a patch, but I'm not sure how this would best be fixed: explicitly check for `TLS_method()` in case the check for `TLSv1_1_method()` fails? Replace this test with a test on `OPENSSL_VERSION_NUMBER`? Find some other function introduced in 1.0.1 and neither removed nor deprecated in 1.1.0?
**Trac**:
**Username**: laomaiwengTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25365Use uint64_t for Tor's hash tables, even if int is 32 bits2020-06-27T13:54:02ZteorUse uint64_t for Tor's hash tables, even if int is 32 bits64-bit macOS and BSD are LP64, which means that their ints are 32 bits. This makes Tor's hash tables 32 bits, reducing their security.
This issue also occurs on 32-bit systems, where using uint64_t might be slower. I don't know if speed...64-bit macOS and BSD are LP64, which means that their ints are 32 bits. This makes Tor's hash tables 32 bits, reducing their security.
This issue also occurs on 32-bit systems, where using uint64_t might be slower. I don't know if speed matters, as siphash is 64 bit anyway.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25368Update the Tor Rust coding standards for new types2021-07-22T16:20:50ZteorUpdate the Tor Rust coding standards for new typesI added some new types to the rust coding standards.
But I think I will need isis' help to explain Stringlist.I added some new types to the rust coding standards.
But I think I will need isis' help to explain Stringlist.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25373Avoid needless wakeups for token bucket refills.2020-06-27T13:54:02ZNick MathewsonAvoid needless wakeups for token bucket refills.In 0.2.3.5-alpha, we increased our default token bucket refill interval from 1 time per second to 10 times per second. (See legacy/trac#3630 and proposal 183.)
AFAICT, this is now the most frequently running timer causing wakeups on an...In 0.2.3.5-alpha, we increased our default token bucket refill interval from 1 time per second to 10 times per second. (See legacy/trac#3630 and proposal 183.)
AFAICT, this is now the most frequently running timer causing wakeups on an idle Tor instance. It even causes wakeups on Tor instances when DisableNetwork is set. We can do better!
Two key insights:
* First, it is not necessary to actually refill these buckets periodically. Instead, we can store the last time at which we refilled each one, and calculate its current size at immediately before we read or write. The only thing we'll need to use a timer for is to wake up connections on which we've stopped reading or writing.
* Second, we only need to have this timer active when at least one connection is blocked on bandwidth.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25374Create a better-designed system for handling computation outside the event loop2020-06-27T13:54:02ZNick MathewsonCreate a better-designed system for handling computation outside the event loopRight now, we do a couple of things in `run_main_loop_once` that happen outside the event loop (because we want to re-scan for events event loop before they happen):
* Making events on active_linked_connection_lst active.
* Running c...Right now, we do a couple of things in `run_main_loop_once` that happen outside the event loop (because we want to re-scan for events event loop before they happen):
* Making events on active_linked_connection_lst active.
* Running connection_ap_attach_pending.
But we can do this much better. With Libevent 2.1, instead of making the loop exit for this, we can should do all of these things in a separate event callback, and call `event_base_loopcontinue()` at the end of that event's callback so that the event_base will get rescanned before we return. With earlier versions of Libevent, we can do something similar with event_base_loopbreak().
Doing this won't lower the number of wakeups we do, but it should simplify our overall event loop logic, and make other event loop simplifications easier.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25375Remove as many items as possible from second_elapsed_callback() and run_sched...2020-06-27T13:54:02ZNick MathewsonRemove as many items as possible from second_elapsed_callback() and run_scheduled_events()We have a real system for periodic events and deferred events and so on -- several of them, in fact. We shouldn't be using second_elapsed_callback() and run_scheduled_events() to do things any more:
* Some things should be done as soo...We have a real system for periodic events and deferred events and so on -- several of them, in fact. We shouldn't be using second_elapsed_callback() and run_scheduled_events() to do things any more:
* Some things should be done as soon as possible, on demand (see legacy/trac#25374).
* Some things should be done on the timers from periodic.c.
* Some things should be done with one-off timers schedueld "for later".
And some things might still need to be done once a second -- but they should be things that only need to happen when Tor is running. When Tor is idle or hibernating, or when DisableNetwork is set, we should be able to disable those once-per-second events so that we don't use so much CPU.
**Please make subtickets for removing things from these functions.**Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25376Disable as many timers as possible when DisableNetwork or when idle/hibernating2022-05-07T06:47:11ZNick MathewsonDisable as many timers as possible when DisableNetwork or when idle/hibernatingWith legacy/trac#25373 and legacy/trac#25375, we should be using first-class timer objects for more and more of our timed events. We should have a way to mark timers that should be disabled when Tor is idle, or when DisableNetwork has ...With legacy/trac#25373 and legacy/trac#25375, we should be using first-class timer objects for more and more of our timed events. We should have a way to mark timers that should be disabled when Tor is idle, or when DisableNetwork has been set. Then we should actually disable them, to lower the amount of wakeups that Tor performs under those circumstances.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25377Provide a control-port mechanisms to manage idle mode better.2020-06-27T13:54:01ZNick MathewsonProvide a control-port mechanisms to manage idle mode better.When Tor is idle, we should fetch directory information less aggressively, not build predictive or probe circuits, and so on. We should provide a way for controllers to manage idle mode: to tell Tor to enter it early, and to leave it in...When Tor is idle, we should fetch directory information less aggressively, not build predictive or probe circuits, and so on. We should provide a way for controllers to manage idle mode: to tell Tor to enter it early, and to leave it in part of in full.
This is related to proposal 286.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25398tests fail if COMPAT_HAS_MMAN_AND_PAGESIZE is not set2020-06-27T13:54:00ZAlex Xutests fail if COMPAT_HAS_MMAN_AND_PAGESIZE is not set`tor_mmap_file` doesn't check for empty files if `COMPAT_HAS_MMAN_AND_PAGESIZE` is not set, causes `test_util_mmap` to fail`tor_mmap_file` doesn't check for empty files if `COMPAT_HAS_MMAN_AND_PAGESIZE` is not set, causes `test_util_mmap` to failTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25399mmap length doesn't need to be page-aligned2020-06-27T13:54:00ZAlex Xummap length doesn't need to be page-alignedPOSIX says that mmap length doesn't need to be page-aligned. addr and off may have page alignment requirements, but length must be handled automatically. getpagesize is deprecated too.POSIX says that mmap length doesn't need to be page-aligned. addr and off may have page alignment requirements, but length must be handled automatically. getpagesize is deprecated too.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25400CIRC_BW event miscounts, should count all circ data2020-06-27T13:54:00ZMike PerryCIRC_BW event miscounts, should count all circ dataThe CIRC_BW event as implemented seems to be totaling only explicit application data on the circuit. To have an accurate representation of circuit usage, it should total all bytes sent on the circuit, including padding, dropped cells, an...The CIRC_BW event as implemented seems to be totaling only explicit application data on the circuit. To have an accurate representation of circuit usage, it should total all bytes sent on the circuit, including padding, dropped cells, and partially full cells.
Furthermore, it currently counts bytes differently depending on if you have the STREAM event enabled (see control_event_stream_bandwidth()). This is definitely a bug.Tor: 0.3.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25409rip out PortForwarding options2022-03-08T17:52:12ZRoger Dingledinerip out PortForwarding optionsA relay operator on tor-relays@ just got snookered into setting PortForwarding to 1, probably because he thought it would help him get port forwarding working on his relay.
I think the reality is that almost nobody uses this option, and...A relay operator on tor-relays@ just got snookered into setting PortForwarding to 1, probably because he thought it would help him get port forwarding working on his relay.
I think the reality is that almost nobody uses this option, and also we don't recommend it.
Yawning rewrote the crappy dangerous C upnp apps in go:
https://gitweb.torproject.org/tor.git/tree/src/tools/tor-fw-helper/README
https://gitweb.torproject.org/tor-fw-helper.git/tree/README.md
But I don't think we've taken any steps to get that go version into any user's hands.
Also, our past use case, where Vidalia would launch Tor and want to let ordinary users turn themselves into relays or bridges, is long deprecated.
Alternatives to "rip it out" would be "get yawning's go stuff packaged properly in Debian", or "add yawning's go stuff to the tor tarball and build it and ship it too".
See also legacy/trac#21765 and its great phrase "I wonder how long this has been broken for".Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25425Add unittests for bridges.c module2020-06-27T13:53:59ZIsis LovecruftAdd unittests for bridges.c moduleIt didn't have any tests explicitly for it, and it currently has:
| make directive | line coverage | function coverage |
|----------------|---------------|-------------------|
| coverage-html | 19.9% | 34.4% |
| coverage-html-full | 58....It didn't have any tests explicitly for it, and it currently has:
| make directive | line coverage | function coverage |
|----------------|---------------|-------------------|
| coverage-html | 19.9% | 34.4% |
| coverage-html-full | 58.1% | 78.1 % |Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/25432remove router.c internal functions from router.h2021-09-16T14:31:19ZTracremove router.c internal functions from router.hThese functions (group A):
```
A
const char *router_get_description(char *buf, const routerinfo_t *ri);
const char *node_get_description(char *buf, const node_t *node);
const char *routerstatus_get_description(char *buf, const routerstat...These functions (group A):
```
A
const char *router_get_description(char *buf, const routerinfo_t *ri);
const char *node_get_description(char *buf, const node_t *node);
const char *routerstatus_get_description(char *buf, const routerstatus_t *rs);
const char *extend_info_get_description(char *buf, const extend_info_t *ei);
```
Do the same as these (group B):
```
B
const char *router_describe(const routerinfo_t *ri);
const char *node_describe(const node_t *node);
const char *routerstatus_describe(const routerstatus_t *ri);
const char *extend_info_describe(const extend_info_t *ei);
```
With the difference that those last allocate a buffer, instead of forcing the caller to create and pass the buffer as a parameter.
The functions from group B are an abstraction to the ones from group A: they are better because they always generate buffers of enough size (the size is NODE_DESC_BUF_LEN). So, we should avoid using group A.
By now, both groups are declared in the header, and there is only one use of a function of group A (router_get_description is used on dirserv.c).
Also, all those functions are abstractions to format_node_description, that should also not be used externally, so we could also remove this one from the header.
The constant NODE_DESC_BUF_LEN is not necessary externally either.
**Trac**:
**Username**: valentecaioTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25494Initial work on making modules conditionally compiled2021-09-16T14:31:19ZDavid Gouletdgoulet@torproject.orgInitial work on making modules conditionally compiledThis is a roadmap master ticket. The idea is to try to extract modules out of Tor into compile time options in order to help the modularization effort and shrinking the binary size down for mobile.
See child tickets for more specific ta...This is a roadmap master ticket. The idea is to try to extract modules out of Tor into compile time options in order to help the modularization effort and shrinking the binary size down for mobile.
See child tickets for more specific tasks.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25495module: Identify a list of tor module2021-09-16T14:30:52ZDavid Gouletdgoulet@torproject.orgmodule: Identify a list of tor moduleWrite a list of all possible module of tor.
Then we should use that list to start extracting module into compile time options so we can end up with a minimal mobile client binary.Write a list of all possible module of tor.
Then we should use that list to start extracting module into compile time options so we can end up with a minimal mobile client binary.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25498module: Basic modularization preparation2021-09-16T14:30:52ZDavid Gouletdgoulet@torproject.orgmodule: Basic modularization preparationTicket legacy/trac#25494 was created to do some initial work in modularization in tor that is the code part. Then legacy/trac#25495 is about identifying the list of modules in a structured list which from there we'll open tickets to do t...Ticket legacy/trac#25494 was created to do some initial work in modularization in tor that is the code part. Then legacy/trac#25495 is about identifying the list of modules in a structured list which from there we'll open tickets to do the work to extract different modules.
This ticket is a sponsor task and should be about what else we need then the list of modules before we start extracting modules.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25508Expose Tor's RNG to Rust2020-06-27T13:53:56ZNick MathewsonExpose Tor's RNG to RustTo get privcount working happily in Tor, we need a CSPRNG. For consistency across languages, we should expose Tor's crypto_rand() as a Rust rand::Rng.To get privcount working happily in Tor, we need a CSPRNG. For consistency across languages, we should expose Tor's crypto_rand() as a Rust rand::Rng.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25511Expose TZ info on control port for better debugging of time errors2020-06-27T13:53:55ZNick MathewsonExpose TZ info on control port for better debugging of time errorsWhen we tell people that their clocks are wrong, it's frequently because they've set up their systems with the wrong time zone. It would be helpful to tell torbrowser (or some other controller) about this information, so that it can giv...When we tell people that their clocks are wrong, it's frequently because they've set up their systems with the wrong time zone. It would be helpful to tell torbrowser (or some other controller) about this information, so that it can give more useful error messages on time-related bootstrapping failures.
~~One complication here is (IIUC) TB runs, and runs tor, with its TZ set to UTC.~~
Further investigation suggests that TB might not set `TZ` for the first time it starts tor. Opened legacy/trac#25823 for the Tor Launcher behavior inconsistency.Tor: 0.3.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25515Add a unit test for geoip_load_file()2020-06-27T13:53:55ZNick MathewsonAdd a unit test for geoip_load_file()The geoip_load_file() function has no test coverage. As a demo at the hackfest, I worked with Juga to fix that situation. Please review branch `geoip_testing` in my public repository.The geoip_load_file() function has no test coverage. As a demo at the hackfest, I worked with Juga to fix that situation. Please review branch `geoip_testing` in my public repository.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25516Refactor relay cell crypto into a new relaycrypt.c2021-09-16T14:30:52ZNick MathewsonRefactor relay cell crypto into a new relaycrypt.cThe functions `relay_crypt`, `relay_crypt_one_payload`, and `relay_init_cpath_crypto`, as well as extractable parts of `onionskin_answer` and `circuit_free_cpath_node` -- belong in their own conceptual module. Considered as such, they b...The functions `relay_crypt`, `relay_crypt_one_payload`, and `relay_init_cpath_crypto`, as well as extractable parts of `onionskin_answer` and `circuit_free_cpath_node` -- belong in their own conceptual module. Considered as such, they become fairly easy to test.
We have identified this work as valuable for modularization, for testing, and potentially valuable for testing future relay crypto designs.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25544Complete vanguard specification2020-06-27T13:53:54ZGeorge KadianakisComplete vanguard specificationWe should revise the vanguard proposal (prop247) to be less ambitious and more down-to-earth and closer to what mike's vanguard script is going to be doing.We should revise the vanguard proposal (prop247) to be less ambitious and more down-to-earth and closer to what mike's vanguard script is going to be doing.Tor: 0.3.4.x-final