The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-11-24T16:42:03Zhttps://gitlab.torproject.org/tpo/ux/team/-/issues/48Compile user problems identified during user feedback collection done by Trai...2020-11-24T16:42:03ZPili GuerraCompile user problems identified during user feedback collection done by Training PartnersSponsor 9: October - December 2019NahNahhttps://gitlab.torproject.org/tpo/ux/team/-/issues/40translations for donate.tpo banner2019-11-23T19:01:57ZPili Guerratranslations for donate.tpo bannerYear End Campaign 2019emmapeelemmapeel2019-10-11https://gitlab.torproject.org/tpo/ux/media/-/issues/4Create image assets for about:tor2019-10-11T17:23:32ZPili GuerraCreate image assets for about:torYear End Campaign 2019Antonelaantonela@torproject.orgAntonelaantonela@torproject.org2019-09-27https://gitlab.torproject.org/tpo/web/community/-/issues/50[Content] Outreach Section: Add Tor Talk Topics2020-05-13T14:07:13ZPili Guerra[Content] Outreach Section: Add Tor Talk TopicsWe need to add a sub-section on Tor Talk Topics to the Outreach section of the community portal
* [ ] review the content (gus coordinate with isa)
* [ ] publish the content (gus)We need to add a sub-section on Tor Talk Topics to the Outreach section of the community portal
* [ ] review the content (gus coordinate with isa)
* [ ] publish the content (gus)Community Portal: Public LaunchGusGushttps://gitlab.torproject.org/tpo/ux/research/-/issues/9Research on information controls to extend our user personas to specific cens...2020-11-08T20:38:03ZGabagaba@torproject.orgResearch on information controls to extend our user personas to specific censored personasWork with OTF fellow and the anti-censorship team to gather interviews and information on specific censored personas.Work with OTF fellow and the anti-censorship team to gather interviews and information on specific censored personas.Sponsor 30 - Objective 3.1Antonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40061Rebuild fallbackdir list 20202020-07-23T14:11:07ZDavid Gouletdgoulet@torproject.orgRebuild fallbackdir list 2020We ran the call for action: fallback-scripts#30971
This ticket is to merge the new list in `fallback_dirs.inc`
This needs to be backported down to 035.We ran the call for action: fallback-scripts#30971
This ticket is to merge the new list in `fallback_dirs.inc`
This needs to be backported down to 035.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40059log: Double fmt_addr() use in the same logging results in same content2020-07-23T11:17:17ZDavid Gouletdgoulet@torproject.orglog: Double fmt_addr() use in the same logging results in same contentThe `log_info()` in `directory_choose_address_routerstatus()` uses two `fmt_addr()`.
Not good.The `log_info()` in `directory_choose_address_routerstatus()` uses two `fmt_addr()`.
Not good.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40058ipv6: check_descriptor_ipaddress_changed() should check for IPv6 changes2020-07-22T20:09:50ZDavid Gouletdgoulet@torproject.orgipv6: check_descriptor_ipaddress_changed() should check for IPv6 changesThat function is part of the `check_descriptor` callback run every minute.
It does _not_ look at IPv6.That function is part of the `check_descriptor` callback run every minute.
It does _not_ look at IPv6.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40056Audit use of `router_get_advertised_*()` functions to see if any callers shou...2020-07-21T17:33:02ZNick MathewsonAudit use of `router_get_advertised_*()` functions to see if any callers should look at descriptor insteadIn #40055 we'll solve the problem of the abovementioned functions having misleading names. But when we do so, we should also check to see whether any of their callers were expecting to find "the orport we advertise", rather than "the or...In #40055 we'll solve the problem of the abovementioned functions having misleading names. But when we do so, we should also check to see whether any of their callers were expecting to find "the orport we advertise", rather than "the orport we are configured to advertise.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40054prop 312: Don't publish IPv6 address if ORPort is IPv4Only2020-07-21T13:03:50ZDavid Gouletdgoulet@torproject.orgprop 312: Don't publish IPv6 address if ORPort is IPv4OnlyNow that tor#40025 is merged, I believe there is an issue for which we assume we'll find an ORPort if we have found an IPv6 address.
In `router_build_fresh_unsigned_routerinfo()`, we should check at the returned value of `router_get_adv...Now that tor#40025 is merged, I believe there is an issue for which we assume we'll find an ORPort if we have found an IPv6 address.
In `router_build_fresh_unsigned_routerinfo()`, we should check at the returned value of `router_get_advertised_or_port_by_af()` and not publish a port value of 0. It is possible for instance if the `ORPort` is `IPv4Only`.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40052S55: Make router_has_advertised_ipv6_orport() look at the descriptor2020-07-21T15:54:06ZNick MathewsonS55: Make router_has_advertised_ipv6_orport() look at the descriptorRight now, `router_has_advertised_ipv6_orport()` only looks at the configured advertised ports, and doesn't look at whether we have a published ORPort. That's not what we want it to do; we should look at the descriptor we're publishing,...Right now, `router_has_advertised_ipv6_orport()` only looks at the configured advertised ports, and doesn't look at whether we have a published ORPort. That's not what we want it to do; we should look at the descriptor we're publishing, I think.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40049CID 1465290: Passing null pointer "ipv4_addr" to "geoip_get_country_by_addr"2020-07-16T18:17:57ZDavid Gouletdgoulet@torproject.orgCID 1465290: Passing null pointer "ipv4_addr" to "geoip_get_country_by_addr"```
*** CID 1465290: Null pointer dereferences (FORWARD_NULL)
/src/feature/nodelist/nodelist.c: 1991 in node_set_country()
1985 /* XXXXipv6 */
1986 if (node->rs)
1987 ipv4_addr = &node->rs->ipv4_addr;
1988 els...```
*** CID 1465290: Null pointer dereferences (FORWARD_NULL)
/src/feature/nodelist/nodelist.c: 1991 in node_set_country()
1985 /* XXXXipv6 */
1986 if (node->rs)
1987 ipv4_addr = &node->rs->ipv4_addr;
1988 else if (node->ri)
1989 ipv4_addr = &node->ri->ipv4_addr;
1990
>>> CID 1465290: Null pointer dereferences (FORWARD_NULL)
>>> Passing null pointer "ipv4_addr" to "geoip_get_country_by_addr", which dereferences it.
1991 node->country = geoip_get_country_by_addr(ipv4_addr);
1992 }
1993
1994 /** Set the country code of all routers in the routerlist. */
1995 void
1996 nodelist_refresh_countries(void)
```Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40045node: format_node_description() interface is not standard2020-07-14T15:36:35ZDavid Gouletdgoulet@torproject.orgnode: format_node_description() interface is not standardFor some reasons, the IPv4 is passed _after_ the IPv6. We should change that so we have a standardize interface across all our APIs which is IPv4 first and then IPv6.For some reasons, the IPv4 is passed _after_ the IPv6. We should change that so we have a standardize interface across all our APIs which is IPv4 first and then IPv6.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40043relay: Stop using uint32_t addr for IPv4 and move to tor_addr_t2020-07-14T14:45:51ZDavid Gouletdgoulet@torproject.orgrelay: Stop using uint32_t addr for IPv4 and move to tor_addr_tThis is actually pretty big change. Originally, I planned to have it part of tor#40025 but it turns out quite a diff.
The goal is to stop using `uint32_t addr` to represent an IPv4 address and inste
ad standardize it onto `tor_addr_t` s...This is actually pretty big change. Originally, I planned to have it part of tor#40025 but it turns out quite a diff.
The goal is to stop using `uint32_t addr` to represent an IPv4 address and inste
ad standardize it onto `tor_addr_t` so the IPv4 and IPv6 interface are the same.
So many places in the code we convert from `ipv4{h|n}` to `tor_addr_t`, it is not pretty so this ticket is to move every use of those for relay objects (ri, rs, md, etc...).Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40040Document behavior of addr/address/real_addr fields2021-09-16T14:21:52ZNick MathewsonDocument behavior of addr/address/real_addr fieldsAs examined in #33898, the address-related fields on our `connection_t` objects are a big mess.
We came up with a plan there to make progress on the situation. The first step is to document how the fields are used and modified today, an...As examined in #33898, the address-related fields on our `connection_t` objects are a big mess.
We came up with a plan there to make progress on the situation. The first step is to document how the fields are used and modified today, and suggest alternatives to direct use and inspection of those fields.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40033Rename blacklist and whitelist to something without a harmful connotation2020-07-21T20:23:42ZDavid Gouletdgoulet@torproject.orgRename blacklist and whitelist to something without a harmful connotationThis is to remove from our codebase the obvious connotation that black is bad and white is good.
And please, lets keep etymology out of this discussion.This is to remove from our codebase the obvious connotation that black is bad and white is good.
And please, lets keep etymology out of this discussion.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40032Nonfatal assertion in `relay_new_address_suggestion()`2020-07-10T17:19:40ZNick MathewsonNonfatal assertion in `relay_new_address_suggestion()`Found with Chutney and travis
```
Warning: Bug: Tor 0.4.5.0-alpha-dev: Non-fatal assertion !(!server_mode(options)) failed in relay_address_new_suggestion at ../src/feature/relay/relay_find_addr.c:68. Stack trace: (on Tor 0.4.5.0-alpha-...Found with Chutney and travis
```
Warning: Bug: Tor 0.4.5.0-alpha-dev: Non-fatal assertion !(!server_mode(options)) failed in relay_address_new_suggestion at ../src/feature/relay/relay_find_addr.c:68. Stack trace: (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: tor(+0x76b19) [0x56419a3d7b19] (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: tor(+0xacc4c) [0x56419a40dc4c] (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: tor(channel_tls_handle_cell+0x18b) [0x56419a3e504b] (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: tor(connection_handle_read+0xa3d) [0x56419a3d282d] (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: tor(do_main_loop+0xfd) [0x56419a3d8d9d] (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: tor(log_backtrace_impl+0x56) [0x56419a585ae6] (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: tor(main+0x19) [0x56419a3c3249] (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: tor(_start+0x2a) [0x56419a3c329a] (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: tor(tor_bug_occurred_+0x16c) [0x56419a580c9c] (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: tor(tor_main+0x3a) [0x56419a3c36ba] (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: tor(tor_run_main+0x121d) [0x56419a3c60ed] (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x1e8f8) [0x7f391805a8f8] (on Tor 0.4.5.0-alpha-dev ) Number: 5
Warning: Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x53f) [0x7f391805b33f] (on Tor 0.4.5.0-alpha-dev ) Number: 5
```Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40025Prop 312: Make relay pick IPv4 or/and IPv6 resolved address in descriptor2020-07-21T12:04:11ZDavid Gouletdgoulet@torproject.orgProp 312: Make relay pick IPv4 or/and IPv6 resolved address in descriptorAt the moment, `router_pick_published_address()` is used to pick the address we'll put in a relay descriptor. It checks at the last resolved address, then attempts to locally find the address and finally attempts to look at what a direct...At the moment, `router_pick_published_address()` is used to pick the address we'll put in a relay descriptor. It checks at the last resolved address, then attempts to locally find the address and finally attempts to look at what a directory server suggested us.
With the work in tor#40022, we now discover our address with the `NETINFO` cell for both IPv4 and IPv6. We should use that.
Thus this ticket means that we need a new interface to query "what address should I use in my descriptor" so it is usable per address family and queries the right caches (that is not the directory guessed IP cache anymore).Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40022Prop 312: Relay learn address from NETINFO cell2020-07-14T18:17:12ZDavid Gouletdgoulet@torproject.orgProp 312: Relay learn address from NETINFO cellRelays do not currently use any address information from NETINFO cells.
We should try to learn our address for relays and possibly using `router_new_address_suggestion()` to do so.Relays do not currently use any address information from NETINFO cells.
We should try to learn our address for relays and possibly using `router_new_address_suggestion()` to do so.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33768Make tor_inet_pton() handle bad addresses consistently on Windows2020-07-09T17:42:27ZteorMake tor_inet_pton() handle bad addresses consistently on Windowstor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/p...tor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/pull/1831/commits/05f4f93722d46c0e8f1d09b4dea4bf5d1743d93f#diff-048243cd6d9ed36dda0944181d8ec8abR1729
Let's fix this bug and backport it.
In general, we should make all the functions in this file behave identically:
* zero any out parameters at the start of the function
* zero any out parameters on failureTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org