The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:00:59Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16563Log function prettyprint on os x sure is verbose2020-06-27T14:00:59ZRoger DingledineLog function prettyprint on os x sure is verboseOn Linux, my debug-level log says things like
```
Jul 12 12:19:17.904 [debug] choose_good_middle_server(): Contemplating intermediate hop 1: random choice.
```
I just saw a debug level log from osx, and it said
```
Jul 12 11:45:54.528 [...On Linux, my debug-level log says things like
```
Jul 12 12:19:17.904 [debug] choose_good_middle_server(): Contemplating intermediate hop 1: random choice.
```
I just saw a debug level log from osx, and it said
```
Jul 12 11:45:54.528 [debug] const node_t *choose_good_middle_server(uint8_t, cpath_build_state_t *, crypt_path_t *, int): Contemplating intermediate hop 1: random choice.
```
Wow! Is that level of detail really desired?Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16562Harmonize curve25519-signature format with what others are doing2020-07-24T17:49:51ZNick MathewsonHarmonize curve25519-signature format with what others are doingHere's another one that we have to do before the 0.2.7.2-alpha release if we're going to do it at all:
https://github.com/trevp/tswip/blob/master/curve25519sigs.md
I'm not in love with the differences here, but they seem mostly harmles...Here's another one that we have to do before the 0.2.7.2-alpha release if we're going to do it at all:
https://github.com/trevp/tswip/blob/master/curve25519sigs.md
I'm not in love with the differences here, but they seem mostly harmless. Trevor tells me that there's a chance of his that format being standardized. If so, we might as well help it along by doing what they do.
Changing the nonce-generation mechanism is IMO not very important. The change to consider before the next alpha would be the signature format.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16558Dir auths should vote about Invalid like they do about BadExit2022-06-17T13:54:30ZRoger DingledineDir auths should vote about Invalid like they do about BadExitRight now only three dir auths put BadExit in their known-flags, so it takes any 2 of those 3 to give a relay the BadExit flag, which causes an exit relay to not be used by clients for exiting. This is a great convenience for the dir aut...Right now only three dir auths put BadExit in their known-flags, so it takes any 2 of those 3 to give a relay the BadExit flag, which causes an exit relay to not be used by clients for exiting. This is a great convenience for the dir auth operators, since otherwise we'd have to get a majority of all nine (i.e. five) dir auth operators to declare that a relay shouldn't be used for exiting, and we'd be much less agile in response to detected bad behavior.
In comparison, all nine relays put Valid in their known-flags, so it takes a full 5 of the 9 to give a relay the Valid flag -- or said another way, it takes a full 5 of the 9 to take it away.
In the context of malicious HSDir roles, this lack of agility is hurting us. We should explore ways to make !invalid more like !badexit.https://gitlab.torproject.org/tpo/core/tor/-/issues/16556NEWDESC clarification2020-06-27T14:01:00ZDamian JohnsonNEWDESC clarificationHi Nick. Minor-ish thing but in working on Nyx just realized the NEWDESC event is too imprecise to be useful...
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1868
The trouble is that it merely says it's triggered by ...Hi Nick. Minor-ish thing but in working on Nyx just realized the NEWDESC event is too imprecise to be useful...
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1868
The trouble is that it merely says it's triggered by 'getting a descriptor'. But descriptors include a very wide array of things: server descriptors, extrainfo descriptors, microdescriptor, router status entries, and maybe even hidden service descriptors.
I kinda suspect this event is just triggered by server and microdescriptors, but the spec should say. :)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16545too many windows failures on jenkins with 0.2.72020-06-27T14:01:00ZNick Mathewsontoo many windows failures on jenkins with 0.2.7Right now, too many of the windows builders are failing because of the getpassword code needing more workarounds. We need to fix this before the next alpha.Right now, too many of the windows builders are failing because of the getpassword code needing more workarounds. We need to fix this before the next alpha.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16543Retire VoteOnHidServDirectoriesV2 ?2020-06-27T14:01:00ZRoger DingledineRetire VoteOnHidServDirectoriesV2 ?The VoteOnHidServDirectoriesV2 config option has been 1 for a long time. Nobody ever sets it to anything else. I don't think we'd ever want them to.
Should we just replace it with always-on?The VoteOnHidServDirectoriesV2 config option has been 1 for a long time. Nobody ever sets it to anything else. I don't think we'd ever want them to.
Should we just replace it with always-on?Tor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16539Still had 9 address policies cached at shutdown.2020-06-27T14:01:00ZRoger DingledineStill had 9 address policies cached at shutdown.moria1 running Tor 0.2.7.1-alpha-dev (git-130a9c0ac8aa13ac) exited (in a controlled way), and its last words were:
```
Jul 09 17:23:11.788 [notice] Clean shutdown finished. Exiting.
Jul 09 17:23:12.423 [warn] Still had 9 address policies...moria1 running Tor 0.2.7.1-alpha-dev (git-130a9c0ac8aa13ac) exited (in a controlled way), and its last words were:
```
Jul 09 17:23:11.788 [notice] Clean shutdown finished. Exiting.
Jul 09 17:23:12.423 [warn] Still had 9 address policies cached at shutdown.
Jul 09 17:23:12.423 [warn] 1 [6]: reject 127.0.0.0/8:*
Jul 09 17:23:12.423 [warn] 2 [6]: reject 0.0.0.0/8:*
Jul 09 17:23:12.423 [warn] 3 [6]: reject 10.0.0.0/8:*
Jul 09 17:23:12.423 [warn] 4 [6]: reject 172.16.0.0/12:*
Jul 09 17:23:12.423 [warn] 5 [6]: reject 192.168.0.0/16:*
Jul 09 17:23:12.423 [warn] 6 [6]: reject 169.254.0.0/16:*
Jul 09 17:23:12.423 [warn] 7 [6]: accept *4:52519
Jul 09 17:23:12.423 [warn] 8 [6]: reject 198.50.156.78:*
Jul 09 17:23:12.423 [warn] 9 [40]: reject *4:*
```
I guess this is something somebody wants to know? :)Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16538Limit the impact of a malicious HSDir2020-07-24T17:48:43ZRoger DingledineLimit the impact of a malicious HSDirAn adversary who can control all six hsdir points for an onion service can censor it. You can observe lookups of it even if you control only some of these six.
So we should raise the bar for getting the HSDir flag, to raise the cost to ...An adversary who can control all six hsdir points for an onion service can censor it. You can observe lookups of it even if you control only some of these six.
So we should raise the bar for getting the HSDir flag, to raise the cost to an adversary who tries the Sybil the network in order to control lots of HSDir points. We should also make it harder to target which onion service your relay becomes the HSDir for.
There's a contradiction here: the more restrictive we are about who gets the HSDir flag, the more valuable it becomes to get it. At the one extreme (our current choice), we give it to basically everybody, so you have to get a lot of them before your attack matters. At the other extreme, we could give it to our favorite 20 relays, and if we choose wisely then basically no adversaries will get the HSDir flag. I suspect there are no sweet spots in between.
This ticket is the parent ticket for all the components of making bad HSDirs less risky.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16537Allow onion services to publish voluntary usage stats2022-06-16T18:06:41ZRoger DingledineAllow onion services to publish voluntary usage statsI would like to tell the world about the load and popularity of my onion service. In particular, how many connection requests I've received, and how many of those I managed to reach the clients on, and how many rendezvous circuits I used...I would like to tell the world about the load and popularity of my onion service. In particular, how many connection requests I've received, and how many of those I managed to reach the clients on, and how many rendezvous circuits I used on average when reaching rendezvous points, and so on.
One option is to put my statistics into my onion service descriptor -- then folks who want to record it over time can fetch it over time and record it as they like (e.g. by remembering the output of the HS_DESC_CONTENT event). (Even post proposal 224, they can do this, if they know my onion address name.)
I think this is in the "if somebody wrote it adequately, we'd take the patch" category.https://gitlab.torproject.org/tpo/core/tor/-/issues/16535Investigate building ed25519-donna with SSE2 support.2020-06-27T14:01:01ZYawning AngelInvestigate building ed25519-donna with SSE2 support.Followup to legacy/trac#9663/legacy/trac#16467, now that we include ed25519-donna, we should look into building it with SSE2 support where appropriate.
Adding something like this to `ed25519-donna-portable.h` should do the trick:
```
/*...Followup to legacy/trac#9663/legacy/trac#16467, now that we include ed25519-donna, we should look into building it with SSE2 support where appropriate.
Adding something like this to `ed25519-donna-portable.h` should do the trick:
```
/* Tor: Build with SSE2 where it makes sense to do so. */
#if defined(__SSE2__) && !(defined(__x86_64__) || defined(__amd64__))
#define ED25519_SSE2
#endif
```
Potential pitfalls:
* SSE2 builds benchmark worse on x86_64, at least Haswell.
* This opens us up to potentially really obnoxious compiler bugs/pathologically bad code generation.
* Most distribution packages probably don't build for an architecture that will define `_SSE2_`, so this would only get picked up by people doing custom builds.
Open questions:
* Is this actually faster on 32 bit Intel?
* Is doing something like "always building SSE2 and non-SSE2 and using CPUID to pick at runtime" sensible? (I personally think "No").Tor: 0.2.7.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16533Use ed25519-donna batch verification.2020-06-27T14:01:01ZYawning AngelUse ed25519-donna batch verification.ed25519-donna supports batch verification that is faster than verifying each signature individually in a loop. The Tor side code assumes such a construct is available, so it should be wired in.
Mostly already done as `#if 0`-ed out cod...ed25519-donna supports batch verification that is faster than verifying each signature individually in a loop. The Tor side code assumes such a construct is available, so it should be wired in.
Mostly already done as `#if 0`-ed out code, just needs to be integrated into the new infrastructure added via legacy/trac#16467 and debugged/cleaned up.Tor: 0.2.7.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16530uploaded a descriptor with a Ed25519 key but the <rsa,ed25519> keys don't mat...2020-06-27T14:01:01ZRoger Dingledineuploaded a descriptor with a Ed25519 key but the <rsa,ed25519> keys don't match what they were before.On moria1, running Tor 0.2.7.1-alpha-dev (git-130a9c0ac8aa13ac), I get these each vote time.
```
Jul 08 22:50:29.411 [warn] Router $A69221A7EC7498D2F88A0FB795261013FA36CAAE~Truie at 198.50.156.78 uploaded a descriptor with a Ed25519 key ...On moria1, running Tor 0.2.7.1-alpha-dev (git-130a9c0ac8aa13ac), I get these each vote time.
```
Jul 08 22:50:29.411 [warn] Router $A69221A7EC7498D2F88A0FB795261013FA36CAAE~Truie at 198.50.156.78 uploaded a descriptor with a Ed25519 key but the <rsa,ed25519> keys don't match what they were before.
Jul 08 22:50:29.411 [warn] Router $CF6D0AAFB385BE71B8E111FC5CFF4B47923733BC~Faravahar at 154.35.175.225 uploaded a descriptor with a Ed25519 key but the <rsa,ed25519> keys don't match what they were before.
```
Am I supposed to do something?Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16529stable flag calculation2020-06-27T14:01:01Zcypherpunksstable flag calculationhi,
once again, please enlighten how stable flag calculation works.
node should be (see mailing list)
CWis20 41C526E3C1441A3CDE9B605002643B94F3750E8C
we have
```
$ curl -s -o - 'https://onionoo.torproject.org/details?fingerprint=41C526...hi,
once again, please enlighten how stable flag calculation works.
node should be (see mailing list)
CWis20 41C526E3C1441A3CDE9B605002643B94F3750E8C
we have
```
$ curl -s -o - 'https://onionoo.torproject.org/details?fingerprint=41C526E3C1441A3CDE9B605002643B94F3750E8C' | jq --raw-output '.relays[] | .nickname,.first_seen,.last_seen,.flags[]'
CWis20
2015-07-02 20:00:00
2015-07-08 20:00:00
Fast
HSDir
Running
Stable
V2Dir
Valid
```
first seen on 2015-07-02 20:00:00
```
$ curl -s --compressed -o - https://collector.torproject.org/recent/relay-descriptors/consensuses/ | \
sed 's/.*<a href=\"\([^"]*\).*/\1/' | \
egrep '2015-07-07-(19|20)' | \
xargs -i{} curl -s --compress -o - https://collector.torproject.org/recent/relay-descriptors/consensuses/{} | \
grep -A1 -e '^r CWis20' -e 'valid-after'
valid-after 2015-07-07 19:00:00
fresh-until 2015-07-07 20:00:00
--
r CWis20 QcUm48FEGjzem2BQAmQ7lPN1Dow DBVW0Got4hh3U7o6itrG8+NId6g 2015-07-07 01:22:46 198.100.155.194 443 80
s Fast Running V2Dir Valid
--
valid-after 2015-07-07 20:00:00
fresh-until 2015-07-07 21:00:00
--
r CWis20 QcUm48FEGjzem2BQAmQ7lPN1Dow I/5vfvcsIo2LKWmi17aKmhbTCkk 2015-07-07 19:23:29 198.100.155.194 443 80
s Fast HSDir Running Stable V2Dir Valid
```
first Stable flag at 2015-07-07 20:00:00 (5 days after first seen)
```
$ curl -s --compressed -o - https://collector.torproject.org/recent/relay-descriptors/votes/ | \
sed 's/.*<a href=\"\([^"]*\).*/\1/' | \
grep 2015-07-07-20 | \
xargs -i{} curl -s --compress -o - https://collector.torproject.org/recent/relay-descriptors/votes/{} | \
grep '^flag-thresholds' | \
sort -t= -n -k2
flag-thresholds stable-uptime=818532 stable-mtbf=1475068 fast-speed=85000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=2097000 guard-bw-exc-exits=1945000 enough-mtbf=1 ignoring-advertised-bws=0
flag-thresholds stable-uptime=861077 stable-mtbf=1948931 fast-speed=102000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=2560000 guard-bw-exc-exits=2097000 enough-mtbf=1 ignoring-advertised-bws=0
flag-thresholds stable-uptime=890305 stable-mtbf=2029744 fast-speed=93000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=2411000 guard-bw-exc-exits=2097000 enough-mtbf=1 ignoring-advertised-bws=0
flag-thresholds stable-uptime=891459 stable-mtbf=2007627 fast-speed=93000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=2465000 guard-bw-exc-exits=2097000 enough-mtbf=1 ignoring-advertised-bws=0
flag-thresholds stable-uptime=962383 stable-mtbf=2124393 fast-speed=59000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=3460000 guard-bw-exc-exits=2730000 enough-mtbf=1 ignoring-advertised-bws=1
flag-thresholds stable-uptime=962384 stable-mtbf=2124558 fast-speed=74000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=3960000 guard-bw-exc-exits=3240000 enough-mtbf=1 ignoring-advertised-bws=1
flag-thresholds stable-uptime=1005509 stable-mtbf=2023456 fast-speed=84000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=4730000 guard-bw-exc-exits=3930000 enough-mtbf=1 ignoring-advertised-bws=1
flag-thresholds stable-uptime=1018793 stable-mtbf=2208701 fast-speed=65000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=4370000 guard-bw-exc-exits=3240000 enough-mtbf=1 ignoring-advertised-bws=1
```
Stable flag consensuse should occur after stable-uptime 962383 sec (11.1 days), right?
But node CWis20 41C526E3C1441A3CDE9B605002643B94F3750E8C get Stable flag after only 5 days?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16524Don't vote HSDir if we aren't voting Valid2020-06-27T14:01:01ZRoger DingledineDon't vote HSDir if we aren't voting ValidSimilar to legacy/trac#15963 and legacy/trac#8243, if we end up taking away the Valid flag from a relay, I would like us to take away the HSDir flag too.
(I think there may still be some bug where if you take away the Valid flag, you en...Similar to legacy/trac#15963 and legacy/trac#8243, if we end up taking away the Valid flag from a relay, I would like us to take away the HSDir flag too.
(I think there may still be some bug where if you take away the Valid flag, you end up taking away the Running flag soon after, accidentally. But I think that bug is different and orthogonal to this one.)
In particular, there are relays currently that are running malicious HSDirs, but I'd like the opportunity to still make use of them for other (less sensitive) positions.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16518Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.122020-06-27T14:01:01ZteorRead-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12tor_0.2.5.12-1~d70.wheezy+1_amd64 can open the tor lockfile, but tor-0.2.6.9 gets a EROFS error.
The error happens in the first open() call in tor_open_cloexec, when called from tor_lockfile_lock. But I can't work out why.
aexl will wr...tor_0.2.5.12-1~d70.wheezy+1_amd64 can open the tor lockfile, but tor-0.2.6.9 gets a EROFS error.
The error happens in the first open() call in tor_open_cloexec, when called from tor_lockfile_lock. But I can't work out why.
aexl will write to tor-dev to provide more information.https://gitlab.torproject.org/tpo/core/tor/-/issues/16515tor_open_cloexec only uses the sandbox when O_CLOEXEC is defined2020-06-27T14:01:02Zteortor_open_cloexec only uses the sandbox when O_CLOEXEC is definedIn `tor_open_cloexec`, the `sandbox_intern_string` call is inside `#ifdef O_CLOEXEC`.
This means that we only use the sandbox if O_CLOEXEC is defined, which I doubt is the desired behaviour.
Bug from 0.2.3.1-alpha.
Fix branch coming soon.In `tor_open_cloexec`, the `sandbox_intern_string` call is inside `#ifdef O_CLOEXEC`.
This means that we only use the sandbox if O_CLOEXEC is defined, which I doubt is the desired behaviour.
Bug from 0.2.3.1-alpha.
Fix branch coming soon.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16512Proposal to combine HSDir and IP in next-gen hidden services2020-06-27T14:01:02ZJohn BrooksProposal to combine HSDir and IP in next-gen hidden servicesThis ticket exists to track the scheme[1] to remove HSDirs along with proposal 224, by combining their behavior with the introduction point.
The broad overview is that the client would choose an IP using the same algorithm proposed for ...This ticket exists to track the scheme[1] to remove HSDirs along with proposal 224, by combining their behavior with the introduction point.
The broad overview is that the client would choose an IP using the same algorithm proposed for choosing a HSDir, build a circuit, and ask for a "descriptor" containing metadata and the IP encryption key. The client then sends INTRODUCE1 over the same circuit, and from there proceeds as already proposed.
See the tor-dev thread for some prior discussion on the tradeoffs. I have tasked myself with writing some real text for this based on proposal 224.
[1] https://lists.torproject.org/pipermail/tor-dev/2015-April/008743.htmlhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16506Open subtickets tor improving test coverage in specific areas2020-06-27T14:01:02ZIsabela FernandesOpen subtickets tor improving test coverage in specific areasThis ticket is to track the work related on making sure we have test coverage to the most important pieces of core tor.
The task is to review the output of NickM's coverage script [0,1] and identify the modules that we should write test...This ticket is to track the work related on making sure we have test coverage to the most important pieces of core tor.
The task is to review the output of NickM's coverage script [0,1] and identify the modules that we should write tests for. For each one we identify we will create a sub-ticket to track the actual work of writing the tests for that module.
![0]!https://lists.torproject.org/pipermail/tor-dev/2015-July/009011.html
![1]!https://people.torproject.org/~nickm/volatile/coverage-65a1e27.tar.bz2Tor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16480connection_write_to_buf: indirect recursion for CONN_TYPE_CONTROL2020-06-27T14:01:02Zcypherpunksconnection_write_to_buf: indirect recursion for CONN_TYPE_CONTROLCall of `connection_write_to_buf` for CONN_TYPE_CONTROL allows immediate flush of the outbuf. Then if code tries to log something and `control_event_logmsg` is involved then it call of `connection_write_to_buf` recursively. Consequence c...Call of `connection_write_to_buf` for CONN_TYPE_CONTROL allows immediate flush of the outbuf. Then if code tries to log something and `control_event_logmsg` is involved then it call of `connection_write_to_buf` recursively. Consequence calls blocked by `++disable_log_messages` only then.
Three ways to fix:
1. Remove ability for immediate flush of the outbuf by `connection_write_to_buf`
2. Check `in_connection_handle_write` flag at start of `connection_handle_write`
3. Guard call of `connection_handle_write` by `disable_control_logging` and `enable_control_logging`
Every way have negative and positive impacts.Tor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16470Rule 'test-stem-full' ignores configured Python2020-06-27T14:01:02ZcypherpunksRule 'test-stem-full' ignores configured PythonThe make rule `test-stem-full` ignores the configured Python executable stored in the variable `PYTHON`. Instead it uses the system default which isn't necessarily the correct one.
A patch will follow. Created the ticket to give it a nu...The make rule `test-stem-full` ignores the configured Python executable stored in the variable `PYTHON`. Instead it uses the system default which isn't necessarily the correct one.
A patch will follow. Created the ticket to give it a number.Tor: 0.2.7.x-final