Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:39:12Zhttps://gitlab.torproject.org/legacy/trac/-/issues/29732Add full-fledged deterministic PRNG support for testing.2020-06-13T15:39:12ZNick MathewsonAdd full-fledged deterministic PRNG support for testing.In several places, the tests override crypto_rand() or crypto_fast_prng() for one reason or another. We should provide a standard way for the tests to do this.In several places, the tests override crypto_rand() or crypto_fast_prng() for one reason or another. We should provide a standard way for the tests to do this.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/27244Use mmap to hold our cached consensus, when we even need it stored in RAM at ...2020-06-13T15:29:52ZNick MathewsonUse mmap to hold our cached consensus, when we even need it stored in RAM at all.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27139macOS i386 fails time unit tests2020-06-13T15:29:21ZteormacOS i386 fails time unit tests```
circuitmux/compute_ticks: [forking]
FAIL src/test/test_circuitmux.c:109: assert(rem OP_LT .150000001): 0.1505 vs 0.15
[compute_ticks FAILED]
```
```
mainloop/update_time_jumps: [forking]
FAIL src/test/test_mainloop.c:115: ex...```
circuitmux/compute_ticks: [forking]
FAIL src/test/test_circuitmux.c:109: assert(rem OP_LT .150000001): 0.1505 vs 0.15
[compute_ticks FAILED]
```
```
mainloop/update_time_jumps: [forking]
FAIL src/test/test_mainloop.c:115: expected log to not contain entries Captured logs:
1. notice: "Your system clock just jumped 1800 seconds forward; assuming established circuits no longer work.\n"
[update_time_jumps FAILED]
```
Should we set up macOS i386 CI to detect issues like this?
Or should we remove macOS i386 from our supported platforms?
(Apple won't support i386 in the next macOS, so in ~3 years time, we won't need to support it.)Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/26744Split common/client/cache/authority parts of directory.c and dirserv.c2020-06-13T15:27:50ZNick MathewsonSplit common/client/cache/authority parts of directory.c and dirserv.cTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/26446Split out the easier libraries from lib/common2020-06-13T15:26:56ZNick MathewsonSplit out the easier libraries from lib/commonNow that I've made a start (see #26442) it's time to split the rest of the common directory.
Some of the splitting will require disentangling individual files, but some is fairly easy. I'll do the easy part first.Now that I've made a start (see #26442) it's time to split the rest of the common directory.
Some of the splitting will require disentangling individual files, but some is fairly easy. I'll do the easy part first.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/24546Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addresses2020-06-13T15:26:54ZteorUse tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addressesIn Tor, we try to support v6-mapped IPv4 addresses.
We should either:
* reject them unconditionally, or
* audit all uses of tor_addr_t.family to see if we should be calling tor_addr_is_v4() instead, and add a comment to the struct that s...In Tor, we try to support v6-mapped IPv4 addresses.
We should either:
* reject them unconditionally, or
* audit all uses of tor_addr_t.family to see if we should be calling tor_addr_is_v4() instead, and add a comment to the struct that says we should consider using tor_addr_is_v4() rather than comparing family.
If no relay in the consensus is currently using these addresses, then maybe we should just call them internal on authorities, relays, and clients, and remove all the code that tries to deal with them.
Discovered as part of #15518.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26427Remove circularity surrounding functions called by tor_logv()2020-06-13T15:26:52ZNick MathewsonRemove circularity surrounding functions called by tor_logv()These functions should not be allowed to log failure fail when tor_logv calls them, because tor_logv is required for logging.
This will help us untangle some call cycles at the bottom of our callgraph, and thereby help with our library ...These functions should not be allowed to log failure fail when tor_logv calls them, because tor_logv is required for logging.
This will help us untangle some call cycles at the bottom of our callgraph, and thereby help with our library refactoringTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22636Add Travis configs so GitHub forks get CI coverage2020-06-13T15:23:20ZTaylor YuAdd Travis configs so GitHub forks get CI coverageIt would be useful to have Travis configs for tor so GitHub users can have CI coverage for changes in their forks. This should probably run `make check` or whatever more strict level of tests we converge on later.It would be useful to have Travis configs for tor so GitHub users can have CI coverage for changes in their forks. This should probably run `make check` or whatever more strict level of tests we converge on later.Tor: 0.3.2.x-finalpatrickodpatrickodhttps://gitlab.torproject.org/legacy/trac/-/issues/25381Add crypto_rand_double_sign() in C and Rust2020-06-13T15:22:33ZteorAdd crypto_rand_double_sign() in C and RustWe need a function that returns 1.0 or -1.0 with equal probability, so we can avoid weird tricks that waste floating point precision.
Since we want to use this in the laplace and guassian distributions, it needs to be implemented in bot...We need a function that returns 1.0 or -1.0 with equal probability, so we can avoid weird tricks that waste floating point precision.
Since we want to use this in the laplace and guassian distributions, it needs to be implemented in both C and Rust.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23347Using bridges or switching to bridges sometimes does not work with tor 0.3.22020-06-13T15:17:47ZGeorg KoppenUsing bridges or switching to bridges sometimes does not work with tor 0.3.2Trying to switch from a direct connection to using a bridge is not working anymore with tor on `master` (found while using commit f2f1cab2b3c6a56f93862c424663f083b79c7bc3) on my Linux box.
Steps to reproduce:
1) Take a recent Tor Brows...Trying to switch from a direct connection to using a bridge is not working anymore with tor on `master` (found while using commit f2f1cab2b3c6a56f93862c424663f083b79c7bc3) on my Linux box.
Steps to reproduce:
1) Take a recent Tor Browser (e.g. an alpha version)
2) Make sure you replace `tor` shipped in your Tor Browser instance with one compiled from a recent master commit
3) Start Tor Browser and choose direct connection
4) Shut Tor Browser down after you got greeted with the `about:tor` page
5) Restart Tor Browser and press the "Open Settings" button before the bootstrapping is finished
6) Select e.g. the recommended `obfs4` default bridge option
7) The start-up stalls (I quit Tor Browser after 5 minutes waiting)
The first bad commit is c21cfd28f43a969229ede02e20c6b554c1b88aae which fixed #17750. Without that one Tor Browser resumes bootstrapping after a couple of seconds and is using an `obfs4` bridge.Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23827Clients/Relays: Use IPv6 Addresses from microdesc consensus2020-06-13T15:15:44ZteorClients/Relays: Use IPv6 Addresses from microdesc consensusClient/Relay Implementation for #20916.
We need to use the IPv6 addresses from consensuses with versions that implement #23826, and ignore microdesc IPv6 addresses.Client/Relay Implementation for #20916.
We need to use the IPv6 addresses from consensuses with versions that implement #23826, and ignore microdesc IPv6 addresses.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23820Make sure v3 single onion services and v3 onion service clients only send IPv...2020-06-13T15:15:33ZteorMake sure v3 single onion services and v3 onion service clients only send IPv4 addressesThis fixes the bug warning in #23493, and allows our users to migrate to IPv4 v3 single onion services.This fixes the bug warning in #23493, and allows our users to migrate to IPv4 v3 single onion services.Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23819Support IPv6 link-local interface addresses2020-06-13T15:15:32ZTracSupport IPv6 link-local interface addressesThis is either a **bug** or a **documentation defect** (didn't dive into the code yet).
Standard routing with ipv6 happens with link-local as next hop.
Hence, for the sake of making a transparent proxy for VMs, I am trying to specify a...This is either a **bug** or a **documentation defect** (didn't dive into the code yet).
Standard routing with ipv6 happens with link-local as next hop.
Hence, for the sake of making a transparent proxy for VMs, I am trying to specify a **TransPort** with the link-local of my bridge.
The standard way of specifying that is: [fe80::xxxx:xxxx:xxxx:xxxx%iface]
Tor parses correctly this ipv6 address (removing iface) but fails to bind.
To reproduce:
`$cat /etc/tor/torrc:`
(...)
`TransPort fe80::1c9a:c3ff:fec8:7768%vnet0:9040`
(...)
`$ ifconfig vnet0`
`vnet0 Link encap:Ethernet HWaddr 1e:9a:c3:c8:77:68`
` inet6: fe80::1c9a:c3ff:fec8:7768/64 c9a:c3ff:fec8:7768/64 Scope:Link`
As you can see, I have a vnet0. It has the link-local address that is specified as TransPort.
Now let's start tor:
`$ sudo tor`
`Oct 10 21:34:28.384 [notice] Tor 0.2.9.11 (git-aa8950022562be76) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g and Zlib 1.2.8.`
(...)
`Oct 10 21:34:28.385 [notice] You configured a non-loopback address '[fe80::1c9a:c3ff:fec8:7768]:9040' for TransPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.`
(...)
`Oct 10 21:34:28.386 [notice] Opening Transparent pf/netfilter listener on [fe80::1c9a:c3ff:fec8:7768]:9040`
`Oct 10 21:34:28.386 [warn] Could not bind to fe80::1[c9a:c3ff:fec8:7768:9040 c9a:c3ff:fec8:7768:9040]: Invalid argument`
As you can see, it is correctly striping the **%vnet0** and reading my link-local address from the /etc/tor/torrc
It then tries to open the "pf/netfilter" and fails to bind, and says "invalid argument"!
Indeed, binding a link-local ipv6 address needs one more argument in the syscall to bind: the interface!
**Other tests:**
Trying with fancy notations like
TransPort [fe80::1c9a:c3ff:fec8:7768]%vnet0:9040
fails at parsing.
Trying with a global address (with ipV6 you can just add addresses to the interface) works but opens other headaches such as having to advertise a different router address to the clients.
**Conclusion**, this is either:
* **(bug)** the implementation of the "interface" parameter when binding link-local addresses is missing or failing.
or
* **(documentation)** it works and it is a documentation defect since nowhere we can find how to bind a link-local ipv6 address or even a working example.
**Additional:** there could be the exact same bug/missing documentation in other places where you can specify an ipv6 address.
**Trac**:
**Username**: ZakharTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22927zstd tests fail with libzstd 1.3.02020-06-13T15:11:46Zteorzstd tests fail with libzstd 1.3.0When I run the unit tests on tor master:
`
[notice] Tor 0.3.2.0-alpha-dev (git-9a1338d9df938fba) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2l, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.3.0.
`
I see the following failures...When I run the unit tests on tor master:
`
[notice] Tor 0.3.2.0-alpha-dev (git-9a1338d9df938fba) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2l, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.3.0.
`
I see the following failures:
```
buffer/compress/zstd: [forking]
FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf, compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf, compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf, compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf, compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
[compress/zstd FAILED]
...
util/compress_concat/zstd:
FAIL src/test/test_util.c:2414: assert(r OP_EQ 0): -1 vs 0
[compress_concat/zstd FAILED]
```Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22883Bridge unavailable during differential consensus update2020-06-13T15:11:30ZTracBridge unavailable during differential consensus updateAfter updating Tor from 0.3.0.9 to 0.3.1.4 (on a Raspberry Pi running Raspbian), I observed that my bridge became unable to answer new connection requests for extended periods, from 10 to 20 minutes or more, while tor process uses all av...After updating Tor from 0.3.0.9 to 0.3.1.4 (on a Raspberry Pi running Raspbian), I observed that my bridge became unable to answer new connection requests for extended periods, from 10 to 20 minutes or more, while tor process uses all available cpu (more than 90% on average - with no corresponding traffic for clients) and files are updated in /var/lib/tor/diff-cache directory.
(For example, if I launch a TorBrowser using this bridge during such an update, it remains blocked before opening the Welcome window, and the corresponding client tor process remains blocked after "Bootstrapped 90%: Establishing a Tor circuit", for 10 minutes or more).
So I had to downgrade to 0.3.0.9, so that my bridge doesn't become unavailable for a total of several hours per day.
May I suggest that an option make it possible to choose between the new differential update mode and the traditional one?
First, this would be necessary for some (like me) to keep following new Tor versions long term.
And even on more powerful platforms, and even if a better handling of priorities could make it possible for main Tor thread to remain available on Pi, Tor relay operators might want to make different choices between minimizing bandwidth for consensus transfer or minimizing cpu usage, and hence power consumption. (Please think of the Planet globally, and not only of the network ;) )
**Trac**:
**Username**: torvlnt33rTor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22460Link handshake trouble: certificates and keys can get out of sync2020-06-13T15:09:51ZteorLink handshake trouble: certificates and keys can get out of syncI'm running a recent tor master as an authority in a tor testing network:
```
[notice] Tor 0.3.1.0-alpha-dev (git-0266c4ac819d9c83) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2k, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
...I'm running a recent tor master as an authority in a tor testing network:
```
[notice] Tor 0.3.1.0-alpha-dev (git-0266c4ac819d9c83) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2k, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
```
I get this warning every so often:
```
[warn] Received a bad CERTS cell: Link certificate does not match TLS certificate
```
Is this expected?Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21677Prop140: analyze diff performance2020-06-13T15:07:11ZNick MathewsonProp140: analyze diff performanceTor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21650prop140: Clients request diffs and handle diffs in replies2020-06-13T15:07:02ZNick Mathewsonprop140: Clients request diffs and handle diffs in repliesFor the final piece of prop140, clients should ask for consensus diffs as appropriate, and handle them if they're received.
We may need proposal extensions here:
* Should clients begin doing this immediately, or should there be a tris...For the final piece of prop140, clients should ask for consensus diffs as appropriate, and handle them if they're received.
We may need proposal extensions here:
* Should clients begin doing this immediately, or should there be a tristate where "default" means "look at the consensus"?
* Should there be an option -- maybe for testing, maybe not -- that forces clients to look for directory guards that support consensus diffs?Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21649prop140: Caches serve diffs on request2020-06-13T15:07:02ZNick Mathewsonprop140: Caches serve diffs on requestWhen a client asks for it, caches should serve consensus diffs.
We'll want to integrate this with the new compression logic that ahf is proposing.When a client asks for it, caches should serve consensus diffs.
We'll want to integrate this with the new compression logic that ahf is proposing.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21646prop140/compression: Refactor "directory request" code2020-06-13T15:06:59ZNick Mathewsonprop140/compression: Refactor "directory request" codeOur current notion of "what is a directory request" includes a bunch of fields that are strewn around directory connections and passed to different functions. It would be nice to instead have a "directory request" type that we created a...Our current notion of "what is a directory request" includes a bunch of fields that are strewn around directory connections and passed to different functions. It would be nice to instead have a "directory request" type that we created and passed around as appropriate. This would make it easier to test our request generation/parsing code.Tor: 0.3.1.x-finalNick MathewsonNick Mathewson