The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-10-11T23:39:34Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33712Design a PoW scheme for HS DoS defence2022-10-11T23:39:34ZGeorge KadianakisDesign a PoW scheme for HS DoS defenceSome initial research has been done on comment:13:ticket:31223 to sketch out a PoW/credential scheme that works for HS DoS defence.
This ticket is to continue scheming and working on this design.
See https://lists.torproject.org/piperm...Some initial research has been done on comment:13:ticket:31223 to sketch out a PoW/credential scheme that works for HS DoS defence.
This ticket is to continue scheming and working on this design.
See https://lists.torproject.org/pipermail/tor-dev/2020-April/014215.html for initial proposal.https://gitlab.torproject.org/tpo/core/tor/-/issues/33703Improving HS availability under DoS (master ticket)2022-10-11T23:39:34ZGeorge KadianakisImproving HS availability under DoS (master ticket)This is the master ticket for organizing work under this topic.This is the master ticket for organizing work under this topic.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33702RSA_get0_d could not be located in the dynamic link library tor.exe2023-05-31T18:44:10ZTracRSA_get0_d could not be located in the dynamic link library tor.exeOS: Win10 (win64)
Tor Browser will not run, when attempting to establish a connection the following error appeats:
The procedure entry point RSA_get0_d could not be located in the dynamic link library C:\Users\MyUser\Desktop\Tor Browse...OS: Win10 (win64)
Tor Browser will not run, when attempting to establish a connection the following error appeats:
The procedure entry point RSA_get0_d could not be located in the dynamic link library C:\Users\MyUser\Desktop\Tor Browser\Browser\TorBrowser\Tor\tor.exe
**Trac**:
**Username**: ner0https://gitlab.torproject.org/tpo/core/tor/-/issues/33689README cleanups2020-06-27T13:47:59ZGhost UserREADME cleanupsHello everyone,
I just started playing around with Tor a few days back so as one could expect I started with `README.1st.md` file. I realized that different `*.md` files are not consistent style-wise so I decided to clean them up a bit.
...Hello everyone,
I just started playing around with Tor a few days back so as one could expect I started with `README.1st.md` file. I realized that different `*.md` files are not consistent style-wise so I decided to clean them up a bit.
Brief summary:
- no empty line at the very beginning of the file,
- single empty line between sections (sometimes there were two)
```
... end of the sentence.
New Section
----
```
rather than
```
... end of the sentence.
New Section
----
```
- external links use [name](url) format,
- there is no single space in front of the section name
```
Foo
===
```
is changed to
```
Foo
===
```
Which fixes syntax issues in editors like GNU Emacs with enabled markdown preview.
- I tried to check all links (local and external) and fix the ones which were broken.
For example **the Tor proposal process** inside `README.1st.md` or `doc/WritingTests.txt` were changed to `.../doc/HACKING/WritingTests.md` in few places).
----
At the very end of `README.1st.md` file there are some TODO (I think?) sections. I wrapped them around in "TODO" section.
```
TODO
-----------------------
XXXXX also describe
doc/HACKING/WritingTests.md
torguts.git
torspec.git
The design paper
freehaven.net/anonbib
XXXX describe these and add links.
```
However I am not sure if these are still needed there. Most of these topics are mentioned already in this file and linked to other files (WritingTests, torspec, etc.).https://gitlab.torproject.org/tpo/core/tor/-/issues/33687Create rotating DNS DoH/DoT server list option Trr Core Tor2020-07-29T14:43:15ZcypherpunksCreate rotating DNS DoH/DoT server list option Trr Core TorReference
https://github.com/curl/curl/wiki/DNS-over-HTTPS
https://dnsprivacy.org/wiki/m/mobile.action#page/1277971
Add options to UX/UI and etc.Reference
https://github.com/curl/curl/wiki/DNS-over-HTTPS
https://dnsprivacy.org/wiki/m/mobile.action#page/1277971
Add options to UX/UI and etc.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33681Refactor using_default_dir_authorities() local address checks2021-09-16T14:22:18ZteorRefactor using_default_dir_authorities() local address checksCurrently, we check for IPv4 and IPv6 local addresses and using_default_dir_authorities() in two different places:
* IPv4: resolve_my_address()
* IPv6: router_get_advertised_ipv6_or_ap()
Once we've combined the code that checks IPv4 and...Currently, we check for IPv4 and IPv6 local addresses and using_default_dir_authorities() in two different places:
* IPv4: resolve_my_address()
* IPv6: router_get_advertised_ipv6_or_ap()
Once we've combined the code that checks IPv4 and IPv6 advertised ORPorts, we can do a single using_default_dir_authorities() check.https://gitlab.torproject.org/tpo/core/tor/-/issues/33678Disable practracker in git hooks in maint-0.4.32020-06-27T13:48:00ZteorDisable practracker in git hooks in maint-0.4.3Let's remove .enable_practracker_in_hooks to disable practracker in hooks in maint-0.4.3.Let's remove .enable_practracker_in_hooks to disable practracker in hooks in maint-0.4.3.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33670Fix erroneous spaces in circuitmux_ewma.c2020-06-27T13:48:01ZNeel Chauhanneel@neelc.orgFix erroneous spaces in circuitmux_ewma.cNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33668--disable-module-relay yields to a Bug:2020-06-27T13:48:01Ztoralf--disable-module-relay yields to a Bug:At a hardened Gentoo Linux the configure option yields to a
```
# tor --verify-config
Mar 19 19:44:35.839 [notice] Tor 0.4.3.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and L...At a hardened Gentoo Linux the configure option yields to a
```
# tor --verify-config
Mar 19 19:44:35.839 [notice] Tor 0.4.3.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
Mar 19 19:44:35.840 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 19 19:44:35.840 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Mar 19 19:44:35.840 [notice] Read configuration file "/etc/tor/torrc".
Mar 19 19:44:35.843 [err] tor_assertion_failed_(): Bug: src/app/config/config.c:1473: options_switch_id: Assertion have_low_ports != -1 failed; aborting. (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.844 [err] Bug: Tor 0.4.3.3-alpha: Assertion have_low_ports != -1 failed in options_switch_id at src/app/config/config.c:1473: . Stack trace: (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(log_backtrace_impl+0x59) [0x5564677d3ab9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(tor_assertion_failed_+0x150) [0x5564677cecb0] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(set_options+0x404) [0x5564677535d4] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(+0x1648a0) [0x5564677548a0] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(options_init_from_string+0x119) [0x556467754af9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(options_init_from_torrc+0x359) [0x5564677550f9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(tor_init+0x1c7) [0x55646764ade7] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(tor_run_main+0x71) [0x55646764b4e1] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(tor_main+0x46) [0x55646764a006] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(main+0x19) [0x556467649bd9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xeb) [0x7ff9817b8f1b] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(_start+0x2a) [0x556467649c2a] (on Tor 0.4.3.3-alpha )
Aborted
```
The same tarball at the same system works fine with that option being enabled.
The config is
```
cat /etc/tor/torrc
User tor
PIDFile /var/run/tor/tor.pid
Log notice file /tmp/notice.log
DataDirectory /var/lib/tor/data
CookieAuthentication 1
ControlPort 9051
SocksPort 9050
SandBox 1
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33650Verify that intro2 cell extensions actually work2022-10-11T23:39:34ZRoger DingledineVerify that intro2 cell extensions actually workIn the future we're going to want to transport end-to-end tokens, proofs of work, or other blobs from client to onion service. We should make sure that we can actually add these into the cells without anything going wrong, like surprisin...In the future we're going to want to transport end-to-end tokens, proofs of work, or other blobs from client to onion service. We should make sure that we can actually add these into the cells without anything going wrong, like surprising asserts or surprising length enforcement.
(Now is the time to notice if things will go wrong, so we can fix them and deploy that fix, and then people will have upgraded by the time we're ready to actually use them.)
So: let's make a branch that adds "hi mom" on the client side, and reads it out again on the service side.
In spelunking through the code and the spec, I found that modern intro2 cells have an "extensions" field inside their encrypted component, which seems perfectly suited for transporting arbitrary blobs from client to service. Here's how we set it currently on the client side:
```
/* Set extension data. None are used. */
ext = trn_cell_extension_new();
tor_assert(ext);
trn_cell_extension_set_num(ext, 0);
trn_cell_introduce_encrypted_set_extensions(enc_cell, ext);
```
So that 0 needs to become a 1, and then we need something new that makes and sets a new extension in ext (modeled maybe on `build_establish_intro_dos_extension()`, and something on the receiving end that invokes trn_cell_extension_parse() and reads it out to us.
I am optimistic, because this thing is encrypted, so the intro point in the middle can't be looking at it very carefully. But if we have bugs on the client side or the service side, or surprise length enforcement in the middle, now is a great time to notice and fix them.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33648vanguards: What is the recommended value?2020-07-29T14:36:11Zcypherpunksvanguards: What is the recommended value?Since your default configuration & github document doesn't tell me much, I'd like to hear developer's opinion on this.
vanguards.conf
Bandguards:
circ_max_age_hours = 1 (Mine is just simple WWW service without fancy WebSockets, downl...Since your default configuration & github document doesn't tell me much, I'd like to hear developer's opinion on this.
vanguards.conf
Bandguards:
circ_max_age_hours = 1 (Mine is just simple WWW service without fancy WebSockets, downloads or videos)
circ_max_hsdesc_kilobytes = 30
circ_max_megabytes = 5
Q1. Is using smaller value such as 1 for circ_max_age_hours have any problems regarding anonymity?
Q2. You didn't mention default size of hidden service descriptor. What value is it? This is not OnionShare or onionbalance.
(if you can do {circ_max_hsdesc_kilobytes != normal_desc_size kill_connection} that's great)
Q3. You said "HTTP GET can resume if this limit is hit, HTTP POST will not" in circ_max_megabytes. You better add this text, don't you think: "If the client reach this limit, we close the connection and create another one to continue operation. Client will experience small downtime."
Q4. Can you add an option to slow down packets on purpose, to prevent simple DDoS? e.g. 'limit_packets_per_seconds = 10' will allow 10 packets per seconds and delay exceeded packets (x) secondsTor: unspecifiedMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33646Wrong list of enabled modules2021-07-05T11:27:26ZTracWrong list of enabled modulesWhen I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth...When I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth (--disable-module-dirauth): yes
dircache (--disable-module-dircache): yes
```
Which is wrong, since I have enabled relay and disabled dirauth.
Looks like problem is located in commit [9c33d36113447d38decd22d177e62fb225826d78](https://gitweb.torproject.org/tor.git/commit/?id=9c33d36113447d38decd22d177e62fb225826d78).
Related: legacy/trac#32230.
Please recheck.
**Trac**:
**Username**: VortTor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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.