The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-04-18T13:55:23Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33632List ed25519 fingerprints on the command line2021-04-18T13:55:23ZteorList ed25519 fingerprints on the command lineFor RSA keys, tor has `tor --list-fingerprint`.
We could add a feature to tor so it accepts a key type argument:
* `tor --list-fingerprint rsa`
* `tor --list-fingerprint ed25519`
And defaults to RSA (for now).
Related to legacy/trac#30...For RSA keys, tor has `tor --list-fingerprint`.
We could add a feature to tor so it accepts a key type argument:
* `tor --list-fingerprint rsa`
* `tor --list-fingerprint ed25519`
And defaults to RSA (for now).
Related to legacy/trac#30642, which adds an `ed25519-fingerprint` file.https://gitlab.torproject.org/tpo/core/tor/-/issues/33629Use stale bot to close old pull requests2021-02-05T21:03:36ZteorUse stale bot to close old pull requestsShould we automatically close stale pull request on GitHub?
Some GitHub users won't contribute to a project with lots of open pull requests, because they think it's been abandoned. (Or they think we're bad at merging PRs.)
But lots of ...Should we automatically close stale pull request on GitHub?
Some GitHub users won't contribute to a project with lots of open pull requests, because they think it's been abandoned. (Or they think we're bad at merging PRs.)
But lots of our PRs get left open because we've squashed and merged the PR, and GitHub doesn't recognise the squashed commits, so GitHub doesn't auto-close the PR.
Closing a PR:
* hides it from the default list of PRs
* hides its CI results in the PR itself (but they still appear in the PR list)
Anyone can reopen a closed PR. Re-opening a PR re-runs CI (which is usually what we want for old PRs).
I suggest we use probot stale:
https://probot.github.io/apps/stale/
With the following options:
* daysUntilStale: 60
* some backport PRs are older than 60 days, but their CI should have been checked when they were reviewed
* we don't merge very many stale PRs to master
* any period from 30 days (most reviews completed) to 6 months (release cycle) would probably work for us
* daysUntilClose: 7
* exemptLabels: pinned
* staleLabel: stale-closed
* markComment: (like the suggested one, but mention the "pinned" label)
* closeComment: false
On the following network team repositories:
* tor
* ~400 older than 2 months
* ~270 older than 6 months
* torspec
* 8 older than 2 months
* 6 older than 6 months
* chutney
* 1 older than 6 months, needs to be pinned?
* fallback-scripts
And the top-level GitHub config repository:
* .githubhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33623sendme: Change default emit cell version from 0 to 12020-07-09T15:03:04ZDavid Gouletdgoulet@torproject.orgsendme: Change default emit cell version from 0 to 1In legacy/trac#32774, the consensus is telling every relay to emit SENDME v1.
We should change the default hardcoded value from 0 to 1 as well.In legacy/trac#32774, the consensus is telling every relay to emit SENDME v1.
We should change the default hardcoded value from 0 to 1 as well.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33619Resolve TROVE-2020-0042020-06-27T13:48:03ZNick MathewsonResolve TROVE-2020-004This is a remotely triggerable memory leak on relays and clients, found by tobias pulls.
The issue is that when circpad_setup_machine_on_circ() is reached with an inconsistent internal configuration, it fails to free an object that is r...This is a remotely triggerable memory leak on relays and clients, found by tobias pulls.
The issue is that when circpad_setup_machine_on_circ() is reached with an inconsistent internal configuration, it fails to free an object that is replaced. It logs a bug warning, but that isn't enough.
Tobias Pulls found that this code was actually reachable, though, and results in a memory leak.Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33617Add a BandwidthStatistics option and consensus parameter2022-06-17T19:10:47ZteorAdd a BandwidthStatistics option and consensus parameterStage 1:
We propose adding a new BandwidthStatistics torrc option, which activates reporting of all the bandwidth statistics. At the moment, all statistics are controlled by ExtraInfoStatistics, but we propose using the new BandwidthSt...Stage 1:
We propose adding a new BandwidthStatistics torrc option, which activates reporting of all the bandwidth statistics. At the moment, all statistics are controlled by ExtraInfoStatistics, but we propose using the new BandwidthStatistics option specifically for the bandwidth statistics.
The default value of this option should be 1. (The existing bandwidth statistics are reported by default.)
The new option should have a manual page entry, and test_parseconf.sh tests in src/test/conf_examples.
Stage 2:
Add a BandwidthStatistics consensus paramter.
Change the default value of the BandwidthStatistics option to "auto". If the value is "auto", use the value of the consensus parameter. If the consensus parameter is not set, use "1".
Update the manual page to describe the new consensus parameter.
See the proposal:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n298MrSquancheeMrSquancheehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33608Stop forcing prefer IPv6 on non-SOCKSPorts2020-06-27T13:48:04ZteorStop forcing prefer IPv6 on non-SOCKSPortsIn legacy/trac#32637 we forced PreferIPv6 on all non-SOCKSPorts.
That could be a breaking change for some users, and they will have no way to recover. We should just set a sensible default, and let users tweak it if it doesn't work for ...In legacy/trac#32637 we forced PreferIPv6 on all non-SOCKSPorts.
That could be a breaking change for some users, and they will have no way to recover. We should just set a sensible default, and let users tweak it if it doesn't work for them.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33607Stop forcing IPv4 and IPv6 traffic on non-SOCKSPorts2021-07-09T17:22:51ZteorStop forcing IPv4 and IPv6 traffic on non-SOCKSPortsAfter legacy/trac#32994, the defaults in `port_cfg_new()` will apply to all parsed ports. (Not just default ports.)
I am not sure what we should do with the extra settings in `connection_listener_new()`:
```
if (type != CONN_TYPE_AP_L...After legacy/trac#32994, the defaults in `port_cfg_new()` will apply to all parsed ports. (Not just default ports.)
I am not sure what we should do with the extra settings in `connection_listener_new()`:
```
if (type != CONN_TYPE_AP_LISTENER) {
lis_conn->entry_cfg.ipv4_traffic = 1;
lis_conn->entry_cfg.ipv6_traffic = 1;
lis_conn->entry_cfg.prefer_ipv6 = 1;
}
```
Here are our options:
* leave them there: non-SOCKSPorts will always have IPv4, IPv6, and prefer IPv6 traffic
* copy the defaults from port_cfg_new(): non-SOCKSPorts will always have DNS, Onion, and prefer IPv6 virtual addresses. Forcing these options on might make some configs break.
* delete them: non-SOCKSPorts can now disable IPv4, IPv6, and prefer IPv4 traffic. Some rare configs might break, because they relied on the options being forced on.
Here's what I think we should do long-term:
* set reasonable defaults (in legacy/trac#32994)
* stop forcing options on (this ticket)
* warn users that some rare configs might break, and they should remove NoIPv4Traffic or NoIPv6Traffic as needed (this changes file)
"prefer IPv6 traffic" was added in legacy/trac#32637 in 0.4.3.1-alpha. We don't want to force that option on in 0.4.3, that makes the problem worse, and might break some existing configs. See legacy/trac#33608 for a fix.https://gitlab.torproject.org/tpo/core/tor/-/issues/33582Make bridges wait until they have bootstrapped, before publishing their descr...2022-06-17T18:47:09ZteorMake bridges wait until they have bootstrapped, before publishing their descriptorInstead of this fix, we can make chutney check tor's logs for reachability self-test successes (legacy/trac#34037), or implement strict self-tests (legacy/trac#33222).
On bridges, there's a race condition when bridges try to publish the...Instead of this fix, we can make chutney check tor's logs for reachability self-test successes (legacy/trac#34037), or implement strict self-tests (legacy/trac#33222).
On bridges, there's a race condition when bridges try to publish their descriptor to the bridge authority:
* bridges try to publish their descriptors before bootstrapping
* but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Bridges will eventually try to publish their descriptors again, when they become dirty.
We should make bridges wait until they have bootstrapped, before they try to publish their descriptors. (This might be a good change for relays as well: there isn't much point in publishing a relay that can't bootstrap.)
This issue happens regardless of `AssumeReachable`. It is most obvious in chutney networks.
This ticket isn't essential. But the workarounds seem to cause weird race conditions, which are time-consuming to diagnose and fix.https://gitlab.torproject.org/tpo/core/tor/-/issues/33572Add the tor version key to the bandwidth file specification2020-06-27T13:48:05ZjugaAdd the tor version key to the bandwidth file specificationIt has already been done and reviewed in https://trac.torproject.org/projects/tor/ticket/30196#comment:16, but the component of that ticket is sbws, no Tor.
GH PR: https://github.com/torproject/torspec/pull/107.It has already been done and reviewed in https://trac.torproject.org/projects/tor/ticket/30196#comment:16, but the component of that ticket is sbws, no Tor.
GH PR: https://github.com/torproject/torspec/pull/107.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33554Excessive CPU usage in windows tor_cond_t code?2020-07-29T14:37:47ZNick MathewsonExcessive CPU usage in windows tor_cond_t code?On legacy/trac#33411, gvanem reports excdessive CPU consumption in the windows tor_cond_t code. We should see if we can fix that.On legacy/trac#33411, gvanem reports excdessive CPU consumption in the windows tor_cond_t code. We should see if we can fix that.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33553Target and Eliminate http & adjacent algorithms & increase algorithm complexi...2020-07-29T14:38:27ZcypherpunksTarget and Eliminate http & adjacent algorithms & increase algorithm complexity given set standard.Core network of nodes limit to https only by default for clear net interaction.
Eliminate "128" algorithms and weak SSL&TLS
Focus on quantum and PQ encryption of traffic.Core network of nodes limit to https only by default for clear net interaction.
Eliminate "128" algorithms and weak SSL&TLS
Focus on quantum and PQ encryption of traffic.https://gitlab.torproject.org/tpo/core/tor/-/issues/33550Bandbreiten Problem mit der Brücke2020-07-29T14:38:54ZTracBandbreiten Problem mit der BrückeHi everyone.
It looks like I can no longer reach the full bandwidth with my relay or my bridge. Are there currently problems in the network or is it due to my server? I released 16Mbits. And it looks like my bridge is not valid.
Sorry, ...Hi everyone.
It looks like I can no longer reach the full bandwidth with my relay or my bridge. Are there currently problems in the network or is it due to my server? I released 16Mbits. And it looks like my bridge is not valid.
Sorry, but I'm an absolute amateur.
This is my bridge:
[https://metrics.torproject.org/rs.html#details/0A2A19DCF7D6C3D07CBDA06AF44A8B90114B8033]
**Trac**:
**Username**: habusTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33547Config: add a type or helper for range-restricted variables2022-06-17T13:24:14ZNick MathewsonConfig: add a type or helper for range-restricted variablesVery frequently we want to have a config type that is "int, restricted to some range of values". We should have a means to represent that, and thereby save a bunch of boilerplate code.
This could be done with new var_type_def_t for eac...Very frequently we want to have a config type that is "int, restricted to some range of values". We should have a means to represent that, and thereby save a bunch of boilerplate code.
This could be done with new var_type_def_t for each range, but that could get out of hand. Probably we want a way to add more info to the config_var_t.https://gitlab.torproject.org/tpo/core/tor/-/issues/33545assertion failure when "all zero" client auth key provided2021-08-23T15:12:44ZMark Smithassertion failure when "all zero" client auth key providedWhile doing some Tor Browser testing for Sponsor 27, I experienced the following after I intentionally used an incorrect client auth key for a v3 onion service:
```
... [err] tor_assertion_failed_: Bug: src/feature/hs/hs_descriptor.c:142...While doing some Tor Browser testing for Sponsor 27, I experienced the following after I intentionally used an incorrect client auth key for a v3 onion service:
```
... [err] tor_assertion_failed_: Bug: src/feature/hs/hs_descriptor.c:1423: decrypt_descriptor_cookie: Assertion !fast_mem_is_zero((char *) client_auth_sk, sizeof(*client_auth_sk)) failed; aborting. (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
```
As it turns out, I happened to enter a key that is consists entirely of zero bits. This is an unusual thing to do, but I do not think tor should exit.
Steps to reproduce in Tor Browser:
1. Try to load an http or https page for a v3 onion service that requires client authentication, e.g., dgoulet's test server.
2. Enter 56 'A's when prompted for a client auth key.
Result: tor exits due to the assertion failure. Behind the scenes, the browser installs the key via a control port command like the following:
```
onion_client_auth_add <onion-addr> x25519:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
```
and then tries to access the onion service again (page reload).Tor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/33542Orbot not working after the update.2020-07-29T14:39:26ZTracOrbot not working after the update.Hello,
I have an Android 7.1.1 and after updated the Orbot then it can't work. It just show me "Orbot is starting..." . I removed and installed it again, but problem not solved.
How can I fix it?
Thank you.
**Trac**:
**Username**: Ha...Hello,
I have an Android 7.1.1 and after updated the Orbot then it can't work. It just show me "Orbot is starting..." . I removed and installed it again, but problem not solved.
How can I fix it?
Thank you.
**Trac**:
**Username**: Hack3rconhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33538v3bw files with too large of weights lead to relays being selected nearly uni...2021-09-27T16:44:52Zpastlyv3bw files with too large of weights lead to relays being selected nearly uniformly at randomAs part of working on the FlashFlow paper (currently under submission) we ran Shadow simulations and compared it to TorFlow. Not surprising.
Summary of the Shadow network used:
- 5% of the real Tor network in size
- 44 exits
- ...As part of working on the FlashFlow paper (currently under submission) we ran Shadow simulations and compared it to TorFlow. Not surprising.
Summary of the Shadow network used:
- 5% of the real Tor network in size
- 44 exits
- 104 guards
- 180 middles
- 3 auths
- 10 "markov" clients. It's not terribly important to know what they're doing, other than knowing they're making lots of 3-hop exit circuits and exchanging traffic with servers. 2 of the clients have tor debug logs. All 10 contribute to the relay selection data.
- Tor version used is a63b4148229ae8ce46494fd6a0f99149c231605c (master branch as of March 5th, 2020) plus a small logging patch. [Branch here](https://github.com/pastly/public-tor/tree/log-relay-weights). This existed in 0.3.5.7 as well. I don't know when this problem started because I don't know exactly what the problem is.
- Shadow 292cd89ba52fc2972fdd9d2e27e384db9601663b (as of Jan 10th, 2020).
- Shadow-plugin-tor 8deab15a032f5173ba7c12ad6dd0bcb1cb0c3463 (as of Oct 2019) plus patch so it works with new Tors. [Branch here](https://github.com/pastly/shadow-plugin-tor/tree/three-stubs).
The only difference in the simulations are the v3bw files used.
There are three simulations:
1. Torflow-derived weights (TF)
1. FlashFlow-derived weights (FF init)
1. FlashFlow-derived weights that have all been divided by 136 (FF scaled)
weight-dist.pdf shows the distribution of the weights in the v3bw files, both with the raw absolute weights and as normalized (norm_weight = weight / total_weight). Despite having nearly identical normalized weight distributions (note: FF init and FF scaled are obviously identical), FF init results in (1) relays being selected seemingly uniformly at random, and (2) significantly worse performance as a consequence.
selection-v-weight.pdf shows how often the 10 markov clients picked each relay. Focus on the scatter plots. Notice how in TF and FF scaled there is basically a 1:1 linear relationship between additional weight and selection frequency, while in FF init the selection frequency is roughly the same regardless of the relay's weight.
I am also attaching the three v3bw files, combined into one file to reduce email spam.
I am also attaching small snippits from the debug logs (again: combined into one file) of one of the markov clients. The snippits show some of the relay weights the client is using when deciding which relays to use. You can see in the FF initial one that the weights are much more similar than in FF scaled and TF.https://gitlab.torproject.org/tpo/core/tor/-/issues/33530Dir auths should notice relays with wrong clocks and act somehow (BadClock fl...2023-02-07T10:15:08ZRoger DingledineDir auths should notice relays with wrong clocks and act somehow (BadClock flag, withhold Guard)Directory authorities scan every relay every 22 minutes or so, to test reachability.
As part of establishing the Tor connection handshake, they get a netinfo cell from the relay. So if they look at it, they will know whether the relay's...Directory authorities scan every relay every 22 minutes or so, to test reachability.
As part of establishing the Tor connection handshake, they get a netinfo cell from the relay. So if they look at it, they will know whether the relay's clock is right or wrong.
So we're nearly there. Now we should act when we find a relay with a wrong clock, to help the relay operator fix it, and to reduce the harm to clients.
I suggest taking two responses if a relay has a wrong clock:
(A) Don't assign it the Guard flag. Clients rely on their guards for time, e.g. because they need the guards to have proper cached dir info. And in the glorious future where we've made progress on legacy/trac#2628 and friends, while we won't want to rely solely on non-dir-auth relays to tell us if we're skewed, if we can drive down false positives from normal relays, the parameters get easier to pick for whatever solutions we decide on.
(B) Put the "BadClock" flag in our vote about it. We don't need to change the consensus building process, or even get that flag into the consensus itself. Just having it in the votes means that consensus-health and relay-search can look at it and visualize it for relay operators, rather than needing to do their own clock scans. (And having it there helps the operator debug confusing questions like *why* they aren't getting the Guard flag.) And as a bonus here, eventually Serge will put that flag in its bridge networkstatus document, so bridgedb can make a smarter decision, and so relay-search can visualize it too.https://gitlab.torproject.org/tpo/core/tor/-/issues/33522Add iOS support in your CI2020-06-27T13:48:07ZTracAdd iOS support in your CIAFAIK, Tor.framework is the most advanced library to package Tor for iOS.
You can find it here:
https://github.com/iCepa/Tor.framework
It has a Travis-CI configuration, which I just updated to work on the latest macOS/Xcode image:
htt...AFAIK, Tor.framework is the most advanced library to package Tor for iOS.
You can find it here:
https://github.com/iCepa/Tor.framework
It has a Travis-CI configuration, which I just updated to work on the latest macOS/Xcode image:
https://github.com/iCepa/Tor.framework/blob/master/.travis.yml
Currently, we have issues in getting past Tor 0.4.0.6 on iOS. When I try to use a newer core, I get this error message:
> Unknown type name 'dispatch_queue_t'
in CFStream of Apple's CoreFoundation framework.
But "dispatch_queue_t" is actually a valid symbol from Apple's Foundation libraries.
So somehow, it gets cancelled out through something which changed in Tor recently.
We're really stuck here, so it would be a huge help, if you could add Tor.framework to your Continuous Integration so you'd be able to support us here and detect problems earlier in the future.
For your purposes, there's no need to have Macs and Xcode.
The most important files to control the build are these shell scripts:
https://github.com/iCepa/Tor.framework/blob/master/Tor/tor.sh
https://github.com/iCepa/Tor.framework/blob/master/Tor/libevent.sh
https://github.com/iCepa/Tor.framework/blob/master/Tor/openssl.sh
https://github.com/iCepa/Tor.framework/blob/master/Tor/xz.sh
Tor and the other libraries come in via Git submodules:
https://github.com/iCepa/Tor.framework/blob/master/.gitmodules
So the dev process on your side would be:
Update submodules to your latest state, let it build in Travis. If broken, fix above build scripts. Re-run through Travis.
Could that work for you?
**Trac**:
**Username**: tlaTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33513Check boolean values and semantic versioning in the bandwidth file specification2020-07-31T12:54:24ZjugaCheck boolean values and semantic versioning in the bandwidth file specificationThere're KeyValues that are `bool` (as defined in the dirspec) in the bandwidth file specification and in the actual bandwidth files they're some times {0,1} or {True, False}.
Maybe the True/False values should actually be changed in sbw...There're KeyValues that are `bool` (as defined in the dirspec) in the bandwidth file specification and in the actual bandwidth files they're some times {0,1} or {True, False}.
Maybe the True/False values should actually be changed in sbws.
The versioning is also defined in dirspec, but Tor versioning is not exactly semantic versioning. For the software version we have started to use PEP404 specifically, while for the specification version we're using just mayor.minor.path format.https://gitlab.torproject.org/tpo/core/tor/-/issues/33469INTERNAL ERROR: Raw assertion failed at src/lib/malloc/map_anon.c:239: lock_r...2022-06-17T18:06:22ZTracINTERNAL ERROR: Raw assertion failed at src/lib/malloc/map_anon.c:239: lock_result == 0I tried updating to latest stable version and I have this error after a couple of minutes:
```
Feb 27 14:38:04.987 [notice] Tor 0.4.2.6 (git-971a6beff5a53434) running on Windows Server 2003 with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zli...I tried updating to latest stable version and I have this error after a couple of minutes:
```
Feb 27 14:38:04.987 [notice] Tor 0.4.2.6 (git-971a6beff5a53434) running on Windows Server 2003 with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Feb 27 14:38:05.003 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 27 14:38:05.018 [notice] Read configuration file "U:\2\Server\TOR\tor.ini".
Feb 27 14:38:05.018 [notice] Based on detected system memory, MaxMemInQueues is set to 2048 MB. You can override this by setting MaxMemInQueues by hand.
Feb 27 14:38:05.034 [warn] You specified a public address '0.0.0.0:8080' for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
Feb 27 14:38:05.034 [notice] Opening Socks listener on 0.0.0.0:8080
Feb 27 14:38:05.034 [notice] Opened Socks listener on 0.0.0.0:8080
Feb 27 14:38:05.034 [notice] Opening Control listener on 127.0.0.1:9051
Feb 27 14:38:05.049 [notice] Opened Control listener on 127.0.0.1:9051
Feb 27 14:38:05.049 [notice] Opening OR listener on 0.0.0.0:9001
Feb 27 14:38:05.049 [notice] Opened OR listener on 0.0.0.0:9001
Feb 27 14:38:05.049 [notice] Opening Directory listener on 0.0.0.0:9030
Feb 27 14:38:05.049 [notice] Opened Directory listener on 0.0.0.0:9030
============================================================ T= 1582807176
INTERNAL ERROR: Raw assertion failed in Tor 0.4.2.6 (git-971a6beff5a53434) at src/lib/malloc/map_anon.c:239: lock_result == 0
```
**Trac**:
**Username**: m95d