Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:49:11Zhttps://gitlab.torproject.org/legacy/trac/-/issues/17080Improve coverage on src/or/main.c (run_scheduled_events)2020-06-13T14:49:11ZTracImprove coverage on src/or/main.c (run_scheduled_events)The changes are in the branch "run-scheduled-events"
https://github.com/twstrike/tor_for_patching/tree/run-scheduled-events
**Trac**:
**Username**: rjuniorThe changes are in the branch "run-scheduled-events"
https://github.com/twstrike/tor_for_patching/tree/run-scheduled-events
**Trac**:
**Username**: rjuniorhttps://gitlab.torproject.org/legacy/trac/-/issues/17079Improve coverage on src/or/rendcache.c2020-06-13T14:49:10ZTracImprove coverage on src/or/rendcache.cThe changes are in the branch "rendcache_tests"
https://github.com/twstrike/tor_for_patching/tree/rendcache_tests
**Trac**:
**Username**: rjuniorThe changes are in the branch "rendcache_tests"
https://github.com/twstrike/tor_for_patching/tree/rendcache_tests
**Trac**:
**Username**: rjuniorTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17078Improve coverage on src/common/procmon.c2020-06-13T14:49:10ZTracImprove coverage on src/common/procmon.cThe changes are in the branch "procmon_tests"
https://github.com/twstrike/tor_for_patching/tree/procmon_tests
**Trac**:
**Username**: rjuniorThe changes are in the branch "procmon_tests"
https://github.com/twstrike/tor_for_patching/tree/procmon_tests
**Trac**:
**Username**: rjuniorTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17077Improve coverage on src/or/config.c (parse_port_config)2020-06-13T14:49:09ZTracImprove coverage on src/or/config.c (parse_port_config)The changes are in the branch "parse_port_config_tests"
https://github.com/twstrike/tor_for_patching/tree/parse_port_config_tests
**Trac**:
**Username**: rjuniorThe changes are in the branch "parse_port_config_tests"
https://github.com/twstrike/tor_for_patching/tree/parse_port_config_tests
**Trac**:
**Username**: rjuniorTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17075Improve coverage on common/compat_libevent.c2020-06-13T14:49:07ZTracImprove coverage on common/compat_libevent.cThe changes are in the branch "compat_libevent_tests"
https://github.com/twstrike/tor_for_patching/tree/compat_libevent_tests
**Trac**:
**Username**: rjuniorThe changes are in the branch "compat_libevent_tests"
https://github.com/twstrike/tor_for_patching/tree/compat_libevent_tests
**Trac**:
**Username**: rjuniorTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17074Improve coverage on src/common/address.c2020-06-13T14:49:07ZTracImprove coverage on src/common/address.cThe changes are in the branch "address_tests"
https://github.com/twstrike/tor_for_patching/tree/address_tests
**Trac**:
**Username**: rjuniorThe changes are in the branch "address_tests"
https://github.com/twstrike/tor_for_patching/tree/address_tests
**Trac**:
**Username**: rjuniorTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17060routerset_parse doesn't accept IPv6 addresses2020-06-13T14:49:03Zteorrouterset_parse doesn't accept IPv6 addresses`routerset_parse` accepts addresses containing '.' (literal IPv4) and '*' (wildcard, potentially IPv4 and/or IPv6). But it doesn't accept addresses containing ':' (literal IPv6).
This is a bugfix on 3ce6e2fba290 (Thu Jul 24 13:44:04 200...`routerset_parse` accepts addresses containing '.' (literal IPv4) and '*' (wildcard, potentially IPv4 and/or IPv6). But it doesn't accept addresses containing ':' (literal IPv6).
This is a bugfix on 3ce6e2fba290 (Thu Jul 24 13:44:04 2008) in 0.2.1.3-alpha, and similar code which added IPv6 address parsing capabilities to `tor_addr_parse_mask_ports`.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17026Set unused smartlist entries to zero2020-06-13T14:48:53ZSebastian HahnSet unused smartlist entries to zeroBranch forthcoming.Branch forthcoming.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17004Add tests for function directory_handle_command_get2020-06-13T14:48:50ZTracAdd tests for function directory_handle_command_getIncrease test coverage for the function `directory_handle_command_get `
All changes are in the following branch (https://github.com/twstrike/tor/tree/dir-handle-cmd-get)
**Trac**:
**Username**: rjuniorIncrease test coverage for the function `directory_handle_command_get `
All changes are in the following branch (https://github.com/twstrike/tor/tree/dir-handle-cmd-get)
**Trac**:
**Username**: rjuniorTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17003Improve test coverage on src/or/directory.c2020-06-13T14:48:50ZTracImprove test coverage on src/or/directory.cRelated branch on github (https://github.com/twstrike/tor/tree/directory-tests)
I believe it's related to #16805
**Trac**:
**Username**: rjuniorRelated branch on github (https://github.com/twstrike/tor/tree/directory-tests)
I believe it's related to #16805
**Trac**:
**Username**: rjuniorTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16698Split directory_handle_command_get into per-command functions2020-06-13T14:47:45ZNick MathewsonSplit directory_handle_command_get into per-command functionsTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16506Open subtickets tor improving test coverage in specific areas2020-06-13T14:47:12ZIsabela FernandesOpen subtickets tor improving test coverage in specific areasThis ticket is to track the work related on making sure we have test coverage to the most important pieces of core tor.
The task is to review the output of NickM's coverage script [0,1] and identify the modules that we should write test...This ticket is to track the work related on making sure we have test coverage to the most important pieces of core tor.
The task is to review the output of NickM's coverage script [0,1] and identify the modules that we should write tests for. For each one we identify we will create a sub-ticket to track the actual work of writing the tests for that module.
![0]!https://lists.torproject.org/pipermail/tor-dev/2015-July/009011.html
![1]!https://people.torproject.org/~nickm/volatile/coverage-65a1e27.tar.bz2Tor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16382man page has misleading info about the min bw rate2020-06-13T14:46:57ZNima Fatemiman page has misleading info about the min bw rate```
GENERAL OPTIONS
BandwidthRate N bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits
A token bucket limits the average incoming bandwidth usage on this node to the
specified number of bytes per second, and the av...```
GENERAL OPTIONS
BandwidthRate N bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits
A token bucket limits the average incoming bandwidth usage on this node to the
specified number of bytes per second, and the average outgoing bandwidth usage to that
same value. If you want to run a relay in the public network, this needs to be at the
very least 30 KBytes (that is, 30720 bytes). (Default: 1 GByte)
```
The number has been lifted to 250KBytes in our [online documentation](https://www.torproject.org/docs/tor-relay-debian) and this one should probably get fixed too. Anything below 250KBytes (each direction) is probably hurting the network.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16035Implement proposal 244: RFC5705 for exporting key material in tls handshake2020-06-13T14:46:12ZNick MathewsonImplement proposal 244: RFC5705 for exporting key material in tls handshakeFrom the proposal:
{{{ We use AUTHENTICATE cells to bind the connection-initiator's Tor
identity to a TLS session. Our current type of authentication
("RSA-SHA256-TLSSecret", see tor-spec.txt section 4.4) does this by
signing a d...From the proposal:
{{{ We use AUTHENTICATE cells to bind the connection-initiator's Tor
identity to a TLS session. Our current type of authentication
("RSA-SHA256-TLSSecret", see tor-spec.txt section 4.4) does this by
signing a document that includes an HMAC of client_random and
server_random, using the TLS master secret as a secret key.
There is a more standard way to get at this information, by using the
facility defined in RFC5705. Further, it is likely to continue to.
work with more TLS libraries, including TLS libraries like OpenSSL 1.1
that make master secrets and session data opaque.
}}}
This is easy, and easily done as part of #15055Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15228Identify candidates for FallbackDir, and ship with a list of them2020-06-13T14:45:50ZNick MathewsonIdentify candidates for FallbackDir, and ship with a list of themBack long ago, we added a feature to allow torrc to list a bunch of FallbackDir entries. These tell a client where to look for consensus directory documents, so that the clients don't just load the authorities down.
It would be good if...Back long ago, we added a feature to allow torrc to list a bunch of FallbackDir entries. These tell a client where to look for consensus directory documents, so that the clients don't just load the authorities down.
It would be good if we shipped with such a list.
One idea has been to identify directories that have:
* a stable IP:Port over a long time,
* reasonably good uptime (as a fraction)
* good bandwidth
* a contact address.
Then, contact the admins of these directory caches and ask them for permission to put them on a list.
(See also #8374)Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/15849Make relay be directory server without a DirPort2020-06-13T14:45:42ZDavid Gouletdgoulet@torproject.orgMake relay be directory server without a DirPortChild ticket of #15801.
In `directory_permits_begindir_requests()`, a relay doesn't accept `BEGIN_DIR` cell if the DirPort isn't set.
```
int
directory_permits_begindir_requests(const or_options_t *options)
{
return options->BridgeRe...Child ticket of #15801.
In `directory_permits_begindir_requests()`, a relay doesn't accept `BEGIN_DIR` cell if the DirPort isn't set.
```
int
directory_permits_begindir_requests(const or_options_t *options)
{
return options->BridgeRelay != 0 || options->DirPort_set;
}
```
Fixing this would make every relay being able to answer directory requests without a DirPort. Turns out, it's a part of proposal 237 so we should make those two happens and incidently helping with the global issue in the parent ticket.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15087Move timeliness check out of tor_cert_checksig, or into tor_cert_get_checkabl...2020-06-13T14:43:55ZNick MathewsonMove timeliness check out of tor_cert_checksig, or into tor_cert_get_checkable_sigThere's a mismatch in our certificate API: When we're doing single verification, we check the expiration time, but when we are doing batch verification, we rely on the caller to do so. We should make these functions do the same thing.There's a mismatch in our certificate API: When we're doing single verification, we check the expiration time, but when we are doing batch verification, we rely on the caller to do so. We should make these functions do the same thing.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/14683Document medium-scale design of key Tor abstractions2020-06-13T14:42:27ZNick MathewsonDocument medium-scale design of key Tor abstractionsIn between the specs and the doxygen documentation, there isn't much to explain _why_ our subsystems work that way, how they fit together, and so on.
Some areas we should really elaborate are:
* circuits
* cmux
* circuitpathbias
...In between the specs and the doxygen documentation, there isn't much to explain _why_ our subsystems work that way, how they fit together, and so on.
Some areas we should really elaborate are:
* circuits
* cmux
* circuitpathbias
* entrynodes
* channels
* the main event loop/connection abstraction
We should probably try to make it a practice to _always_ document new things, and to fill in documentation for older things as we can. Whatever has changed most recently is probably going to be freshest on our minds, so let's start there.
I'm putting this in 0.2.??? as non-blocker, but we should try to get more stuff documented whenever the opportunity exists.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/14165Tor needs a protocol versioning scheme2020-06-13T14:41:42ZTvdWTor needs a protocol versioning schemeTo support alternate OR implementations, it would be nice if it wasn't required for relays to announce themselves as "Tor <version> on <os>". The current dir-spec.txt mentions :
```
The version of the Tor protocol that this rela...To support alternate OR implementations, it would be nice if it wasn't required for relays to announce themselves as "Tor <version> on <os>". The current dir-spec.txt mentions :
```
The version of the Tor protocol that this relay is running. If
the value begins with "Tor" SP, the rest of the string is a Tor
version number, and the protocol is "The Tor protocol as supported
by the given version of Tor." Otherwise, if the value begins with
some other string, Tor has upgraded to a more sophisticated
protocol versioning system, and the protocol is "a version of the
Tor protocol more recent than any we recognize."
```
This means that any implementation not listing "Tor .*" is required to implement the entire spec plus any feature that may ever be in the spec. Until we invent time travel this will be difficult to achieve.
The alternative is that any alternate Tor implementation needs to announce itself as "Tor".
Suggestions mentioned in #tor-dev :
* Numerical protocol versions. Basically what we have now but without the "Tor" prefix, and published separately in the consensus. They're nice and compact but require all alternative implementations to implement the exact same set of features. Also doesn't deal with forward compatibility well if features are dropped in newer versions.
* Capability lists. arma mentioned that this is already there as a hack (V2Dir flag, for example). It also takes a lot of space in the consensus, and they may grow a lot over time.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/13989Freak out if we pick too many new guards in too short a time2020-06-13T14:41:13ZNick MathewsonFreak out if we pick too many new guards in too short a timeAccording to the sniper attack paper, we should never really have to pick more than 5 new guards in a 4 week period (I think that's the number). If we do, our network is probably down or filtered or our guards are under attack.
This is...According to the sniper attack paper, we should never really have to pick more than 5 new guards in a 4 week period (I think that's the number). If we do, our network is probably down or filtered or our guards are under attack.
This is going to have some tricky issues. For example, what should we do if we hit this threshold? We could decline to pick circuits until some node we've been willing to use as a guard comes up again, unless the user explicitly tells us to, I guess.
As another issue, we don't currently store exactly when we added a guard, but a randomized version of that. So perhaps we need a fuzzier version of this test.Tor: unspecified