The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-12-22T21:18:56Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/48Let NetDir expose consensus parameters; use them elsewhere2020-12-22T21:18:56ZNick MathewsonLet NetDir expose consensus parameters; use them elsewhereThe initial value of sendwindow, for example, should not be hardcoded.The initial value of sendwindow, for example, should not be hardcoded.A1: minimal socksportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/network-health/doctor/-/issues/40015Add tests we currently have to the wiki page and explain what they do2022-02-28T14:57:55ZGeorg KoppenAdd tests we currently have to the wiki page and explain what they doI created a first page in our wiki and I think it would be useful to mention all the tests we currently have on it + what they do and which of them we are actually running.I created a first page in our wiki and I think it would be useful to mention all the tests we currently have on it + what they do and which of them we are actually running.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40314Review GeckoView Changelog for gv862021-02-09T22:50:10ZMatthew FinkelReview GeckoView Changelog for gv86Tor Browser: 10.0https://gitlab.torproject.org/tpo/applications/android-components/-/issues/40043Rebase android-components patches for Fenix 87 beta X builds2021-03-18T18:03:15ZMatthew FinkelRebase android-components patches for Fenix 87 beta X buildsTor Browser: 10.0https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40323Prep 10.5a9 Android2021-02-04T19:03:47ZMatthew FinkelPrep 10.5a9 AndroidTor Browser: 10.5https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40225Prep 10.5a9 Android2021-02-04T21:12:46ZMatthew FinkelPrep 10.5a9 AndroidTor Browser: 10.5https://gitlab.torproject.org/tpo/core/arti/-/issues/49Restore received_end in stream.rs2020-12-22T14:41:35ZNick MathewsonRestore received_end in stream.rsI hacked this out when I was trying to get proxying to work; I should turn it back on.I hacked this out when I was trying to get proxying to work; I should turn it back on.A1: minimal socksportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/network-health/doctor/-/issues/40017Doctor incorrectly reports clock skew2022-09-07T07:01:44ZRoger DingledineDoctor incorrectly reports clock skewOn the consensus-health mails, we're getting lines like this:
```
NOTICE: The system clock of moria1 is 48 seconds off
NOTICE: The system clock of dizum is 70 seconds off
NOTICE: The system clock of Faravahar is 37 seconds off
NOTICE: Th...On the consensus-health mails, we're getting lines like this:
```
NOTICE: The system clock of moria1 is 48 seconds off
NOTICE: The system clock of dizum is 70 seconds off
NOTICE: The system clock of Faravahar is 37 seconds off
NOTICE: The system clock of longclaw is 41 seconds off
```
But I believe the clocks on these systems are fine.
What I assume is happening is that DocTor is launching a directory fetch for an object like the consensus, and it's taking 48 seconds to finish retrieving the answer, and then DocTor looks at the Date header in the resulting http response, notices that it is from 48 seconds ago, and reports a clock problem.
Here is an improved algorithm: remember when we started the request, and when we finished it, and if the Date header is anywhere within that range, there is nothing to report.
We could instead consider making additional tiny requests where we expect the answer to come back quickly, but I think that might be overkill at this stage.https://gitlab.torproject.org/tpo/applications/android-components/-/issues/40044Review MozAC Changelog for Fenix872021-03-15T14:06:22ZMatthew FinkelReview MozAC Changelog for Fenix87Tor Browser: 10.0https://gitlab.torproject.org/tpo/web/community/-/issues/196Arrange numbered points2021-04-08T21:39:26ZSehrish AslamArrange numbered pointsOn Community Portal under User Research Guidelines [https://community.torproject.org/user-research/guidelines/](https://community.torproject.org/user-research/guidelines/) **Report to Tor UX team** numbered points need to be arranged. ![...On Community Portal under User Research Guidelines [https://community.torproject.org/user-research/guidelines/](https://community.torproject.org/user-research/guidelines/) **Report to Tor UX team** numbered points need to be arranged. ![img2](/uploads/58dd2d626d3143b78a653182715e87bc/img2.PNG)
@gus if approved, will fix this.https://gitlab.torproject.org/tpo/core/tor/-/issues/40204Travis chutney tests are borked by two bad commits2021-02-05T21:03:36ZGeorge KadianakisTravis chutney tests are borked by two bad commitsSeems like Travis chutney tests have been broken for the past 7 days. I did some investigation today using git-bisect and found out that there are two offending commits that both need to be reverted for the tests to pass.
These two comm...Seems like Travis chutney tests have been broken for the past 7 days. I did some investigation today using git-bisect and found out that there are two offending commits that both need to be reverted for the tests to pass.
These two commits are 1588767e655f87f49cf0f71d6e604117be52a135 and 4382e977f74e41f65170b4d9292678859c9e521f. Reverting just one of them won't do it and both of them need to be reverted for the tests to pass.
We should fix this so that we start getting a proper CI again.Tor: 0.4.6.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40324Disable autocorrection in address bar2022-07-15T13:33:09ZanadahzDisable autocorrection in address barTor Browser auto corrects entries in address bar.
For instance `example.ocm` becomes `example.com`.
Version: `10.0.10 (based on Mozilla Firefox 78.7.0esr) (64-bit)`
## Related
- https://wiki.mozilla.org/Firefox/Feature_Brainstorming:A...Tor Browser auto corrects entries in address bar.
For instance `example.ocm` becomes `example.com`.
Version: `10.0.10 (based on Mozilla Firefox 78.7.0esr) (64-bit)`
## Related
- https://wiki.mozilla.org/Firefox/Feature_Brainstorming:Addressbar#Autocorrection
- https://bugzilla.mozilla.org/show_bug.cgi?id=175634https://gitlab.torproject.org/tpo/core/arti/-/issues/31Implement (client-side) consensus diffs2020-12-17T20:56:19ZNick MathewsonImplement (client-side) consensus diffsWe should write support for processing consensus diffs.
This should be pretty simple, since we don't need to generate diffs.We should write support for processing consensus diffs.
This should be pretty simple, since we don't need to generate diffs.A1: minimal socksportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40094Sandbox failure when adding an extra %include file.2020-12-15T14:29:26ZtoralfSandbox failure when adding an extra %include file.Sandbox aborts Tor when when reloading and finding an extra %included torrc file /etc/tor/torrc.d//50_reject_abuse_complaints (on Tor 0.4.4.3-alpha )
I get that warning/Bug when I added a file to the rc.d directory of a sandbox'ed Tor r...Sandbox aborts Tor when when reloading and finding an extra %included torrc file /etc/tor/torrc.d//50_reject_abuse_complaints (on Tor 0.4.4.3-alpha )
I get that warning/Bug when I added a file to the rc.d directory of a sandbox'ed Tor relay and try to reload Tor.
IMO Tor should refuse to reload in such a case rather than abort.
```
Aug 10 23:24:49.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Aug 10 23:24:49.000 [notice] Read configuration file "/etc/tor/torrc".
Aug 10 23:24:49.000 [notice] Processing configuration path "/etc/tor/torrc.d/" at recursion level 1.
Aug 10 23:24:49.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d//50_reject_abuse_complaints (on Tor 0.4.4.3-alpha )
Aug 10 23:24:49.000 [notice] Including configuration file "/etc/tor/torrc.d//00_common".
Aug 10 23:24:49.000 [notice] Including configuration file "/etc/tor/torrc.d//20_exit_flag".
Aug 10 23:24:49.000 [notice] Including configuration file "/etc/tor/torrc.d//40_reject".
Aug 10 23:24:49.000 [notice] Including configuration file "/etc/tor/torrc.d//50_reject_abuse_complaints".
Aug 10 23:24:49.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d//50_reject_abuse_complaints (on Tor 0.4.4.3-alpha )
Aug 10 23:24:49.000 [warn] Could not open "/etc/tor/torrc.d//50_reject_abuse_complaints": Operation not permitted
Aug 10 23:24:49.000 [warn] Error reading included configuration file or directory: "/etc/tor/torrc.d/".
Aug 10 23:24:49.000 [err] Reading config failed--see warnings above. For usage, try -h.
Aug 10 23:24:49.000 [warn] Restart failed (config error?). Exiting.
```Tor: 0.4.5.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/android-components/-/issues/40045Add External App Prompt for Sharing Images2021-03-20T15:02:55ZMatthew FinkelAdd External App Prompt for Sharing Imagesa9044cf959c7d163ec59ee528cd7d522b5c70cdd introduced a way of sharing an actual image (not only the URL). We should pass this through the external app prompt.a9044cf959c7d163ec59ee528cd7d522b5c70cdd introduced a way of sharing an actual image (not only the URL). We should pass this through the external app prompt.https://gitlab.torproject.org/tpo/web/community/-/issues/197[Bridge] Duplicate keys2021-04-09T14:21:53Zkulsoom.zahrakulsoomzahra24@gmail.com[Bridge] Duplicate keysOn the Community portal Relay operation section, the [Technical setup of Bridges](https://community.torproject.org/relay/setup/bridge/) the following has duplicate keys:
1. **Fedora** and **CentOS / RHEL / OpenSUSE** key:2
2. **Dragon...On the Community portal Relay operation section, the [Technical setup of Bridges](https://community.torproject.org/relay/setup/bridge/) the following has duplicate keys:
1. **Fedora** and **CentOS / RHEL / OpenSUSE** key:2
2. **DragonflyBSD** and **Docker** key:5
3. **NetBSD** and **Post-install** key:6kulsoom.zahrakulsoomzahra24@gmail.comkulsoom.zahrakulsoomzahra24@gmail.comhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19011Use of maxunmeasuredbw and bwweightscale is broken in consensus2021-09-16T14:33:29ZNick MathewsonUse of maxunmeasuredbw and bwweightscale is broken in consensusWhile refactoring, I noticed this code in dirvote.c:
```
if (params) {
if (strcmpstart(params, "bwweightscale=") == 0)
bw_weight_param = params;
else
bw_weight_param = strstr(params, " bwweightscale=");
...While refactoring, I noticed this code in dirvote.c:
```
if (params) {
if (strcmpstart(params, "bwweightscale=") == 0)
bw_weight_param = params;
else
bw_weight_param = strstr(params, " bwweightscale=");
}
if (bw_weight_param) {
int ok=0;
char *eq = strchr(bw_weight_param, '=');
if (eq) {
weight_scale = tor_parse_long(eq+1, 10, 1, INT32_MAX, &ok,
NULL);
if (!ok) {
log_warn(LD_DIR, "Bad element '%s' in bw weight param",
escaped(bw_weight_param));
weight_scale = BW_WEIGHT_SCALE;
}
} else {
log_warn(LD_DIR, "Bad element '%s' in bw weight param",
escaped(bw_weight_param));
weight_scale = BW_WEIGHT_SCALE;
}
}
```
Looking at the use of tor_parse_ulong(). Since "next" is NULL, any unconverted characters should make it give an error, making us use the default value.Tor: 0.4.6.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40188Tor man page doesn't mention !badexit2022-05-05T06:36:04ZRoger DingledineTor man page doesn't mention !badexitIn the "DataDirectory/approved-routers" section of the man page, it mentions you can say !reject and !invalid, but it doesn't mention !badexit and it should.
While I'm here, is !invalid even still a thing, now that we stopped paying att...In the "DataDirectory/approved-routers" section of the man page, it mentions you can say !reject and !invalid, but it doesn't mention !badexit and it should.
While I'm here, is !invalid even still a thing, now that we stopped paying attention to the Valid flag?Tor: 0.4.5.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40224Find a working alternative to using MaxMind's GeoLite2 databases2024-01-25T11:54:26ZKarsten LoesingFind a working alternative to using MaxMind's GeoLite2 databasesMaxMind has recently changed access and use of their GeoLite2 databases: https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/
This affects Onionoo and tor. I started a [thread on tor-dev@](h...MaxMind has recently changed access and use of their GeoLite2 databases: https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/
This affects Onionoo and tor. I started a [thread on tor-dev@](https://lists.torproject.org/pipermail/tor-dev/2020-January/014117.html) about this topic last week with some more details.
Let's use this ticket to brainstorm and discuss working alternatives to the way we used their databases in the past.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40190Delaying hostname send in SOCKS5 `CONNECT` command causes failure in hostname...2022-07-07T00:48:31ZZmnSCPxjDelaying hostname send in SOCKS5 `CONNECT` command causes failure in hostname resolutionTested on systems
-----------------
* Linux 5.8.0-7625-generic amd64, Tor 0.4.2.7
* FreeBSD 11.2-RELEASE-p15 amd64, Tor 0.4.4.5
Replication
-----------
SOCKS5 has the below specification for the request (RFC1928)
```
The SOCKS req...Tested on systems
-----------------
* Linux 5.8.0-7625-generic amd64, Tor 0.4.2.7
* FreeBSD 11.2-RELEASE-p15 amd64, Tor 0.4.4.5
Replication
-----------
SOCKS5 has the below specification for the request (RFC1928)
```
The SOCKS request is formed as follows:
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Where:
o VER protocol version: X'05'
o CMD
o CONNECT X'01'
o BIND X'02'
o UDP ASSOCIATE X'03'
o RSV RESERVED
o ATYP address type of following address
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port in network octet
order
```
To replicate:
* Send the `VER`, `CMD`, `RSV`, and `ATYP` bytes (4 bytes) in a single `write`.
* Wait a short while.
* Send the rest of the request (`DST.ADDR`, `DST.PORT`) in another `write`.
This consistently leads to hostname resolution failure as logged in the Tor logs.
Test Code
---------
```c
#include<netinet/in.h>
#include<netinet/ip.h>
#include<stdint.h>
#include<stdio.h>
#include<string.h>
#include<sys/socket.h>
#include<sys/types.h>
#include<unistd.h>
static
const short proxy_port = 9050;
#define PROXY_HOST htonl(INADDR_LOOPBACK)
static
const char* hostname = "www.google.com";
static
const short port = 443;
int main() {
uint8_t buffer[1024];
int fd;
struct sockaddr_in si;
short n_port;
int success = 0;
fd = socket(AF_INET, SOCK_STREAM, 0);
si.sin_family = AF_INET;
si.sin_port = htons(proxy_port);
si.sin_addr.s_addr = PROXY_HOST;
connect(fd, (const struct sockaddr*) &si, sizeof(si));
buffer[0] = 0x05; /* SOCKS5 */
buffer[1] = 0x01; /* Number of authentication methods*/
buffer[2] = 0x00; /* No authentication. */
write(fd, buffer, 3);
buffer[0] = ~0x05;
buffer[1] = ~0x00;
read(fd, buffer, 2);
if (buffer[0] != 0x05)
fprintf(stderr, "Unexpected response from proxy, expecting SOCKS5\n");
if (buffer[1] != 0x00)
fprintf(stderr, "Unexpected response from proxy, expecting unauthenticated\n");
buffer[0] = 0x05; /* SOCKS5 */
buffer[1] = 0x01; /* CMD CONNECT */
buffer[2] = 0x00; /* RSV */
buffer[3] = 0x03; /* ATYP DOMAINNAME */
write(fd, buffer, 4);
/* This delay, should not affect the behavior of a proxy! */
usleep(1000); /* 1ms */
/* If the above delay is commented out, *sometimes* on my
* system this program succeeds and prints "connected",
* *sometimes* it fails and prints "not connected".
* With the above 1-millisecond delay, it always prints
* "not connected".
* Without the above delay, if I run in any kind of test
* harness (`strace`, `valgrind`) it always says "not
* connected", suggesting that any minor delay after
* `ATYP` can trigger this.
*/
buffer[0] = (uint8_t)strlen(hostname);
memcpy(&buffer[1], hostname, (size_t) buffer[0]);
write(fd, buffer, 1 + ((size_t) buffer[0]));
n_port = htons(port);
memcpy(&buffer[0], &n_port, 2);
write(fd, buffer, 2);
buffer[0] = ~0x05;
buffer[1] = ~0x00;
read(fd, buffer, 2);
if (buffer[0] != 0x05)
fprintf(stderr, "Unexpected response from proxy, expecting SOCKS5\n");
success = (buffer[1] == 0x00);
close(fd);
if (success)
fprintf(stdout, "Connected.\n");
else
fprintf(stdout, "Not connected.\n");
return 0;
}
```
Notes
-----
In principle, it should not matter if I send all of the data in a single `write`, or if I want to send each individual byte into its own `write` with a 100-millisecond delay each. This is supposedly a TCP stream socket, after all; such timing delays may matter on datagram-based sockets, but in principle not to stream sockets (where all that *should* matter is ordering of bytes).
`curl --socks5-hostname` and `torify wget` do not tickle this bug since they consistently send the entire request in a single `write`/`sendto`.
This suggests to me that some layer inside Tor is triggering the hostname lookup as soon as it receives `ATYP` and simply assumes that the entire hostname has been received, without actually verifying that the `DST.ADDRESS` after `ATYP` was ***actually*** received. The problem is that this layer inside Tor may be reading an uninitialized buffer with all the security problems that implies, **and** sending it out to a remote resolver. This was not easy to spot as well, since Tor logs will show hostnames it failed to look up as `[Scrubbed]`, and I spent a lot of time looking for other bugs in my code before I thought to look into the behavior of Tor.
This might not be a high priority issue, since it seems most commodity libraries and tools send the entire request as a single `write`, it was only my own internal library that, for code simplicicty, wrote the hostname (stored in a different buffer) separately from the `VER` `CMD` `RSV` `ATYP` sequence. However, others reimplementing a simple SOCKS5 client might stumble into this as well, since typically in TCP it does not matter how many `write`s you use to send the data, as long as the order of bytes is correct.
Marked as confidential as I suspect Tor may be triggered into reading uninitialized buffers and possibly sending the contents of that buffer to a remote node.Tor: 0.4.4.x-finalNick MathewsonNick Mathewson