The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:01:15Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15989Add AccountingRule in and out2020-06-27T14:01:15ZteorAdd AccountingRule in and out`AccountingRule max` is often used for services that actually only charge for bandwidth out, such as AWS.
There may also be services that only charge for bandwidth in, although it seems somewhat unlikely. However, it should be included ...`AccountingRule max` is often used for services that actually only charge for bandwidth out, such as AWS.
There may also be services that only charge for bandwidth in, although it seems somewhat unlikely. However, it should be included for completeness.
The current `AccountingRule max` and `AccountingRule sum` implementation assumes that an increase in outgoing bandwidth always increases the amount being measured. Therefore, it disabes the `DirPort` when `AccountingMax` is in effect.
It might make sense to only do this for AccountingRules max, sum, and out; and not for AccountingRule in.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16082man page says "bandwidth accounting values" in state file are "unused so far"2020-06-27T14:01:12ZRoger Dingledineman page says "bandwidth accounting values" in state file are "unused so far"In the Tor man page, under DataDirectory/state, it says
```
· The current bandwidth accounting values (unused so far; see
below).
```
and then below is a DataDirectory/bw_accounting section, which says
```
...In the Tor man page, under DataDirectory/state, it says
```
· The current bandwidth accounting values (unused so far; see
below).
```
and then below is a DataDirectory/bw_accounting section, which says
```
Used to track bandwidth accounting values (when the current period
starts and ends; how much has been read and written so far this
period). This file is obsolete, and the data is now stored in the
'state' file as well. Only used when bandwidth accounting is
enabled.
```
So which is it?
I think it's in the state file, and we should stop saying that it's unused there.
I think.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16134The various stream lists tied to the circuit structures should use tor_queue.h2021-09-16T14:35:00ZYawning AngelThe various stream lists tied to the circuit structures should use tor_queue.hOffshoot of legacy/trac#16052.
Every list that uses `edge_connection_t.next_stream`, should be converted to a `TOR_SLIST` for maintainability/sanity. Carved off into a separate ticket because legacy/trac#16052 will probably get a 0.2.6...Offshoot of legacy/trac#16052.
Every list that uses `edge_connection_t.next_stream`, should be converted to a `TOR_SLIST` for maintainability/sanity. Carved off into a separate ticket because legacy/trac#16052 will probably get a 0.2.6 backport, while this should not as it is rather intrusive (if mechanical).Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16350tor.pid should be deleted on exit in every case possible, like assert termina...2022-02-07T19:38:03Zyurivict271tor.pid should be deleted on exit in every case possible, like assert termination, and catchable signalsI had tor fail with assertion, printing message into log and exiting, yet it left tor.pid. It could have easily delete it, since this wasn't the non-catchable signal.
It doesn't make sense to leave tor.pid when tor exited.
0.2.6.7 on F...I had tor fail with assertion, printing message into log and exiting, yet it left tor.pid. It could have easily delete it, since this wasn't the non-catchable signal.
It doesn't make sense to leave tor.pid when tor exited.
0.2.6.7 on FreeBSDhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16372tor uses getaddrinfo even if DisableNetwork is set2021-07-22T16:25:48Zteortor uses getaddrinfo even if DisableNetwork is setIf DisableNetwork is set, but tor is passed a textual (?) address in a `*Port` config line, it uses `getaddrinfo` to lookup the address. This can access the network and cause config parsing to hang. (See legacy/trac#16366.)
The document...If DisableNetwork is set, but tor is passed a textual (?) address in a `*Port` config line, it uses `getaddrinfo` to lookup the address. This can access the network and cause config parsing to hang. (See legacy/trac#16366.)
The documentation for DisableNetwork could be clearer about this - that tor *will* make certain network-related calls as part of its config process, even if DisableNetwork is set.
If the config uses names that need to be looked up using the network, this also means the external network needs to be up for config parsing to succeed. (Which seems like an unexpected dependency.)
So DisableNetwork may not be able to be used as described (implied?) - for a controller to setup the config while the network is down, then re-enable tor networking when the network comes up.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16458torspec references UTC, but tor uses unix time (leap second handling)2021-07-22T16:25:32Zteortorspec references UTC, but tor uses unix time (leap second handling)When the various torspec documents specify time, they refer to UTC. But the implementations used by at least Linux, *BSD and OS X are based on the Unix time epoch.
This makes a difference to how leap seconds are handled: UTC includes le...When the various torspec documents specify time, they refer to UTC. But the implementations used by at least Linux, *BSD and OS X are based on the Unix time epoch.
This makes a difference to how leap seconds are handled: UTC includes leap seconds, but unix time excludes them.
We should:
* ensure that none of the security properties of tor depend on leap seconds either being present or absent, either individually or in aggregate:
* every minute is not 60 seconds long (and equivalently for hour, day, week)
* some epoch times can repeat or be missing
* UTC and Unix time differ by approximately 30 seconds
* check how the current Linux, BSD, Windows and OS X implementations handle leap seconds (in roughly that order of priority)
* consider and document tor's handling of leap seconds
See:
* https://en.wikipedia.org/wiki/Leap_second
* https://en.wikipedia.org/wiki/Unix_timehttps://gitlab.torproject.org/tpo/core/tor/-/issues/16564WIP: Reject bridge descriptors posted to non-bridge authorities2022-02-07T19:38:32ZRoger DingledineWIP: Reject bridge descriptors posted to non-bridge authoritiesRight now if my bridge descriptor gets uploaded to the directory authorities, poof I'm now a public relay, even if I didn't mean to be.
That's not the end of the world, since I am technically offering to be a relay already, and the only...Right now if my bridge descriptor gets uploaded to the directory authorities, poof I'm now a public relay, even if I didn't mean to be.
That's not the end of the world, since I am technically offering to be a relay already, and the only difference is that I didn't opt to publish my descriptor myself.
But still it seems like we should make the choice explicit inside the descriptor.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/28892Check for `file` command in Tor Browser start script before using it2022-07-13T23:34:14ZGeorg KoppenCheck for `file` command in Tor Browser start script before using itIn `start-tor-browser` we do
```
SYSARCHITECTURE=$(getconf LONG_BIT)
TORARCHITECTURE=$(expr "$(file TorBrowser/Tor/tor)" : '.*ELF \([[:digit:]]*\)')
if [ $SYSARCHITECTURE -ne $TORARCHITECTURE ]; then
complain "Wrong architecture? 32-...In `start-tor-browser` we do
```
SYSARCHITECTURE=$(getconf LONG_BIT)
TORARCHITECTURE=$(expr "$(file TorBrowser/Tor/tor)" : '.*ELF \([[:digit:]]*\)')
if [ $SYSARCHITECTURE -ne $TORARCHITECTURE ]; then
complain "Wrong architecture? 32-bit vs. 64-bit."
exit 1
fi
```
to bail out early in case users have downloaded a bundle for the wrong architecture. Now, it turns out that there are Linux distros out there (NixOS seems to be one of those) that don't find `file` that way. A fix for that would be to check for the existence of `file` and if we can't find it to note that we assume the user knows what they are doing and proceed anyway.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40579Check for `file` command in Tor Browser start script before using it2022-07-13T23:34:14ZGeorg KoppenCheck for `file` command in Tor Browser start script before using itIn `start-tor-browser` we do
```
SYSARCHITECTURE=$(getconf LONG_BIT)
TORARCHITECTURE=$(expr "$(file TorBrowser/Tor/tor)" : '.*ELF \([[:digit:]]*\)')
if [ $SYSARCHITECTURE -ne $TORARCHITECTURE ]; then
complain "Wrong architecture? 32-...In `start-tor-browser` we do
```
SYSARCHITECTURE=$(getconf LONG_BIT)
TORARCHITECTURE=$(expr "$(file TorBrowser/Tor/tor)" : '.*ELF \([[:digit:]]*\)')
if [ $SYSARCHITECTURE -ne $TORARCHITECTURE ]; then
complain "Wrong architecture? 32-bit vs. 64-bit."
exit 1
fi
```
to bail out early in case users have downloaded a bundle for the wrong architecture. Now, it turns out that there are Linux distros out there (NixOS seems to be one of those) that don't find `file` that way. A fix for that would be to check for the existence of `file` and if we can't find it to note that we assume the user knows what they are doing and proceed anyway.https://gitlab.torproject.org/tpo/core/tor/-/issues/16598fsync ed25519 master key files before closing them.2022-02-07T19:39:17ZNick Mathewsonfsync ed25519 master key files before closing them.Weasel says this is a good idea, and IMO it can't hurt.Weasel says this is a good idea, and IMO it can't hurt.https://gitlab.torproject.org/tpo/core/tor/-/issues/16636Add AccountingSetBytesRead/Written2021-06-18T18:15:52ZteorAdd AccountingSetBytesRead/WrittenA relay operator asked for the ability to reset the state file's `AccountingBytesReadInInterval` and `AccountingBytesWrittenInInterval` values.
While a workaround is to edit or delete the state file, perhaps command-line arguments `Acco...A relay operator asked for the ability to reset the state file's `AccountingBytesReadInInterval` and `AccountingBytesWrittenInInterval` values.
While a workaround is to edit or delete the state file, perhaps command-line arguments `AccountingSetRead` and `AccountingSetWritten` could be useful.
See also legacy/trac#15989 for `AccountingRule` `in` and `out`, as well as the `AccountingEnableDirPort` override.https://gitlab.torproject.org/tpo/core/tor/-/issues/16774Add fallback directories to GETINFO2020-06-27T14:00:53ZteorAdd fallback directories to GETINFOIn legacy/trac#15775, we add a list of ~100 fallback directories to the Tor codebase.
Do want to add these to `GETINFO config/defaults` if not already present, or to a separate `GETINFO config/fallback_directories`?In legacy/trac#15775, we add a list of ~100 fallback directories to the Tor codebase.
Do want to add these to `GETINFO config/defaults` if not already present, or to a separate `GETINFO config/fallback_directories`?Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16785Only build/use ed25519-donna.2021-06-18T18:15:52ZYawning AngelOnly build/use ed25519-donna.More a long term thing so I don't forget about it, but once we are sure we like `ed25519-donna`, we can/should remove the `ref10` code from builds, along with the paranoid initialization/runtime sanity checking, as well as only using the...More a long term thing so I don't forget about it, but once we are sure we like `ed25519-donna`, we can/should remove the `ref10` code from builds, along with the paranoid initialization/runtime sanity checking, as well as only using the donna Curve25519 keypair generation code.
I'd be ok with keeping the code around as part of the test suite to catch mysterious breakage. Tentatively setting this to `0.2.8.x-final` since I don't think enough people run the alpha build for us to catch discrepancies between the two codebases if any exist.https://gitlab.torproject.org/tpo/core/tor/-/issues/16803Unit tests for sandbox failures2021-09-04T16:25:49ZNick MathewsonUnit tests for sandbox failuresWe should check that our sandboxing code blocks what it's supposed to block. This seems like something to do in a program to be invoked from a shell script.We should check that our sandboxing code blocks what it's supposed to block. This seems like something to do in a program to be invoked from a shell script.https://gitlab.torproject.org/tpo/core/tor/-/issues/16811Mark TestingTorNetwork PREDICT_UNLIKELY2020-07-24T18:04:31ZteorMark TestingTorNetwork PREDICT_UNLIKELYI'd like to see every instance of:
`if (options->TestingTorNetwork) {` (or similarly, `get_options()->`)
transformed to:
`if (PREDICT_UNLIKELY(options->TestingTorNetwork)) {`
This should give us a slight performance boost in relays and ...I'd like to see every instance of:
`if (options->TestingTorNetwork) {` (or similarly, `get_options()->`)
transformed to:
`if (PREDICT_UNLIKELY(options->TestingTorNetwork)) {`
This should give us a slight performance boost in relays and authorities, at the cost of a slight slowdown due to missed branch predictions in test networks.
This would be best done using a coccinelle, perl, or sed script.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16822make certificate lifetime accessible through Tor's ControlPort2022-06-17T18:46:01Zpropermake certificate lifetime accessible through Tor's ControlPortI am referring to the following. Sometimes user Tor logs contain something like this.
```
Sep 03 10:32:59.000 [warn] Certificate already expired. Either their clock is set wrong, or your clock is wrong.
Sep 03 10:32:59.000 [warn] (certi...I am referring to the following. Sometimes user Tor logs contain something like this.
```
Sep 03 10:32:59.000 [warn] Certificate already expired. Either their clock is set wrong, or your clock is wrong.
Sep 03 10:32:59.000 [warn] (certificate lifetime runs from Aug 16 00:00:00 2014 GMT through Jul 29 23:59:59 2015 GMT. Your time is Sep 03 10:32:59 2015 UTC.)
```
This information is interesting in context for anonymity distributions and secure network time synchronization, usability and whatnot. Used by Tails' [tordate](https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh) or Whonix's [anondate](https://www.whonix.org/wiki/Dev/TimeSync#anondate).
However, these tools rely on parsing Tor's log, which is [fragile](https://labs.riseup.net/code/issues/8977).
It would be nice, if something like
* `certificate/valid-after`
* and `certificate/valid-until`
where accessible through Tor's ControlPort.https://gitlab.torproject.org/tpo/core/tor/-/issues/16824Emit a warning message about side channel leaks when using relays as clients2022-02-07T19:39:17ZstarlightEmit a warning message about side channel leaks when using relays as clientsAnalysis presented in bug legacy/trac#16585 demonstrates client circuit formation processing perturbs relay cell forwarding in a manner that may be susceptible to traffic confirmation analysis.
With the present code structure it is reco...Analysis presented in bug legacy/trac#16585 demonstrates client circuit formation processing perturbs relay cell forwarding in a manner that may be susceptible to traffic confirmation analysis.
With the present code structure it is recommended that simultaneous client and relay operation be aggressively discouraged with a new `torrc` configuration parameter to inhibit it--default value set to prevent. In addition log warnings should be generated when both client and relay functions are allowed to operate concurrently.
Correct support of simultaneous client and relay function requires segregation of the client function to a separate thread running on a different processor core than the relay function.
Correcting the current client implementation's deficit of transaction granularity is unlikely to eliminate the potential for a sophisticated advisory to detect perturbation of cell forwarding by client circuit creation activity.https://gitlab.torproject.org/tpo/core/tor/-/issues/16846Include sizeof(void *) in your extrainfo.2020-06-27T14:00:48ZYawning AngelInclude sizeof(void *) in your extrainfo.From legacy/trac#16535, it appears that it would be useful to get an idea of how much x86 vs x86_64 we have as part of the tor network. If we don't also include CPU architecture information, it would be good to have that as well if we ca...From legacy/trac#16535, it appears that it would be useful to get an idea of how much x86 vs x86_64 we have as part of the tor network. If we don't also include CPU architecture information, it would be good to have that as well if we can do it safely.https://gitlab.torproject.org/tpo/core/tor/-/issues/16894Check all logging output is appropriately escaped / escaped_safe_str_client2022-02-07T19:38:03ZteorCheck all logging output is appropriately escaped / escaped_safe_str_clientSecurity bugs like legacy/trac#16891 show up every so often, where sensitive input is logged, rather than being obscured. Similarly, client input is sometimes logged unsanitised (I fixed one of these in the directory request logging code...Security bugs like legacy/trac#16891 show up every so often, where sensitive input is logged, rather than being obscured. Similarly, client input is sometimes logged unsanitised (I fixed one of these in the directory request logging code about 9-12 months ago.)
It would be great if someone could review all the strings that are logged by Tor, and categorise them into:
* static or calculated internally: trusted, log as-is
* externally provided: unsanitised, use escaped()
* sensitive client information: use escaped_safe_str_client()
Do we want this in 0.2.7, or should we leave it until 0.2.8?https://gitlab.torproject.org/tpo/core/tor/-/issues/17028silently ignore a bad/missing --defaults-torrc2020-06-27T20:40:08ZLunarsilently ignore a bad/missing --defaults-torrcThe nightly Debian packages for wheezy were broken because they were missing `/usr/share/tor/tor-service-defaults-torrc`. The issue was not easy to diagnose because Tor currently silently ignore a `--defaults-torrc` pointing to a non-exi...The nightly Debian packages for wheezy were broken because they were missing `/usr/share/tor/tor-service-defaults-torrc`. The issue was not easy to diagnose because Tor currently silently ignore a `--defaults-torrc` pointing to a non-existing file.
At least a warning would be good, but I think it would be even better to bail out unless `--ignore-missing-torrc` is specified.Tor: unspecified