Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-07-02T19:46:44Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33226Prop 311: 5. Declare Support for Subprotocol Version "Relay=3"2020-07-02T19:46:44ZteorProp 311: 5. Declare Support for Subprotocol Version "Relay=3"This ticket depends on relay IPv6 extends in #33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this proposal.
See p...This ticket depends on relay IPv6 extends in #33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this proposal.
See proposal 311, section 5:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n601Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33225Prop 311: 4.4.1. Extend IPv6 From All Supported Second-Last Hops2020-06-13T15:50:59ZteorProp 311: 4.4.1. Extend IPv6 From All Supported Second-Last HopsThis is an optional change.
This change has a zero points estimate, because I think it is the fastest way of implementing #33222. (The alternative design requires creating different circuit types for IPv4 and IPv6 reachability checks.)
...This is an optional change.
This change has a zero points estimate, because I think it is the fastest way of implementing #33222. (The alternative design requires creating different circuit types for IPv4 and IPv6 reachability checks.)
4.4.1. Extend IPv6 From All Supported Second-Last Hops
The testing relay (or bridge) puts both IPv4 and IPv6 ORPorts in its final
extend cell, and the receiving ORPort is selected at random by the
extending relay (see sections 3.2.1 and 4.2). Therefore, approximately half
of IPv6 ORPort reachability circuits will actually end up confirming IPv4
ORPort reachability.
We propose this optional change, to improve the rate of IPv6 ORPort
reachability checks:
If the second-last hop of an IPv4 ORPort reachability circuit supports IPv6
extends, testing relays may put the IPv4 and IPv6 ORPorts in the extend
cell for the final extend.
As the number of relays that support IPv6 extends increases, this change
will increase the number of IPv6 reachability confirmations. In the ideal
case, where the entire network supports IPv4 and IPv6 extends, IPv4 and IPv6
ORPort reachability checks would require a similar number of circuits.
See proposal 311, section 4.4.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n439Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33222Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests2020-06-13T15:53:19ZteorProp 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#n283Tor: 0.4.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33218Add Jenkins builders for 0.4.32020-06-13T17:00:50ZNick MathewsonAdd Jenkins builders for 0.4.3Tor 0.4.3.x development now proceeds on its own branches (maint-0.4.3 and release-0.4.3); let's add them to Jenkins too.Tor 0.4.3.x development now proceeds on its own branches (maint-0.4.3 and release-0.4.3); let's add them to Jenkins too.Tor: 0.4.3.x-finalweasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/legacy/trac/-/issues/33217Update scripts to add 0.4.3 and remove 0.4.02020-06-13T15:50:52ZNick MathewsonUpdate scripts to add 0.4.3 and remove 0.4.0Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33214ConnDirectionStatistics is off by default, but most relays report it2020-06-13T15:50:51ZteorConnDirectionStatistics 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/legacy/trac/-/issues/33213remove obsolete mirroring job from .gitlab-ci.yml2020-06-13T15:50:50ZTaylor Yuremove obsolete mirroring job from .gitlab-ci.ymlThis is just to incorporate the deletion of the mirroring job suggested in #32193.This is just to incorporate the deletion of the mirroring job suggested in #32193.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33212Warning in protover.rs making CI fail.2020-06-13T15:50:50ZNick 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/legacy/trac/-/issues/33204Upgrade Rust typenum for Python 3 compatibility2020-06-13T15:50:49ZteorUpgrade 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/legacy/trac/-/issues/33203Fix typo in makedesc.py2020-06-13T15:50:48ZteorFix 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/legacy/trac/-/issues/33201Tor relays ignore some local bytes in their statistics2020-06-13T15:50:48ZteorTor 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/legacy/trac/-/issues/33199Fix lint error after merging #307332020-06-13T16:16:28ZjugaFix lint error after merging #30733Because there was a merge conflict merging #30733 after merging #30727, we accepted changes from both, but a new line is missing and flake8 complains (https://travis-ci.org/juga0/sbws/jobs/648108391#L2024)Because there was a merge conflict merging #30733 after merging #30727, we accepted changes from both, but a new line is missing and flake8 complains (https://travis-ci.org/juga0/sbws/jobs/648108391#L2024)sbws: 1.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33198Check changes related to descriptors in a bandwidth file created by a bwauth ...2020-06-13T16:16:28ZjugaCheck changes related to descriptors in a bandwidth file created by a bwauth before next releaseIn #30733 we did not create tests for the changes updating descriptors nor dormant mode.
Until those tests are implemented, we could change a bwauth to run the latest maint-1.1 branch and look the bandwidth files produced.
This way we co...In #30733 we did not create tests for the changes updating descriptors nor dormant mode.
Until those tests are implemented, we could change a bwauth to run the latest maint-1.1 branch and look the bandwidth files produced.
This way we could avoid some bugs before releasing a new version.
Maybe #30899 should be child of this to know that the bwauth is not running a released version but a git version.sbws: 1.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33197Refactor code that obtain headers from the state file2020-06-13T16:16:27ZjugaRefactor code that obtain headers from the state fileWorking on #30196 there was a commit to do what the title says. It was suggested to do it in a different PR.Working on #30196 there was a commit to do what the title says. It was suggested to do it in a different PR.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33196Make flake8 test Python 3 syntax2020-06-13T15:50:47ZteorMake flake8 test Python 3 syntaxFollow up to #33193.Follow up to #33193.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33195Require IPv6 tests in Travis CI2020-06-13T15:50:47ZteorRequire 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/legacy/trac/-/issues/33194Sort Travis jobs in speed order2020-06-13T15:50:46ZteorSort 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/legacy/trac/-/issues/33193Travis CI: Find and fix Python syntax errors2020-06-13T15:50:45ZteorTravis 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/legacy/trac/-/issues/33192Stop assuming that /usr/bin/python exists2020-06-13T15:50:44ZTracStop assuming that /usr/bin/python existsThis issue is relevant to the following ticket: #29913
In short, the problem in #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 ...This issue is relevant to the following ticket: #29913
In short, the problem in #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/legacy/trac/-/issues/33167Test changes in descriptors2020-06-13T16:16:26ZjugaTest changes in descriptorsWorking on #30733 asn pointed out that there're no tests to check the changes in descriptors.
It'll be easier to create these tests when:
- sbws can use chutney (#33150) so that the test network lives longer than the 1st consensus
- `R...Working on #30733 asn pointed out that there're no tests to check the changes in descriptors.
It'll be easier to create these tests when:
- sbws can use chutney (#33150) so that the test network lives longer than the 1st consensus
- `RelayList` can be initialized with different consensus/descriptors and not only a controller (#29717)
- have an external tool that check the generated bandwidth files in the Tor network and detects changes in the descriptors (#33152)
Maybe we should include this ticket as part of #33121sbws: unspecified