The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:49:34Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31532Use ptrdiff_t for struct_member_t.offset, etc2020-06-27T13:49:34ZNick MathewsonUse ptrdiff_t for struct_member_t.offset, etcWe have several fields in our configuration code that use int for a struct offset:
* `struct_member_t.offset`
* `struct_magic_decl_t.magic_offset`
* `config_format_t.config_suite_offset`
These should all use ptrdiff_t instead.We have several fields in our configuration code that use int for a struct offset:
* `struct_member_t.offset`
* `struct_magic_decl_t.magic_offset`
* `config_format_t.config_suite_offset`
These should all use ptrdiff_t instead.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31531Make control_event_conf_changed() take a smartlist of config_line_t2021-09-16T14:22:37ZteorMake control_event_conf_changed() take a smartlist of config_line_tcontrol_event_conf_changed() currently takes smartlist(k, v, k, v, …), which is an unexpected API.
We should change it so the keys and values are part of a config_line_t struct, and the smartlist contains config_line_t.control_event_conf_changed() currently takes smartlist(k, v, k, v, …), which is an unexpected API.
We should change it so the keys and values are part of a config_line_t struct, and the smartlist contains config_line_t.Tor: 0.4.3.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31530Shall we require STMT_BEGIN/STMT_END everywhere?2021-09-16T14:22:37ZNick MathewsonShall we require STMT_BEGIN/STMT_END everywhere?We use STMT_BEGIN/STMT_END in some places, and do...while(0) in others. Let's pick which we prefer, and make it universal.We use STMT_BEGIN/STMT_END in some places, and do...while(0) in others. Let's pick which we prefer, and make it universal.https://gitlab.torproject.org/tpo/core/tor/-/issues/31529config refactoring: fix redundant reset logic2020-06-27T13:49:34ZNick Mathewsonconfig refactoring: fix redundant reset logicWe have this block in our code now:
```
// XXXX This is unreachable, since a CLEAR line always has an
// XXXX empty value.
config_reset(mgr, options, mvar, use_defaults); // LCOV_EXCL_LINE
```
We should fix it by changing it...We have this block in our code now:
```
// XXXX This is unreachable, since a CLEAR line always has an
// XXXX empty value.
config_reset(mgr, options, mvar, use_defaults); // LCOV_EXCL_LINE
```
We should fix it by changing it to a nonfatal assertion.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31527In Tor Browser nightly, Tor fails to boostrap, hangs at 50%2021-07-09T17:22:32ZrichardIn Tor Browser nightly, Tor fails to boostrap, hangs at 50%Tor Log:
```
8/26/19, 20:54:01.877 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
8/26/19, 20:54:01.877 [NOTICE] DisableNetwork is set. Tor will not ...Tor Log:
```
8/26/19, 20:54:01.877 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
8/26/19, 20:54:01.877 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
8/26/19, 20:54:01.878 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
8/26/19, 20:54:01.878 [NOTICE] Opening Socks listener on 127.0.0.1:9150
8/26/19, 20:54:01.878 [NOTICE] Opened Socks listener on 127.0.0.1:9150
8/26/19, 20:54:01.878 [NOTICE] Renaming old configuration file to "C:\Users\user\Desktop\Tor Browser GeKo Test2\Browser\TorBrowser\Data\Tor\torrc.orig.1"
8/26/19, 20:54:02.292 [NOTICE] Bootstrapped 5% (conn): Connecting to a relay
8/26/19, 20:54:02.622 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
8/26/19, 20:54:03.285 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay
8/26/19, 20:54:03.579 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a relay done
8/26/19, 20:54:03.580 [NOTICE] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
8/26/19, 20:54:03.863 [NOTICE] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
8/26/19, 20:54:04.155 [NOTICE] Bootstrapped 30% (loading_status): Loading networkstatus consensus
8/26/19, 20:54:06.827 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
8/26/19, 20:54:07.168 [NOTICE] Bootstrapped 40% (loading_keys): Loading authority key certs
8/26/19, 20:54:08.289 [WARN] Your configuration excludes 100% of all possible guards. That's likely to make you stand out from the rest of the world.
8/26/19, 20:54:08.289 [NOTICE] Switching to guard context "restricted" (was using "default")
8/26/19, 20:54:08.289 [NOTICE] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
8/26/19, 20:54:08.289 [NOTICE] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
8/26/19, 20:54:08.290 [NOTICE] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/0, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
8/26/19, 20:54:08.807 [NOTICE] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
8/26/19, 20:54:09.210 [NOTICE] The current consensus contains exit nodes. Tor can build exit and internal paths.
```Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31524GETINFO bw-event-cache spike value(s) in it2022-06-17T17:46:34ZtoralfGETINFO bw-event-cache spike value(s) in itDiscussing with atagar an issue with the bandwidth graph of Nyx yield into the fact, that Tor reports 1 or 2 unusal high values when nyx is started. After a minute or so the effect is gone and Nyx can scale the y-axis to a reasonable val...Discussing with atagar an issue with the bandwidth graph of Nyx yield into the fact, that Tor reports 1 or 2 unusal high values when nyx is started. After a minute or so the effect is gone and Nyx can scale the y-axis to a reasonable value.
atagar found out, that there are 1 or 2 spike values in it (look for 3495411062,3952777936) of the debug out out of Nyx:
```
08/25/2019 21:18:09 [TRACE] Sent to tor: GETINFO bw-event-cache
08/25/2019 21:18:09 [TRACE] Received from tor: 250-bw-event-cache=1374134393,1426052109 20086925,20125282 21800116,21982023 21443601,21381953 21284145,21223794 20736818,20840129 20095450,20002302 20327971,20091436 18481818,18770265 20642518,20484788 17916670,17984439 21675050,21693959 21112734,20784723 19053526,19193284 19295884,19489502 21443785,21575604 21134294,21020113 24810387,24663932 21866896,22876759 22146840,22135880 21265637,21323808 20355415,20195913 22161894,22076797 23243894,23320227 22162244,22280711 20837266,20883852 21569369,21709237 19729547,19565307 19509953,19770894 20445427,20681393 21164201,22030989 23182698,23054018 22427910,22683231 24570368,24540675 23788945,23736745 24326209,24063010 23491274,23547576 24465451,24291718 23117418,23200615 22771292,22946982 23969237,23981784 23612713,23562155 23382374,23423884 20351264,20211681 21590861,21769434 21812207,21644025 23301464,23486635 23190866,23611494 25596210,25579703 23296743,23781312 24948896,24956987 25415713,25555740 26407789,26504165 25006181,25166607 3495411062,3952777936 28124111,26406950 26007090,26935060 26897763,26935089 26866687,27170833 28168859,26699345 25750280,26406950 27570110,26935089 28007323,26935089 26590862,26935089 28579673,26935089 112518425,114606735 27113917,27462685 26127629,26406921 79812696,79748989 25846716,26896706 29074858,26973472 24947719,26935089 27687620,26864938 25539933,26838674 27171107,27068897 27140138,26879337 26899976,26495460 25950990,26844241 28442790,27025937 26116568,26829132 27827545,26960905 27035490,26415775\n250 OK
```
Just a guess: The 2 affected relays have about 20 - 40 MByte/sec bw. The spike values are often above 3,000,000,000, looking like an arbitrary unsigned long int.
Whilst the severity on the Nyx graph is negligible I do wonder about the root cause.https://gitlab.torproject.org/tpo/core/tor/-/issues/31519git-push-all.sh: shellcheck warnings2020-06-27T13:49:35ZNick Mathewsongit-push-all.sh: shellcheck warningsWe've got a bunch of shellcheck warnings here since I merged legacy/trac#29879.We've got a bunch of shellcheck warnings here since I merged legacy/trac#29879.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31518HAProxy implementation in TCPProxy option.2020-06-27T13:49:35ZhaxxpopHAProxy implementation in TCPProxy option.Since SOCKS5 takes 2 round trips, SOCKS4 doesn't support IPv6 and the proxy has to support DNS resolving in HTTP CONNECT, I would like to implement the proxy protocol of HAProxy to support IPv6 and the proxy doesn't have to resolve domai...Since SOCKS5 takes 2 round trips, SOCKS4 doesn't support IPv6 and the proxy has to support DNS resolving in HTTP CONNECT, I would like to implement the proxy protocol of HAProxy to support IPv6 and the proxy doesn't have to resolve domain names by itself.
According to the mail thread, https://lists.torproject.org/pipermail/tor-dev/2019-August/013968.html, people suggested to create a new torrc option called TCPProxy and have a protocol as a parameter.Tor: 0.4.3.x-finalhaxxpophaxxpophttps://gitlab.torproject.org/tpo/core/tor/-/issues/31516config refactor: every function table entry should be documented and unit tested2020-06-27T13:49:35Zteorconfig refactor: every function table entry should be documented and unit testedWe've added a lot of function tables, but some of their entries are all NULL, everywhere in the code.
So even if it looks like we have 100% coverage, we're not testing these code paths.
Ideally, we should have non-trivial functions, wh...We've added a lot of function tables, but some of their entries are all NULL, everywhere in the code.
So even if it looks like we have 100% coverage, we're not testing these code paths.
Ideally, we should have non-trivial functions, which do the thing that the function table entry is mean to do.
Edited to add:
Also, function table types should be documented with the same level of detail as regular functions. Each argument should have a type, name?, and description.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31511config refactor: split mass change commits into automated and manual steps2020-06-27T13:49:35Zteorconfig refactor: split mass change commits into automated and manual stepsIn future, please split mass change commits into at least two commits:
* automated changes using sed or coccinelle scripts
* manual cleanup changes
This does not block reviews for code that is already in commits or branches. But it shou...In future, please split mass change commits into at least two commits:
* automated changes using sed or coccinelle scripts
* manual cleanup changes
This does not block reviews for code that is already in commits or branches. But it should block reviews for any new commits.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31509config refactor: make test-stem should pass2020-06-27T13:49:35Zteorconfig refactor: make test-stem should passStem should check a lot of useful option combinations.
But the stem CI job is current set to allow_failure, because of legacy/trac#29437.
So we should check that the stem CI job passes, or fails due to a timeout. Or we should run "make...Stem should check a lot of useful option combinations.
But the stem CI job is current set to allow_failure, because of legacy/trac#29437.
So we should check that the stem CI job passes, or fails due to a timeout. Or we should run "make test-stem" manually on each PR.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31508config refactor: create simple summaries for each refactor step2020-06-27T13:49:35Zteorconfig refactor: create simple summaries for each refactor stepIt would be helpful to have a quick summary showing the ideal state, and where we are in the refactor.
For example, the legacy/trac#30914 original state was:
* confparse
* typed_var
And the final state was:
* confparse
* struct_var...It would be helpful to have a quick summary showing the ideal state, and where we are in the refactor.
For example, the legacy/trac#30914 original state was:
* confparse
* typed_var
And the final state was:
* confparse
* struct_var
* typed_varTor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31507Change the client default to AvoidDiskWrites 1, or otherwise make disk writes...2022-06-17T13:02:48ZteorChange the client default to AvoidDiskWrites 1, or otherwise make disk writes less frequent.Since 2007, we've seen some significant technological changes:
* More devices with batteries
* More devices with SSDs
* Better disk forensics techniques
So it might be a good idea to change the client default to AvoidDiskWrites 1.Since 2007, we've seen some significant technological changes:
* More devices with batteries
* More devices with SSDs
* Better disk forensics techniques
So it might be a good idea to change the client default to AvoidDiskWrites 1.https://gitlab.torproject.org/tpo/core/tor/-/issues/31502Revise authority and fallback code so that they use the same "defaults" logic...2021-09-16T14:22:37ZNick MathewsonRevise authority and fallback code so that they use the same "defaults" logic as other codeFor ages we've let "NULL" be the default set of authorities, and then added code to substitute "NULL" with the actual authorities.
Same with fallback directories.
We should fix that so that the real defaults are the "actual" defaults f...For ages we've let "NULL" be the default set of authorities, and then added code to substitute "NULL" with the actual authorities.
Same with fallback directories.
We should fix that so that the real defaults are the "actual" defaults from the POV of what counts as default in the code.https://gitlab.torproject.org/tpo/core/tor/-/issues/31498clarify that tor's license is free software / open source2020-06-27T13:49:36ZRoger Dingledineclarify that tor's license is free software / open sourceOne of our Tor people was just asking whether Tor's license is OSI-approved.
The answer is yes, it's distributed under the 3-clause bsd license:
https://gitweb.torproject.org/tor.git/tree/LICENSE#n12
But that description in the license...One of our Tor people was just asking whether Tor's license is OSI-approved.
The answer is yes, it's distributed under the 3-clause bsd license:
https://gitweb.torproject.org/tor.git/tree/LICENSE#n12
But that description in the license file could be even clearer, for people who don't already recognize the text of the 3-clause bsd license.
I propose this change:
```
diff --git a/LICENSE b/LICENSE
index cc27668427..438208426c 100644
--- a/LICENSE
+++ b/LICENSE
@@ -9,7 +9,8 @@
there may be other license terms that you should be aware of.
===============================================================================
-Tor is distributed under this license:
+Tor is distributed under the "3-clause BSD" license, a commonly used
+software license that means Tor is both free software and open source:
Copyright (c) 2001-2004, Roger Dingledine
Copyright (c) 2004-2006, Roger Dingledine, Nick Mathewson
```
I admit there is a bit of politics in my proposed change, but it's hard to describe free software licenses without a bit of politics creeping in, and this seems to me like a balanced approach.
Nick, feel free to do the commit if you're ok with it, or tell me and I will.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31495cannot configure bridges2021-02-25T15:32:26ZMark Smithcannot configure bridgesWhen using code from tor master (`Tor version 0.4.2.0-alpha-dev (git-d475d7c2fb3c0ed5`), I cannot configure bridges in Tor Browser. This seems to be a very recent regression, probably caused by the changes in https://gitweb.torproject.or...When using code from tor master (`Tor version 0.4.2.0-alpha-dev (git-d475d7c2fb3c0ed5`), I cannot configure bridges in Tor Browser. This seems to be a very recent regression, probably caused by the changes in https://gitweb.torproject.org/tor.git/commit/?id=d475d7c2fb3c0ed5120c50011b187f6957a4f52c
The relevant portion of the control port conversation is:
```
SETCONF UseBridges=1 Bridge="obfs4 ..."
513 Unacceptable option value: You cannot set both UseBridges and EntryNodes.
```
As far as I can tell, `EntryNodes` is not present in any of my configuration.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31494config refactoring: follow-ups from merged commits2020-06-27T13:49:36ZNick Mathewsonconfig refactoring: follow-ups from merged commitsI'm using this ticket to track follow-up items from merged commits that I can try to do once we have caught up more with the backlog of commits.I'm using this ticket to track follow-up items from merged commits that I can try to do once we have caught up more with the backlog of commits.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31492Update hsv3 spec for unreachable/failed single onion retries using 3 hops2021-06-23T17:24:15ZteorUpdate hsv3 spec for unreachable/failed single onion retries using 3 hopsThis ticket is the spec part of legacy/trac#23818, legacy/trac#23507, and legacy/trac#23588.This ticket is the spec part of legacy/trac#23818, legacy/trac#23507, and legacy/trac#23588.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31490hs-v3: Turns out the hs_ident circuit_type is not used2021-06-23T17:24:15ZDavid Gouletdgoulet@torproject.orghs-v3: Turns out the hs_ident circuit_type is not usedI stumble upon this while investigating legacy/trac#30200. My HS debugging showed up with circuit type set to `INTRO` for a rendezvous circuit.
In, one of the most insane function we have, `circuit_get_open_circ_or_launch()`, towards th...I stumble upon this while investigating legacy/trac#30200. My HS debugging showed up with circuit type set to `INTRO` for a rendezvous circuit.
In, one of the most insane function we have, `circuit_get_open_circ_or_launch()`, towards the end, we set the HS identifier of the open circuit:
```
circ->hs_ident =
hs_ident_circuit_new(&edge_conn->hs_ident->identity_pk,
HS_IDENT_CIRCUIT_INTRO);
```
... notice, we only use INTRO type, never the RENDEZVOUS one.
Further looking at it, it appears that the `hs_ident->circuit_type` field is just pointless. Client will only set the INTRO (see code above) and the service will properly set both. But then after that, it is just never used.
I propose we either remove it or fix the client side because if we ever rely on that field, it is of today really wrong client side.Tor: 0.4.3.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31484Add a tor-libtor-gen tool, which generates libtor C code that executed that c...2020-07-29T12:49:21ZteorAdd a tor-libtor-gen tool, which generates libtor C code that executed that command linecurl has a --libcurl option that transforms a curl command-line into libcurl code:
https://curl.haxx.se/docs/manpage.html#--libcurl
We could do the same with a tor command-line,
But we wouldn't want C code generation in tor itself, so...curl has a --libcurl option that transforms a curl command-line into libcurl code:
https://curl.haxx.se/docs/manpage.html#--libcurl
We could do the same with a tor command-line,
But we wouldn't want C code generation in tor itself, so we should build a separate tool. That will be a lot easier once our config parsing has been refactored.Tor: unspecified