Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-06-17T19:08:29Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40517Bring sanity to the tor side of the PT shutdown process.2022-06-17T19:08:29ZYawning AngelBring sanity to the tor side of the PT shutdown process.This is the final phase of my great PT shutdown process cleanup as a follow up to legacy/trac#15545.
Now that there's a portable mechanism to signal termination to PTs (close the stdin), we should change the PT shutdown process to allow...This is the final phase of my great PT shutdown process cleanup as a follow up to legacy/trac#15545.
Now that there's a portable mechanism to signal termination to PTs (close the stdin), we should change the PT shutdown process to allow graceful termination to look like this:
1. Close stdin (and on U*IX, send a SIGTERM, PT behavior here is equivalent).
2. Wait for a grace period (~1 sec?)
3. If the child still is not dead, send a SIGKILL/TerminateProcess(). (Failsafe)
This fixes legacy/trac#9330 in that, PTs that wish to trap a graceful shutdown on Windows have a way to do so, despite the final stage of the process killing the PT in the most violent way possible as a failsafe (realistically, PTs should exit shortly after step 1).https://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/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/17038Provide scripts to set up transparent proxying, where supported2022-06-17T17:55:24ZTracProvide scripts to set up transparent proxying, where supportedSetting up a transparent TOR proxy is quite complicated when it comes to firewall rules (e.g. IPTables). Any configuration slip breaks the anonymity.
So I suggest to add the options '[Trans{Local|MiddleBox}](uploads/TransProxyLocal)IPv{...Setting up a transparent TOR proxy is quite complicated when it comes to firewall rules (e.g. IPTables). Any configuration slip breaks the anonymity.
So I suggest to add the options '[Trans{Local|MiddleBox}](uploads/TransProxyLocal)IPv{4|6}' to torrc which automagically configure a transparent TOR proxy with all necessary settings (e.g. IPTables rules, system resolver set-up with .onion).
**Trac**:
**Username**: rennehttps://gitlab.torproject.org/tpo/core/tor/-/issues/17343Add torrc option OnionService* alias for HiddenService*2022-10-20T22:33:53ZDavid Gouletdgoulet@torproject.orgAdd torrc option OnionService* alias for HiddenService*Since the rebranding of Hidden Service to "Onion Service" is now a thing, it would make sense to add aliases for every hidden service torrc option to be changed to use "OnionService" instead. Here are the options I can find in tor man pa...Since the rebranding of Hidden Service to "Onion Service" is now a thing, it would make sense to add aliases for every hidden service torrc option to be changed to use "OnionService" instead. Here are the options I can find in tor man page:
```
HidServAuth --> OnionServiceAuth
HidServDirectoryV2 --> OnionServiceDirectoryV2
MinUptimeHidServDirectoryV2 --> MinUptimeOnionServiceDirectoryV2
VoteOnHidServDirectoriesV2 --> VoteOnOnionServiceDirectoriesV2
PublishHidServDescriptors --> PublishOnionServiceDescriptors
FetchHidServDescriptors --> FetchOnionServiceDescriptors
HiddenService* --> OnionService*
```
Just to be clear, it's NOT a renaming but we add an alias for the current options so both live together.https://gitlab.torproject.org/tpo/core/tor/-/issues/17520Relax the rend cache failure cleanup timer2022-06-17T17:37:27ZDavid Gouletdgoulet@torproject.orgRelax the rend cache failure cleanup timer`rend_cache_failure_clean()` is called every second and the reason is that we want to make the client wait as little as possible so we try our best to cleanup the failure cache.
This is not ideal CPU wise since the cache could technical...`rend_cache_failure_clean()` is called every second and the reason is that we want to make the client wait as little as possible so we try our best to cleanup the failure cache.
This is not ideal CPU wise since the cache could technically grow to the number of possible introduction point in the network thus making it a larger loop every second.
Let's relax the cleanup timer here to 5 minutes (expiry time of an entry) and at each lookup, if the entry did expire, clean it and return that "we do not have an entry". This will not address the size of the cache that can grows but that's fine since we can handle that in the OOM. Also, a cache that has the maximum number of entries is a valid use case.https://gitlab.torproject.org/tpo/core/tor/-/issues/18298reduce warn loglevel entry for missing ed25519_master_id_public_key to notice...2022-06-17T17:42:02Zcypherpunksreduce warn loglevel entry for missing ed25519_master_id_public_key to notice loglevelWhen ed25519_master_id_public_key is not present on the system, tor issues the following log entry:
```
[warn] No key found in .../keys/ed25519_master_id_secret_key or
.../keys/ed25519_master_id_public_key.
[warn] Master public key was ...When ed25519_master_id_public_key is not present on the system, tor issues the following log entry:
```
[warn] No key found in .../keys/ed25519_master_id_secret_key or
.../keys/ed25519_master_id_public_key.
[warn] Master public key was absent; inferring from public key in
signing certificate and saving to disk.
```
Is that such bad after all?
https://lists.torproject.org/pipermail/tor-dev/2015-November/009961.htmlhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18757Memunit config defaults say "KB" rather than "KBytes"2022-06-17T18:36:26ZRoger DingledineMemunit config defaults say "KB" rather than "KBytes"E.g.
```
V(AuthDirFastGuarantee, MEMUNIT, "100 KB"),
V(AuthDirGuardBWGuarantee, MEMUNIT, "2 MB"),
```
and others. These should say "100 KBytes", "2 MBytes", etc, in the same way that we've updated the documentation and s...E.g.
```
V(AuthDirFastGuarantee, MEMUNIT, "100 KB"),
V(AuthDirGuardBWGuarantee, MEMUNIT, "2 MB"),
```
and others. These should say "100 KBytes", "2 MBytes", etc, in the same way that we've updated the documentation and sample configs and so on.https://gitlab.torproject.org/tpo/core/tor/-/issues/18788Make the copyright license clear for torspec and proposals2021-12-13T23:16:21ZRoger DingledineMake the copyright license clear for torspec and proposalsOnce upon a time, the tor spec files and proposals were in the Tor tarball, so they clearly were covered under Tor's copyright license (3-clause BSD).
But now they're in their own git repository.
I think maybe they technically have no ...Once upon a time, the tor spec files and proposals were in the Tor tarball, so they clearly were covered under Tor's copyright license (3-clause BSD).
But now they're in their own git repository.
I think maybe they technically have no copyright license now?
We should pick one (I vote cc-by) and try to apply it. This plan could become tricky for proposals, because there are a lot of authors on proposals by now.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19220Do not override Makefile user variables2022-06-17T14:04:35ZcypherpunksDo not override Makefile user variablesThis was supposed to be a comment to legacy/trac#19216 but i figured it's better to open a new ticket because it's out of scope.
The real solution to the issue fixed in ticket:19216#comment:4 is to stop assigning to CFLAGS (unless when ...This was supposed to be a comment to legacy/trac#19216 but i figured it's better to open a new ticket because it's out of scope.
The real solution to the issue fixed in ticket:19216#comment:4 is to stop assigning to CFLAGS (unless when testing the flag but restore the old CFLAGS after) because it's a [user variable](https://www.gnu.org/software/autoconf/manual/automake.html#User-Variables) which should never be set by the package. Instead the additional parameters should be assigned to a temporary variable (like `TOR_CFLAGS` or something) which can be `AC_SUBST`ed and appended to `AM_CFLAGS`. The same can be said about `CPPFLAGS` and `LDFLAGS`. For more information see [https://www.gnu.org/software/autoconf/manual/automake.html#Flag-Variables-Ordering].
Overriding user variables also causes issues when trying to run `make distcheck` in build directories that are configured with `--enable-fatal-warnings`. It seems the overridden CFLAGS are integrated into the tarball and causes the default Autoconf checks to fail.https://gitlab.torproject.org/tpo/core/tor/-/issues/19507tor and tor-gencert disagree on what a month is2022-06-17T16:16:51Zweasel (Peter Palfrader)tor and tor-gencert disagree on what a month isIf I create a new authority-signing-key on June 1st at 00:00 with a life time of 5 months using tor-gencert, then the new authority signing certificate will expire November 1st at 00:00.
If I create a new identity signing key on June 1s...If I create a new authority-signing-key on June 1st at 00:00 with a life time of 5 months using tor-gencert, then the new authority signing certificate will expire November 1st at 00:00.
If I create a new identity signing key on June 1st at 00:00 with a life time of 5 months using tor, then the new identity signing cert will expire October 31st at 06:00.
Obviously this disagreement is suboptimal.https://gitlab.torproject.org/tpo/core/tor/-/issues/19661tor refuses to use /dev/null as a config file2022-06-17T16:11:07Zweasel (Peter Palfrader)tor refuses to use /dev/null as a config filesometimes it is useful to make sure tor does not load any values from a config file, and -f /dev/null is the default way to give it an empty one on linux.
Tor now refuses to use that as a file.sometimes it is useful to make sure tor does not load any values from a config file, and -f /dev/null is the default way to give it an empty one on linux.
Tor now refuses to use that as a file.https://gitlab.torproject.org/tpo/core/tor/-/issues/20469Expose predicted-ports state over the control port2023-09-13T17:23:57ZRoger DingledineExpose predicted-ports state over the control portWhile debugging legacy/trac#19969 I wanted to ask my Tor whether it had any predicted ports in its internal state. But I think there is no way to ask it? I would like a 'getinfo predicted-ports' or the like.While debugging legacy/trac#19969 I wanted to ask my Tor whether it had any predicted ports in its internal state. But I think there is no way to ask it? I would like a 'getinfo predicted-ports' or the like.https://gitlab.torproject.org/tpo/core/tor/-/issues/20827Record guards' ed25519 identities2022-06-17T17:46:16ZNick MathewsonRecord guards' ed25519 identitieshttps://gitlab.torproject.org/tpo/core/tor/-/issues/21133Add stem support to expose ed25519 relay key expire date2022-06-16T18:00:56ZTom Rittertom@ritter.vgAdd stem support to expose ed25519 relay key expire date"Stem should presently support everything in descriptors." so hopefully the expiredate is in there."Stem should presently support everything in descriptors." so hopefully the expiredate is in there.https://gitlab.torproject.org/tpo/core/tor/-/issues/21281Allow process poll rate to be customized2022-06-22T15:13:46ZDamian JohnsonAllow process poll rate to be customizedHi Nick, I've been digging into Stem test performance with an aim of making them faster. Our tests regarding OwningControllerProcess take fifteen seconds each because that's the poll rate of the tor process. Looks like this is defined at...Hi Nick, I've been digging into Stem test performance with an aim of making them faster. Our tests regarding OwningControllerProcess take fifteen seconds each because that's the poll rate of the tor process. Looks like this is defined at...
https://gitweb.torproject.org/tor.git/tree/src/common/procmon.c#n165
Would you mind making this customizable (probably via a hidden double-underscore torrc options)? This will let me make our tests run faster for us both. :)
Thanks!https://gitlab.torproject.org/tpo/core/tor/-/issues/21413Exits can get the Exit flag without having any ports in their microdescriptor...2022-06-22T15:51:15ZteorExits can get the Exit flag without having any ports in their microdescriptor port summaryAlmost all clients, relays, and authorities use microdescriptors by default.
Microdescriptor port summaries include a port if it exits to almost all IPv4 addresses (blocks no more than an IPv4 /7).
But the Exit flag is given if at leas...Almost all clients, relays, and authorities use microdescriptors by default.
Microdescriptor port summaries include a port if it exits to almost all IPv4 addresses (blocks no more than an IPv4 /7).
But the Exit flag is given if at least two of ports 80, 443, 6667 exit to at least an IPv4 /8.
This means an Exit can get the Exit flag, without having any of these ports in its IPv4 exit policy summary.
I suggest we only award the Exit flag if an Exit has at least two of ports 80, 443, 6667 in its IPv4 Exit policy summary.
This also requires a spec change for the Exit flag.https://gitlab.torproject.org/tpo/core/tor/-/issues/21465Tor relays fix data directory permissions, but tor clients do not2022-06-17T16:10:33ZteorTor relays fix data directory permissions, but tor clients do notWhen adding control socket support to chutney (legacy/trac#21462), I discovered that relays set their data directory permissions to 0700 as a side-effect of adding keys to the keys directory.
But clients don't, because they don't have a...When adding control socket support to chutney (legacy/trac#21462), I discovered that relays set their data directory permissions to 0700 as a side-effect of adding keys to the keys directory.
But clients don't, because they don't have any (filesystem) keys.
Is the client state file worth protecting with 0700?
Would we have many fewer ControlSocket permissions errors if we changed the DataDirectory to 0700?https://gitlab.torproject.org/tpo/core/tor/-/issues/21910Refactor connection_edge_process_relay_cell()2022-06-17T17:40:30ZDavid Gouletdgoulet@torproject.orgRefactor connection_edge_process_relay_cell()Ticket legacy/trac#16706 is one of the possible many issues we had and will have with this function.
It is quite big with many many return callsite and it is confusing on how it behaves. For instance, if `-reason` is returned, the calle...Ticket legacy/trac#16706 is one of the possible many issues we had and will have with this function.
It is quite big with many many return callsite and it is confusing on how it behaves. For instance, if `-reason` is returned, the caller should teardown the circuit and log warn but yet this functions already does many `LOG_PROTOCOL_WARN` in that case.
One thing we could do is maybe return a different error code (or set an error code) depending on what's happening (should close circ, cell dropped, error). For instance, currently, returning 0 can either mean that a cell was dropped or successfully relayed.
Auditing every callsite of this function would be important to understand how it is actually used so we can properly improve it and make it less error prone with dubious logging (or improved logging).https://gitlab.torproject.org/tpo/core/tor/-/issues/40519pluggable transport specs need to be more consistent about quoting2022-06-17T18:05:54ZTaylor Yupluggable transport specs need to be more consistent about quotingThere's some inconsistency among the specs (and code doesn't necessarily match the specs either) about how pluggable transports quote or escape special characters in transport arguments. See legacy/trac#12930 for additional background.
...There's some inconsistency among the specs (and code doesn't necessarily match the specs either) about how pluggable transports quote or escape special characters in transport arguments. See legacy/trac#12930 for additional background.
Proposal:
* Explicitly disallow whitespace (or control characters for that matter) in keys or values of PT arguments. (No PT does this now that I know of, and people with Unix-ish backgrounds are likely to avoid using whitespace in this context anyway.)
* Explicitly disallow `=` and `\` in keys of PT arguments. (I'm assuming PT designers have more flexibility in choosing keys than value encodings, but if this poses a problem for someone please speak up.)
* Allow but discourage `=` in values of PT arguments. (If you encode something in base64 or base32, try to truncate the trailing padding.)
* Allow but discourage `\` in values of PT arguments.
* Require `\` to be escaped by `\` (in addition to escaping `,`, which is already required) in `SMETHOD ARGS` and `transport` lines of `extra-info` documents. (Almost everywhere else I've seen that uses `\` for escaping also requires that `\` itself be escaped, and it's closer to what people already expect. goptlib already implemented this despite it not being specified in `pt-spec.txt`)
* Do not require `=` to be escaped by `\` in `SMETHOD ARGS` and `transport` lines of `extra-info` documents.
* Do not require any PT argument characters to be escaped in BridgeDB output or `Bridge` lines in `torrc`. (Any `\` characters stand for themselves. This requires the fewest changes to existing `tor` code.)