Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:23:14Zhttps://gitlab.torproject.org/legacy/trac/-/issues/25530Closing Tor cleanly from command line (when started from command line) on win322020-06-13T15:23:14ZTracClosing Tor cleanly from command line (when started from command line) on win32When I close Tor after a session being started through Tor Browser, I see the log:
```
Mar 11 02:21:08.000 [notice] Owning controller connection has closed -- exiting now.
Mar 11 02:21:08.000 [notice] Catching signal TERM, exiting clean...When I close Tor after a session being started through Tor Browser, I see the log:
```
Mar 11 02:21:08.000 [notice] Owning controller connection has closed -- exiting now.
Mar 11 02:21:08.000 [notice] Catching signal TERM, exiting cleanly.
```
I think there's some operations Tor does in order to close it self cleanly.
I usually run Tor over command line (_**Windows 10**_) through:
```
cd "C:\Tor Browser\Browser\"
"C:\Tor Browser\Browser\TorBrowser\Tor\tor.exe" -f "C:\Tor Browser\Browser\TorBrowser\Data\Tor\torrc" | more
```
I just kill the _tor.exe_ process in order to close it. I don't get those two logs.
How could I close Tor cleanly through command line?
**Trac**:
**Username**: omareg94Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25456tor's systemd service should SIGHUP tor on resume/thaw after sleep/hibernate2020-06-13T15:22:51ZIsis Lovecrufttor's systemd service should SIGHUP tor on resume/thaw after sleep/hibernateI very often need to SIGHUP my tor process after reopening my laptop after the new guard algorithm was merged (I had to also do so before, but now it's seemingly worse), and I hear from other users who are more technically-inclined that ...I very often need to SIGHUP my tor process after reopening my laptop after the new guard algorithm was merged (I had to also do so before, but now it's seemingly worse), and I hear from other users who are more technically-inclined that there experience is the same. Humans doing things computers can do is bad UX. I propose, at the very least, on *nix systems that we modify the systemd `.service` file(s) we already distribute to do this for the human. (We should also figure out some equivalent for MacOS, Windows, and mobile, if possible, but those can be separate tickets.)
From reading [this question](https://askubuntu.com/questions/661715/make-a-script-start-after-suspend-in-ubuntu-15-04-systemd/661747#661747) that femme linked me to, it looks like the way to do it is either a script which gets installed into `/lib/systemd/system-sleep/`, or a second `.service` file that is wanted by `suspend.target`. I'm not sure which is cleaner? I would assume the `.service` file approach is cleaner, because then it can be selectively enabled/disabled by the human more easily.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22703Add a KeyDirectory option to override location of $datadir/keys, and/or a cac...2020-06-13T15:46:16ZNick MathewsonAdd a KeyDirectory option to override location of $datadir/keys, and/or a cachedir option to override location of cached files.It is at least mildly naughty how Tor currently uses the same DataDirectory for both persistent secret things (keys), persistent sensitive things (the state file), runtime stuff (the lock file), and cached objects (cached-*). Perhaps we...It is at least mildly naughty how Tor currently uses the same DataDirectory for both persistent secret things (keys), persistent sensitive things (the state file), runtime stuff (the lock file), and cached objects (cached-*). Perhaps we should provide options to split these up?
This might help a bit with memory usage on platforms where /var is a tmpfs. In #7176, there was an openwrt patch that changed the key directory to a hardcoded path, but that's obviously not mergeable in mainline tor.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22700Stop relays using the Client*IPv6* options2020-06-13T15:10:30ZteorStop relays using the Client*IPv6* optionsSome operators add all the IPv6 options to their torrcs.
We should warn when they add client options on relays.Some operators add all the IPv6 options to their torrcs.
We should warn when they add client options on relays.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22619SessionGroup = Reading config failed2020-06-13T15:10:12ZTracSessionGroup = Reading config failedIf i specify SessionGroup as described in manual. tor stops with error.
torrc:
SocksPort 9051 SessionGroup=1
Jun 15 16:46:24.700 [warn] Invalid SocksPort option '"SessionGroup=INT"'
Jun 15 16:46:24.700 [warn] Failed to parse/validate...If i specify SessionGroup as described in manual. tor stops with error.
torrc:
SocksPort 9051 SessionGroup=1
Jun 15 16:46:24.700 [warn] Invalid SocksPort option '"SessionGroup=INT"'
Jun 15 16:46:24.700 [warn] Failed to parse/validate config: Invalid SocksPort/SocksListenAddress configuration
Jun 15 16:46:24.701 [err] Reading config failed--see warnings above.
second try
SocksPort 9051 SessionGroup=INT
Results into:
Jun 15 16:46:35.677 [warn] Invalid SocksPort option '"SessionGroup=1"'
Jun 15 16:46:35.678 [warn] Failed to parse/validate config: Invalid SocksPort/SocksListenAddress configuration
Jun 15 16:46:35.677 [warn] Invalid SocksPort option '"SessionGroup=1"'
Jun 15 16:46:35.678 [warn] Failed to parse/validate config: Invalid SocksPort/SocksListenAddress configuration
Jun 15 16:46:35.678 [err] Reading config failed--see warnings above.
**Trac**:
**Username**: acceleraTorTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22469tor should probably reject "0x00" in port range specifications2020-06-13T15:09:55Ztoralftor should probably reject "0x00" in port range specificationssomething like
```
ExitPolicy reject6 [2a00:1450:4001:0815:0000:0000:0000:200e]:0x00
```
should spew an error message.something like
```
ExitPolicy reject6 [2a00:1450:4001:0815:0000:0000:0000:200e]:0x00
```
should spew an error message.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22203Should a hup reload the geoip files?2020-06-13T15:08:37ZRoger DingledineShould a hup reload the geoip files?In config.c in config_maybe_load_geoip_files_() we have this line:
```
/* XXXX Reload GeoIPFile on SIGHUP. -NM */
```
and sure enough, it looks like there's nothing in main.c's do_hup() that would make us reload the geoip files.
It w...In config.c in config_maybe_load_geoip_files_() we have this line:
```
/* XXXX Reload GeoIPFile on SIGHUP. -NM */
```
and sure enough, it looks like there's nothing in main.c's do_hup() that would make us reload the geoip files.
It would be relatively easy to do I think:
* In do_hup(), right around the call to routerlist_reset_warnings(), we call something in geoip.c that tells it to no longer consider itself initialized. Maybe that call is something like clear_geoip_db().
* Then in config_maybe_load_geoip_files_(), since geoip_is_loaded() returns 0, it loads them.
Things get tricky though: catalyst asked if reloading the geoip files messes up the statistics gathering.
If reloading the geoip files *does* mess up statistics gathering, we have ourselves a minor bug, since config_maybe_load_geoip_files_() does reload them if the GeoIPFile location changes.
But it turns out to be more complicated than that, since geoip_load_file() only clears selective things: it clears geoip_ipv4_entries and geoip_ipv6_entries, but it leaves geoip_countries alone! And I see elsewhere, at the bottom of geoip_note_client_seen(), that we are keeping statistics directly in the geoip_countries smartlist:
```
geoip_country_t *country = smartlist_get(geoip_countries, country_idx);
++country->n_v3_ns_requests;
```
So we would not want to call clear_geoip_db() on hup, or we'd lose some stats.
I guess that means if we want to make do_hup reload the geoip stats file, the better (non-invasive) plan is to have a boolean want_to_reload_geoip{4,6} in geoip.c that we turn on in do_hup, and then we check the right boolean in geoip_is_loaded().
I think there's a big argument for growing some good unit tests here, around "what happens when we reload this, collect those stats, reload that, examine those other stats, etc", since things are either subtly broken right now, or awfully fragile.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22094Creating private_key/hostname fails with "RO filesystem" message but target d...2020-06-13T15:08:16ZTracCreating private_key/hostname fails with "RO filesystem" message but target dir is actually RWVersion: 0.2.9.10 (git-e28303bcf90b842d) on debian jessie live iso
## Problem
```
Apr 28 10:22:58.000 [warn] Couldn't open "/var/tor/hidden_site/private_key.tmp" (/var/tor/hidden_site/private_key) for writing: Read-only file system
Apr...Version: 0.2.9.10 (git-e28303bcf90b842d) on debian jessie live iso
## Problem
```
Apr 28 10:22:58.000 [warn] Couldn't open "/var/tor/hidden_site/private_key.tmp" (/var/tor/hidden_site/private_key) for writing: Read-only file system
Apr 28 10:22:58.000 [err] Couldn't write generated key to "/var/tor/hidden_site/private_key".
```
## Wanted behaviour
These files are to be written in a directory which *IS* writable by the designated running user
These error/warning message seem wrong, and the creating of the hidden service is rendered impossible, if running through systemd
## Steps to reproduce
1) run debian-live-8.7.1-amd64-standard.iso is live mode
2) run following commands
```
gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
cat << "EOF" | sudo tee /etc/apt/sources.list.d/tor.list
deb http://deb.torproject.org/torproject.org jessie main
deb-src http://deb.torproject.org/torproject.org jessie main
EOF
sudo apt-get update
sudo apt-get install deb.torproject.org-keyring
sudo apt-get install tor
sudo systemctl stop tor
sudo mkdir -p /var/tor
sudo mount -t tmpfs tmpfs /var/tor/
sudo mkdir -p /var/tor/hidden_site
sudo chmod 700 /var/tor/hidden_site
sudo chown debian-tor:debian-tor /var/tor/hidden_site
cat << "EOF" | sudo tee /etc/tor/torrc
HiddenServiceDir /var/tor/hidden_site
HiddenServicePort 80 127.0.0.1:8080
EOF
sudo -u debian-tor tor --verify-config
sudo systemctl start tor
```
NOTE: mounting a tmpfs is just an attempt at making sure no RO filesystem was in the game...
3) tor log
```
Apr 28 10:22:58.000 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) opening log file.
Apr 28 10:22:58.067 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Apr 28 10:22:58.067 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 28 10:22:58.067 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 28 10:22:58.067 [notice] Read configuration file "/etc/tor/torrc".
Apr 28 10:22:58.071 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 28 10:22:58.000 [warn] Couldn't open "/var/tor/hidden_site/private_key.tmp" (/var/tor/hidden_site/private_key) for writing: Read-only file system
Apr 28 10:22:58.000 [err] Couldn't write generated key to "/var/tor/hidden_site/private_key".
Apr 28 10:22:58.000 [warn] Error loading rendezvous service keys
Apr 28 10:22:58.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.2.9.10 )
```
## Actual mountpoints
```
aufs on / type aufs (rw,noatime,si=2cb2b7e036b24d5d,noxino)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=10240k,nr_inodes=124323,mode=755)
/dev/sr0 on /lib/live/mount/medium type iso9660 (ro,noatime)
tmpfs on /lib/live/mount/overlay type tmpfs (rw,noatime,mode=755)
tmpfs on /lib/live/mount/overlay type tmpfs (rw,relatime)
/dev/loop0 on /lib/live/mount/rootfs/filesystem.squashfs type squashfs (ro,noatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=204864k,mode=755)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /var/tor type tmpfs (rw,relatime)
```
## Manual run
If instead of running tor via systemctl, we then launch it manually in shell through ssh :
```
sudo /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
```
`ps auxf` confirms it runs as `debian-tor`.
Here everything goes fine :
```
Apr 28 13:00:41.281 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Apr 28 13:00:41.281 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 28 13:00:41.281 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 28 13:00:41.282 [notice] Read configuration file "/etc/tor/torrc".
Apr 28 13:00:41.286 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 28 13:00:41.000 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) opening log file.
Apr 28 13:00:41.281 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Apr 28 13:00:41.281 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 28 13:00:41.281 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 28 13:00:41.282 [notice] Read configuration file "/etc/tor/torrc".
Apr 28 13:00:41.286 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 28 13:00:41.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Apr 28 13:00:41.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Apr 28 13:00:41.000 [notice] Bootstrapped 0%: Starting
Apr 28 13:00:41.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Apr 28 13:00:42.000 [notice] Opening Socks listener on /var/run/tor/socks
Apr 28 13:00:42.000 [notice] Opening Control listener on /var/run/tor/control
Apr 28 13:00:42.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Apr 28 13:00:42.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Apr 28 13:00:43.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Apr 28 13:00:43.000 [notice] Bootstrapped 100%: Done
```
The hidden service files are created :
```
sudo find /var/tor -ls
31802 0 drwxrwxrwt 3 root root 60 Apr 28 12:30 /var/tor
31841 0 drwx------ 2 debian-tor debian-tor 80 Apr 28 13:00 /var/tor/hidden_site
36795 4 -rw------- 1 debian-tor debian-tor 23 Apr 28 13:00 /var/tor/hidden_site/hostname
36794 4 -rw------- 1 debian-tor debian-tor 887 Apr 28 13:00 /var/tor/hidden_site/private_key
```
**Trac**:
**Username**: nipilTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21975Refactor all the startup stuff in config.c, with dependencies in mind2020-06-13T15:07:58ZRoger DingledineRefactor all the startup stuff in config.c, with dependencies in mindMotivated by #21974:
"""
We sure have a bunch of stuff we do at startup now, and the dependency graph of what has to happen before what is complicated, and I bet there are bugs in the current order of things. It would be a swell project ...Motivated by #21974:
"""
We sure have a bunch of stuff we do at startup now, and the dependency graph of what has to happen before what is complicated, and I bet there are bugs in the current order of things. It would be a swell project for somebody to make a list of all the things we do at startup, and figure out their dependencies, and sort them into "waves" or something, and then refactor the stuff in config.c so it matches the new world order.
"""Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21597ExitRelay configuration option is confusingly named2020-06-13T15:06:50ZcypherpunksExitRelay configuration option is confusingly namedI imagine this is already well known, and that the option is very unlikely to change names, but I wish to identify the issue regardless. Perhaps the consideration of phasing in a new option with a more descriptive name is valid.
As I u...I imagine this is already well known, and that the option is very unlikely to change names, but I wish to identify the issue regardless. Perhaps the consideration of phasing in a new option with a more descriptive name is valid.
As I understand, the ExitRelay config option applies to non-exit relays in addition to exit relays. It is not considered for bridge relays (which are by definition non-exit and in a separate classification entirely).
This is confusing when configuring a non-exit, non-bridge relay. The confusion can be avoided by renaming the option to e.g. "AllowTraffic" or "AllowExitingTraffic" (or "AllowOutbound"/"Traffic" ... "...Outgoing...").
It seems the ExitRelay option is intended to be more of a safety switch to accommodate a transition in Tor concepts (the addition of bridge relays, I believe) without introducing breaking changes, rather than actually having anything to do with establishing a configured relay as an "exit" relay, as one might easily misunderstand.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21530Make ExitRelay 0 the default when there is no exit policy2020-06-13T15:38:46ZteorMake ExitRelay 0 the default when there is no exit policyWe have logged a message saying we might do this for a while.
This caused chutney bug #17090.We have logged a message saying we might do this for a while.
This caused chutney bug #17090.Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21281Allow process poll rate to be customized2020-06-13T15:05:34ZDamian 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!Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21115Building Tor With Static SNI2020-06-13T15:05:04ZTracBuilding Tor With Static SNII want to have a static value of SNI in TOR in Https Connection. TOR currently uses Random SNI but Firewall is blocking it by checking random SNI.
I have changed crypto_random_hostname to a Static char* in /src/common/tortls.c to a fixed...I want to have a static value of SNI in TOR in Https Connection. TOR currently uses Random SNI but Firewall is blocking it by checking random SNI.
I have changed crypto_random_hostname to a Static char* in /src/common/tortls.c to a fixed string but after that it is not working.
**Trac**:
**Username**: mintu.juit@gmail.comTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21043Make ClientUseIPv4 and ClientUseIPv6 equivalent to ReachableAddresses2020-06-13T15:04:47ZteorMake ClientUseIPv4 and ClientUseIPv6 equivalent to ReachableAddressesOnce #20996 is fixed, we should also make ClientUseIPv4 and ClientUseIPv6 work the same as the equivalent ReachableAddresses settings.
For example:
ClientUseIPv4 = accept/reject 0.0.0.0/0 = accept/reject *4
ClientUseIPv6 = accept/reject...Once #20996 is fixed, we should also make ClientUseIPv4 and ClientUseIPv6 work the same as the equivalent ReachableAddresses settings.
For example:
ClientUseIPv4 = accept/reject 0.0.0.0/0 = accept/reject *4
ClientUseIPv6 = accept/reject [::]/0 = accept6/reject6 * = accept/reject *6
Bootstrap and guards should also work if ReachableAddresses blocks almost all addresses of a particular type.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20919Extract prop271 state-parsing code into a generic thing2020-06-13T15:04:10ZNick MathewsonExtract prop271 state-parsing code into a generic thingTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20874ReachableAddresses adds an extra reject *:* on every SAVECONF2020-06-13T15:03:59ZteorReachableAddresses adds an extra reject *:* on every SAVECONFTo fix this issue, we can do two things:
1) We should add the reject *:* to a copy of the list after it has been parsed in parse_reachable_addresses() using append_exit_policy_string(), rather than adding it to the option itself in opti...To fix this issue, we can do two things:
1) We should add the reject *:* to a copy of the list after it has been parsed in parse_reachable_addresses() using append_exit_policy_string(), rather than adding it to the option itself in options_validate().
2) We might also want to call exit_policy_remove_redundancies() on the parsed policy, so that long policies with redundancies are handled more efficiently. This is only likely to ever matter on busy hidden services.Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/20719prop271 -- make parameters configurable2020-06-13T15:03:36ZNick Mathewsonprop271 -- make parameters configurableTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20606Make the test network exponential backoff multiplier configurable2020-06-13T15:03:08ZteorMake the test network exponential backoff multiplier configurableIn #20597, we hard-coded a multiplier of 2 (exponent 3) in test networks, and a multiplier of 3 (exponent 4) by default. These should probably be configurable using a torrc option.
This task should be performed after we modify the expon...In #20597, we hard-coded a multiplier of 2 (exponent 3) in test networks, and a multiplier of 3 (exponent 4) by default. These should probably be configurable using a torrc option.
This task should be performed after we modify the exponential backoff distributions in #20604 and #20605.
Follow-up to #20499, #20597, and #20534.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20340nice to have: test torrc for incompatible transistions of config values2020-06-13T15:02:00Ztoralfnice to have: test torrc for incompatible transistions of config valuesUnder Gentoo we do have a config check in the OpenRc script:
"${command} --verify-config --hush"
But unfortunately that will not catch the case where the config is ok but a reload will fail due to changes eg. from "SandBox 0" to "SandBox...Under Gentoo we do have a config check in the OpenRc script:
"${command} --verify-config --hush"
But unfortunately that will not catch the case where the config is ok but a reload will fail due to changes eg. from "SandBox 0" to "SandBox 1".
It would be a nifty feature to prevent a reload of Tor in such a case.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19034Declaring authorities with matching relay keys should fail2020-06-13T14:57:19ZteorDeclaring authorities with matching relay keys should failIf a:
* hard-coded entry or
* config entry,
tries to add:
* an authority,
* a bridge authority, or
* a fallback directory,
with the same:
* relay key,
* v3ident key,
* IPv4 address and ORPort (matching any other IPv4 address and port)...If a:
* hard-coded entry or
* config entry,
tries to add:
* an authority,
* a bridge authority, or
* a fallback directory,
with the same:
* relay key,
* v3ident key,
* IPv4 address and ORPort (matching any other IPv4 address and port), or
* IPv4 address and DirPort (matching any other IPv4 address and port),
* IPv6 address and ORPort (matching any other IPv6 address and port), or
* IPv6 address and (IPv4) DirPort (matching any other IPv6 address and port),
as an existing entry, tor should warn and refuse to start.Tor: unspecified