The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:48:42Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32695Remove consensus methods 25-272020-06-27T13:48:42ZteorRemove consensus methods 25-27According to proposal 290, we remove some consensus methods every time an LTS release is no longer supported:
https://gitweb.torproject.org/torspec.git/tree/proposals/290-deprecate-consensus-methods.txt
When 0.2.9 is no longer supported...According to proposal 290, we remove some consensus methods every time an LTS release is no longer supported:
https://gitweb.torproject.org/torspec.git/tree/proposals/290-deprecate-consensus-methods.txt
When 0.2.9 is no longer supported, the earliest stable LTS will be 0.3.5.7, which supports consensus methods 25-28. Therefore, we can remove all consensus methods less than 28:
https://gitweb.torproject.org/tor.git/tree/src/feature/dirauth/dirvote.h?h=tor-0.3.5.7#n60Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32690Create new directive HiddenServiceExportStats.2022-06-22T15:44:12ZTracCreate new directive HiddenServiceExportStats.Currently `HiddenServiceExportCircuitID` specifies the protocol. As we move towards exporting as much stats as we can, I think it's better to create a new directive(`HiddenServiceExportStats`) for the protocol only.
Also, I need some op...Currently `HiddenServiceExportCircuitID` specifies the protocol. As we move towards exporting as much stats as we can, I think it's better to create a new directive(`HiddenServiceExportStats`) for the protocol only.
Also, I need some opinions on the directives.
1. Create directive per stat(`HiddenServiceExport*`), make all of them bound to the hidden service (in `hs_service_config_t`).
2. Create directive per stat, only `HiddenServiceExportStats` bounds to the hidden service and others are global (in `or_options_st`).
3. Don't create directive per stat, Only one directrive `HiddenServiceExportStats`, bound to the hidden service, exports all.https://gitlab.torproject.org/tpo/core/tor/-/issues/32688Make tor_tls_get_buffer_sizes() work again2022-06-17T18:30:22ZNick MathewsonMake tor_tls_get_buffer_sizes() work againWhere supported, Tor uses OpenSSL skulduggery to find out how much RAM openssl has allocated and/or is using for buffers in each SSL object, and . This information is only used for logging right now (in `dumpstats()`), but it has potent...Where supported, Tor uses OpenSSL skulduggery to find out how much RAM openssl has allocated and/or is using for buffers in each SSL object, and . This information is only used for logging right now (in `dumpstats()`), but it has potential use in our OOM/DOS prevention code.
The tricks that we used up till now no longer actually work with OpenSSL 1.1.0, however, since the relevant structures are now opaque. We'll either need to find another way to get their sizes, or add some API to OpenSSL to expose them.
This is low-priority, unless we actually have time to use this information in OOM calculation.https://gitlab.torproject.org/tpo/core/tor/-/issues/32685Update to December GeoIP2 database2020-06-27T13:48:42ZKarsten LoesingUpdate to December GeoIP2 database[My geoip-2019-12-03 branch](https://gitweb.torproject.org/user/karsten/tor.git/log/?h=geoip-2019-12-03) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other b...[My geoip-2019-12-03 branch](https://gitweb.torproject.org/user/karsten/tor.git/log/?h=geoip-2019-12-03) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branches that are still maintained.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32680Circpad: More/better pattern recognition events2022-06-17T13:04:56ZMike PerryCircpad: More/better pattern recognition eventsResearchers might want other internal events for custom packet pattern recognition, so that they do not have to build quite so complicated state machines. One such example would be an event for ANY_BINS_EMPTY. Others might include packet...Researchers might want other internal events for custom packet pattern recognition, so that they do not have to build quite so complicated state machines. One such example would be an event for ANY_BINS_EMPTY. Others might include packet arrival length counts or patterns.
These are best implemented by adding new circpad_internal_event_*() functions and internal event enums, so that it is easy for machines to make use of them.https://gitlab.torproject.org/tpo/core/tor/-/issues/32678Exit relay DNS cache leaks information2022-09-08T18:00:32ZMike PerryExit relay DNS cache leaks informationIn https://petsymposium.org/2020/files/papers/issue1/popets-2020-0013.pdf by Tobias Pulls and Rasmus Dahlberg, they describe that it is possible to use Tor's Exit DNS cache to determine if a particular domain was accessed from that exit ...In https://petsymposium.org/2020/files/papers/issue1/popets-2020-0013.pdf by Tobias Pulls and Rasmus Dahlberg, they describe that it is possible to use Tor's Exit DNS cache to determine if a particular domain was accessed from that exit in the past hour, and then use this information to eliminate website traffic fingerprinting false positives. This information leak might also be useful for other attacks.
One option is to disable caching entirely. I'm not a fan of this approach.
I think it is better for the cache to perform some kind of "hotness" threshold, where entries are stored in the cache as today, but not *used* from the cache until they are "hot" enough to no longer represent unique visits.. Something like N hits in T time. The edges of this threshhold would have to be randomized, to prevent an adversary from trivially keeping the cache on the edge of "hot" in order to probe it as it crosses over to hot by one visit..
The cache in general should be more closely tied to TTL, IMO, so we can cache longer than an hour if a name supports it. It also should be given better OOM priority, so it is not trivial to flush by SENDME window filling attacks.
Alex also suggested that we may just want to provide our own recursive resolver, properly sandboxed, so that people don't misconfigure DNS to cache in ways that are detectable, or use centralized DNS due to a system-wide default. Until then we should at least come up with some kind of official resolver conf recommendation. If Tor's cache is smart, it seems reasonable to instruct people to disable upstream DNS caching.https://gitlab.torproject.org/tpo/core/tor/-/issues/32673'buf_read_from_tls()' can return the wrong error code2021-08-23T15:12:43Zopara'buf_read_from_tls()' can return the wrong error codeThe [function](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/buffers_tls.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n63) `buf_read_from_tls(...)` returns an integer. This integer can either be `<=0` (in which case it correspo...The [function](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/buffers_tls.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n63) `buf_read_from_tls(...)` returns an integer. This integer can either be `<=0` (in which case it corresponds to a `TOR_TLS_` status) or a positive number (in which case it corresponds to the number of bytes read). This return value is [used in](https://gitweb.torproject.org/tor.git/tree/src/core/mainloop/connection.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n3749) `connection_buf_read_from_socket()` in a large `switch(result)` statement.
At the beginning of `buf_read_from_tls(...)`, it returns `-1` on the lines:
```
IF_BUG_ONCE(buf->datalen >= INT_MAX)
return -1;
IF_BUG_ONCE(buf->datalen >= INT_MAX - at_most)
return -1;
```
This value of `-1` is the [same as](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/tortls.h?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n48) `TOR_TLS_WANTWRITE`. This causes the switch statement in `connection_buf_read_from_socket()` to interpret the return value as `TOR_TLS_WANTWRITE`, which is not correct for the `buf->datalen >= INT_MAX` bug. I suggest returning `TOR_TLS_ERROR_MISC` instead of `-1`. Note that this would close the connection.
I don't think you'll see incorrect behavior due to this, but it might be a good idea to fix.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32672Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()2022-02-25T13:34:12ZteorReject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()We should modify dirserv_rejects_tor_version() to keep it up to date with our supported versions:
* After 1 January 2020, we should reject all versions less than 0.3.5.
* After 2 February 2020, we should reject the 0.4.0 series, but allo...We should modify dirserv_rejects_tor_version() to keep it up to date with our supported versions:
* After 1 January 2020, we should reject all versions less than 0.3.5.
* After 2 February 2020, we should reject the 0.4.0 series, but allow the 0.3.5 series
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current
After these dates, we should get arma to test this change, then merge it.
After we merge, we should create a ticket in 0.4.4 to reject 0.4.1.Tor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32671Circpad padding timer flag is not properly reset2021-07-09T17:22:51ZMike PerryCircpad padding timer flag is not properly resetThis appears to have no consequences outside of the circpad simulator, but we are forgetting to reset the is_padding_timer_scheduled flag in circpad_send_padding_cell_for_callback(). It should get set to 0 at the top of that function.This appears to have no consequences outside of the circpad simulator, but we are forgetting to reset the is_padding_timer_scheduled flag in circpad_send_padding_cell_for_callback(). It should get set to 0 at the top of that function.https://gitlab.torproject.org/tpo/core/tor/-/issues/32670Provide and use higher resolution padding callback timers2022-06-17T17:56:15ZMike PerryProvide and use higher resolution padding callback timersDuring testing, I noticed that the timers.c callbacks could be up to 10 milliseconds late on an otherwise idle Linux laptop tor client. They might be even later on busy relays.
Circuit fingerprinting results may be impacted by this dela...During testing, I noticed that the timers.c callbacks could be up to 10 milliseconds late on an otherwise idle Linux laptop tor client. They might be even later on busy relays.
Circuit fingerprinting results may be impacted by this delay. If a deep learning classifier is able to determine padding cells through recognizing this delay, padding will entirely ineffective.
It would be nice to have either high priority timers for things like this, or at least better idle resolution.
We do not yet have enough results to say with certainty if high accuracy padding timers are more important for clients, or for relays.https://gitlab.torproject.org/tpo/core/tor/-/issues/32667CID 1456199: Resource leak in test_hs_control_store_permanent_creds()2021-06-23T17:23:07ZGeorge KadianakisCID 1456199: Resource leak in test_hs_control_store_permanent_creds()```
** CID 1456199: Resource leaks (RESOURCE_LEAK)
/src/test/test_hs_control.c: 534 in test_hs_control_store_permanent_creds()
________________________________________________________________________________________________________
**...```
** CID 1456199: Resource leaks (RESOURCE_LEAK)
/src/test/test_hs_control.c: 534 in test_hs_control_store_permanent_creds()
________________________________________________________________________________________________________
*** CID 1456199: Resource leaks (RESOURCE_LEAK)
/src/test/test_hs_control.c: 534 in test_hs_control_store_permanent_creds()
528
529 #ifdef _WIN32
530 ret = mkdir(perm_creds_dir);
531 #else
532 ret = mkdir(perm_creds_dir, 0700);
533 #endif
>>> CID 1456199: Resource leaks (RESOURCE_LEAK)
>>> Variable "perm_creds_dir" going out of scope leaks the storage it points to.
534 tt_int_op(ret, OP_EQ, 0);
535
536 get_options_mutable()->ClientOnionAuthDir = perm_creds_dir;
537 }
538
539 tor_free(args);
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32664hs-v3: Segfault in hs_circ_service_get_established_intro_circ()2021-06-23T17:23:07ZDavid Gouletdgoulet@torproject.orghs-v3: Segfault in hs_circ_service_get_established_intro_circ()Reported by atagar on IRC:
```
<+atagar> Looks like stem's jenkins runs are presently failing due to tor segfaults: https://paste.debian.net/plain/1119133
```
The report:
```
...
Dec 02 17:03:09.077 [notice] Configured to measure dire...Reported by atagar on IRC:
```
<+atagar> Looks like stem's jenkins runs are presently failing due to tor segfaults: https://paste.debian.net/plain/1119133
```
The report:
```
...
Dec 02 17:03:09.077 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option.
Dec 02 17:03:09.085 [warn] Controller gave us config lines that didn't validate: Unknown option 'bombay'. Failing.
Dec 02 17:03:09.085 [warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742
Dec 02 17:03:09.088 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option.
Dec 02 17:03:09.225 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
============================================================ T= 1575306189
Tor 0.4.3.0-alpha-dev died: Caught signal 11
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(+0x21ceb5)[0x56360d945eb5]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(hs_circ_service_get_established_intro_circ+0x27)[0x56360d8327e7]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(hs_circ_service_get_established_intro_circ+0x27)[0x56360d8327e7]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(hs_service_run_scheduled_events+0x14ff)[0x56360d849ccf]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(+0x72961)[0x56360d79b961]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(+0x762f3)[0x56360d79f2f3]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0)[0x7f6688b925a0]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(do_main_loop+0xe5)[0x56360d79e565]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(tor_run_main+0x122d)[0x56360d78ba2d]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(tor_main+0x3a)[0x56360d7891da]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(main+0x19)[0x56360d788d59]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f66873e72e1]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(_start+0x2a)[0x56360d788daa]
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32663Require coccinelle 1.0.4 in check_cocci_parse.sh2020-06-27T13:48:44ZteorRequire coccinelle 1.0.4 in check_cocci_parse.shIn legacy/trac#31919, we upgraded most of our CI jobs to Ubuntu bionic, so that we had a recent enough version of coccinelle (1.0.4 or later).
But we didn't put a minimum coccinelle version requirement in check_cocci_parse.sh.
We shoul...In legacy/trac#31919, we upgraded most of our CI jobs to Ubuntu bionic, so that we had a recent enough version of coccinelle (1.0.4 or later).
But we didn't put a minimum coccinelle version requirement in check_cocci_parse.sh.
We should also check what happens if we install coccinelle on Windows.
For details, see:
https://trac.torproject.org/projects/tor/ticket/32500#comment:18Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32655Try finding unused includes by compiling without each include2022-06-17T16:01:57ZteorTry finding unused includes by compiling without each includeIn legacy/trac#32522, we deleted some includes and PRIVATE defines, because they were duplicate (or the defines were never actually checked in the headers).
But we could go further, using this algorithm:
1. Make sure all the files are s...In legacy/trac#32522, we deleted some includes and PRIVATE defines, because they were duplicate (or the defines were never actually checked in the headers).
But we could go further, using this algorithm:
1. Make sure all the files are sorted
2. Find all the includes (and maybe PRIVATE defines)
3. Delete the first include
4. Try compiling
5. If the include is required to compile, revert
6. Try again from step 3, with the next include
We'd need to skip conditional includes, and check the results in CI before merging.
I'll wait until legacy/trac#32522 is reviewed, and also see if we want this task on our roadmap.https://gitlab.torproject.org/tpo/core/tor/-/issues/32648core dump centos82020-06-27T13:48:44ZTraccore dump centos8CentOS 8 4.18.0-80.11.2.el8_0.x86_64.
Tor 0.4.1.6-1.el8.
Started with root and non-privileged user: /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc
torrc contains:
RunAsDaemon 1
BridgeRelay...CentOS 8 4.18.0-80.11.2.el8_0.x86_64.
Tor 0.4.1.6-1.el8.
Started with root and non-privileged user: /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc
torrc contains:
RunAsDaemon 1
BridgeRelay 1
ORPort 443
ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:587
ExtORPort auto
ContactInfo test@test.com
ORPort 443
ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:587
ExtORPort auto
ContactInfo test@test.com
Nickname mybridge
**Trac**:
**Username**: mikebTor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32639cancel_descriptor_fetches() uses wrong connection list function2021-06-23T17:23:07ZGeorge Kadianakiscancel_descriptor_fetches() uses wrong connection list functioncancel_descriptor_fetches() does:
```
smartlist_t *conns =
connection_list_by_type_state(CONN_TYPE_DIR, DIR_PURPOSE_FETCH_HSDESC);
```
when it should be using `connection_list_by_type_purpose()`.cancel_descriptor_fetches() does:
```
smartlist_t *conns =
connection_list_by_type_state(CONN_TYPE_DIR, DIR_PURPOSE_FETCH_HSDESC);
```
when it should be using `connection_list_by_type_purpose()`.Tor: 0.4.3.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32637SocksPort IPv6 flags differs in default config and in Torlauncher prefs, and ...2021-08-23T15:12:43ZcypherpunksSocksPort IPv6 flags differs in default config and in Torlauncher prefs, and exits can distinguish themBy default tor daemon set only IPv6Traffic flag in client sockets, but not PreferIPv6
https://gitweb.torproject.org/tor.git/tree/src/app/config/config.c#n6094
But Torlauncher sets them both when launch tor daemon with Tor Browser
https:...By default tor daemon set only IPv6Traffic flag in client sockets, but not PreferIPv6
https://gitweb.torproject.org/tor.git/tree/src/app/config/config.c#n6094
But Torlauncher sets them both when launch tor daemon with Tor Browser
https://gitweb.torproject.org/tor-launcher.git/tree/src/defaults/preferences/torlauncher-prefs.js#n41
As i can see in spec, this flags sets bits in "FLAGS" value in RELAY_BEGIN cell, and exit relays can recognize which flags sets in client port settings. So, exits can distinguish circuits from Tor Browser Bundle clients and, as example, from daemons in linux distro repositories, with high level of probability.
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1595
Is there any reasons why PreferIPv6 flag is not turned on by default? This issue raises up in past (legacy/trac#21269), but solution is not efficient - anyway flags sent to exit by default differs from vast majority of real usecases - surfing web with TBB.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32629Re-enable 1 or 2 more macOS jobs in Travis2020-06-27T13:48:44ZteorRe-enable 1 or 2 more macOS jobs in TravisReverts legacy/trac#32177.
We might need to merge or disable some jobs, to get builds to finish fast enough.Reverts legacy/trac#32177.
We might need to merge or disable some jobs, to get builds to finish fast enough.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32627deploy torspec as HTML to GitLab Pages2021-07-22T16:19:07Zeighthavedeploy torspec as HTML to GitLab Pageshttps://github.com/torproject/torspec/pull/96 will deploy torspec in HTML to any GitLab fork setup with CI and Pages (default on gitlab.com). it only adds one file: _.gitlab-ci.yml_
Once merged, the site will show up automatically on ht...https://github.com/torproject/torspec/pull/96 will deploy torspec in HTML to any GitLab fork setup with CI and Pages (default on gitlab.com). it only adds one file: _.gitlab-ci.yml_
Once merged, the site will show up automatically on https://torproject.gitlab.io/torspec, and it'll sync every commit from the canonical repo and automatically rebuild the HTML.
The sed regexps in _.gitlab-ci.yml_ could be used as the beginnings of a conversion to Markdown format, as needed.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32626Remove extra space in #define in ed25519-donna-portable-identify.h2020-06-27T13:48:45ZNeel Chauhanneel@neelc.orgRemove extra space in #define in ed25519-donna-portable-identify.hThis line:
```
#if defined(__amd64__) || defined(__amd64) || defined(__x86_64__ ) || defined(_M_X64)
```
should be:
```
#if defined(__amd64__) || defined(__amd64) || defined(__x86_64__) || defined(_M_X64)
```This line:
```
#if defined(__amd64__) || defined(__amd64) || defined(__x86_64__ ) || defined(_M_X64)
```
should be:
```
#if defined(__amd64__) || defined(__amd64) || defined(__x86_64__) || defined(_M_X64)
```Neel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.org