The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-06-17T18:46:01Zhttps://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/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/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/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/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/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/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/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/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/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/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/15759test_address_get_if_addrs_[ifaddrs,win32]() will assert instead of failing gr...2020-06-27T14:01:20ZYawning Angeltest_address_get_if_addrs_[ifaddrs,win32]() will assert instead of failing gracefully.Reported here: https://lists.torproject.org/pipermail/tor-talk/2015-April/037541.html
Passing in severity of `0`, instead of `LOG_ERR` causes the logging code to assert. Mostly harmless since the test was going to fail anyway, but shou...Reported here: https://lists.torproject.org/pipermail/tor-talk/2015-April/037541.html
Passing in severity of `0`, instead of `LOG_ERR` causes the logging code to assert. Mostly harmless since the test was going to fail anyway, but should be fixed to fail in a more graceful manner.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15692'GETINFO config-file' command on ControlPort returns the standard torrc file ...2022-06-16T15:19:54Zyurivict271'GETINFO config-file' command on ControlPort returns the standard torrc file when it was overridden in the command line> GETINFO config-file
> 250-config-file=/usr/local/etc/tor/torrc
When command line begins with: --ignore-missing-torrc -f /no/file
Tor v0.2.6.6 (git-bb8c4e69ca5c8bca) running on FreeBSD with Libevent 2.0.22-stable, OpenSSL 1.0.2a and ...> GETINFO config-file
> 250-config-file=/usr/local/etc/tor/torrc
When command line begins with: --ignore-missing-torrc -f /no/file
Tor v0.2.6.6 (git-bb8c4e69ca5c8bca) running on FreeBSD with Libevent 2.0.22-stable, OpenSSL 1.0.2a and Zlib 1.2.8.https://gitlab.torproject.org/tpo/core/tor/-/issues/15645Document PublishServerDescriptor better2021-07-22T16:25:48ZJens KubiezielDocument PublishServerDescriptor betterThe manpage lists `0|1|v3|bridge,...` as possible arguments to `PublishServerDescriptor`. However there is no description what `v3` or `bridge` or if there is a difference between `1` and `bridge`. So I propose to add some more lines of ...The manpage lists `0|1|v3|bridge,...` as possible arguments to `PublishServerDescriptor`. However there is no description what `v3` or `bridge` or if there is a difference between `1` and `bridge`. So I propose to add some more lines of explanation.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15612Remove references to '*' wildcard transport from pt-spec.txt2020-06-27T14:01:24ZGeorge KadianakisRemove references to '*' wildcard transport from pt-spec.txtWe recently decided to remove support for the wildcard transport from our specs. It still hasn't been implemented anywhere, so it's a simple spec change.
The rationale can be found in https://lists.torproject.org/pipermail/tor-dev/2015-...We recently decided to remove support for the wildcard transport from our specs. It still hasn't been implemented anywhere, so it's a simple spec change.
The rationale can be found in https://lists.torproject.org/pipermail/tor-dev/2015-March/008491.html and in legacy/trac#10131 (also legacy/trac#3725).Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15607Tor log dates imprecise2021-07-09T17:21:59ZDamian JohnsonTor log dates impreciseHi Nick. Tor's log file uses the local timezone and lacks the year in its log file entries...
```
Apr 06 11:03:39.000 [notice] Tor 0.2.7.0-alpha-dev (git-4247ce99e5d9b7b2) opening new log file.
Apr 06 11:03:39.832 [notice] Tor v0.2.7.0-...Hi Nick. Tor's log file uses the local timezone and lacks the year in its log file entries...
```
Apr 06 11:03:39.000 [notice] Tor 0.2.7.0-alpha-dev (git-4247ce99e5d9b7b2) opening new log file.
Apr 06 11:03:39.832 [notice] Tor v0.2.7.0-alpha-dev (git-4247ce99e5d9b7b2) running on Linux with Libevent 2.0.16-stable, OpenSSL 1.0.1 and Zlib 1.2.3.4.
Apr 06 11:03:39.832 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
```
This is fine, but has meant some hacks for arm which reads the log file to prepopulate that information. For instance, arm pretends the year is always 2012 to ensure log files made on leap years are readable (otherwise February 29th isn't a thing, see legacy/trac#5265).
Feel free to close this as 'no plan to fix' if you'd like. Just thought I'd run this by you to see if iso8601 timestamps or something more complete would be preferable.https://gitlab.torproject.org/tpo/core/tor/-/issues/15554Put some actual hsdescs in the unit tests for parsing2020-06-27T14:01:26ZRoger DingledinePut some actual hsdescs in the unit tests for parsingRight now our test_rend_fns() function in src/test/test.c builds a "rend_service_descriptor_t *generated", and then it encodes it, and then it parses it, to make sure it gets the expected descriptor back. That's a great start.
But there...Right now our test_rend_fns() function in src/test/test.c builds a "rend_service_descriptor_t *generated", and then it encodes it, and then it parses it, to make sure it gets the expected descriptor back. That's a great start.
But there are now several different versions of the descriptor format in play, and our unit tests by definition only test the one that the current Tor version generates.
Also, it would be easier to play around with "how Tor handles it if you take that stanza out of the descriptor" experiments, if there are some actual descriptors in the unit tests.
Good idea / bad idea?Tor: 0.3.2.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/15543Undocumented + and / for config options2021-07-22T16:25:48ZDamian JohnsonUndocumented + and / for config optionsFrom legacy/trac#14742, we have special behaviour when a config option when a config option is passed on the commandline with a '+' or '/'...
https://gitweb.torproject.org/stem.git/tree/test/integ/process.py#n199
This looks to presentl...From legacy/trac#14742, we have special behaviour when a config option when a config option is passed on the commandline with a '+' or '/'...
https://gitweb.torproject.org/stem.git/tree/test/integ/process.py#n199
This looks to presently be undocumented. Obvious guess is 'adds/removed from existing config rather than replacing' but I'm getting some unexpected behavior when I pass '/PublishServerDescriptor'. Probably only works properly for LineList arguments.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15518Tor considers routers in the same IPv6 /16 to be "in the same subnet"2020-06-27T14:01:27ZIsis LovecruftTor considers routers in the same IPv6 /16 to be "in the same subnet"When `EnforceDistinctSubnets` is enabled, tor uses:
```
/** Return true iff router1 and router2 have similar enough network addresses ...When `EnforceDistinctSubnets` is enabled, tor uses:
```
/** Return true iff router1 and router2 have similar enough network addresses
* that we should treat them as being in the same family */
static INLINE int
addrs_in_same_network_family(const tor_addr_t *a1,
const tor_addr_t *a2)
{
return 0 == tor_addr_compare_masked(a1, a2, 16, CMP_SEMANTIC);
}
```
to determine if an address is in the same family. For an example IPv6 address, `2001:1234::0:1`, its /16 representation is `2001::/16`, meaning that `2001:ffff::` would be in the same family. A `\16` for IPv6 is _huge_, particularly considering that [only one-eighth of all IPv6 space is currently allocated for use on the internet](https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml) (`2000::/3`). For the path selection code, using `/16` essentially means that no two IPv6 routers in the same country (or possibly even continent) will be in the same path, and might possibly provide extremely increased chance of selection to routers in weird/rare IPv6 subnets.
For a related ticket, see legacy/trac#15517 governing how BridgeDB's version of `EnforceDistinctSubnets` will work for IPv6. (In that ticket, I proposed using IPv6 `/32`s, since that is the [minimum ARIN IPv6 subnet allocation for a LIR](https://www.arin.net/resources/request/ipv6_initial_assign.html).Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/15471Tor should prctl(PR_SET_PDEATHSIG, SIGTERM) background processes.2020-06-27T14:01:28ZYawning AngelTor should prctl(PR_SET_PDEATHSIG, SIGTERM) background processes.From the man page:
```
PR_SET_PDEATHSIG (since Linux 2.1.57)
Set the parent process death signal of the calling process to
arg2 (either a signal value in the range 1..maxsig, or 0 to
...From the man page:
```
PR_SET_PDEATHSIG (since Linux 2.1.57)
Set the parent process death signal of the calling process to
arg2 (either a signal value in the range 1..maxsig, or 0 to
clear). This is the signal that the calling process will get
when its parent dies. This value is cleared for the child of a
fork(2) and (since Linux 2.4.36 / 2.6.23) when executing a set-
user-ID or set-group-ID binary, or a binary that has associated
capabilities (see capabilities(7)). This value is preserved
across execve(2).
```
This will ensure at least on Linux that all background processes will get a `SIGTERM` if Tor dies, and can cleanup appropriately.
I don't think this behavior would be particularly shocking to PT developers (who should be handling SIGTERM already), so this probably doesn't even need a spec patch since "tor dying" invoking the normal termination signaling is appropriate.
The choice of `SIGTERM` over `SIGKILL` here is so that PTs have the option to trap it and terminate their own children as appropriate.
Pros:
* Easy to do.
* The kernel does all of the heavy lifting for us, as a catchall.
* Fixes certain nasty issues in unmodified pt code on the relevant platform automatically.
Cons:
* Non-portable (legacy/trac#15435 aka legacy/trac#10047 is a portable fix that requires pt modification).
* We have pts (obfs4proxy in particular) that can be ran with elevated capabilities.Tor: 0.2.7.x-final