The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:53:21Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26188Bug: src/or/circuitbuild.c:27792020-06-27T13:53:21ZcypherpunksBug: src/or/circuitbuild.c:2779
```
Bug: src/or/circuitbuild.c:2779: onion_extend_cpath: Non-fatal assertion info failed. (on Tor 0.3.3.6 7dd0813e783ae16e)
Non-fatal assertion info failed in onion_extend_cpath at src/or/circuitbuild.c:2779. Stack trace: (on Tor 0.3....
```
Bug: src/or/circuitbuild.c:2779: onion_extend_cpath: Non-fatal assertion info failed. (on Tor 0.3.3.6 7dd0813e783ae16e)
Non-fatal assertion info failed in onion_extend_cpath at src/or/circuitbuild.c:2779. Stack trace: (on Tor 0.3.3.6 7dd0813e783ae16e)
0x11b0428 <log_backtrace+0x48> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x11cb8ea <tor_bug_occurred_+0x10a> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x10fe2ea <circuit_establish_circuit+0x11aa> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x10bf2b2 <consider_testing_reachability+0x1f2> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x10feeb5 <circuit_send_next_onion_skin+0x445> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x10a174b <relay_crypt+0x8bb> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x10a0ab3 <circuit_receive_relay_cell+0x3e3> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x1115d4f <command_process_cell+0x6ff> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x113d4db <connection_or_process_inbuf+0x24b> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x112ff41 <connection_handle_read+0x871> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x1075f64 <connection_add_impl+0x224> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x801b5006f <event_base_assert_ok_nolock_+0xc9f> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.3.6 7dd0813e783ae16e)
0x801b4bf4e <event_base_loop+0x50e> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.3.6 7dd0813e783ae16e)
0x107815b <do_main_loop+0x62b> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x107a785 <tor_run_main+0xb5> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x1075c2c <tor_main+0x4c> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x1075ac9 <main+0x19> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
0x10759c0 <_start+0x180> at /usr/local/bin/tor (on Tor 0.3.3.6 7dd0813e783ae16e)
```https://gitlab.torproject.org/tpo/core/tor/-/issues/26181Apparmor + systemd failures when loading included service files + DisableAllS...2020-07-28T19:16:20ZTracApparmor + systemd failures when loading included service files + DisableAllSwap Fix**__Environment:__**
Ubuntu 16.04.4 (linux kernel 4.16.0-041600-generic)
Tor version 0.3.3.6 (git-c9903102c98cd028).
systemd version 229
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL ...**__Environment:__**
Ubuntu 16.04.4 (linux kernel 4.16.0-041600-generic)
Tor version 0.3.3.6 (git-c9903102c98cd028).
systemd version 229
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN
----------------------------------------------------------------------
I had to completely redo the service files in order to get it to actually load with systemd
Firstly I disabled the init script for tor in /etc/init.d/tor:
**update-rc.d disable tor**
Then made changes to tor.service torrc and system_tor files as everything was basically conflicting with each other, mainly with apparmor denying access to /var/run because the apparmor system_tor authorized paths for the cookie file was not matching with what the torrc default path is, so I had to update either system_tor or change the path in torrc this file to reflect this, so I went with updating apparmor's profile as well as adding a couple more variations of the cookie file.
I had to also add the following lines to tor.service:
**RuntimeDirectory=tor**
**RuntimeDirectoryMode=0700**
In order for tor to actually initialize and create the files in the /var/run directory as anything with permissions allowing more than the owner would issue a warning and fail.
--------
I also added some of the configuration from /etc/default/tor to torrc because that file was only used by the /etc/init.d/tor scrip, which is not touched when using systemd to start tor.
From what I tested, tor will not start with systemd if defining user/group as any other than root when it tries to create/read/write to the /var/run/tor directory, as I get the warning for example setting 'User demon' in torrc and User=demon Group=sudo in tor.service results in:
* [notice] Opening Socks listener on /var/run/tor/socks
* [warn] Unable to chown() /var/run/tor/socks socket: Operation not permitted.
* [notice] Opening Socks listener on 127.0.0.1:9050
* [warn] /var/run/tor is not owned by this user (root, 0) but by demon (1000). Perhaps you are running Tor as the wrong user?
* [warn] Before Tor can create a control socket in "/var/run/tor/socks", the directory "/var/run/tor" 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.)
* [notice] Closing partially-constructed Socks listener on 127.0.0.1:9050
* [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
* [err] Reading config failed--see warnings above.
This seems to be an issue with tor and not systemd. T
The files I've attached are setup where tor successfully loads with systemd using User root group=root.
Lastly the other modification I had to make was in /etc/apparmor.d/system_tor wherefore the default cookie locations are mismatched between apparmor and tor:
apparmor.d/system_tor sets the cookie path as:
** /{,var/}run/tor/control.authcookie w,**
** /{,var/}run/tor/control.authcookie.tmp rw,**
tor's default sets the cookie path as:
** /var/run/tor/control_auth_cookie**
Which causes apparmor to trigger and deny tor from writing/reading the cookie file and tor fails to start. Thus I had to add to system_tor the lines:
/{,var/}run/tor/control_auth_cookie w,
/{,var/}run/tor/control_auth_cookie.tmp rw,
------------------------
The other issue is with starting tor with systemd is the option DisableAllSwap doesn't work and gets the error:
* [warn] You appear to lack permissions to change memory limits. Are you root?
* [warn] Unable to raise RLIMIT_MEMLOCK: Operation not permitted
* [notice] Unable to lock all current and future memory pages: Cannot allocate memory
* [warn] Failed to parse/validate config: DisableAllSwap failure. Do you have proper permission
I haven't been able to resolve the cause of this. However, the option does work when starting tor from the command line with DisableAllSwap enabled.
Hopefully the maintainers of tor will address and correct this for the next release.
**Trac**:
**Username**: d3m0nkingxTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26170Core Tor releases typo2021-07-22T16:20:51ZTracCore Tor releases typoIt says 0.3.3 end of life is on `On or after Mar 22, 2018` but that is the day that it should be released.
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases?version=40
**Trac**:
**Username**: Dbryrtfb...It says 0.3.3 end of life is on `On or after Mar 22, 2018` but that is the day that it should be released.
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases?version=40
**Trac**:
**Username**: DbryrtfbcbhgfTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26168Rename HSDir consensus flag to OnionDir2022-06-17T17:31:31ZRoger DingledineRename HSDir consensus flag to OnionDirOver time, nobody is going to know what an HSDir is. Eventually we will want to use a more understandable name. I propose OnionDir.
Step 1: Make clients able to parse the OnionDir flag, and they just treat it as a synonym for HSDir.
St...Over time, nobody is going to know what an HSDir is. Eventually we will want to use a more understandable name. I propose OnionDir.
Step 1: Make clients able to parse the OnionDir flag, and they just treat it as a synonym for HSDir.
Step 2: Wait a long time until all clients from before step 1 are gone.
Step 3: Have dir auths start saying OnionDir instead of HSDir.
(In the above plan, step 2 could take years. But I think it's still the simplest plan. The only real risk is if we somehow screw up with step 1, and don't notice the screw-up until we try step 3.)https://gitlab.torproject.org/tpo/core/tor/-/issues/26166Protect directory servers and torproject.org against TCP reset attacks2020-06-27T13:53:22ZTracProtect directory servers and torproject.org against TCP reset attacksSome ISP's using TCP reset attacks to enforce censorship and block Tor.
Is it possible to make torproject.org and Tor directory servers to drop (ignore) all spoofed TCP reset packets?
**Trac**:
**Username**: indigotimeSome ISP's using TCP reset attacks to enforce censorship and block Tor.
Is it possible to make torproject.org and Tor directory servers to drop (ignore) all spoofed TCP reset packets?
**Trac**:
**Username**: indigotimehttps://gitlab.torproject.org/tpo/core/tor/-/issues/26161Design and implement a Rust dirauth module2020-07-28T19:15:29ZteorDesign and implement a Rust dirauth moduleSome of our protoceratops`*` functions are only used when dirauths vote:
* protover_compute_vote
* protover_compute_for_old_tor
This function is implemented in Rust and C:
* protover_compute_vote
We should work out how to split protove...Some of our protoceratops`*` functions are only used when dirauths vote:
* protover_compute_vote
* protover_compute_for_old_tor
This function is implemented in Rust and C:
* protover_compute_vote
We should work out how to split protover in Rust and C, and put the dirauth parts in a separate module.
`*` I blame autocorrectTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26160Move dirserv_read_measured_bandwidths() and related functions to dirauth module2020-07-28T19:15:10ZteorMove dirserv_read_measured_bandwidths() and related functions to dirauth moduledirserv_read_measured_bandwidths() is only called by dirauths.dirserv_read_measured_bandwidths() is only called by dirauths.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26158A little bug of circular path of Tor2021-08-23T15:16:34ZTracA little bug of circular path of TorIn order to defend the **circular-path** attacks, Tor relays detects the next hop and previous hop of a circuit through node-id and Ed25519-id.
However, when the Tor relay detects the previous node has the same Ed25519-id with next nod...In order to defend the **circular-path** attacks, Tor relays detects the next hop and previous hop of a circuit through node-id and Ed25519-id.
However, when the Tor relay detects the previous node has the same Ed25519-id with next node, it forgot to return -1, and continue to extend the circuit.
This might cause some loopholes for the circular-path.
```
/* Next, check if we're being asked to connect to the hop that the
* extend cell came from. There isn't any reason for that, and it can
* assist circular-path attacks. */
if (tor_memeq(ec.node_id,
TO_OR_CIRCUIT(circ)->p_chan->identity_digest,
DIGEST_LEN)) {
log_fn(LOG_PROTOCO[[Image()]]L_WARN, LD_PROTOCOL,
"Client asked me to extend back to the previous hop.");
return -1;
}
/* Check the previous hop Ed25519 ID too */
if (! ed25519_public_key_is_zero(&ec.ed_pubkey) &&
ed25519_pubkey_eq(&ec.ed_pubkey,
&TO_OR_CIRCUIT(circ)->p_chan->ed25519_identity)) {
log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
"Client asked me to extend back to the previous hop "
"(by Ed25519 ID).");
}
```
**Trac**:
**Username**: TBD.ChenTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26156Undefined references to EVP_CIPHER_CTX_cleanup() with OpenSSL 1.1.0 no-deprec...2020-06-27T13:53:23ZTracUndefined references to EVP_CIPHER_CTX_cleanup() with OpenSSL 1.1.0 no-deprecatedOn my machine with OpenSSL 1.1.0 `no-deprecated', Tor 0.3.4.1-alpha fails to build. The failure happens when linking several utilities, with the following error:
```
src/common/libor-crypto.a(aes.o): In function `aes_cipher_free_':
/hom...On my machine with OpenSSL 1.1.0 `no-deprecated', Tor 0.3.4.1-alpha fails to build. The failure happens when linking several utilities, with the following error:
```
src/common/libor-crypto.a(aes.o): In function `aes_cipher_free_':
/home/quentin/Security/Code/Tor/tor/src/common/aes.c:121: undefined reference to `EVP_CIPHER_CTX_cleanup'
```
This appears to be due to _src/common/aes.c_ not #include-ing "compat_openssl.h", and thus not having the OPENSSL_1_1_API #define. Simply adding `#include "compat_openssl.h"` in _aes.c_ fixes the build.
I have also checked that building still succeeds against OpenSSL 1.0.1 and 1.0.2 with this modification.
**Trac**:
**Username**: laomaiwengTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26155Bandwidth file Timestamp is the latest scanner result, not the file creation ...2021-02-18T15:34:40ZteorBandwidth file Timestamp is the latest scanner result, not the file creation timeThe bandwidth file timestamp should be the last time a relay was scanned. But we say it's the file creation time, which is wrong.
in torflow, the timestamp is actually the oldest of the most recent timestamps for all scanners:
https://g...The bandwidth file timestamp should be the last time a relay was scanned. But we say it's the file creation time, which is wrong.
in torflow, the timestamp is actually the oldest of the most recent timestamps for all scanners:
https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/aggregate.py#n409
(This is buggy in small networks, because the unmeasured node scanner may end up in a state where is never has any nodes to scan. But we are not fixing torflow bugs.)
Here's how I suggest we fix the spec issue:
Replace the initial Timestamp with:
```
Timestamp NL
[At start, exactly once.]
The Unix Epoch time in seconds of the most recent scanner result.
If there are multiple scanners which can fail independently, implementations
SHOULD take the most recent timestamp from each scanner and use the
oldest value. This ensures all the scanners continue running.
If there are scanners that do not run continuously, they SHOULD be excluded
from the timestamp calculation,
It does not follow the KeyValue format for backwards
compatibility with version 1.0.0.
```
Add a file creation date:
```
"file_created=" DateTime NL
[Zero or one time.]
The date and time timestamp in ISO 8601 format and UTC time zone
when the file was created.
This Line has been added in version 1.1.0 of this specification.
```
Add a latest bandwidth in human-readable format:
```
"latest_bandwidth=" DateTime NL
[Zero or one time.]
The date and time timestamp in ISO 8601 format and UTC time zone
of the most recent scanner result.
This time MUST be identical to the initial Timestamp line.
This duplicate value is included to make the format easier for people
to read.
This Line has been added in version 1.1.0 of this specification.
```Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26152Improve errors on crypto/openssl_version badness2020-06-27T13:53:23ZNick MathewsonImprove errors on crypto/openssl_version badnessWhen these tests fail, they currently do so in an unhelpful way. They should log the offending strings when the version strings don't match.
Extracted from legacy/trac#25549.When these tests fail, they currently do so in an unhelpful way. They should log the offending strings when the version strings don't match.
Extracted from legacy/trac#25549.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26142replace uses of U64_* and I64_* macros with their C99 stdint.h or inttypes.h ...2021-09-16T14:30:20ZTaylor Yureplace uses of U64_* and I64_* macros with their C99 stdint.h or inttypes.h equivalentsThere are many macros in compat.h that try to portably handle 64-bit integer values in `printf()` and `scanf()` calls. Now that we seem to require C99, we should use the equivalent macros from stdint.h or inttypes.h instead. For exampl...There are many macros in compat.h that try to portably handle 64-bit integer values in `printf()` and `scanf()` calls. Now that we seem to require C99, we should use the equivalent macros from stdint.h or inttypes.h instead. For example, `U64_FORMAT` is equivalent to `PRIu64` in inttypes.h.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26139start aplication2020-07-28T19:15:45ZTracstart aplication[Sun May 20 08:50:50 2018] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "Bug: 8 tor 0x000...[Sun May 20 08:50:50 2018] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "Bug: 8 tor 0x00000001065c9786 tor_main + 70 (on Tor 0.3.3.5-rc 81d71f0d41adf0d8)
"
**Trac**:
**Username**: xrootersTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26138DirPort /tor/server/all document contains spurrious blank line following serv...2020-07-28T19:13:56ZstarlightDirPort /tor/server/all document contains spurrious blank line following serving relay's descriptorissuing
```
curl -s http://x.x.x.x:x/tor/server/all.z | openssl zlib -d | less -SX
```
as expected retrieves a complete set of server descriptors; contains one blank line immediately after the descriptor of the serving relay which is n...issuing
```
curl -s http://x.x.x.x:x/tor/server/all.z | openssl zlib -d | less -SX
```
as expected retrieves a complete set of server descriptors; contains one blank line immediately after the descriptor of the serving relay which is not expected
trivial issue, but noticed it so reported it
glitch appears in 0.3.3 as wellTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26137Integrate AS-aware circuit selection2020-07-28T19:13:45ZcypherpunksIntegrate AS-aware circuit selectionThe "ASToria" Tor client has been available since 2015, but I haven't seen any analysis of it from Tor Project or any plans to integrate any of the ideas. The general idea behind ASToria is to improve path selection to minimize the risk ...The "ASToria" Tor client has been available since 2015, but I haven't seen any analysis of it from Tor Project or any plans to integrate any of the ideas. The general idea behind ASToria is to improve path selection to minimize the risk of AS-level traffic correlation. It is effectively an enhanced version of Tor's current naïve path-selection behavior which simply involves avoiding circuits with relays that share too small of a subnet. This is a similar proposal to legacy/trac#10221, which was created before this paper was published.
Tor should integrate AS-aware circuit selection (whether by including the ASToria code or creating a bespoke solution), or at the very least integrate AS-aware circuit measurement to make potential transition easier in the future. Additionally, this change would require no modifications of the Tor protocol and would be completely backwards-compatible with the network. From the paper's abstract:
>We find that up to 40% of all circuits created by Tor are vulnerable to attacks by traffic correlation from Autonomous System (AS)-level adversaries, 42% from colluding AS-level adversaries, and 85% from state-level adversaries. In addition, we find that in some regions (notably, China and Iran) there exist many cases where over 95% of all possible circuits are vulnerable to correlation attacks, emphasizing the need for AS-aware relay-selection.
>
>Astoria reduces the number of vulnerable circuits to 2% against AS-level adversaries, under 5% against colluding AS-level adversaries, and 25% against state-level adversaries. In addition, Astoria load balances across the Tor network so as to not overload any set of relays.
Key points:
* The code has already been written and just needs a cleanup and some review.
* Load balancing is done to prevent individual relays from being overloaded.
* No changes to the protocol are needed, making this fully backwards-compatible.
* AS-level traffic analysis risk is reduced from 40% to 2% for any given circuit.
https://arxiv.org/abs/1505.05173
https://github.com/sbunrg/AstoriaTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26136DirPort reachability test inconsistency when only "DirPort x.x.x.x:x NoAdvert...2020-07-28T19:14:45ZstarlightDirPort reachability test inconsistency when only "DirPort x.x.x.x:x NoAdvertise" configuredIf relay starts with only NoAdvertise DirPorts configured, ~~bootstrapping fails~~ the relay's descriptor is never published:
```
Tor 0.3.4.1-alpha (git-deb8970a29ef7427) running on Linux with Libevent x.x.x, OpenSSL x.x.x, Zlib x.x.x, ...If relay starts with only NoAdvertise DirPorts configured, ~~bootstrapping fails~~ the relay's descriptor is never published:
```
Tor 0.3.4.1-alpha (git-deb8970a29ef7427) running on Linux with Libevent x.x.x, OpenSSL x.x.x, Zlib x.x.x, Liblzma x.x.x, and Libzstd x.x.x.
.
.
.
Opening Control listener on x.x.x.y:r
Opening OR listener on x.x.x.x:o
Opening Directory listener on x.x.x.y:d
.
.
.
Bootstrapped 80%: Connecting to the Tor network
Bootstrapped 85%: Finishing handshake with first hop
Bootstrapped 90%: Establishing a Tor circuit
Tor has successfully opened a circuit. Looks like client functionality is working.
Bootstrapped 100%: Done
Now checking whether ORPort x.x.x.x:o is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Self-testing indicates your ORPort is reachable from the outside. Excellent.
Performing bandwidth self-test...done.
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Your server (x.x.x.x:0) has not managed to confirm that its DirPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
```
```
ORPort x.x.x.x:o
DirPort x.x.x.y:d NoAdvertise
ControlPort x.x.x.y:r
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26121BUILDTIMEOUT_SET totals are still off2020-06-27T13:53:24ZMike PerryBUILDTIMEOUT_SET totals are still offWhile testing and examining onion service timeout rates and trying to verify them from a controller script, I realized that our timeout rates are still off in the BUILDTIMEOUT_SET event.
The reason for the discrepancy is that we're doub...While testing and examining onion service timeout rates and trying to verify them from a controller script, I realized that our timeout rates are still off in the BUILDTIMEOUT_SET event.
The reason for the discrepancy is that we're double-counting circuits that transition into MEASUREMENT_EXPIRED. Every circuit that transitions into MEASUREMENT_EXPIRED is first counted as a timeout in circuit_build_times_mark_circ_as_measurement_only(). Of those that do not complete within the measurement window, we again count as a "closed" circuit in circuit_build_times_count_close(). If a measurement circuit succeeds, we do *not* count it as a success (see circuit_build_times_handle_completed_hop()).
This means that the total_circuits value in cbt_control_event_buildtimeout_set() should be timeouts+succeeded, and not timeouts+succeeded+closed. (Again, counting closed in the total there double-counts "closed" MEASUREMENT circuits, which were also counted as timeout circuits earlier).
Since this is just a control port stats change, it would be nice to get it into 0.3.4 (and maybe 0.3.3) so it is easier to get more accurate data about how the circuit build timeout is interacting with vanguards there.Tor: 0.3.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26117AF_UNSPEC are actually valid connected cells2020-06-27T13:53:24ZMike PerryAF_UNSPEC are actually valid connected cellsThe DELIVERED and OVERHEAD cell count in legacy/trac#25903 used the AF_UNSPEC check to represent validity. In legacy/trac#26072 we discovered that the connected cell processing was wrong. Also, AF_UNSPEC may be used for rend connects.
N...The DELIVERED and OVERHEAD cell count in legacy/trac#25903 used the AF_UNSPEC check to represent validity. In legacy/trac#26072 we discovered that the connected cell processing was wrong. Also, AF_UNSPEC may be used for rend connects.
Not in any released version of tor.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26116OpenSSL 1.1.1 changed the semantics of the password callback return value2020-06-27T13:53:25ZNick MathewsonOpenSSL 1.1.1 changed the semantics of the password callback return valueIn c82c3462267afdbbaa5, openssl changed its interpretation of getting a "0" result from a PEM password callback. Previously, this indicated an error, and the documentation said:
>The callback **must** return the number of characters i...In c82c3462267afdbbaa5, openssl changed its interpretation of getting a "0" result from a PEM password callback. Previously, this indicated an error, and the documentation said:
>The callback **must** return the number of characters in the passphrase or 0 if an error occurred.
But now, 0 means an empty passphrase, and -1 means that an error occurred.
To avoid strange bugs and compatibility issues, we should have our pem_no_password_cb function return -1 instead. (-1 was always a supported return value, even if it isn't documented.)Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26113Control spec is ambiguous whether a GETCONF error message is specified2020-07-31T14:03:27ZdmrControl spec is ambiguous whether a GETCONF error message is specifiedThe [[spec for `GETCONF` response](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n307|control)] says:
```
If some of the listed keywords can't be found, Tor replies with a
...The [[spec for `GETCONF` response](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n307|control)] says:
```
If some of the listed keywords can't be found, Tor replies with a
"552 unknown configuration keyword" message.
```
The spec also has a [[about error messages](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n1809|clause)]:
```
Unless specified to have specific contents, the human-readable messages
in error replies should not be relied upon to match those in this document.
```
Unfortunately, it's unclear what //specified to have specific contents// means here. The message for `GETCONF` is quoted, which at least in cursory read made me think it was //specified//.
But I suppose it's ambiguous.
==== Expected change
In discussion over IRC, arma suggested it...
> might be even better to change the spec to be like "replies with a 552 message because of the unrecognized configuration key."
Overall, it was agreed upon amongst arma, meejah, sysrqb, and myself that the spec shouldn't be denoting a specific message here, and that controllers shouldn't rely on a specific message. Only the numeric code `552` should be relied upon.