The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:05:45Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6791Deprecate "DirServer"; call them "DirAuthority".2020-06-27T14:05:45ZNick MathewsonDeprecate "DirServer"; call them "DirAuthority".We don't call the directory authorities "DirServers" much these days. The name dates back to when there was just one server in the whole network, I think, and everything else was a mere cache. It would probably make way more sense to r...We don't call the directory authorities "DirServers" much these days. The name dates back to when there was just one server in the whole network, I think, and everything else was a mere cache. It would probably make way more sense to rename the option. We should keep the old one as an alias, though, so things don't break.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6781Make cell statistics useful in simulations again2021-06-18T18:25:22ZRob JansenMake cell statistics useful in simulations againOnce upon a time, when I set "CellStatistics 1" in my torrc files, each relay in my TestingTorNetwork would track and write statistics to disk. Since writing these every 24 hours was too long for my simulations, I just needed to patch WR...Once upon a time, when I set "CellStatistics 1" in my torrc files, each relay in my TestingTorNetwork would track and write statistics to disk. Since writing these every 24 hours was too long for my simulations, I just needed to patch WRITE_STATS_INTERVAL to a smaller value (once per minute). Every new interval, a new entry would be appended to the stats files. These statistics are very useful in determining how our test network looks and how it compares to live Tor.
Somewhere along the line (in 0.2.3.x-alpha I think, but I can't find the ticket), the behavior changed so that each new entry replaces the existing file, presumably under the assumption that by that time the stats from the last entry were already sent to the authority and were no longer needed. Of course they weren't in my simulations, and only getting the last minute of statistics from each relay isn't nearly as useful.
Whats the best solution here? Is there another #define that I should patch so my relays upload stats every minute instead of the current rate? That will cause extra network load. Should we allow the option of appending statistics instead of replacing?
Ideally, I wouldn't have to patch anything and this would all be handled automatically if TestingTorNetwork is 1.https://gitlab.torproject.org/tpo/core/tor/-/issues/6777add config option to not rate limit authority dir conns2022-10-11T23:41:01ZRoger Dingledineadd config option to not rate limit authority dir connsDuring today's consensus fiasco, several authorities were hitting their configured bandwidth rates. In moria1's case, we were using the default 5MB/10MB, and we were basically sustaining 5MB/s of directory output for 6+ hours. Most thing...During today's consensus fiasco, several authorities were hitting their configured bandwidth rates. In moria1's case, we were using the default 5MB/10MB, and we were basically sustaining 5MB/s of directory output for 6+ hours. Most things weren't finishing getting written -- including votes.
weasel suggested a feature where we allow dir conns to/from authorities to go above our bandwidth limits.
I was thinking we would implement it just by making connection_is_rate_limited() say "no" for them.
but weasel suggested that we count the bytes, and reduce them from our totals, but not limit the conns. That sounds worthwhile but more complex.
On the theory that we want this hack in rather than waiting forever for the elegant solution, I convinced weasel that he should be ok with the simpler approach.
Heck, maybe rather than making it a config option, we should just make it standard behavior for authorities.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6773DirServer lines should take more than one "orport="2020-06-27T14:05:47ZLinus Nordberglinus@torproject.orgDirServer lines should take more than one "orport="In order for clients and relays to be able to contact an authority
server over IPv6 we should expand the DirServer line to accept more
than one OR port.
Do we prefer "orport=ADDR0,ADDR1,..." or "orport=ADDR0 orport=ADDR1 ..."?
Or perhap...In order for clients and relays to be able to contact an authority
server over IPv6 we should expand the DirServer line to accept more
than one OR port.
Do we prefer "orport=ADDR0,ADDR1,..." or "orport=ADDR0 orport=ADDR1 ..."?
Or perhaps something completely different?
Note that an ADDR will be IP-ADDRESS ":" PORT-NUMBER rather than
todays PORT-NUMBER..
We need to
- add field(s) to trusted_dir_server_t
- fix the parsing in parse_dir_server_line(), probably by calling tor_addr_port_lookup().
We also need legacy/trac#6772 (Fall back to alternative OR port if the current
fails) to be implemented for this to be useful, f.ex. in
directory_post_to_dirservers().Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6520read_from_old_location is set twice in router_reload_router_list_impl2020-06-27T14:05:57ZMatthew Finkelread_from_old_location is set twice in router_reload_router_list_implThe second mutation appears to exist so that the conditional above it can exist. Is there a reason to check the return value?
read_from_old_location = 1;
log_notice(LD_DIR, "Couldn't read %s; trying to load routers from old "
...The second mutation appears to exist so that the conditional above it can exist. Is there a reason to check the return value?
read_from_old_location = 1;
log_notice(LD_DIR, "Couldn't read %s; trying to load routers from old "
"location %s.", fname, altname);
if ((store->mmap = tor_mmap_file(altname)))
read_from_old_location = 1;Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6504Support Windows environment variables in HiddenServiceDir2020-07-24T13:39:18ZTracSupport Windows environment variables in HiddenServiceDirExpansion should be done each time the hidden service dir is opened, and stored unexpanded. Actually, my impression is that if you use the right Win32 API calls to open the location, tor itself doesn't need to worry about expansion. Win3...Expansion should be done each time the hidden service dir is opened, and stored unexpanded. Actually, my impression is that if you use the right Win32 API calls to open the location, tor itself doesn't need to worry about expansion. Win32 will take care of any necessary.
One direct benefit to you devs is that you could then use '%UserProfile%' in the HiddenServiceDir examples for Windows in your documentation, such as the one discussed in !legacy/trac#4798, yielding the appropriate location in every version that Tor supports.
This behavior could/should eventually broadened to all options for which a path can be specified (e.g. DataDirectory, GeoIPFile, PidFile), so if the fix would affect the opening of other paths (I haven't looked through the source code), all the better. If the fix isn't in a core function, I'd be happy to add a new, broader, ticket.
P.S. The version I'm using is actually 0.2.2.37, but I don't see it in the list.
**Trac**:
**Username**: criticoderTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6490Warn if traffic accounting is enabled and likely to break anonymity2020-06-27T14:05:58ZRobert RansomWarn if traffic accounting is enabled and likely to break anonymityA Tor instance should log a warning if traffic accounting is enabled and any of the following are true:
* It is configured to operate two or more hidden services (e.g. there are two or more HiddenServiceDir lines in its configuration)....A Tor instance should log a warning if traffic accounting is enabled and any of the following are true:
* It is configured to operate two or more hidden services (e.g. there are two or more HiddenServiceDir lines in its configuration).
* It is configured to operate at least one hidden service and run as a relay or bridge.
This change attempts to address a possible user safety issue and can't break Tor in a subtle way, so I'm filing it for 0.2.3.x.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6489Document that clients also have BWRate and BWBurst.2021-07-22T16:26:01ZproperDocument that clients also have BWRate and BWBurst.The manual only talks about limiting bandwidth for relays.
Tor clients, especially hidden servers do not have an option to limit bandwidth or traffic. I am suggesting that feature.
Use cases:
* Tor user, especially hidden servers want...The manual only talks about limiting bandwidth for relays.
Tor clients, especially hidden servers do not have an option to limit bandwidth or traffic. I am suggesting that feature.
Use cases:
* Tor user, especially hidden servers want to reserve some free non-Tor bandwidth for other things (software downloads, updates, non-Tor browsing, etc.).
* Tor user has a limited amount of traffic available in it's plan.
* DDoS protection.
* Workaround for legacy/trac#6473. (bandwidth related anonymity set reduction)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6384Log library versions at startup, and in response to a command-line option2020-06-27T14:06:02ZJacob AppelbaumLog library versions at startup, and in response to a command-line optionI'd like to know which openssl/libevent/zlib that I'm using when I start Tor. This should be output with --version.I'd like to know which openssl/libevent/zlib that I'm using when I start Tor. This should be output with --version.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6350Extra-info descriptors contain extra space between nickname and fingerprint2020-06-27T14:06:04ZKarsten LoesingExtra-info descriptors contain extra space between nickname and fingerprintStarting 16 hours ago, a relay started publishing the following extra-info descriptor that makes metrics-lib choke:
```
extra-info free EB2798A84E9D962DF13C61FA055C2513DDDAF800
published 2012-07-08 13:36:56
router-signature
-----BEGIN ...Starting 16 hours ago, a relay started publishing the following extra-info descriptor that makes metrics-lib choke:
```
extra-info free EB2798A84E9D962DF13C61FA055C2513DDDAF800
published 2012-07-08 13:36:56
router-signature
-----BEGIN SIGNATURE-----
nn7itViCioERo/QzaKYB5AKu/ufMjukORZBU4QXqL0PPSvjDVix1+ckK8J5xYJc7
6fie9moyZpUK+bdz4xzIf/YECMbGwT3lJOZO59f+vMwQycI6tRWHyCWc9A941Mf4
6hrvwRj7IKgIcJdhxFp3FevREx5CCA3f+yhWJdAbQ5s=
-----END SIGNATURE-----
```
metrics-lib would expect a single SP between nickname and fingerprint, which is the default for most descriptor lines. I'm not entirely certain that dir-spec.txt doesn't allow two SP though:
```
"extra-info" Nickname Fingerprint NL
```
The space between Nickname and Fingerprint could be interpreted as SP (which is what I did in many places that didn't have an explicit definition of SP), or it could be considered WS which is defined as `WS = (SP | TAB)+`.
So, should the directory authorities reject this descriptor for being malformed? Or should metrics-lib (and stem) interpret multiple SP as well as any combination of SP and TAB as keyword separator whenever there's no explicit definition in dir-spec.txt?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6313Many of Tor's complex functions should be refactored2020-07-24T13:29:19ZNick MathewsonMany of Tor's complex functions should be refactoredSee some discussion on legacy/trac#6177.
I'm attaching a list of the most complex functions in Tor (by cyclomatic complexity).
Possibly cyclomatic-complexity-per-line would be another good thing to look at.See some discussion on legacy/trac#6177.
I'm attaching a list of the most complex functions in Tor (by cyclomatic complexity).
Possibly cyclomatic-complexity-per-line would be another good thing to look at.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6298Tests should not depend on localhost==127.0.0.1 (Test 'addr/basic' failure in...2020-06-27T14:06:07ZAndrea ShepardTests should not depend on localhost==127.0.0.1 (Test 'addr/basic' failure in tor master)I just built branch 'master' (revision 46434ecf5b6f1ad88deb86fdac044c41ae4b534b) from the tor.git repository with gcc 4.5.3 on x86_64-linux using this configure line:
CC="gcc -m64 -mtune=core2" PKG_CONFIG_LIBDIR=/usr/lib64/pkgconfig PKG...I just built branch 'master' (revision 46434ecf5b6f1ad88deb86fdac044c41ae4b534b) from the tor.git repository with gcc 4.5.3 on x86_64-linux using this configure line:
CC="gcc -m64 -mtune=core2" PKG_CONFIG_LIBDIR=/usr/lib64/pkgconfig PKG_CONFIG_PATH=/usr/share/pkgconfig ./configure --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/libexec64 --sysconfdir=/etc --localstatedir=/var --build=x86_64-linux --host=x86_64-linux --disable-linker-hardening --disable-asciidoc
This causes a test suite failure I haven't seen before:
addr/basic:
FAIL test_addr.c:36: assert((u32) == (0x7f000001u)): 2851995905 vs 2130706433
[basic FAILED]
Turns out the DNS in this hotel *resolves localhost to 169.254.1.1*. This is horribly wrong, of course, and I should have had a proper /etc/hosts for it anyway (*lashes self with wet noodle*), but why does the test suite depend on stuff random machines elsewhere on the network do at all to pass? Shouldn't we mock this stuff somehow?Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6238"Removed n/m microdescriptors as old" log message once per hour on notice2020-06-27T14:06:09ZSebastian Hahn"Removed n/m microdescriptors as old" log message once per hour on noticeLooks like we forgot to demote a log message because it only happens after a relay has been running for a couple of days. Probably we should move that message to infoLooks like we forgot to demote a log message because it only happens after a relay has been running for a couple of days. Probably we should move that message to infoTor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6236Remove duplicate code between parse_{c,s}method_line2021-09-16T14:36:00ZGeorge KadianakisRemove duplicate code between parse_{c,s}method_line`parse_{c,s}method_line` share lots of duplicate code. We must find a way to merge the two functions, or hide the duplicate code into functions.`parse_{c,s}method_line` share lots of duplicate code. We must find a way to merge the two functions, or hide the duplicate code into functions.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6176Clean up service IDs2020-06-27T14:06:11ZAndrea ShepardClean up service IDsThere are several occurences in rendservice.c and rendclient.c of service IDs produced by hashing public keys. They should be properly zeroed when functions return/heap is freed.
* rendclient.c:
* lookup_last_hid_serv_request() (li...There are several occurences in rendservice.c and rendclient.c of service IDs produced by hashing public keys. They should be properly zeroed when functions return/heap is freed.
* rendclient.c:
* lookup_last_hid_serv_request() (line 430)
* directory_get_from_hs_dir() (line 539)
* rendservice.c:
* rend_service_intro_has_opened() (line 1562)
* rend_service_intro_established() (line 1680)
* rend_service_rendezvous_has_opened() (line 1721)
* upload_service_descriptor() (line 1981)
* rend_service_set_connection_addr_port() (line 2463)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6153Make circ_times static, and abstract most of its accessors.2020-06-27T14:06:13ZNick MathewsonMake circ_times static, and abstract most of its accessors.The circ_times structure is exported as a global from circuitbuild.c. It really shouldn't be. It has 3 kinds of external users FWICT:
* Things that pass it as an argument to circuit_build_*().
* Two functions in circuituse.c that wa...The circ_times structure is exported as a global from circuitbuild.c. It really shouldn't be. It has 3 kinds of external users FWICT:
* Things that pass it as an argument to circuit_build_*().
* Two functions in circuituse.c that want to know the current timeout values.
For the former we could use an accessor function, or we could have the functions in circuitbuild.c use the static object if they receive NULL. For the latter, we could have a function that returns the current timeouts.
Making this change would also let us more completely avoid looking at circ_times when LearnCircuitBuildTimeout is 0.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6113We say GMT when we should say UTC2020-06-27T14:06:14ZNick MathewsonWe say GMT when we should say UTCIn several places throughout the codebase and specifications, we say "GMT" when we ought to say "UTC". Nearly all of these are trivial to replace, except for our "parse_rfc1123_time" and "format_rfc1123_time" functions, where we apparen...In several places throughout the codebase and specifications, we say "GMT" when we ought to say "UTC". Nearly all of these are trivial to replace, except for our "parse_rfc1123_time" and "format_rfc1123_time" functions, where we apparently depend on the exact string GMT. Everything else can change.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5915Write patch to make socks handshakes succeed instantly2022-07-20T16:29:47ZRoger DingledineWrite patch to make socks handshakes succeed instantlyIn legacy/trac#3875 Mike suggests we try out the usability of having the Tor in TBB just immediately succeed at all socks handshakes, and hang up if it gets an end cell rather than a connected cell.
We should whip up a Tor patch that do...In legacy/trac#3875 Mike suggests we try out the usability of having the Tor in TBB just immediately succeed at all socks handshakes, and hang up if it gets an end cell rather than a connected cell.
We should whip up a Tor patch that does this behavior, so somebody can try it out.
(We may or may not want to merge it into mainline Tor branches. I guess it depends how complex the patch is and how successful the tests are.)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5847Better error message on GETINFO desc/* when you only have MDs.2020-06-27T14:06:22ZTracBetter error message on GETINFO desc/* when you only have MDs.The "GETINFO desc/id/OR identity" and "GETINFO desc/name/OR nick" options don't seem to work on the Tor control port:
GETINFO desc/id/DD397148A4AB4D43E5E6CB9C5F45E922872CC2D3
552 Unrecognized key "desc/id/DD397148A4AB4D43E5E6CB9C5F45E92...The "GETINFO desc/id/OR identity" and "GETINFO desc/name/OR nick" options don't seem to work on the Tor control port:
GETINFO desc/id/DD397148A4AB4D43E5E6CB9C5F45E922872CC2D3
552 Unrecognized key "desc/id/DD397148A4AB4D43E5E6CB9C5F45E922872CC2D3"
If I replace "desc" with "md" I get the expected response, and they're both described in the spec as taking the same arguments...
**Trac**:
**Username**: mickeycTor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5825Bridges without geoip file report empty statistics2021-07-09T17:21:59ZKarsten LoesingBridges without geoip file report empty statisticsA bridge that doesn't have a geoip file reports empty statistics, implying that it saw zero users. That's confusing, because we cannot distinguish this case from a bridge that actually didn't see any users. The bridge should simply lea...A bridge that doesn't have a geoip file reports empty statistics, implying that it saw zero users. That's confusing, because we cannot distinguish this case from a bridge that actually didn't see any users. The bridge should simply leave out its statistics if it doesn't have a geoip file.
There are [not many bridges affected](https://metrics.torproject.org/papers/bridge-report-usage-stats-2012-04-30.pdf) by this bug, but we should probably fix it anyway. 0.2.3.x or 0.2.4.x?