The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-22T16:18:20Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33188Tor Manual: Alphabetize Server and Directory Server Options2021-07-22T16:18:20ZTracTor Manual: Alphabetize Server and Directory Server OptionsAlphabetize options in the Server Options and Directory Server Options
**Trac**:
**Username**: swatiAlphabetize options in the Server Options and Directory Server Options
**Trac**:
**Username**: swatihttps://gitlab.torproject.org/tpo/core/tor/-/issues/33192Stop assuming that /usr/bin/python exists2020-07-14T18:30:36ZTracStop assuming that /usr/bin/python existsThis issue is relevant to the following ticket: legacy/trac#29913
In short, the problem in legacy/trac#29913 was that Python 3 scripts cannot depend on a hardcoded path in order to find the Python 3 executable, because the path itself i...This issue is relevant to the following ticket: legacy/trac#29913
In short, the problem in legacy/trac#29913 was that Python 3 scripts cannot depend on a hardcoded path in order to find the Python 3 executable, because the path itself is not immutable. (For instance, as seen in that ticket itself.
Unfortunately, the same exact issue also applies to Python 2 scripts and their relevant executables.
**Trac**:
**Username**: alwayslividTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33193Travis CI: Find and fix Python syntax errors2020-06-27T13:48:21ZteorTravis CI: Find and fix Python syntax errorsHere's a PR from a new contributor:
https://github.com/torproject/tor/pull/1686Here's a PR from a new contributor:
https://github.com/torproject/tor/pull/1686Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33194Sort Travis jobs in speed order2020-06-27T13:48:21ZteorSort Travis jobs in speed orderAnd remove a redundant job.
We try to put the slowest Travis jobs first, so CI finishes as early as possible.
But we put the optional macOS chutney / IPv6 job last, because it's very very slow, so we don't wait for it to finish.
This ...And remove a redundant job.
We try to put the slowest Travis jobs first, so CI finishes as early as possible.
But we put the optional macOS chutney / IPv6 job last, because it's very very slow, so we don't wait for it to finish.
This ticket is required for Sponsor 55, because we need to do it to make IPv6 tests mandatory.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33195Require IPv6 tests in Travis CI2020-06-27T13:48:21ZteorRequire IPv6 tests in Travis CIWhile we're actively changing our IPv6 code, we should make sure that the macOS chutney IPv6 tests pass in Travis CI.
While I'm doing this change, I will see if there are:
* some redundant jobs I can delete, or
* some inactive areas th...While we're actively changing our IPv6 code, we should make sure that the macOS chutney IPv6 tests pass in Travis CI.
While I'm doing this change, I will see if there are:
* some redundant jobs I can delete, or
* some inactive areas that I can make fast_finish.
I think our Rust build might be a good candidate for fast_finish, we haven't changed that code much in about a year. But I should check with the team before making this change.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33196Make flake8 test Python 3 syntax2022-06-17T18:37:43ZteorMake flake8 test Python 3 syntaxFollow up to legacy/trac#33193.Follow up to legacy/trac#33193.https://gitlab.torproject.org/tpo/core/tor/-/issues/33201Tor relays ignore some local bytes in their statistics2020-06-27T13:48:21ZteorTor relays ignore some local bytes in their statisticsIn record_num_bytes_transferred_impl(), tor records local connection bytes on:
* directory connections
But ignores them for:
* OR connectons,
* exit connections, and
* accounting.
I don't think that's right, tor should only be ignoring...In record_num_bytes_transferred_impl(), tor records local connection bytes on:
* directory connections
But ignores them for:
* OR connectons,
* exit connections, and
* accounting.
I don't think that's right, tor should only be ignoring local connections for accounting.
This is a sponsor 55 must ticket, because we need accurate statistics during testing and deployment.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33203Fix typo in makedesc.py2020-06-27T13:48:21ZteorFix typo in makedesc.pySee this commit:
https://github.com/torproject/tor/pull/1686/commits/16561514782498009335205b08b2c0c123c6ab9bSee this commit:
https://github.com/torproject/tor/pull/1686/commits/16561514782498009335205b08b2c0c123c6ab9bTor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33204Upgrade Rust typenum for Python 3 compatibility2020-07-29T14:27:11ZteorUpgrade Rust typenum for Python 3 compatibility./src/ext/rust/crates/typenum-1.9.0/ghp-import Is not Python 3 compatible.
Please upgrade to v1.11.2 https://docs.rs/crate/typenum
From:
https://github.com/torproject/tor/pull/1686#issuecomment-583808548./src/ext/rust/crates/typenum-1.9.0/ghp-import Is not Python 3 compatible.
Please upgrade to v1.11.2 https://docs.rs/crate/typenum
From:
https://github.com/torproject/tor/pull/1686#issuecomment-583808548Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33210old torrc in tor debian package in stable2020-07-29T14:26:45ZGabagaba@torproject.orgold torrc in tor debian package in stableThe torrc from the 0.3.5 tor version debian package by default in the Debian's tor package is very old:
"## Configuration file for a typical Tor user
## Last updated 9 October 2013 for Tor 0.2.5.2-alpha.
## (may or may not work for much...The torrc from the 0.3.5 tor version debian package by default in the Debian's tor package is very old:
"## Configuration file for a typical Tor user
## Last updated 9 October 2013 for Tor 0.2.5.2-alpha.
## (may or may not work for much older or much newer versions of Tor.)
##
...
"
Package: tor
Version: 0.3.5.8-1
And the documentation here needs to mention the version that was written for:
https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DebianUbuntu
I couldn't find any ticket mentioning this and I'm trying to figure out how this should be fixed.https://gitlab.torproject.org/tpo/core/tor/-/issues/33212Warning in protover.rs making CI fail.2020-06-27T13:48:20ZNick MathewsonWarning in protover.rs making CI fail.It looks like a new version of Rust is warning about extraneous parentheses, causing our CI to fail in some cases. Let's fix that.
(This is possibly a duplicate, but I can't find the original.)It looks like a new version of Rust is warning about extraneous parentheses, causing our CI to fail in some cases. Let's fix that.
(This is possibly a duplicate, but I can't find the original.)Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33213remove obsolete mirroring job from .gitlab-ci.yml2020-06-27T13:48:20ZTaylor Yuremove obsolete mirroring job from .gitlab-ci.ymlThis is just to incorporate the deletion of the mirroring job suggested in legacy/trac#32193.This is just to incorporate the deletion of the mirroring job suggested in legacy/trac#32193.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33214ConnDirectionStatistics is off by default, but most relays report it2020-06-27T13:48:20ZteorConnDirectionStatistics is off by default, but most relays report itKarsten noticed that most relays report ConnDirectionStatistics, but it's off by default in tor:
https://lists.torproject.org/pipermail/tor-dev/2020-February/014159.html
https://2019.www.torproject.org/docs/tor-manual.html.en
That's a b...Karsten noticed that most relays report ConnDirectionStatistics, but it's off by default in tor:
https://lists.torproject.org/pipermail/tor-dev/2020-February/014159.html
https://2019.www.torproject.org/docs/tor-manual.html.en
That's a bit of a mystery, here are some possible causes:
* most large distributions set it on by default
* Debian + Ubuntu + ... ?
* sample torrcs?
* there is a bug in most tor relays, that sets it on by default
* since at least 0.2.9?
We don't have to fix this bug in Sponsor 55, but we need to be aware of it, because we're going to modify the ConnDirectionStatistics code.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33217Update scripts to add 0.4.3 and remove 0.4.02020-06-27T13:48:20ZNick MathewsonUpdate scripts to add 0.4.3 and remove 0.4.0Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33262Prop 313: 3. Write a Script that Counts IPv6 Relays in the Consensus2020-07-02T19:46:43ZteorProp 313: 3. Write a Script that Counts IPv6 Relays in the ConsensusWe want to write a script that generates statistics for relays that:
1. have an IPv6 ORPort,
2. support IPv6 clients,
3. support IPv6 reachability checks, and
4. support IPv6 reachability checks, and IPv6 clients.
The first two ...We want to write a script that generates statistics for relays that:
1. have an IPv6 ORPort,
2. support IPv6 clients,
3. support IPv6 reachability checks, and
4. support IPv6 reachability checks, and IPv6 clients.
The first two statistics have no dependencies. The last two statistics depend on the "Relay=3" subprotocol in legacy/trac#33226.
The script should calculate:
* the number of relays, and
* the consensus weight fraction of relays.
In order to provide easy access to these statistics, we propose
that the script should:
* download a consensus (or read an existing consensus), and
* calculate and report these statistics.
We could write this script using Python 3 and Stem:
https://stem.torproject.org
The following consensus weight fractions should divide by the total
consensus weight:
* have an IPv6 ORPort (all relays have an IPv4 ORPort), and
* support IPv6 reachability checks (all relays support IPv4 reachability).
The following consensus weight fractions should divide by the
"usable Guard" consensus weight:
* support IPv6 clients, and
* support IPv6 reachability checks and IPv6 clients.
"Usable Guards" have the Guard flag, but do not have the Exit flag. If the
Guard also has the BadExit flag, the Exit flag should be ignored.
The script should check that Wgd is 0. If it is not, the script
should log a warning about the accuracy of the "Usable Guard" statistics.
See proposal 313, section 3:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n82Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33268Prop 313: 8.1. Test IPv6 Relay Consensus Counts on the Tor Network2020-07-02T19:47:19ZteorProp 313: 8.1. Test IPv6 Relay Consensus Counts on the Tor NetworkThis task depends on legacy/trac#33262.
Test the IPv6 relay count script in proposal 313, using the public tor network.
There isn't really much to test here. There are only 4 calculations. We've done counts like this before.
See propo...This task depends on legacy/trac#33262.
Test the IPv6 relay count script in proposal 313, using the public tor network.
There isn't really much to test here. There are only 4 calculations. We've done counts like this before.
See proposal 313, section 8.1, public tor network tests part:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n337Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33272Prop 313: 8.2. Test IPv6 Stats on the Tor Network2020-08-07T13:17:17ZteorProp 313: 8.2. Test IPv6 Stats on the Tor NetworkWe want to test the IPv6 connection and bandwidth statistics on the public network, with a small number of relays and bridges.
See proposal 313, section 8.2, public tor network tests part:
https://gitweb.torproject.org/torspec.git/tree/...We want to test the IPv6 connection and bandwidth statistics on the public network, with a small number of relays and bridges.
See proposal 313, section 8.2, public tor network tests part:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n355Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33222Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests2020-10-22T15:12:33ZteorProp 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests4.2. Checking IPv6 ORPort Reachability
We propose that testing relays (and bridges) select some IPv6 extend-capable
relays for their reachability circuits, and include their own IPv4 and IPv6
ORPorts in the final extend cells on those c...4.2. Checking IPv6 ORPort Reachability
We propose that testing relays (and bridges) select some IPv6 extend-capable
relays for their reachability circuits, and include their own IPv4 and IPv6
ORPorts in the final extend cells on those circuits.
The final extending relay will extend to the testing relay:
* using an existing authenticated connection to the testing relay
(which may be over IPv4 or IPv6), or
* over a new connection via the IPv4 or IPv6 ORPort in the extend cell.
The testing relay will confirm that test circuits can extend to both its
IPv4 and IPv6 ORPorts.
4.2.1. Selecting the Final Extending Relay
IPv6 ORPort reachability checks require an IPv6 extend-capable relay as
the second-last hop of reachability circuits. (The testing relay is the
last hop.)
IPv6-extend capable relays must have:
* Relay subprotocol version 3 (or later), and
* an IPv6 ORPort.
(See section 5.1 for the definition of Relay subprotocol version 3.)
The other relays in the path do not require any particular protocol
versions.
4.2.2. Extending from the Second-Last Hop
IPv6 ORPort reachability circuits should put the IPv4 and IPv6 ORPorts in
the extend cell for the final extend in reachability circuits.
Supplying both ORPorts makes these extend cells indistinguishable from
future client extend cells.
If reachability succeeds, the testing relay (or bridge) will accept the
final extend on one of its ORPorts, selected at random by the extending
relay (see section 3.2.1).
4.2.3. Separate IPv4 and IPv6 Reachability Flags
Testing relays (and bridges) will record reachability separately for IPv4
and IPv6 ORPorts, based on the ORPort that the test circuit was received on.
Here is a reliable way to do reachability self-tests for each ORPort:
1. Check for create cells on inbound ORPort connections from other relays
Check for a cell on any IPv4 and any IPv6 ORPort. (We can't know which listener(s) correspond to the advertised ORPorts, particularly when using port forwarding.) Make sure the cell was received on an inbound OR connection, that is authenticated to another relay.
2. Check for created cells from testing circuits on outbound OR connections
Check for a returned created cell on our IPv4 and IPv6 self-test circuits. Make sure those circuits were on outbound OR connections.
By combining these tests, we confirm that we can:
* reach our own ORPorts with testing circuits
* send and receive cells via inbound OR connections from other relays to our own ORPorts
* send and receive cells via outbound OR connections to other relays' ORPorts
This isn't a perfect test, there are a few false positives:
* relays with multiple IPv4 or IPv6 ORPorts, where only some ports are reachable:
* (this configuration is uncommon, but multiple ORPorts are supported)
* the final extend cell contains the advertised IPv6 address of the self-testing relay
* if the extending relay already has a connection to an old but working ORPort, it may use that connection instead
* so these tests can pass, even when the advertised ORPort is unreachable
* relays whose keys have been copied from another relay in the consensus, for similar reasons
* this configuration is rare and unsupported
From proposal 311, section 4.2:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n283teorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33253Prop 312: 5.1. Ask Relay Operators to Test IPv6 Addresses Discovery2020-07-22T19:55:48ZteorProp 312: 5.1. Ask Relay Operators to Test IPv6 Addresses DiscoverySee legacy/trac#33252 for advice on testing stages.
Write an email to the tor-relays list, asking relay operators to help test the proposal 312 IPv4 and IPv6 Address Discovery changes.
Once these changes are merged, volunteer relay and...See legacy/trac#33252 for advice on testing stages.
Write an email to the tor-relays list, asking relay operators to help test the proposal 312 IPv4 and IPv6 Address Discovery changes.
Once these changes are merged, volunteer relay and bridge operators will be able to test them by:
* compiling from source,
* running nightly builds, or
* running alpha releases.
See proposal 312, section 5.1, relay operator test part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1461Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33248Prop 312: 3.5.5. Detailed Address Resolution Logs2020-07-22T17:33:47ZteorProp 312: 3.5.5. Detailed Address Resolution LogsThis is an optional change, to help diagnose relay address resolution
issues.
Relays (and bridges) should log the address chosen using each address
resolution method, when:
* address resolution succeeds,
* address resolution fails,...This is an optional change, to help diagnose relay address resolution
issues.
Relays (and bridges) should log the address chosen using each address
resolution method, when:
* address resolution succeeds,
* address resolution fails,
* reachability checks fail, or
* publishing the descriptor fails.
These logs should be rate-limited separately for successes and failures.
The logs should tell operators to set the Address torrc option for IPv4 and
IPv6 (if available).
See proposal 312, section 3.5.5:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1083Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org