The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-09-30T13:45:56Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26930Potential thundering herd HS upload once a day with hsv32021-09-30T13:45:56ZGeorge KadianakisPotential thundering herd HS upload once a day with hsv3Here is a potential bug we found with dgoulet at HOPE.
In `set_rotation_time()` we set the rotation time of the next descriptor to the next midnight UTC with no randomization at all:
```
service->state.next_rotation_time =
sr_stat...Here is a potential bug we found with dgoulet at HOPE.
In `set_rotation_time()` we set the rotation time of the next descriptor to the next midnight UTC with no randomization at all:
```
service->state.next_rotation_time =
sr_state_get_start_time_of_current_protocol_run() +
sr_state_get_protocol_run_duration();
```
After descriptors get rotated, a new descriptor is built and uploaded, so it might be the case that all hsv3s upload that new descriptor at the same time at midnight UTC.
We should investigate more.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26929[suggestion] Warning "Skipping obsolete configuration option" should suggest ...2022-06-16T15:27:07Zyurivict271[suggestion] Warning "Skipping obsolete configuration option" should suggest what the replacement isI've encountered these two messages in the log:
```
Jul 24 22:39:01.908 [warn] Skipping obsolete configuration option 'DNSListenAddress'
Jul 24 22:39:01.909 [warn] Skipping obsolete configuration option 'TransListenAddress'
```
An obvio...I've encountered these two messages in the log:
```
Jul 24 22:39:01.908 [warn] Skipping obsolete configuration option 'DNSListenAddress'
Jul 24 22:39:01.909 [warn] Skipping obsolete configuration option 'TransListenAddress'
```
An obvious improvement for such messages is to suggest what they should be replaced with.https://gitlab.torproject.org/tpo/core/tor/-/issues/26928Taint untrusted link authentication keys2021-09-30T13:45:56ZteorTaint untrusted link authentication keysWe should taint untrusted link auth keys, and then downgrade connections using tainted keys to protocol warnings.
Link auth keys from the following sources are trusted:
* hard-coded authorities
* the consensus signed by hard-coded autho...We should taint untrusted link auth keys, and then downgrade connections using tainted keys to protocol warnings.
Link auth keys from the following sources are trusted:
* hard-coded authorities
* the consensus signed by hard-coded authorities
Link auth keys from the following sources are untrusted:
* hardcoded fallback dirs, because relay keys change over time
* our state file (if not confirmed in the consensus), because relay keys change over time
* onion service descriptors, because they come from untrusted services
* onion service introduce cells, because they come from untrusted clients
Split off legacy/trac#26924.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26927Improve the log message when peer id authentication fails2020-06-27T13:52:46ZteorImprove the log message when peer id authentication failsSplit off legacy/trac#26924.Split off legacy/trac#26924.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26925Make link specifier handling in rend-spec-v3 more precise2021-07-22T16:20:36ZteorMake link specifier handling in rend-spec-v3 more preciseSplit off legacy/trac#26627.
We should specify that clients and services must not check untrusted link specifiers against the consensus:
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1338
https://gitweb.torproject.org...Split off legacy/trac#26627.
We should specify that clients and services must not check untrusted link specifiers against the consensus:
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1338
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
Services should also copy unrecognized rend point link specifiers from the introduce cell to the rendezvous join cell.
We can copy the text from the service intro->rend spec:
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
To the the client desc->intro spec:
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1338
Thanks to catalyst for picking up on these missing parts of the spec.
Edit: fix line numbersTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26924Make single onion service to rend and Tor2web to intro link authentication in...2021-09-30T13:45:56ZteorMake single onion service to rend and Tor2web to intro link authentication into a protocol warningSingle onion services and Tor2web connect directly to relays using untrusted link authentication keys.
These connections can cause a lot of warnings, particularly due to the link auth bugs in legacy/trac#26627.
We can either:
* downgra...Single onion services and Tor2web connect directly to relays using untrusted link authentication keys.
These connections can cause a lot of warnings, particularly due to the link auth bugs in legacy/trac#26627.
We can either:
* downgrade all link auth warnings to protocol warnings on single onion services and Tor2web (this is the fast fix)
* taint untrusted link auth keys, and then downgrade connections using tainted keys to protocol warnings (this is very intrusive)Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26913DataDirectoryGroupReadable enabled does not have effect2020-06-27T13:52:46ZTracDataDirectoryGroupReadable enabled does not have effectOn RedHat based systems the defaultrc includes DataDirectoryGroupReadable set to 1. But when starting up the daemon this is ignored and chmod of /var/lib/tor is set back to 0700.
This can be demostrated by the following test using vagra...On RedHat based systems the defaultrc includes DataDirectoryGroupReadable set to 1. But when starting up the daemon this is ignored and chmod of /var/lib/tor is set back to 0700.
This can be demostrated by the following test using vagrant:
```
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'centos/7'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'centos/7' is up to date...
==> default: Setting the name of the VM: tor-bug_default_1532356217662_9318
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 (guest) => 2200 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2200
default: SSH username: vagrant
default: SSH auth method: private key
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
default: No guest additions were detected on the base box for this VM! Guest
default: additions are required for forwarded ports, shared folders, host only
default: networking, and more. If SSH fails on this machine, please install
default: the guest additions and repackage the box to continue.
default:
default: This is not an error message; everything may continue to work properly,
default: in which case you may ignore this message.
==> default: Rsyncing folder: /home/mh/fedora/tor-bug/ => /vagrant
==> default: Running provisioner: shell...
default: Running: inline script
default: Installing tor
default: Loaded plugins: fastestmirror
default: Determining fastest mirrors
default: * base: mirror.spreitzer.ch
default: * extras: mirror.spreitzer.ch
default: * updates: mirror.spreitzer.ch
default: Resolving Dependencies
default: --> Running transaction check
default: ---> Package tor.x86_64 0:0.3.3.9-1.el7 will be installed
default: --> Processing Dependency: torsocks for package: tor-0.3.3.9-1.el7.x86_64
default: --> Running transaction check
default: ---> Package torsocks.x86_64 0:2.2.0-1.el7.centos will be installed
default: --> Finished Dependency Resolution
default:
default: Dependencies Resolved
default:
default: ================================================================================
default: Package Arch Version Repository Size
default: ================================================================================
default: Installing:
default: tor x86_64 0.3.3.9-1.el7 maha-tor-latest 2.8 M
default: Installing for dependencies:
default: torsocks x86_64 2.2.0-1.el7.centos maha-tor-latest 65 k
default:
default: Transaction Summary
default: ================================================================================
default: Install 1 Package (+1 Dependent package)
default:
default: Total download size: 2.9 M
default: Installed size: 13 M
default: Downloading packages:
default: Public key for torsocks-2.2.0-1.el7.centos.x86_64.rpm is not installed
default: warning: /var/cache/yum/x86_64/7/maha-tor-latest/packages/torsocks-2.2.0-1.el7.centos.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID fe1432b1: NOKEY
default: --------------------------------------------------------------------------------
default: Total 1.4 MB/s | 2.9 MB 00:02
default: Retrieving key from https://copr-be.cloud.fedoraproject.org/results/maha/tor-latest/pubkey.gpg
default: Importing GPG key 0xFE1432B1:
default: Userid : "maha_tor-latest (None) <maha#tor-latest@copr.fedorahosted.org>"
default: Fingerprint: ddc6 1efd 56fa 03e5 e2d8 fa26 03f9 1145 fe14 32b1
default: From : https://copr-be.cloud.fedoraproject.org/results/maha/tor-latest/pubkey.gpg
default: Running transaction check
default: Running transaction test
default: Transaction test succeeded
default: Running transaction
default: Installing : torsocks-2.2.0-1.el7.centos.x86_64 1/2
default:
default: Installing : tor-0.3.3.9-1.el7.x86_64 2/2
default:
default: Verifying : torsocks-2.2.0-1.el7.centos.x86_64 1/2
default:
default: Verifying : tor-0.3.3.9-1.el7.x86_64 2/2
default:
default:
default: Installed:
default: tor.x86_64 0:0.3.3.9-1.el7
default:
default: Dependency Installed:
default: torsocks.x86_64 0:2.2.0-1.el7.centos
default:
default: Complete!
default:
default: ls -la /var/lib/tor
default: total 4
default: drwxr-x---. 2 toranon root 6 Jul 14 09:59 .
default: drwxr-xr-x. 29 root root 4096 Jul 23 14:31 ..
default:
default: Grep Data
default: /etc/tor/torrc:## things in $HOME/.tor on Unix, and in Application Data\tor on Windows.
default: /etc/tor/torrc:#DataDirectory /var/lib/tor
default: /usr/share/tor/defaults-torrc:DataDirectory /var/lib/tor
default: /usr/share/tor/defaults-torrc:DataDirectoryGroupReadable 1
default:
default: starting tor
default:
default: tor logs
default: -- Logs begin at Mon 2018-07-23 14:30:24 UTC, end at Mon 2018-07-23 14:31:08 UTC. --
default: Jul 23 14:31:07 localhost.localdomain systemd[1]: Starting Anonymizing overlay network for TCP...
default: Jul 23 14:31:08 localhost.localdomain tor[2563]: Jul 23 14:31:08.126 [notice] Tor 0.3.3.9 (git-45028085ea188baf) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2k-fips, Zlib 1.2.7, Liblzma N/A, and Libzstd N/A.
default: Jul 23 14:31:08 localhost.localdomain tor[2563]: Jul 23 14:31:08.127 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
default: Jul 23 14:31:08 localhost.localdomain tor[2563]: Jul 23 14:31:08.127 [notice] Read configuration file "/usr/share/tor/defaults-torrc".
default: Jul 23 14:31:08 localhost.localdomain tor[2563]: Jul 23 14:31:08.127 [notice] Read configuration file "/etc/tor/torrc".
default: Jul 23 14:31:08 localhost.localdomain tor[2563]: Jul 23 14:31:08.135 [warn] Fixing permissions on directory /var/lib/tor
default: Jul 23 14:31:08 localhost.localdomain tor[2563]: Configuration was valid
default: Jul 23 14:31:08 localhost.localdomain systemd[1]: Started Anonymizing overlay network for TCP.
default:
default: ls -la /var/lib/tor
default: total 4
default: drwx------. 2 toranon root 6 Jul 14 09:59 .
default: drwxr-xr-x. 29 root root 4096 Jul 23 14:31 ..
```
Using the following Vagrantfile:
```
$ cat Vagrantfile
script = <<-SCRIPT
curl -s -o /etc/yum.repos.d/maha-tor-latest-epel-7.repo https://copr.fedorainfracloud.org/coprs/maha/tor-latest/repo/epel-7/maha-tor-latest-epel-7.repo
echo Installing tor
yum install tor -y
echo 'Log debug stderr' >> /etc/tor/torrc
echo
echo ls -la /var/lib/tor
ls -la /var/lib/tor
echo
echo "Grep Data"
grep Data /etc/tor/torrc /usr/share/tor/defaults-torrc
echo
echo starting tor
systemctl start tor
echo
echo tor logs
journalctl -u tor -n 2000 --no-pager
echo
echo ls -la /var/lib/tor
ls -la /var/lib/tor
SCRIPT
Vagrant.configure("2") do |config|
config.vm.box = "centos/7"
config.vm.provision "shell", inline: script
end
```
**Trac**:
**Username**: mahaTor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26910Could tor drop privileges even earlier? (before trying to access anything on ...2022-06-17T13:40:48ZnusenuCould tor drop privileges even earlier? (before trying to access anything on the filesystem beyond its torrc files)Fedora/CentOS starts the tor service as root and drops
privileges to user 'toranon' due to the torrc 'User' parameter by default.
Also by default the tor service runs in a SELinux confined domain (tor_t). That means
root in that domain...Fedora/CentOS starts the tor service as root and drops
privileges to user 'toranon' due to the torrc 'User' parameter by default.
Also by default the tor service runs in a SELinux confined domain (tor_t). That means
root in that domain can NOT access just any files regardless
of DAC filesystem permissions (DAC_OVERRIDE is not granted by default).
Which results in the situation that during startup (before privileges
are dropped and user is switched to 'toranon') tor can not access
the hiddenservicedir without allowing DAC_OVERRIDE or changing filesystem permissions,
but it could if at that point privileges were already switched to the user specified in the torrc file.
From my point of view the nicest solution would be if tor drops
privileges before it accesses anything on the filesystem -
which would solve above problem. Would that introduce other problems?
Is there a specific reason why tor drops privileges later?
(this is about running tor and tor in --verify-config mode)
context:
https://bugzilla.redhat.com/show_bug.cgi?id=1602171
(I consider this problem solved via the workaround but
I'm still interested in the above question)https://gitlab.torproject.org/tpo/core/tor/-/issues/26909ignore MyFamily lines and emit a warning on bridges2020-06-27T13:52:47Znusenuignore MyFamily lines and emit a warning on bridgessplit from legacy/trac#26908:
tor in bridge mode should ignore MyFamily lines (meaning: not include that data when creating/uploading descriptors) in its torrc file and emit a warning.split from legacy/trac#26908:
tor in bridge mode should ignore MyFamily lines (meaning: not include that data when creating/uploading descriptors) in its torrc file and emit a warning.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26905Work out if we need to round observed relay bandwidths to protect individual ...2021-02-18T15:34:40ZteorWork out if we need to round observed relay bandwidths to protect individual client usageRelays maintain detailed information about their maximum network load. After legacy/trac#24104, relays only report their maximum bandwidth once a day, over 10 seconds of measurement.
How sensitive is this bandwidth information?
Should ...Relays maintain detailed information about their maximum network load. After legacy/trac#24104, relays only report their maximum bandwidth once a day, over 10 seconds of measurement.
How sensitive is this bandwidth information?
Should we round these bandwidths to:
* a number of decimal places?
* a set amount of client usage that we want to protect?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26904Work out if we need to round scanner measured bandwidths to protect individua...2020-07-28T22:34:26ZteorWork out if we need to round scanner measured bandwidths to protect individual client usageNetwork scanners like torflow and sbws maintain detailed information about relay load. This information is only collected occasionally (perhaps once or twice a day), over a few seconds of measurement.
How sensitive is this bandwidth inf...Network scanners like torflow and sbws maintain detailed information about relay load. This information is only collected occasionally (perhaps once or twice a day), over a few seconds of measurement.
How sensitive is this bandwidth information?
Should we round these bandwidths to:
* a number of decimal places?
* a set amount of client usage that we want to protect?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26903Document what 'GETINFO net/listeners/*' do2020-06-27T13:52:47ZDamian JohnsonDocument what 'GETINFO net/listeners/*' doHi lovely tor folks. Minor thing but a recent spec addition made me realize that we should document what the listener ports do...
https://gitweb.torproject.org/torspec.git/commit/?id=a8a838f
Personally I haven't a clue what extor or ht...Hi lovely tor folks. Minor thing but a recent spec addition made me realize that we should document what the listener ports do...
https://gitweb.torproject.org/torspec.git/commit/?id=a8a838f
Personally I haven't a clue what extor or httptunnel endpoints are, and if I'm puzzled by them I suspect others might be as well. ;)
This is an existing problem. Control, dns, and such weren't documented either. Since they were self explanatory it didn't seem worth bringing this up when we first added the field, but now that the endpoints are getting more exotic I'd appreciate a short description in the spec for what they do.
Thanks!Tor: 0.3.5.x-finalhttps://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/26899Rev counter prevents easy move of v3 onion service2020-06-27T13:52:47ZirlRev counter prevents easy move of v3 onion serviceThis weekend I was moving a v3 onion service to another box. Copying the folder alone was not enough. I also had to manually edit the rev counter in the state file otherwise the hs descriptors were always rejected as invalid. It took me ...This weekend I was moving a v3 onion service to another box. Copying the folder alone was not enough. I also had to manually edit the rev counter in the state file otherwise the hs descriptors were always rejected as invalid. It took me a while to figure this out, perhaps I was looking in the wrong place or perhaps this isn't documented.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26896Duplicate call to connection_mark_for_close2020-06-27T13:52:47ZtoralfDuplicate call to connection_mark_for_closecatched that warning (for the 1st time IIRC) at a hardened stable Gentoo Linux exit relay with LibreSSL 2.6.5:
```
Jul 21 08:02:55.000 [warn] connection_mark_for_close_internal_(): Bug: Duplicate call to connection_mark_for_close at src/...catched that warning (for the 1st time IIRC) at a hardened stable Gentoo Linux exit relay with LibreSSL 2.6.5:
```
Jul 21 08:02:55.000 [warn] connection_mark_for_close_internal_(): Bug: Duplicate call to connection_mark_for_close at src/or/directory.c:5204 (first at src/or/main.c
:1210) (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] tor_bug_occurred_(): Bug: src/or/connection.c:841: connection_mark_for_close_internal_: This line should not have been reached. (Future in
stances of this warning will be silenced.) (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: Line unexpectedly reached at connection_mark_for_close_internal_ at src/or/connection.c:841. Stack trace: (on Tor 0.3.4.5-rc 673f3d64
0ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x43) [0x564c703385b3] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x564c70353419] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /usr/bin/tor(connection_dir_finished_flushing+0x99) [0x564c702ee739] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0xb06) [0x564c702c7df6] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /usr/bin/tor(+0x5211e) [0x564c7021511e] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /usr/lib64/libevent-2.1.so.6(+0x2259d) [0x7fd546aa759d] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /usr/lib64/libevent-2.1.so.6(event_base_loop+0x4e7) [0x7fd546aa8367] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x17a) [0x564c7021733a] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1015) [0x564c70219725] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x564c70211bba] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x564c70211949] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /lib64/libc.so.6(__libc_start_main+0xea) [0x7fd545829eda] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
Jul 21 08:02:55.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x564c7021199a] (on Tor 0.3.4.5-rc 673f3d640ef7fb05)
```Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26894spec: say CREATE/CREATE2 and EXTEND/EXTEND2 when we mean to2020-06-27T13:52:48ZTaylor Yuspec: say CREATE/CREATE2 and EXTEND/EXTEND2 when we mean toIn several places in tor-spec.txt, it looks like we say only `CREATE` or `EXTEND` when we really mean to also include `CREATE2` or `EXTEND2`. We should fix those.In several places in tor-spec.txt, it looks like we say only `CREATE` or `EXTEND` when we really mean to also include `CREATE2` or `EXTEND2`. We should fix those.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26893spec: all-zeroes special case is for relay IDs, not cell digests2020-06-27T13:52:48ZTaylor Yuspec: all-zeroes special case is for relay IDs, not cell digeststor-spec.txt Section 5.3 (Creating circuits) says:
```
As special cases, if the extend cell includes a digest of
all zeroes, or asks to extend back to the relay that sent the extend
```
The implementation uses "digest" internally t...tor-spec.txt Section 5.3 (Creating circuits) says:
```
As special cases, if the extend cell includes a digest of
all zeroes, or asks to extend back to the relay that sent the extend
```
The implementation uses "digest" internally to refer to relay ID hashes, while tor-spec.txt primarily uses it to refer to the truncated running SHA-1 hash that relays use to "recognize" a cell as targeting them.
arma says this probably intends to refer to relay ID hashes, and pointed to commit e34727a65c411a6260f3960ff8a753088e287565.
We should reword this text to make it clear it refers to relay ID hashes.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26892log_addr_has_changed() does not heed SafeLogging2020-06-27T13:52:48Zrl1987log_addr_has_changed() does not heed SafeLoggingNo IP address scrubbing is performed at any loglevel:
```
2694 if (!tor_addr_is_null(prev))
2695 log_fn(severity, LD_GENERAL,
2696 "Our IP Address has changed from %s to %s; "
2697 "rebuilding descriptor (sou...No IP address scrubbing is performed at any loglevel:
```
2694 if (!tor_addr_is_null(prev))
2695 log_fn(severity, LD_GENERAL,
2696 "Our IP Address has changed from %s to %s; "
2697 "rebuilding descriptor (source: %s).",
2698 addrbuf_prev, addrbuf_cur, source);
2699 else
2700 log_notice(LD_GENERAL,
2701 "Guessed our IP address as %s (source: %s).",
2702 addrbuf_cur, source);
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26890Redefine coverity version of the BUG macro2020-06-27T13:52:48ZNick MathewsonRedefine coverity version of the BUG macroOur BUG macro definition is all wrong for coverity.
We shouldn't be including __coverity_panic__, since hitting a BUG doesn't actually mean Tor will crashed, and we shouldn't imply that the condition might be visited anyway. We should ...Our BUG macro definition is all wrong for coverity.
We shouldn't be including __coverity_panic__, since hitting a BUG doesn't actually mean Tor will crashed, and we shouldn't imply that the condition might be visited anyway. We should just do "#define BUG(x) (x)" when we're building with coverity.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26886prop295: revise proposal and determine feasability2020-07-28T22:33:42Zteorprop295: revise proposal and determine feasabilityProposal 295 is:
> Filename: 295-relay-crypto-with-atl.txt
> Title: Using ADL-GCM for relay cryptography (solving the crypto-tagging attack)
> Author: Tomer Ashur
At:
https://github.com/torproject/torspec/blob/master/proposals/295-relay...Proposal 295 is:
> Filename: 295-relay-crypto-with-atl.txt
> Title: Using ADL-GCM for relay cryptography (solving the crypto-tagging attack)
> Author: Tomer Ashur
At:
https://github.com/torproject/torspec/blob/master/proposals/295-relay-crypto-with-atl.txtTor: unspecified