The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:24:15Zhttps://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/18354flush cached host_name on IP change2020-06-27T14:24:15Zcypherpunksflush cached host_name on IP changedescription (somehow) implies that the host_name field is reset on IP change:
```
Host name as found in a reverse DNS lookup of the relay IP address. This field is updated at most once in 12 hours, unless the relay IP address changes. Om...description (somehow) implies that the host_name field is reset on IP change:
```
Host name as found in a reverse DNS lookup of the relay IP address. This field is updated at most once in 12 hours, unless the relay IP address changes. Omitted if the relay IP address was not looked up or if no lookup request was successful yet.
```
this would make sense but that does not seem to be the case:
```
+-----------------+-----------------+
| IP | host_name |
+-----------------+-----------------+
| 162.218.239.125 | 162.218.233.43 |
| 160.166.216.122 | 160.163.106.82 |
| 198.96.94.98 | 155.94.246.179 |
| 198.96.94.122 | 155.94.246.178 |
| 197.242.119.107 | 154.118.35.110 |
| 151.20.142.35 | 151.64.24.192 |
| 151.45.92.96 | 151.45.211.193 |
| 178.33.156.144 | 149.202.233.205 |
| 129.21.101.45 | 129.21.102.240 |
| 117.254.79.156 | 117.252.95.186 |
| 104.192.0.18 | 104.192.0.22 |
| 103.44.149.45 | 103.44.149.43 |
```
Additionally:
I would suggest to omit the host_name record if IP == host_name (saves space).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18353Let’s Encrypt Tor Browser 5.5.22020-06-27T14:39:33ZTracLet’s Encrypt Tor Browser 5.5.2Why is Let’s Encrypt not trusted?
**Trac**:
**Username**: HoeChiMeowWhy is Let’s Encrypt not trusted?
**Trac**:
**Username**: HoeChiMeowhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18351Relay directory failures and logging are too aggressive2020-06-27T13:59:34ZMatthew FinkelRelay directory failures and logging are too aggressiveAs mentioned in legacy/trac#18348, when a relay exhausts the available directory authorities, it now produces the below warning. It seems there are three points to consider when taken in the context of a relay:
1) The actual log message ...As mentioned in legacy/trac#18348, when a relay exhausts the available directory authorities, it now produces the below warning. It seems there are three points to consider when taken in the context of a relay:
1) The actual log message is not correct, this completely unrelated to the firewall/reachability logic
2) I'm not certain, but I believe this is likely a normal situation on the network
3) Logging this at warn seems overly aggressive for something a user can't control
1) and 2) are actually the same point. See the attached debug log extract (including some additional messages I added). Nearly all the dir auths are marked as down due to 304 responses. Should tor be less aggressive about avoiding a directory authority after a 304? I worry, if this is normal behavior, then the network's load is not be distributed among all the directories. It seems like they're being picked off, one-by-one. Especially when this is in the logs - unless I'm reading it wrong they're identical requests despite the first one succeeding (possibly another bug?):
```
--
Feb 20 05:26:37.000 [info] directory_send_command: Downloading consensus from 128.31.0.39:9131 using /tor/status-vote/current/consensus-microdesc/0232AF+14C131+23D15D+49015F+805509+D586D1+E8A9C4+ED03BB+EFCBE7.z
Feb 20 05:26:39.000 [debug] connection_dir_client_reached_eof: Received response from directory server '128.31.0.39:9131': 200 "OK" (purpose: 14)
--
Feb 20 05:27:37.000 [info] directory_send_command: Downloading consensus from 131.188.40.189 using /tor/status-vote/current/consensus-microdesc/0232AF+14C131+23D15D+49015F+805509+D586D1+E8A9C4+ED03BB+EFCBE7.z
Feb 20 05:27:38.000 [debug] connection_dir_client_reached_eof: Received response from directory server '131.188.40.189:80': 304 "Not modified" (purpose: 14)
Feb 20 05:29:37.000 [info] directory_send_command: Downloading consensus from 199.254.238.52 using /tor/status-vote/current/consensus-microdesc/0232AF+14C131+23D15D+49015F+805509+D586D1+E8A9C4+ED03BB+EFCBE7.z
Feb 20 05:29:41.000 [debug] connection_dir_client_reached_eof: Received response from directory server '199.254.238.52:80': 304 "Not modified" (purpose: 14)
```
In the attached log, router_set_status() records when a node is marked down. The preceeding lines should say why. router_pick_trusteddirserver_impl() records which nodes we disqualified when we want to send a new request.
Scary backtrace:
```
[warn] router_picked_poor_directory_log: Bug: Firewall denied all OR and Dir addresses for all relays when searching for a directory. (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: Node search initiated by. Stack trace: (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x1157e08 <log_backtrace+0x48> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x10af86b <hid_serv_responsible_for_desc_id+0xdeb> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x10a6a86 <router_pick_trusteddirserver+0x76> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x1126183 <directory_get_from_dirserver+0x293> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x10ad45a <launch_descriptor_downloads+0x4ba> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x10ad21a <launch_descriptor_downloads+0x27a> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x10adb6b <update_consensus_router_descriptor_downloads+0x6cb> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x10ac7f6 <update_all_descriptor_downloads+0x66> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x10602c8 <directory_info_has_arrived+0x48> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x1128890 <connection_dir_reached_eof+0x1160> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x1107f5b <connection_handle_read+0xb3b> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x105f044 <connection_add_impl+0x214> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x801aa538e <event_base_loop+0x81e> at /usr/local/lib/libevent-2.0.so.5 (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x1060cc5 <do_main_loop+0x5c5> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x1062fcf <tor_main+0xdf> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x105ed49 <main+0x19> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
[warn] Bug: 0x105ec41 <_start+0x1a1> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/18350Directory Authorities bind DirPort to IPv62020-06-27T14:11:31ZteorDirectory Authorities bind DirPort to IPv6We should encourage directory authorities on IPv6 - gabelmoo, tor26, and longclaw - to bind their existing DirPort to IPv6 as well as IPv4.
maatuska does this already.
From legacy/trac#18348:
Currently most of the dir auths Dir port...We should encourage directory authorities on IPv6 - gabelmoo, tor26, and longclaw - to bind their existing DirPort to IPv6 as well as IPv4.
maatuska does this already.
From legacy/trac#18348:
Currently most of the dir auths Dir ports are only listening on their ipv4 address, including the dir auths with ipv6 OR addresses. An easy (but not necessary correct) solution is Dir Auth Op configure their dirauths so they accept ipv6 connections on the dir port. A better solution is tor knows when a dir port is ipv4 or ipv6 and chooses the correct corresponding ip address.https://gitlab.torproject.org/tpo/tpa/team/-/issues/18349Please give legind push access to the HTTPS Everywhere git repo.2020-06-27T14:19:33ZWilliam BudingtonPlease give legind push access to the HTTPS Everywhere git repo.Hello, I'm Bill Budington. I am an HTTPS Everywhere maintainer. Please set me up with git push access.
Here's my SSH key:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCqhgrUKHjqcc5mobb1JwVLeXZ+KtIBuzM8f9nxaq7kQsdcLtPQyIJdd/Uab+41GJxWq5a7LQn8M...Hello, I'm Bill Budington. I am an HTTPS Everywhere maintainer. Please set me up with git push access.
Here's my SSH key:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCqhgrUKHjqcc5mobb1JwVLeXZ+KtIBuzM8f9nxaq7kQsdcLtPQyIJdd/Uab+41GJxWq5a7LQn8McK5AvZkVffO0HuFixw3RG99SgZH34yzAiayNH/HJi1f2OZRR3aHF808yvLplV3xOXgQynR1OTc76BNNqektS4ZpyWPITFjBBLbLloDR50ZFs6sNdOLPYF4j7i5kyfQTz5XiFX1QQrUwdxkqZeOKBryloIwL5USAcP6mDjrap1LaZRU1jtRnQd8evaDJfpeZDkE94SM8CXFPjEgNePnqvwwaKPucvDr6ML5m3ftVSEZwwTsRlo/2tA2k6cmj3HJZLEEP+DNfiTUX legind@X1
(clearsigned copy attached)https://gitlab.torproject.org/tpo/core/tor/-/issues/18348Tor conflates IPv4 Dir port with IPv6 OR Port2020-06-27T13:59:34ZMatthew FinkelTor conflates IPv4 Dir port with IPv6 OR PortSince legacy/trac#17840 tor prefers IPv6 addresses for client connections when they're available. This is a significant improvement but is not always correct in the network as it is now. Unfortunately, this affects a relays dirconns, too...Since legacy/trac#17840 tor prefers IPv6 addresses for client connections when they're available. This is a significant improvement but is not always correct in the network as it is now. Unfortunately, this affects a relays dirconns, too. The primary problem arises when a relay attempt a descriptor upload/fetch with a directory authority with an IPv6 OR port.
Currently all configuration options allow configuring IPv6 OR ports, but none specify dir ports. When a client attempts a dir port connection, it implicitly assumes the dir port is listening on the same ip address as the OR port.
Currently most of the dir auths Dir ports are only listening on their ipv4 address, including the dir auths with ipv6 OR addresses. An easy (but not necessary correct) solution is Dir Auth Op configure their dirauths so they accept ipv6 connections on the dir port. A better solution is tor knows when a dir port is ipv4 or ipv6 and chooses the correct corresponding ip address.
Now, as a relay, in fascist_firewall_allows_dir_server() we choose the destination's ipv4 address. However, when we subsequently call directory_choose_address_routerstatus() we don't remember which address we prefer:
```
} else {
/* We use an IPv6 address if we have one and we prefer it.
* Use the preferred address and port if they are reachable, otherwise,
* use the alternate address and port (if any).
*/
have_or = fascist_firewall_choose_address_rs(status,
FIREWALL_OR_CONNECTION, 0,
use_or_ap);
}
have_dir = fascist_firewall_choose_address_rs(status,
FIREWALL_DIR_CONNECTION, 0,
use_dir_ap);
```
Therefore directory_initiate_command_rend() uses the ipv6 address by default.
As an example (with additional debug messages):
```
Feb 19 16:57:33.000 [info] router_upload_dir_desc_to_dirservers: Uploading relay descriptor to directory authorities
Feb 19 16:57:33.000 [info] directory_post_to_dirservers: Uploading an extrainfo too (length 980)
Feb 19 16:57:33.000 [debug] directory_initiate_command_rend: anonymized 0, use_begindir 0.
Feb 19 16:57:33.000 [debug] directory_initiate_command_rend: Initiating server descriptor upload
Feb 19 16:57:33.000 [debug] connection_connect: Connecting to [scrubbed]:9131.
Feb 19 16:57:33.000 [debug] connection_connect_sockaddr: Connection to socket in progress (sock 32).
Feb 19 16:57:33.000 [debug] connection_add_impl: new conn type Directory, socket 32, address 128.31.0.39, n_conns 36.
Feb 19 16:57:33.000 [info] directory_post_to_dirservers: Uploading an extrainfo too (length 980)
Feb 19 16:57:33.000 [debug] directory_initiate_command_rend: anonymized 0, use_begindir 0.
Feb 19 16:57:33.000 [debug] directory_initiate_command_rend: Initiating server descriptor upload
Feb 19 16:57:33.000 [debug] connection_connect: Connecting to [scrubbed]:80.
Feb 19 16:57:33.000 [debug] connection_connect_sockaddr: Connection to socket in progress (sock 33).
Feb 19 16:57:33.000 [debug] connection_add_impl: new conn type Directory, socket 33, address 2001:858:2:2:aabb:0:563b:1526, n_conns 37.
...
Feb 19 16:57:33.000 [debug] conn_read_callback: socket 33 wants to read.
Feb 19 16:57:33.000 [debug] connection_handle_read_impl: Closing conn after error: Connection refused (61)
Feb 19 16:57:33.000 [info] connection_close_immediate: fd 33, type Directory, state connecting, 3298 bytes on outbuf.
Feb 19 16:57:33.000 [debug] conn_close_if_marked: Cleaning up connection (fd -1).
Feb 19 16:57:33.000 [info] connection_dir_request_failed: Setting dir 2001:858:2:2:aabb:0:563b:1526 as down after failed request.
Feb 19 16:57:33.000 [debug] router_set_status: Setting 86.59.21.38 as running: 0
Feb 19 16:57:33.000 [debug] router_set_status: Marking router $847B1F850344D7876491A54892F904934E4EB85D~tor26 at 86.59.21.38 as down.
Feb 19 16:57:33.000 [debug] connection_remove: removing socket -1 (type Directory), n_conns now 47
```
(this issue is only in master, not in any released version)
To make matters worse (and the reason I found this), eventually after most of the ipv6-enabled dir auths are marked as down due to the connection being refused, relays later get this scary thing:
```
Feb 19 09:26:53.000 [warn] router_picked_poor_directory_log: Bug: Firewall denied all OR and Dir addresses for all relays when searching for a directo
ry. (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: Node search initiated by. Stack trace: (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1157ff8 <log_backtrace+0x48> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10af99c <hid_serv_responsible_for_desc_id+0xebc> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10a6ae6 <router_pick_trusteddirserver+0x76> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1126333 <directory_get_from_dirserver+0x293> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10ad4ba <launch_descriptor_downloads+0x4ba> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10ad27a <launch_descriptor_downloads+0x27a> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10adbcb <update_consensus_router_descriptor_downloads+0x6cb> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10ac856 <update_all_descriptor_downloads+0x66> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10602c8 <directory_info_has_arrived+0x48> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1128a40 <connection_dir_reached_eof+0x1160> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x110810b <connection_handle_read+0xb3b> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x105f044 <connection_add_impl+0x214> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x801aa538e <event_base_loop+0x81e> at /usr/local/lib/libevent-2.0.so.5 (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1060cc5 <do_main_loop+0x5c5> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1062fcf <tor_main+0xdf> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x105ed49 <main+0x19> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x105ec41 <_start+0x1a1> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
```
Because we already asked the useful dir auths for descriptors and those requests are still outstanding, so we don't have any viable directories remaining. (Ignore the mention of hid_serv_responsible_for_desc_id+0xbfb, it is actually router_pick_trusteddirserver_impl()).Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18346Separate the various roles that directory authorities play, from a configurat...2022-10-11T23:40:17ZNick MathewsonSeparate the various roles that directory authorities play, from a configuration POVIt would be handy if the following roles were split up:
1) The list of IP:Orport:Identity to which every relay should upload every descriptor.
2) The list of IP:Orport:Identity from which caches should expect to find canonical conse...It would be handy if the following roles were split up:
1) The list of IP:Orport:Identity to which every relay should upload every descriptor.
2) The list of IP:Orport:Identity from which caches should expect to find canonical consensuses and descriptors.
3) The list of IP:Orport:Identity from which non-caches should expect to bootstrap consensuses and descriptors. (See 'fallbackdir')
4) The list of keys that must sign a vote or a consensus.
5) The list of IP:Orport:Identity that authorities use when sending and receiving votes.
Splitting roles up in this way would better prepare us for an implementation of prop#257 down the road.Tor: 0.4.7.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18345Fix all doxygen "X is not documented" warnings2021-07-22T16:23:43ZteorFix all doxygen "X is not documented" warningsQuoting arma:
It occurred to me while looking at the doxygen comment for
router_is_already_dir_fetching_ds() that if we had something go through
and complain about all cases where there's a function argument that is
not mentione...Quoting arma:
It occurred to me while looking at the doxygen comment for
router_is_already_dir_fetching_ds() that if we had something go through
and complain about all cases where there's a function argument that is
not mentioned by `<b>parameter</b>` (with the markup) in the doxygen
comment... we would end up with a lot of complaints.
We could fix this by placing `<b></b>` around documented parameters, and by documented undocumented parameters.
There might even be a way to semi-automatically do this using a script, and then clean up any mismatches.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/community/l10n/-/issues/18344Broken languages for HTTPSE in Transifex2020-06-27T13:45:07ZTracBroken languages for HTTPSE in TransifexThe following languages are checked into the translation repo for HTTPS Everywhere but contain only blank strings, this causes the build script for HTTPS Everywhere for chrome to fail. I would recommend that these languages be removed, o...The following languages are checked into the translation repo for HTTPS Everywhere but contain only blank strings, this causes the build script for HTTPS Everywhere for chrome to fail. I would recommend that these languages be removed, or better yet, fixed:
ms
sv_SE
ca@valencia
**Trac**:
**Username**: cooperqColin ChildsColin Childshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18343Implement a panopticlick-like anti-fingerprinting built-in self-test for the ...2022-06-17T21:44:47ZcypherpunksImplement a panopticlick-like anti-fingerprinting built-in self-test for the browserThere should be a test a user should be able to call securely to make sure his browser is indistinguishable rest of from TBBs.There should be a test a user should be able to call securely to make sure his browser is indistinguishable rest of from TBBs.https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/18342Provide more accurate reverse DNS results2020-06-27T14:24:15ZcypherpunksProvide more accurate reverse DNS resultsWhat DNS server does onionoo use for reverse DNS lookups to generate the host_name entries?
https://onionoo.torproject.org/details?search=SGGS
example, of onionoo's reverse lookup results for SG.GS relays, all IPs:
```
+----------+----...What DNS server does onionoo use for reverse DNS lookups to generate the host_name entries?
https://onionoo.torproject.org/details?search=SGGS
example, of onionoo's reverse lookup results for SG.GS relays, all IPs:
```
+----------+--------------+
| nickname | host_name |
+----------+--------------+
| SGGSUK4 | 124.6.36.196 |
| SGGSHK0 | 124.6.32.230 |
| SGGSUK6 | 124.6.36.198 |
| SGGSUK0 | 124.6.36.230 |
| SGGSUK3 | 124.6.36.195 |
| SGGSUK7 | 124.6.36.199 |
| SGGSUK1 | 124.6.36.193 |
| SGGSUK8 | 124.6.36.200 |
| SGGSUK5 | 124.6.36.197 |
| SGGSUK2 | 124.6.36.194 |
| SGGSLAX0 | 124.6.40.230 |
| SGGSNYC0 | 124.6.44.230 |
| SGGSUK9 | 124.6.36.201 |
+----------+--------------+
```
compare that with
http://torstatus.blutmagie.de/index.phpOnionoo 1.15.0irlirlhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/18341Chutney won't run because some print() statements are borken2020-06-27T13:18:58ZIsis LovecruftChutney won't run because some print() statements are borken```
The above is a description of an error in a Python program. Here is
the original traceback:
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pk...```
The above is a description of an error in a Python program. Here is
the original traceback:
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/home/isis/code/torproject/chutney/lib/chutney/TorNet.py", line 1180, in <module>
sys.exit(main())
File "/home/isis/code/torproject/chutney/lib/chutney/TorNet.py", line 1174, in main
result = runConfigFile(args['action'], f)
File "/home/isis/code/torproject/chutney/lib/chutney/TorNet.py", line 1151, in runConfigFile
return getattr(network, verb)()
File "/home/isis/code/torproject/chutney/lib/chutney/TorNet.py", line 841, in configure
b.preConfig(network)
File "/home/isis/code/torproject/chutney/lib/chutney/TorNet.py", line 320, in preConfig
self._genAuthorityKey()
File "/home/isis/code/torproject/chutney/lib/chutney/TorNet.py", line 387, in _genAuthorityKey
"path, or put the binary into $PATH.") % tor_gencert
TypeError: unsupported operand type(s) for %: 'NoneType' and 'str'
```
Umm… the `%` operator goes _inside_ the `print()` function call. Otherwise, you're attempting to do a format string operation on the return value of the `print()` function (which is `None`).Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40947Make sure the controller password used in Torbutton is conforming to the spec2022-07-09T21:26:16ZGeorg KoppenMake sure the controller password used in Torbutton is conforming to the spec```
var auth_cmd = "AUTHENTICATE "+m_tb_control_pass+"\r\n";
```
is basically just taking `m_tb_control_pass` and passing it along to tor. We should do some checks that it is actually conforming to the spec (it must be comprised of `HEXI...```
var auth_cmd = "AUTHENTICATE "+m_tb_control_pass+"\r\n";
```
is basically just taking `m_tb_control_pass` and passing it along to tor. We should do some checks that it is actually conforming to the spec (it must be comprised of `HEXIDIGIT`s or be a `QuotedString`).Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/core/tor/-/issues/18339Tor master is broken with mingw-w642020-06-27T13:59:34ZGeorg KoppenTor master is broken with mingw-w64It seems tor master is broken if one is using mingw-w64 for cross-compilation:
https://jenkins.torproject.org/job/tor-ci-mingwcross/791/.
We've hit that with our nightly build setup, too:
```
../src/common/util.c: In function 'check_pr...It seems tor master is broken if one is using mingw-w64 for cross-compilation:
https://jenkins.torproject.org/job/tor-ci-mingwcross/791/.
We've hit that with our nightly build setup, too:
```
../src/common/util.c: In function 'check_private_dir':
../src/common/util.c:2085:45: error: 'O_NOFOLLOW' undeclared (first use in this function)
fd = open(sandbox_intern_string(dirname), O_NOFOLLOW);
^
../src/common/util.c:2085:45: note: each undeclared identifier is reported only once for each function it appears in
CC src/ext/csiphash.o
CC src/common/compat_winthreads.o
CC src/common/aes.o
CC src/common/crypto.o
make[1]: *** [src/common/util.o] Error 1
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/18338Make a tor-browser-spec repo for gk2020-06-27T14:19:34ZGeorg KoppenMake a tor-browser-spec repo for gkCould you please make: `/user/gk/tor-browser-spec.git`
with description: `Georg's tor-browser-spec repo`
and write access to me (read access for anybody)?
Thanks!Could you please make: `/user/gk/tor-browser-spec.git`
with description: `Georg's tor-browser-spec repo`
and write access to me (read access for anybody)?
Thanks!https://gitlab.torproject.org/tpo/core/tor/-/issues/18337Remove network dependencies from unit tests2020-06-27T13:59:34ZteorRemove network dependencies from unit testsSome of the new unit tests in 0.2.8 (legacy/trac#17076) seem to be using the resolver on non-existent addresses. This causes them to be slow when the network is up, but fast when it's down (at least on my OS X box).
mikeperry has also c...Some of the new unit tests in 0.2.8 (legacy/trac#17076) seem to be using the resolver on non-existent addresses. This causes them to be slow when the network is up, but fast when it's down (at least on my OS X box).
mikeperry has also complained that they're slow on IRC.
We could mock the address resolution functions to always return NXDOMAIN during these tests to make them faster.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18335arm crashes after Tor update to 0.2.7.62020-06-27T13:59:35ZTracarm crashes after Tor update to 0.2.7.6Hi,
I just updated Tor to 0.2.7.6. When I connected arm, it crashed with the following backtrace
user@host:~$ arm -i 127.0.0.1:5678
Traceback (most recent call last):
File "/usr/share/arm/starter.py", line 534, in <module>
contro...Hi,
I just updated Tor to 0.2.7.6. When I connected arm, it crashed with the following backtrace
user@host:~$ arm -i 127.0.0.1:5678
Traceback (most recent call last):
File "/usr/share/arm/starter.py", line 534, in <module>
controller.init(conn)
File "/usr/share/arm/util/torTools.py", line 670, in init
self._exitPolicyChecker = self.getExitPolicy()
File "/usr/share/arm/util/torTools.py", line 1345, in getExitPolicy
result = ExitPolicy(entry, result)
File "/usr/share/arm/util/torTools.py", line 2611, in __init__
self.ipAddressBin += "".join([str((int(octet) >> y) & 1) for y in range(7, -1, -1)])
ValueError: invalid literal for int() with base 10: 'abcd'
The tor instance is IPv6 enabled and in my exit policy there are reject6 entries:
ExitPolicy reject6 abcd::123:4567:89ab:cdef/64:*
After commenting the line the crash disappeared.
Thanks/Regards
torland
**Trac**:
**Username**: torlandhttps://gitlab.torproject.org/tpo/applications/tor-browser-bundle-testsuite/-/issues/40053Test cases for OCSP isolation2022-08-04T21:45:10ZArthur EdelsteinTest cases for OCSP isolationWe need some sort of regression tests for OCSP isolation, which was implemented in legacy/trac#13670.2.We need some sort of regression tests for OCSP isolation, which was implemented in legacy/trac#13670.2.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18334Test cases for OCSP isolation2022-06-17T21:41:47ZArthur EdelsteinTest cases for OCSP isolationWe need some sort of regression tests for OCSP isolation, which was implemented in legacy/trac#13670.2.We need some sort of regression tests for OCSP isolation, which was implemented in legacy/trac#13670.2.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18333Upgrade go to 1.6.22020-06-27T14:39:33ZDavid Fifielddcf@torproject.orgUpgrade go to 1.6.2Release notes: https://golang.org/doc/go1.6
It's not a security requirement or anything, but we're currently on 1.4.3 and don't want to fall too far behind.Release notes: https://golang.org/doc/go1.6
It's not a security requirement or anything, but we're currently on 1.4.3 and don't want to fall too far behind.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org