The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-09-16T14:31:39Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23579sched: Add accessors for channel_pending list2021-09-16T14:31:39ZDavid Gouletdgoulet@torproject.orgsched: Add accessors for channel_pending listLet's make this list private and have accessors.Let's make this list private and have accessors.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23459prop224: Specialize interface of hs_circuitmap_get_rend_circ_client_side()2021-09-16T14:31:39ZGeorge Kadianakisprop224: Specialize interface of hs_circuitmap_get_rend_circ_client_side()We currently use `hs_circuitmap_get_rend_circ_client_side()` for two reasons:
a) To proceed with the rend protocol as a client when we receive an intro ack (in `handle_introduce_ack_success()`).
b) To close useless rend circuits in `clos...We currently use `hs_circuitmap_get_rend_circ_client_side()` for two reasons:
a) To proceed with the rend protocol as a client when we receive an intro ack (in `handle_introduce_ack_success()`).
b) To close useless rend circuits in `close_or_reextend_intro_circ()`.
To fit these two scenarios, the function `hs_circuitmap_get_rend_circ_client_side()` currently returns all sorts of rend circs (established and unestablished).
We can improve the logic and semantics here by splitting into two funcs. One that returns only established circs (used for (a)), and another that retuns all kinds of circs (used for (b)).Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25432remove router.c internal functions from router.h2021-09-16T14:31:19ZTracremove router.c internal functions from router.hThese functions (group A):
```
A
const char *router_get_description(char *buf, const routerinfo_t *ri);
const char *node_get_description(char *buf, const node_t *node);
const char *routerstatus_get_description(char *buf, const routerstat...These functions (group A):
```
A
const char *router_get_description(char *buf, const routerinfo_t *ri);
const char *node_get_description(char *buf, const node_t *node);
const char *routerstatus_get_description(char *buf, const routerstatus_t *rs);
const char *extend_info_get_description(char *buf, const extend_info_t *ei);
```
Do the same as these (group B):
```
B
const char *router_describe(const routerinfo_t *ri);
const char *node_describe(const node_t *node);
const char *routerstatus_describe(const routerstatus_t *ri);
const char *extend_info_describe(const extend_info_t *ei);
```
With the difference that those last allocate a buffer, instead of forcing the caller to create and pass the buffer as a parameter.
The functions from group B are an abstraction to the ones from group A: they are better because they always generate buffers of enough size (the size is NODE_DESC_BUF_LEN). So, we should avoid using group A.
By now, both groups are declared in the header, and there is only one use of a function of group A (router_get_description is used on dirserv.c).
Also, all those functions are abstractions to format_node_description, that should also not be used externally, so we could also remove this one from the header.
The constant NODE_DESC_BUF_LEN is not necessary externally either.
**Trac**:
**Username**: valentecaioTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25290refactor to use should_record_bridge_info() more2021-09-16T14:31:19ZRoger Dingledinerefactor to use should_record_bridge_info() moreWe have this function
`should_record_bridge_info`
which simply checks
`options->BridgeRelay && options->BridgeRecordUsageByCountry`.
But in geoip_note_client_seen(), where we just added the DoS mitigation stuff, we don't use the functio...We have this function
`should_record_bridge_info`
which simply checks
`options->BridgeRelay && options->BridgeRecordUsageByCountry`.
But in geoip_note_client_seen(), where we just added the DoS mitigation stuff, we don't use the function, instead choosing to check the variables directly. We make the same choice in the options_need_geoip_info() function.
We should refactor things so we use the function in all cases.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25069Improve supported protocols unit test by exposing supported protocols in headers2021-09-16T14:31:19ZteorImprove supported protocols unit test by exposing supported protocols in headersCurrently, we hard-code a lot of supported protocols in the supported protocols unit test.
Instead, we should expose a list of supported protocols in each header, and check those. Or, we can expose a maximum supported protocol.
This al...Currently, we hard-code a lot of supported protocols in the supported protocols unit test.
Instead, we should expose a list of supported protocols in each header, and check those. Or, we can expose a maximum supported protocol.
This allows us to write unit tests like the LinkAuth tests.https://gitlab.torproject.org/tpo/core/tor/-/issues/24904Make geoip use channel_is_client so it ignores flapping relays2021-09-16T14:31:18ZteorMake geoip use channel_is_client so it ignores flapping relaysIn channel_do_open_actions(), we probably want to use channel_is_client() rather than connection_or_digest_is_known_relay().
```
/* only report it to the geoip module if it's not a known router */
if (!connection_or_digest_is_kn...In channel_do_open_actions(), we probably want to use channel_is_client() rather than connection_or_digest_is_known_relay().
```
/* only report it to the geoip module if it's not a known router */
if (!connection_or_digest_is_known_relay(chan->identity_digest)) {
if (channel_get_addr_if_possible(chan, &remote_addr)) {
```
Bugfix on legacy/trac#23533, 0.3.0.1-alpha.
We should make sure legacy/trac#24898 is fixed in any version we backport this to.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24732Remove unused IPv6 DirPort code2021-09-16T14:31:18ZteorRemove unused IPv6 DirPort codeIPv6 DirPorts aren't used by Tor: clients use IPv4/IPv6 ORPorts, and relays use IPv4 DirPorts (and IPv4 ORPorts).
There is code that implements this algorithm in commit 36ba50c820 of my bug23975_tree branch.IPv6 DirPorts aren't used by Tor: clients use IPv4/IPv6 ORPorts, and relays use IPv4 DirPorts (and IPv4 ORPorts).
There is code that implements this algorithm in commit 36ba50c820 of my bug23975_tree branch.https://gitlab.torproject.org/tpo/core/tor/-/issues/24714rename conn->timestamp_lastwritten to conn->timestamp_lastwritable2021-09-16T14:31:18ZRoger Dingledinerename conn->timestamp_lastwritten to conn->timestamp_lastwritable"lastwritten" sure sounds like we actually flushed something or we actually added a new thing to write.
But actually,
```
time_t timestamp_lastwritten; /**< When was the last time libevent said we
* co..."lastwritten" sure sounds like we actually flushed something or we actually added a new thing to write.
But actually,
```
time_t timestamp_lastwritten; /**< When was the last time libevent said we
* could write? */
```
It seems that we changed our definition of this word somewhere along the line, but we left the old word in place. How confusing.
We might want to change lastread to lastreadable too.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25839conn: Move connection bandwidth stuff into its own file2021-09-16T14:30:52ZDavid Gouletdgoulet@torproject.orgconn: Move connection bandwidth stuff into its own fileIn connection.c, we have the connection's bw management which means there are lots of functions only dealing with the `global_bucket` and per-connection rw bucket.
We could move all this to its own file like `connection_bw.c` to offload...In connection.c, we have the connection's bw management which means there are lots of functions only dealing with the `global_bucket` and per-connection rw bucket.
We could move all this to its own file like `connection_bw.c` to offload connection.c making it nicer, clearer and more modularized.https://gitlab.torproject.org/tpo/core/tor/-/issues/25786Policies for HTTPTunnelPort2021-09-16T14:30:52ZTracPolicies for HTTPTunnelPortFor SocksPort/Socks5Port one can configure SocksPolicy.
There should be corresponding option for HTTPTunnelPort.
**Trac**:
**Username**: pyhedgehogFor SocksPort/Socks5Port one can configure SocksPolicy.
There should be corresponding option for HTTPTunnelPort.
**Trac**:
**Username**: pyhedgehoghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27207Examples in CodingStandardsRust.md are wrong2021-09-16T14:29:03ZTracExamples in CodingStandardsRust.md are wrongThe section on `CString` is incorrect:
- `CString::new("bl\x00ah").unwrap().into_raw()` will panic in the 'unwrap' call, it will never return a pointer of any kind, dangling or otherwise.
Also, [12cf04646c571646b726e697d66ecafad7886cf2...The section on `CString` is incorrect:
- `CString::new("bl\x00ah").unwrap().into_raw()` will panic in the 'unwrap' call, it will never return a pointer of any kind, dangling or otherwise.
Also, [12cf04646c571646b726e697d66ecafad7886cf2](https://gitweb.torproject.org/tor.git/commit/doc/HACKING/CodingStandardsRust.md?id=12cf04646c571646b726e697d66ecafad7886cf2) seems to be the result of some miscommunication with [withoutboats](https://github.com/withoutboats):
- `.expect()` is [literally](https://doc.rust-lang.org/std/result/enum.Result.html#method.expect) '`.unwrap()`, but with a custom panic message,' it doesn't return an `Option` and is no safer than unwrap, but it is self-documenting.
**Trac**:
**Username**: cyberpunkshttps://gitlab.torproject.org/tpo/core/tor/-/issues/28779Remove double function declarations in circuitpadding.c/test_circuitpadding.c2021-09-16T14:27:19ZGeorge KadianakisRemove double function declarations in circuitpadding.c/test_circuitpadding.cWe can use the STATIC macro to avoid defining every function twice.
We can also rearrange the circuitpadding.c functions so that we don't need to define them on top of the .c file.We can use the STATIC macro to avoid defining every function twice.
We can also rearrange the circuitpadding.c functions so that we don't need to define them on top of the .c file.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29746Improve Tor best practices tracker2021-09-16T14:24:10ZGeorge KadianakisImprove Tor best practices trackerVarious improvements could be done to the best-practices tracker (practracker legacy/trac#29221). Here are a few from Nick's last review:
https://github.com/torproject/tor/pull/742#discussion_r262564420
https://github.com/torproject/tor...Various improvements could be done to the best-practices tracker (practracker legacy/trac#29221). Here are a few from Nick's last review:
https://github.com/torproject/tor/pull/742#discussion_r262564420
https://github.com/torproject/tor/pull/742#discussion_r262565153
~~https://github.com/torproject/tor/pull/742#discussion_r262566041~~
https://github.com/torproject/tor/pull/742#discussion_r262566501
https://github.com/torproject/tor/pull/742#discussion_r262567882
This could also be a fine starting volunteer project.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29232Write a function that prints a link specifier and link specifier list2021-09-16T14:24:10ZteorWrite a function that prints a link specifier and link specifier listWe want to print link specifiers for debugging, and log link specifiers, but we don't have an easy way to do that.We want to print link specifiers for debugging, and log link specifiers, but we don't have an easy way to do that.https://gitlab.torproject.org/tpo/core/tor/-/issues/29131Split rephist.c into modules for each type of statistic2021-09-16T14:24:09ZteorSplit rephist.c into modules for each type of statisticLet's split up rephist.c by statistic. We can also split out the stat-specific structs at the same time.
If we do this in 0.4.1, it will help us remove the bandwidth stats as part of our Sponsor V work.Let's split up rephist.c by statistic. We can also split out the stat-specific structs at the same time.
If we do this in 0.4.1, it will help us remove the bandwidth stats as part of our Sponsor V work.https://gitlab.torproject.org/tpo/core/tor/-/issues/31311practracker: do not include unwanted files in distribution2021-09-16T14:23:38ZNick Mathewsonpractracker: do not include unwanted files in distributionRight now, "make dist" grabs the entire contents of the practracker directory, including temporary files. That's not a great idea.Right now, "make dist" grabs the entire contents of the practracker directory, including temporary files. That's not a great idea.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31309Add envvar to pass options to practracker2021-09-16T14:23:38ZNick MathewsonAdd envvar to pass options to practrackerOn legacy/trac#30752, catalyst notes:
>The Makefile should provide a way to pass command line options in to practracker from the environment, so CI won't have to run practracker by bypassing the Makefile. This can be useful if we want to...On legacy/trac#30752, catalyst notes:
>The Makefile should provide a way to pass command line options in to practracker from the environment, so CI won't have to run practracker by bypassing the Makefile. This can be useful if we want to run with less-friendly options during cron builds, for example.
I agree.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31304Run practracker_tests.py as part of make check2021-09-16T14:23:38ZteorRun practracker_tests.py as part of make checkRunning these tests in CI will help avoid future bugs like:
The practracker_tests.py unit test file called a function by its old
name.
This change does not block legacy/trac#29746, but it should be done in 0.4.2.Running these tests in CI will help avoid future bugs like:
The practracker_tests.py unit test file called a function by its old
name.
This change does not block legacy/trac#29746, but it should be done in 0.4.2.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31263More tests for practracker2021-09-16T14:23:38ZNick MathewsonMore tests for practrackerI think some integration tests here would make things easier to hack on.I think some integration tests here would make things easier to hack on.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31202Refactor practracker's issue-listing code to return a generator2021-09-16T14:23:38ZNick MathewsonRefactor practracker's issue-listing code to return a generatorRight now, this issue-listing code exposes the problems with "print()". Instead, it should yield them as a generator, so that the invoking code can decide what to do with them.Right now, this issue-listing code exposes the problems with "print()". Instead, it should yield them as a generator, so that the invoking code can decide what to do with them.Tor: 0.4.2.x-finalNick MathewsonNick Mathewson