The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-07-03T13:21:32Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33238Prop 312: 3.2.3. Use Local Interface IPv6 Address2020-07-03T13:21:32ZteorProp 312: 3.2.3. Use Local Interface IPv6 AddressThis ticket depends on `Address IPv6` support in legacy/trac#33233.
If they don't have usable Address or ORPort addresses, relays (and bridges) should use publicly routable addresses
from the OS interface addresses or routing table, as ...This ticket depends on `Address IPv6` support in legacy/trac#33233.
If they don't have usable Address or ORPort addresses, relays (and bridges) should use publicly routable addresses
from the OS interface addresses or routing table, as their IPv4 and IPv6
addresses.
Tor has local interface address resolution functions, which support most
major OSes. Tor uses these functions to guess its IPv4 address. We propose
using them to also guess tor's IPv6 address.
We also propose modifying the address resolution order, so interface
addresses are used before the local hostname. This decision is based
on our principles: interface addresses are local, trusted, and reliable;
hostname lookups may be remote, untrusted, and unreliable.
If the local interface addresses are unavailable, tor opens a UDP socket to
a publicly routable address, but doesn't actually send any packets.
Instead, it uses the socket APIs to discover the interface address for the
socket. (UDP is used because it is stateless, so the OS will not send any
packets to open a connection.)
Tor already ignores private IPv4 interface addresses on public relays. We
propose to also ignore private IPv6 interface addresses.
See proposal 312, section 3.2.1, general case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n359Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33237Prop 312: 3.2.2. Stop Directory Authorities Resolving *Port Hostnames2021-08-23T15:12:44ZteorProp 312: 3.2.2. Stop Directory Authorities Resolving *Port HostnamesFor security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory
authorities only accept IPv4 or IPv6 address literals in the address part
of the ORPort an...For security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory
authorities only accept IPv4 or IPv6 address literals in the address part
of the ORPort and DirPort options.
As part of this fix, we may also ban DNS resolution on all configured Ports. (We should try to avoid banning DNS resolution entirely on authorities, because some test networks use Authority/Exits.)
See proposal 312, section 3.2.2, directory authority case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n340
Directory authorities must not attempt to resolve these
addresses using DNS. It is a config error to provide a hostname as a
directory authority's ORPort or DirPort.
If directory authorities don't have an IPv4 address literal in their
Address or ORPort, they should issue a configuration error, and refuse to
launch. If directory authorities don't have an IPv6 address literal in their
Address or ORPort, they should issue a notice-level log, and fall back to
only using IPv4.Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33236Prop 312: 3.2.2. Use Advertised ORPort IPv4 Address in Descriptors2020-07-07T15:02:30ZteorProp 312: 3.2.2. Use Advertised ORPort IPv4 Address in DescriptorsIf the Address option is not set for IPv4 or IPv6, relays (and bridges) should use the first advertised ORPort IPv4 and IPv6 addresses.
Note that relays already use the first advertised IPv6 ORPort address in their descriptors. So we ju...If the Address option is not set for IPv4 or IPv6, relays (and bridges) should use the first advertised ORPort IPv4 and IPv6 addresses.
Note that relays already use the first advertised IPv6 ORPort address in their descriptors. So we just need to preserve that behaviour.
The ORPort address may be a hostname. If it is, tor should try to use it to
resolve an IPv4 and IPv6 address, and open ORPorts on the first available
IPv4 and IPv6 address. Tor should respect the IPv4Only and IPv6Only port
flags, if specified. (Tor currently resolves IPv4 and IPv6 addresses from
hostnames in ORPort lines.)
Relays (and bridges) currently use the first advertised ORPort IPv6 address
as their IPv6 address. We propose to use the first advertised IPv4 ORPort
address in a similar way, for consistency.
Tor currently uses its listener port list to look up its IPv6 ORPort for
its descriptor. We propose that tor's address discovery uses the listener
port list for both IPv4 and IPv6. (And does not attempt to independently
parse or resolve ORPort configs.)
This design decouples ORPort option parsing, ORPort listener opening, and
address discovery. It also implements a form of caching: IPv4 and IPv6
addresses resolved from hostnames are stored in the listener port list,
then used to open listeners. Therefore, tor should continue to use the same
address, while the listener remains open. (See also sections 3.2.7 and
3.2.8.)
For the purposes of address resolution, tor should ignore private
configured ORPort addresses on public tor networks. (Binding to private
ORPort addresses is supported, even on public tor networks, for relays that use NAT to reach the Internet.)
See proposal 312, section 3.2.2, general case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n306Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33235Prop 312: 3.2.1. Test Address torrc Option Configurations2020-07-01T20:27:30ZteorProp 312: 3.2.1. Test Address torrc Option ConfigurationsThis ticket depends on IPv6 Addresses in legacy/trac#33233, and automatic IPv6 ORPorts in legacy/trac#33246. These tests should be in CI, or they should be repeated after each change.
We should support the following combinations of addr...This ticket depends on IPv6 Addresses in legacy/trac#33233, and automatic IPv6 ORPorts in legacy/trac#33246. These tests should be in CI, or they should be repeated after each change.
We should support the following combinations of address literals and hostnames:
Legacy configurations:
1. (A) No configured Address option
2. (B) Address IPv4 literal
3. (C) Address hostname (use IPv4 and IPv6 DNS addresses)
New configurations:
1. (D) Address IPv6 literal
2. (E) Address IPv4 literal / Address IPv6 literal
3. (F) Address hostname / Address hostname (use IPv4 and IPv6 DNS addresses)
4. (G) Address IPv4 literal / Address hostname (only use IPv6 DNS addresses)
5. (H) Address hostname (only use IPv4 DNS addresses) / Address IPv6 literal
If we can't find an IPv4 or IPv6 address using the configured Address options:
* No IPv4: guess IPv4, and its reachability must succeed.
* No IPv6: guess IPv6, publish if reachability succeeds.
Combinations A and B are the most common legacy configurations. We want to support the following outcomes for all legacy configurations:
* automatic upgrades to guessed and reachable IPv6 addresses,
* continuing to operate on IPv4 when the IPv6 address can't be guessed, and
* continuing to operate on IPv4 when the IPv6 address has been guessed, but it is unreachable.
See proposal 312, section 3.2.1, testing notes:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n270Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32910trace: Add tracepoints and userspace tracer support2020-07-10T17:24:17ZDavid Gouletdgoulet@torproject.orgtrace: Add tracepoints and userspace tracer supportTor-dev email: https://lists.torproject.org/pipermail/tor-dev/2019-December/014111.html
These are what needs to be done but they sorta need to be together to make sense thus this one ticket:
a. Add a series of tracepoints in tor code b...Tor-dev email: https://lists.torproject.org/pipermail/tor-dev/2019-December/014111.html
These are what needs to be done but they sorta need to be together to make sense thus this one ticket:
a. Add a series of tracepoints in tor code base. I propose to start with circuit and cell level tracepoints for now.
b. Add USDT (User Statically-Defined Tracing) probes support which is used by SystemTap, DTrace and perf.
c. Add LTTng support which if enable also emits USDT.
d. Integrate all this to our build system.
About(d), the consensus among the network team is that it should NEVER be enabled in production and should be a configure switch.
I believe if we add on top a torrc option, it might not be that useful in the end considering the configure switch but mainly it will degrade performance since the check needs to be at runtime for every tracepoint.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32822Make authorities add their own IPv6 address to trusted dir servers2020-07-02T13:50:11ZteorMake authorities add their own IPv6 address to trusted dir serversAuthorities add themselves to trusted dir servers, but they don't add their own IPv6 addresses.Authorities add themselves to trusted dir servers, but they don't add their own IPv6 addresses.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32776Remove 0.2.9 from the jenkins builders2021-09-16T14:22:16ZteorRemove 0.2.9 from the jenkins buildersI don't know how to change jenkins configs, but I think we need to make a patch, then put it in the jenkins component?I don't know how to change jenkins configs, but I think we need to make a patch, then put it in the jenkins component?Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/32698Require client protocol versions based on 0.3.5.72020-10-22T15:48:27ZteorRequire client protocol versions based on 0.3.5.7Assuming legacy/trac#32696 is deployed between March and June 2020, we should make the 0.3.5.7 protocol versions required for clients some time in 2021.
See:
https://gitweb.torproject.org/torspec.git/tree/proposals/303-protover-removal-...Assuming legacy/trac#32696 is deployed between March and June 2020, we should make the 0.3.5.7 protocol versions required for clients some time in 2021.
See:
https://gitweb.torproject.org/torspec.git/tree/proposals/303-protover-removal-policy.txt#n49Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/32697Require supported relay protocol versions based on 0.3.5.72020-10-22T15:48:21ZteorRequire supported relay protocol versions based on 0.3.5.7Like legacy/trac#32696, we should make the 0.3.5.7 protocol versions required for relays some time between April and December 2020.
See:
https://gitweb.torproject.org/torspec.git/tree/proposals/303-protover-removal-policy.txt#n36Like legacy/trac#32696, we should make the 0.3.5.7 protocol versions required for relays some time between April and December 2020.
See:
https://gitweb.torproject.org/torspec.git/tree/proposals/303-protover-removal-policy.txt#n36Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/32661Document that we avoid changing src/ext2021-07-22T16:19:07ZteorDocument that we avoid changing src/extWe only change src/ext when necessary for integration with tor, or portability across platforms.
There was some confusion about this in legacy/trac#32626, so I'd like to update one or more of the following documents:
* src/mainpage.md
*...We only change src/ext when necessary for integration with tor, or portability across platforms.
There was some confusion about this in legacy/trac#32626, so I'd like to update one or more of the following documents:
* src/mainpage.md
* src/ext/README
* doc/HACKING/CodeStructure.md
We might also want to change our merge policy, but that's a longer process.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32349hs-v2: Intro point circuit TIMEOUT failure is not reported2021-06-23T17:23:06ZDavid Gouletdgoulet@torproject.orghs-v2: Intro point circuit TIMEOUT failure is not reportedThis was found while I was working on legacy/trac#32020.
For v2, we report a TIMEOUT circuit failure within `circuit_about_to_free()`. The following code is the snippet on how we check if the circuit timed out:
```
int reason = circ->m...This was found while I was working on legacy/trac#32020.
For v2, we report a TIMEOUT circuit failure within `circuit_about_to_free()`. The following code is the snippet on how we check if the circuit timed out:
```
int reason = circ->marked_for_close_reason;
int timed_out = (reason == END_CIRC_REASON_TIMEOUT);
```
However, in `circuit_mark_for_close_()`, if the circuit is an origin one, which is the case for all HS client circuit, the `marked_for_close_reason` is set to `END_CIRC_REASON_NONE` so we don't send back that reason back within the destroy cell.
The fix is that we should be looking at `marked_for_close_orig_reason` instead.
We need to backport this.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32193update .gitlab-ci.yml to remove broken cruft and add a complete test suite2021-02-05T21:03:36Zeighthaveupdate .gitlab-ci.yml to remove broken cruft and add a complete test suiteThis removes the old, broken cruft from the GitLab CI setup, and adds a whole range of new jobs. The most valuable is complete Android builds with NDK r17b and r20, then a limited test run in an Android emulator.
Since I was working on ...This removes the old, broken cruft from the GitLab CI setup, and adds a whole range of new jobs. The most valuable is complete Android builds with NDK r17b and r20, then a limited test run in an Android emulator.
Since I was working on ./configure, I added tests across the GNU/Linux distros. The jobs are added in order of value, so the commits on top could easily be omitted as needed.
This currently does not limit when these jobs runs, and it probably should. Most of the jobs are various GNU/Linux distros and releases, which should be the same for most things. For all those tests, I think they should probably be run only on the stable release branches, e.g.:
```
...
.test-template: &test-template
only:
- /^release-.*$/
script:
...
```
@hiro @catalyst pinging you since you did the previous edits on .gitlab-ci.yml.
The code is here:
https://github.com/torproject/tor/pull/1448Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32190Send a control port event when a stream enters the controller_wait state2020-08-03T12:37:50ZirlSend a control port event when a stream enters the controller_wait stateCurrently the only way to find out whether a stream was waiting for you to attach it is to try to attach it, and then if you get a 555 error back then you know it wasn't waiting for you.
The control protocol could be extended to let con...Currently the only way to find out whether a stream was waiting for you to attach it is to try to attach it, and then if you get a 555 error back then you know it wasn't waiting for you.
The control protocol could be extended to let controllers know when a stream is ready for the controller to attach it.Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/31913Add more robust Tor API documentation2020-10-22T15:35:51ZChelsea KomloAdd more robust Tor API documentationCurrently, Tor's API is not well-documented- adding more rich documentation (and ideally a separate how-to technical guide) would be helpful for external applications to learn how to embed tor.
For example, tor_control_socket_t needs...Currently, Tor's API is not well-documented- adding more rich documentation (and ideally a separate how-to technical guide) would be helpful for external applications to learn how to embed tor.
For example, tor_control_socket_t needs documentation. https://gitweb.torproject.org/tor.git/tree/src/feature/api/tor_api.h#n60
Furthermore, it isn't clear what are the tradeoffs between embedding Tor or running it as an executable: https://gitweb.torproject.org/tor.git/tree/src/feature/api/tor_api.h#n11
Also, it would be helpful to add additional documentation about how to interface with tor once it has been invoked (e.g, reading/writing from the control port via SOCKS). https://gitweb.torproject.org/tor.git/tree/src/feature/api/tor_api.h#n26Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31829Drop support for Python 22021-09-16T14:22:37ZNick MathewsonDrop support for Python 2Tor doesn't need Python to build, but several of our tests require Python to run.
Python 2 will reach end of life on Jan 1 2020 (see https://pythonclock.org/). Let's help it out by:
* Making our configure script only detect python 3...Tor doesn't need Python to build, but several of our tests require Python to run.
Python 2 will reach end of life on Jan 1 2020 (see https://pythonclock.org/). Let's help it out by:
* Making our configure script only detect python 3 as a usable python.
* Removing gross python2 workarounds from our scripts.Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/31565static Tor building against openssl-1.1.1 fails: configure unable to find lin...2020-07-29T13:10:29ZTracstatic Tor building against openssl-1.1.1 fails: configure unable to find linkable OpenSSLTrying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4...Trying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4.0.5 and 0.4.1.5. Building against openssl-1.0.2 works.
**Trac**:
**Username**: shredderTor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/30991Auto-tabify makefiles? complain about mistabbed makefiles?2020-10-22T15:51:44ZNick MathewsonAuto-tabify makefiles? complain about mistabbed makefiles?We have a bunch of lists in our makefile.am and include.am files where we intend to use tabs, but sometimes use spaces by mistake. We should have tooling to keep these consistent. We could either have check-local look for mis-tabbed fi...We have a bunch of lists in our makefile.am and include.am files where we intend to use tabs, but sometimes use spaces by mistake. We should have tooling to keep these consistent. We could either have check-local look for mis-tabbed files of this type, or have autostyle automatically fix them for us.Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/30797Stop shipping an abandoned systemd script?2021-09-16T14:23:38ZRoger DingledineStop shipping an abandoned systemd script?legacy/trac#19759, legacy/trac#19761, legacy/trac#19762 are bugs filed on the systemd script that we ship in "contrib/dist/tor.service.in".
The bugs haven't been looked at in years, and it looks like nobody on our side is paying attenti...legacy/trac#19759, legacy/trac#19761, legacy/trac#19762 are bugs filed on the systemd script that we ship in "contrib/dist/tor.service.in".
The bugs haven't been looked at in years, and it looks like nobody on our side is paying attention to this systemd script. That sounds to me like we would consider people foolish if they tried to use it.
Should we confirm that somebody, somewhere else on the internet, has a better systemd script than we do, and then remove ours?Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29546Update Maintaining.md after new merge policy is final2020-10-22T15:17:21ZteorUpdate Maintaining.md after new merge policy is finalWe should add a list of maintainers to the network team wiki.
We can work on drafts in this ticket.
Based on the table at:
https://trac.torproject.org/projects/tor/wiki/org/meetings/2019BrusselsNetworkTeam/Notes/StableMaintainer#ProposalsWe should add a list of maintainers to the network team wiki.
We can work on drafts in this ticket.
Based on the table at:
https://trac.torproject.org/projects/tor/wiki/org/meetings/2019BrusselsNetworkTeam/Notes/StableMaintainer#ProposalsTor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/25061Relays log a bootstrap warning if they can't extend for somebody else's circuit2020-10-20T10:28:37ZRoger DingledineRelays log a bootstrap warning if they can't extend for somebody else's circuitSay you have a relay that is up and listed as non-slow in the consensus. Due to the current overload (legacy/trac#24902), this relay is getting many many circuit requests per second. Due to bug legacy/trac#24767, we will make a huge numb...Say you have a relay that is up and listed as non-slow in the consensus. Due to the current overload (legacy/trac#24902), this relay is getting many many circuit requests per second. Due to bug legacy/trac#24767, we will make a huge number of connection attempts to other relays that are down, because as soon as we get a "connection refused", we will get another circuit request that triggers another connection attempt.
So when your relay restarts, since it's still in the consensus and clients still think it's usable, it will immediately get flooded with circuit requests, causing these connection attempts to resume.
And Tor calls every one of those connection attempts a bootstrapping attempt, even if there are no origin circuits related to that connection attempt.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewson