The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-06-17T17:55:24Zhttps://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/20827Record guards' ed25519 identities2022-06-17T17:46:16ZNick MathewsonRecord guards' ed25519 identitieshttps://gitlab.torproject.org/tpo/core/tor/-/issues/26900Reduce background compression thread priority2022-06-17T17:45:50ZAlex XuReduce background compression thread priorityAs I understand, the compression is not latency-sensitive, i.e. if we get it done 30 seconds or 1 minute later, nobody really minds, but if we process 10000 packets 200 ms slower, that materially affects user experience. Also, I think if...As I understand, the compression is not latency-sensitive, i.e. if we get it done 30 seconds or 1 minute later, nobody really minds, but if we process 10000 packets 200 ms slower, that materially affects user experience. Also, I think if you do not set the thread priority, modern schedulers may assume that because it runs infrequently, the compression task is a "foreground" or "interactive" task and the actual cell relaying is a "background" task that may be slowed down to minimize user impact, exactly the opposite of what we want.
Therefore, this should improve single-CPU relay performance (and multi-CPU relay performance once we implement better multithreading).https://gitlab.torproject.org/tpo/core/tor/-/issues/22463Reduce REACHABLE_TIMEOUT in test networks2022-06-17T17:42:19ZteorReduce REACHABLE_TIMEOUT in test networksWhen we test relay failure in chutney networks, relays aren't removed from the consensus for 45 minutes. That's way too long.When we test relay failure in chutney networks, relays aren't removed from the consensus for 45 minutes. That's way too long.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/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/27334RelaxDirModeCheck on ControlSocket still requires group to m2022-06-17T17:36:58ZTracRelaxDirModeCheck on ControlSocket still requires group to mEven with RelaxDirModeCheck flag on the ControlSocket tor requires
the folder (containing the socket file) group to match the group of the user running tor.
Could you lift this requirement when the RelaxDirModeCheck flag is given or is ...Even with RelaxDirModeCheck flag on the ControlSocket tor requires
the folder (containing the socket file) group to match the group of the user running tor.
Could you lift this requirement when the RelaxDirModeCheck flag is given or is there an important reason for that?
os: FreeBSD 11.2
conf:
```
ControlSocket /var/run/tor-instances/123/controlsocket GroupWritable RelaxDirModeCheck
```
log:
```
Before Tor can create a control socket in "/var/run/tor-instances/123/controlsocket", the directory "/var/run/tor-instances/123" needs to exist, and to be accessible only by the user and group account that is running Tor. (On some Unix systems, anybody who can list a socket can connect to it, so Tor is being careful.)
```
**Trac**:
**Username**: a_phttps://gitlab.torproject.org/tpo/core/tor/-/issues/9494Remove gratuitous newlines from log messages?2022-06-17T17:34:26ZgrarpampRemove gratuitous newlines from log messages?These log entries (debug, domains) are either
- missing facility
t [notice] Tor v0.2.3.25 (git-r) running on o.
t [notice] Tor can't help you if you use it wrong! Learn how to
t [notice] Read configuration file "/.../torrc".
t [notice...These log entries (debug, domains) are either
- missing facility
t [notice] Tor v0.2.3.25 (git-r) running on o.
t [notice] Tor can't help you if you use it wrong! Learn how to
t [notice] Read configuration file "/.../torrc".
t [notice] Initialized libevent version 2.0.21-stable using method
t [notice] Opening Socks listener on 127.0.0.1:9051
t [notice] Opening Control listener on 127.0.0.1:9050
t [warn] Fixing permissions on directory /.../tor
- missing time, level and facility, and probably need one-lined
0 create
64 created
6494 relay
(644 relayed)
(6494 delivered)
50 destroyhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31647Should OBSOLETE and ___invisible configuration obtions be available to GETCONF?2022-06-17T16:36:34ZNick MathewsonShould OBSOLETE and ___invisible configuration obtions be available to GETCONF?Right now, you can use GETCONF on the invisible `___UsingTestNetworkDefaults` or the obsolete `DisableIOCP` -- without any complaint from Tor.
Perhaps Tor should complain, or even reject these requests.Right now, you can use GETCONF on the invisible `___UsingTestNetworkDefaults` or the obsolete `DisableIOCP` -- without any complaint from Tor.
Perhaps Tor should complain, or even reject these requests.https://gitlab.torproject.org/tpo/core/tor/-/issues/28344Should we log \r\n on Windows?2022-06-17T16:36:14ZteorShould we log \r\n on Windows?Tor's logging code terminates strings with \n.
When I run tor.exe via the command prompt on Windows, I don't see any of the log output, because there's no \r at the end of the line.
Should we make tor log \r\n on Windows?Tor's logging code terminates strings with \n.
When I run tor.exe via the command prompt on Windows, I don't see any of the log output, because there's no \r at the end of the line.
Should we make tor log \r\n on Windows?https://gitlab.torproject.org/tpo/core/tor/-/issues/32354Support "Cache Directory Tagging Standard" (already implemented e.g. in GNU tar)2022-06-17T16:22:17ZTracSupport "Cache Directory Tagging Standard" (already implemented e.g. in GNU tar)Tor seems to store sizable cached data in /var/lib/tor/diff-cache/. There is now a standard for apps to indicate that transient caches like this to be skipped from backups: https://bford.info/cachedir/spec.html
The application needs to ...Tor seems to store sizable cached data in /var/lib/tor/diff-cache/. There is now a standard for apps to indicate that transient caches like this to be skipped from backups: https://bford.info/cachedir/spec.html
The application needs to create (and recreate) a file called "CACHEDIR.TAG" in the cache directory, with content of "Signature: 8a477f597d28d172789f06886806bc55".
Skipping cache directories marked as such via this standard is already supported for example in GNU tar:
--exclude-caches
Exclude contents of directories containing file CACHEDIR.TAG, except for the tag file itself.
--exclude-caches-all
Exclude directories containing file CACHEDIR.TAG and the file itself.
--exclude-caches-under
Exclude everything under directories containing CACHEDIR.TAG
**Trac**:
**Username**: rmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29573Tests fail without network interface configured2022-06-17T16:19:03ZTracTests fail without network interface configuredI build packages on Linux as an unprivileged user inside a network namespace with no interfaces configured (to catch packages that try to use Internet resources during the build process). With tor 0.3.5.7 and earlier, this worked fine an...I build packages on Linux as an unprivileged user inside a network namespace with no interfaces configured (to catch packages that try to use Internet resources during the build process). With tor 0.3.5.7 and earlier, this worked fine and the test suite passed completely.
With tor 0.3.5.8, three test cases fail:
```
address/get_if_addrs_list_internal: Feb 24 12:59:28.031 [err] connect() failed: Network is unreachable
[get_if_addrs_list_internal FAILED]
address/get_if_addrs_list_no_internal: Feb 24 12:59:28.040 [err] connect() failed: Network is unreachable
[get_if_addrs_list_no_internal FAILED]
address/get_if_addrs: Feb 24 12:59:28.309 [err] connect() failed: Network is unreachable
[get_if_addrs FAILED]
```
Here's strace output for one of the failures:
```
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_UDP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(9), sin_addr=inet_addr("18.0.0.1")}, 16) = -1 ENETUNREACH (Network is unreachable)
```
So this looks like get_interface_address6_via_udp_socket_hack failing - comments in the tests suggest that they ought to be getting an empty list rather than an error in this circumstance?
**Trac**:
**Username**: atsampsonhttps://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/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/2914Tor should truncate log file if loglevel < notice2022-06-17T16:09:19ZMike PerryTor should truncate log file if loglevel < noticeA lot of relay operators run tor from git for various reasons. These relay operators don't get the advantage of distribution log rotation, and can unknowingly leave tor running at low log level for long periods while running test branche...A lot of relay operators run tor from git for various reasons. These relay operators don't get the advantage of distribution log rotation, and can unknowingly leave tor running at low log level for long periods while running test branches. In some cases, SafeLogging may also be disabled.
Presumably, since they are running git, they are upgrading often. Based on this assumption, an easy fix should be to just change the default log file open mode from O_APPEND to O_TRUNC if the loglevel is below notice, and/or if SafeLogging is off.
Of course, a better fix is to implement our own log rotation. I don't think the corner case is that important. It is a non-default config that makes it risky** in the first place.
Thanks to Marcia Hofmann @ EFF for pointing this out.
** (The reason it is risky is not because logs are terribly dangerous to anonymity in their current form, but moreso because logs can be such a false path due to the multiplexing of circuits over TLS.)https://gitlab.torproject.org/tpo/core/tor/-/issues/22214When authority certificates expire, give a better error message2022-06-17T14:15:04ZteorWhen authority certificates expire, give a better error messageOn master, I have a test directory authority on i386 macOS 10.12 which can't download certificates. The directory authority had been down (asleep) for a while, and on update to the new master, it said:
```
May 10 19:02:28.645 [notice] T...On master, I have a test directory authority on i386 macOS 10.12 which can't download certificates. The directory authority had been down (asleep) for a while, and on update to the new master, it said:
```
May 10 19:02:28.645 [notice] Tor 0.3.1.0-alpha-dev (git-0266c4ac819d9c83) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2k, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
...
May 10 19:03:15.000 [warn] Got a certificate for lemonpeasy, but we already have it. Maybe they haven't updated it. Waiting for a while.
May 10 19:03:15.000 [warn] Got a certificate for triplepeak, but we already have it. Maybe they haven't updated it. Waiting for a while.
May 10 19:03:15.000 [warn] Got a certificate for Betty, but we already have it. Maybe they haven't updated it. Waiting for a while.
May 10 19:03:15.000 [warn] Got a certificate for Evelyn, but we already have it. Maybe they haven't updated it. Waiting for a while.
May 10 19:03:15.000 [warn] Got a certificate for albert, but we already have it. Maybe they haven't updated it. Waiting for a while.
May 10 19:03:15.000 [warn] Got a certificate for missionary, but we already have it. Maybe they haven't updated it. Waiting for a while.
...
May 10 19:04:16.000 [warn] Looks like we need to download a new certificate from authority 'triplepeak' at ...
May 10 19:04:16.000 [warn] Looks like we need to download a new certificate from authority 'Betty' at ...
```
I suspect this bug might have been introduced in 0.3.1. Or, it might be due to the fact our test network consensus is broken. Or it could be because we're on mixed versions (which should work).https://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/26797DirAuths should only read the V3BandwidthsFile once per vote2022-06-17T13:55:19ZteorDirAuths should only read the V3BandwidthsFile once per voteEvery time we read the file, we increase the risk of race conditions, where some code reads one version of the file, and other code reads another version.
See legacy/trac#26702 for details.
If we implement legacy/trac#21377, we should ...Every time we read the file, we increase the risk of race conditions, where some code reads one version of the file, and other code reads another version.
See legacy/trac#26702 for details.
If we implement legacy/trac#21377, we should do this refactor first.https://gitlab.torproject.org/tpo/core/tor/-/issues/14164Controller method to get our own descriptor2022-06-17T13:39:26ZtoralfController method to get our own descriptorI'm wondering why this pythin snippet
```
def main():
ControlPort = 9051
ProcessName = 'tor'
with Controller.from_port(port = ControlPort) as controller:
controller.authenticate()
#print " Tor version %s" % controller.get_...I'm wondering why this pythin snippet
```
def main():
ControlPort = 9051
ProcessName = 'tor'
with Controller.from_port(port = ControlPort) as controller:
controller.authenticate()
#print " Tor version %s" % controller.get_version()
try:
desc = controller.get_microdescriptor()
print " flags : %s" % desc.flags()
print " measured bandwidth : %i" % desc.measured()
except Exception as exc:
print exc
#pass
```
gives
```
Tor was unable to provide the descriptor for 'F1BE15429B3CE696D6807F4D4A58B1BFEC45C822'
```
Does this means that stems asks tor and tor doesn't know itself ?