The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-01-25T11:54:26Zhttps://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/tpa/team/-/issues/31243TPA-RFC-2: define how users get support, what's an emergency and what is supp...2022-12-20T18:59:27ZanarcatTPA-RFC-2: define how users get support, what's an emergency and what is supportedExtract from parent ticket (#30881):
# 2. Are "the 3 empowering policies" defined and published?
http://opsreportcard.com/section/2
Specifically, this is three questions:
## How do users get help?
Right now, this is unofficially "op...Extract from parent ticket (#30881):
# 2. Are "the 3 empowering policies" defined and published?
http://opsreportcard.com/section/2
Specifically, this is three questions:
## How do users get help?
Right now, this is unofficially "open a ticket in Trac", "ping us over IRC for small stuff", or "write us an email". This could be made more official somewhere.
## What is an emergency?
I am not sure this is formally defined.
## What is supported?
We have the distinction between systems and service admins. We did [talk in Stockholm](https://trac.torproject.org/projects/tor/wiki/org/meetings/2019Stockholm/Notes/SysadminTeamRoadmapping) about clarifying that item, so this is worth expanding further.anarcatanarcathttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/11698Incorporate Tor Browser Manual pages into Tor Browser2022-07-08T11:58:49ZMatt PaganIncorporate Tor Browser Manual pages into Tor BrowserWe want the Tor Browser User Manual to ship with Tor Browser. We need to decide how the manual will be presented to the user, including what file format the user will be accessing.We want the Tor Browser User Manual to ship with Tor Browser. We need to decide how the manual will be presented to the user, including what file format the user will be accessing.Tor Browser 11.5Pier Angelo VendramePier Angelo Vendrame2022-05-02https://gitlab.torproject.org/tpo/core/tor/-/issues/34382Don't require M_SYSCALL in sandbox.c2022-07-07T00:49:01ZNick MathewsonDon't require M_SYSCALL in sandbox.cIn sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we ...In sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we don't have it defined can still build with m_syscall.
See also legacy/trac#32904 and legacy/trac#30987Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://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 Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40035NSS needs to be told that its sockets are nonblocking2022-07-07T00:48:30ZNick MathewsonNSS needs to be told that its sockets are nonblockingApparently NSS does not automatically realize that its SSL sockets are nonblocking when you construct them around a nonblocking TCP socket. You have to make them nonblocking yourself.
Found while investigating #40018. Root cause of #40...Apparently NSS does not automatically realize that its SSL sockets are nonblocking when you construct them around a nonblocking TCP socket. You have to make them nonblocking yourself.
Found while investigating #40018. Root cause of #40018.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34357Reject relays running 0.4.12022-02-03T16:25:08ZNick MathewsonReject relays running 0.4.1Now that 0.4.1 has reached end-of-life, it's time for directory authorities to stop accepting relays running it.
See legacy/trac#32672 for the last time we did this.
Looking at the graphs, I don't see a significant change in the drop-o...Now that 0.4.1 has reached end-of-life, it's time for directory authorities to stop accepting relays running it.
See legacy/trac#32672 for the last time we did this.
Looking at the graphs, I don't see a significant change in the drop-off rate for deprecated versions in between when we announced that they were deprecated, and when we finally removed them. Maybe this time we should just send out an announcment, wait a month, then reject the relays?Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/141Design a logo for arti2022-02-03T00:24:41ZdonutsDesign a logo for artiArti needs a logo! It will be visible on arti.torproject.org (https://gitlab.torproject.org/tpo/core/team/-/issues/19) and reports, among other places. This ticket is to track its development and collate feedback.Arti needs a logo! It will be visible on arti.torproject.org (https://gitlab.torproject.org/tpo/core/team/-/issues/19) and reports, among other places. This ticket is to track its development and collate feedback.Arti 0.0.1 release: basic anonymitydonutsdonutshttps://gitlab.torproject.org/tpo/core/arti/-/issues/199The 'pending' flag is not cleared on a consensus correctly in all cases2021-10-21T17:36:40ZNick MathewsonThe 'pending' flag is not cleared on a consensus correctly in all casesWe don't clear the 'pending' flag on a consensus if we don't have to download any additional microdescriptors to notice that it is usable.
Also, it might be a good idea to clear the 'pending' flag every time we notice that we have a usa...We don't clear the 'pending' flag on a consensus if we don't have to download any additional microdescriptors to notice that it is usable.
Also, it might be a good idea to clear the 'pending' flag every time we notice that we have a usable directory on startup, to work around old cases of this bug.Arti 0.0.1 release: basic anonymityNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27194Reject protover extra commas in protover2021-09-16T14:29:03ZTracReject protover extra commas in protoverLike how it handles spaces, `protover.c` rejects leading commas (`Link=,1-5` or `Link=,`) while it accepts and ignores extra commas elsewhere (`Link=1-5,` and `Link=1,,,2-5` are valid).
The Rust version accepts and ignores all extra com...Like how it handles spaces, `protover.c` rejects leading commas (`Link=,1-5` or `Link=,`) while it accepts and ignores extra commas elsewhere (`Link=1-5,` and `Link=1,,,2-5` are valid).
The Rust version accepts and ignores all extra commas, including leading commas.
**Trac**:
**Username**: cyberpunksTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40080Double-check ed25519 identity and is_canonical in `circuit_n_chan_done()`2021-08-23T15:12:44ZNick MathewsonDouble-check ed25519 identity and is_canonical in `circuit_n_chan_done()`Right now, `circuit_n_chan_done()` checks rsa identity digest, but not ed25519 identity or `is_canonical`.
This is probably not a high-security issue, so I'm going to use it to experiment with confidential issues. Here's why I think th...Right now, `circuit_n_chan_done()` checks rsa identity digest, but not ed25519 identity or `is_canonical`.
This is probably not a high-security issue, so I'm going to use it to experiment with confidential issues. Here's why I think this is not high-security: If we're a client, we already filled in the intended ed25519 identity and address for the channel when we launched it, and rejected the channel if it was wrong.
If we're a relay, then exploiting this issue would _at worst_ require an attacker to jump through a lot of hoops (impersonating RSA identity, sending bogus EXTEND cell at exactly the right time to de-rail other pending circuits), _and also_ either require the attacker to steal onion keys, or limit the attacker's capability to encrypted traffic sniffing.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33119Resolve TROVE-2020-001 (denial-of-service against Tor built with NSS)2021-08-23T15:12:43ZNick MathewsonResolve TROVE-2020-001 (denial-of-service against Tor built with NSS)TROVE-2020-001 is a denial of service issue that affects Tor users running versions of Tor built with NSS. (Building with NSS is not the default.)
When running an affected version of Tor, either as a relay or a client, Tor will crash...TROVE-2020-001 is a denial of service issue that affects Tor users running versions of Tor built with NSS. (Building with NSS is not the default.)
When running an affected version of Tor, either as a relay or a client, Tor will crash under certain circumstances when performing a certificate comparison during our connection handshake. Any party who performs a handshake with a Tor instance can remotely trigger this bug: this means that anybody can crash an affected relay remotely, while affected clients can be crashed by their guards.
The root cause is an out-of-bounds comparison due to an API mismatch -- NSS was telling us a number of bits, but we were expecting it to tell us a number of bytes.
This issue affects all supported versions when they are compiled with NSS. A fix will appear in today's releases (0.3.5.11, 0.4.2.8, 0.4.3.6, and 0.4.4.2-alpha).
This is also tracked as CVE-2020-15572Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://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/network-health/metrics/onionoo/-/issues/27187Possible for inconsistency between summary and details with AS number2021-07-09T18:30:47ZirlPossible for inconsistency between summary and details with AS number```
{"version":"6.2",
"next_major_version_scheduled":"2018-09-03",
"build_revision":"79de0d2",
"relays_published":"2018-08-17 12:00:00",
"relays":[
{"fingerprint":"008E7B70C3B4A7520B5BEAB8067ABCDC8E63F1FD"},
{"fingerprint":"070A0DC5AE71D...```
{"version":"6.2",
"next_major_version_scheduled":"2018-09-03",
"build_revision":"79de0d2",
"relays_published":"2018-08-17 12:00:00",
"relays":[
{"fingerprint":"008E7B70C3B4A7520B5BEAB8067ABCDC8E63F1FD"},
{"fingerprint":"070A0DC5AE71D60A9567FF908A4EBFB52C670E39"},
{"fingerprint":"0AE3AC492B709AA851488D01B1AD1EDFC040947F"},
{"fingerprint":"0CA2FF775712F67AFFAB64CF16EA96E3D13016B4"},
{"fingerprint":"0DE225407D80F8C1121AED264A97EBF56F31F299"},
{"fingerprint":"11757C1EAD3BAD46D2EA2E950D5E9A34035D9B17"},
{"fingerprint":"126B2DD209618B666FF3184EC9D50363B3FB46B7"},
{"fingerprint":"136F9299A5009A4E0E96494E723BDB556FB0A26B"},
{"fingerprint":"19D235674BCA4EAF55BBFFAAE5441C1E392E4C72"},
{"fingerprint":"1CD464437CF6F0AA8B41660D74DCAB8DD7C14373"},
{"fingerprint":"1D3174338A1131A53E098443E76E1103CDED00DC"},
{"fingerprint":"2093B5DC4B595BFD307A26F494A4C31F455DCCCA"},
{"fingerprint":"22E975935BA77EA59A28EA1AA8387F906034FCBE"},
{"fingerprint":"2C8BD998EDE0C66668D7CCAA1A724BF566524395"},
{"fingerprint":"2CDCFED0142B28B002E89D305CBA2E26063FADE2"},
{"fingerprint":"2D74D7EFACC75DCDB3BEE9221B0BEB226754F96E"},
{"fingerprint":"3098231A16A3661AF98A80D62D161AE7B039358E"},
{"fingerprint":"3444F4ACA2A1AB4A5E9DC64295A6D414A03D3503"},
{"fingerprint":"363E2F30AC9823E6094786CE0ABB64B14D2BE233"},
{"fingerprint":"387A7D62EEC5C14FF45ED8AD9B2235BFE9FE9463"},
{"fingerprint":"38A42B8D7C0E6346F4A4821617740AEE86EA885B"},
{"fingerprint":"3B52392E2256C35CDCF7801FF898FC88CE6D431A"},
{"fingerprint":"3D765C586CCA8B437B7697EA2CE6A51312530AB1"},
{"fingerprint":"3E50CBCA98A20F637BC4551FD4F132D062DB9A51"},
{"fingerprint":"41A3C16269C7B63DB6EB741DBDDB4E1F586B1592"},
{"fingerprint":"4C3165B64B8237E5273D388429480080022C6481"},
{"fingerprint":"557B274903A48A611B43B66C5761E4F0AFB248A8"},
{"fingerprint":"55D7C9776246C3C5E683A777D97D3ECDD0C5AF37"},
{"fingerprint":"572D22C1AF720F274D274A189EDB75C3F9BDC777"},
{"fingerprint":"5CEF9FD40E64948093EBC041E33ED3ED12F70DFE"},
{"fingerprint":"5CF8AFA5E4B0BB88942A44A3F3AAE08C3BDFD60B"},
{"fingerprint":"5FAA9FC7000138C480F042DE4C602C56C5AA3C42"},
{"fingerprint":"60D2F22EE6FB75739C1F1EF80A2D99D943F12D9E"},
{"fingerprint":"65F260EAC76E4F72ED2F8C34CE47A8E1E0621B90"},
{"fingerprint":"723E9B29DF0357E19B2D1C86B86A0165335BFAA9","as_number":"AS39309"},
{"fingerprint":"728B01C767259E92262329DC148750C08A3A5259"},
{"fingerprint":"73D6694F1E71EBD138A15091EA6CBB6F94271405"},
{"fingerprint":"75FCFA1225B5B4B35E25DA53C8BA7545463B679E"},
{"fingerprint":"77C99455CF6F68A7FF72F78048D1C39A4719EC59"},
{"fingerprint":"79D41A16341822F03D11361B0A31DC9309CEB748"},
{"fingerprint":"7A622004AE337495692986D973A62EAAF2524455"},
{"fingerprint":"7C494B5BBC1558303DB1CFB840D980A0B4BCC324"},
{"fingerprint":"7DBB97846CC559FDB82FDD53360127A17742C9D8"},
{"fingerprint":"7E7006F96EF48C688EEE1B1095BEC66B4EF28029"},
{"fingerprint":"837D5EA513DF7FDDA36BE569C646151CDA4B9935"},
{"fingerprint":"83F03DA35C8E65474B2B9B5EF81896E12AD6282A"},
{"fingerprint":"851491607C61F6C878FF4C92253274095FD20FBB"},
{"fingerprint":"87EDD379CB568F65704665A291A6186006AFAF57"},
{"fingerprint":"8CC6AAB9CBAB31EE4D9E80071F1330100A962EEF"},
{"fingerprint":"8FA258D0E5F525F6E28E13A0BC2351F766D1DAF7"},
{"fingerprint":"8FC24B546A3603D86901E1892270DAE9718A09A3"},
{"fingerprint":"90352FBFD5D0BD4D6FDC867309F393A8AF99FF8A"},
{"fingerprint":"92CFD9565B24646CAC2D172D3DB503D69E777B8A"},
{"fingerprint":"94342E68666C1307ECC4CB083070F4DEC87408E0"},
{"fingerprint":"95D68B64F42F27AED4CA15D0E9A1D0DA86E60339"},
{"fingerprint":"960F231C1C2CABF752E747A57D6CDEFD13F35570"},
{"fingerprint":"9A90F846871641CB97C70B948963FCA3F7486E5A"},
{"fingerprint":"9B7D6254CE9C2D6EDC9A4510699ADADDF6F4D5F9"},
{"fingerprint":"9BF565F0600126D3E2179CC933AA15E7702B4CE9"},
{"fingerprint":"A2534EF23390CAE079B1586F0FDF9CE11F556062"},
{"fingerprint":"A29B3032E92CB2D79903198DB36E78F848636CF4"},
{"fingerprint":"A2DB293FFC5A76A718863BF1AEDBC8DFB1CB1097"},
{"fingerprint":"A4C98CEA3F34E05299417E9F885A642C88EF6029"},
{"fingerprint":"AD2060260080FE092DE928384E2514A1C596772F"},
{"fingerprint":"AF2249FD0897A9FB961883C567309DE41472D5C6"},
{"fingerprint":"B116D652E092760C1F1C44F4A9CA5D628D17CDE9"},
{"fingerprint":"B44FBE5366AD98B46D829754FA4AC599BAE41A6A"},
{"fingerprint":"B584C23DD8B22121FD1B20F926A528F4586F47E7"},
{"fingerprint":"B7E04B6EC8F69EA05FD8CAD9B70AA76327004B13"},
{"fingerprint":"C28B23A00EFFAD65B705601E6B7E640EB41FF2B7"},
{"fingerprint":"C3503770F465DA6F549F6065AFF7B8CFBF62C222"},
{"fingerprint":"C3F1DC3E6B1FDDC5B09387ACCC06CD89843DD476"},
{"fingerprint":"C4AEA05CF380BAD2230F193E083B8869B4A29937"},
{"fingerprint":"C55AC4238C66CE8D00838572D563A284DBEF0228"},
{"fingerprint":"C6B684F84AEA5E5E90CD77FF1E7BD33A3B9C74B5"},
{"fingerprint":"CA94704217260E7483DA88719CACD7A94C564D5C"},
{"fingerprint":"CD5A298960D0BE77ABBBBBA5177CE4615A9A223B"},
{"fingerprint":"CFA45A4739FBE477D8C6500834B59F41A749A294"},
{"fingerprint":"CFE1359C6D1462BFA70500935AD5F2A4AD80826E"},
{"fingerprint":"D0F09FA43F68E134B9E56743797D040F647174D1","as_number":"AS39309"},
{"fingerprint":"D329417643EF2B0B21E9876A397967A7F190CCA1"},
{"fingerprint":"D3C6D2828C09806AF08D120CB3565D8C41B4383F"},
{"fingerprint":"D5FAAC4138272BEE29EA4BA3F1981B25CB6B6F5F"},
{"fingerprint":"D623B6311821F9DB62AD370ADA0A307BA2E26BAA"},
{"fingerprint":"D6D6B6614C9EF2DAD13AC0C94487AD8ED3B6877F"},
{"fingerprint":"DCAFAE7D9DDFDA41959A6E64D89383F9F3CEFE48"},
{"fingerprint":"DD9B36139A546EFB43CBE1E18F399F02ECBD4EC6"},
{"fingerprint":"DDFD587212E4E1905114377851FFAF6659F19823"},
{"fingerprint":"E43A346CB81DDF364B6FF68235AFADBA0E8692B8"},
{"fingerprint":"F012AD9A08A9E0B4A5C61155284FD795B553B361"},
{"fingerprint":"F50C39BCA90ED9B9E37FB66696D19A74530115D6"},
{"fingerprint":"F81C9B79150D85D78B4DF5D70A1789FBE0D608A4"},
{"fingerprint":"FA16B46809F9ABEE2DB68293E6E400D217554155"},
{"fingerprint":"FD4D401A1D3591653B7DA868A0B4D0754C242447"},
{"fingerprint":"FDAED15C98CFE7A416E5676F614254F78406105C"}
],
"bridges_published":"2018-08-17 11:56:51",
"bridges":[
]}
```
https://oo-hetzner-03.torproject.org/details?as=000000&fields=as_number,fingerprint
My theory is that when the GeoIP database does not contain information on an IP address but it did before, that information is not cleared from the details status but is cleared from the summary.
I also noticed that two less hosts were "resolved" than "looked up" in the output stats for geoip. Maybe it is these two hosts. I'm not sure exactly what this means.irlirlhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33880Confusing "Your relay has a very large number of connections to other relays"...2021-07-09T17:22:52ZRoger DingledineConfusing "Your relay has a very large number of connections to other relays" relay messageA new relay operator reports this complaint in their logs, showing up hourly:
```
Your relay has a very large number of connections to other relays. Is your
outbound address the same as your relay address? Found 13 connections to 8
relay...A new relay operator reports this complaint in their logs, showing up hourly:
```
Your relay has a very large number of connections to other relays. Is your
outbound address the same as your relay address? Found 13 connections to 8
relays. Found 13 current canonical connections, in 0 of which we were a
non-canonical peer. 5 relays had more than 1 connection, 0 had more than 2, and
0 had more than 4 connections.
```
I checked, and their outbound address was the same as their relay address.
Upon investigation, it looks like the redundant connections are to directory authorities.
My theory is that the change from legacy/trac#17592 (which went into 0.3.1.1-alpha, commit d5a151a0) is responsible: while before that canonical relay-to-relay connections would expire after either side first reached its randomized "15 to 22.5 minute" timeout, now they expire after either side reaches its "45 to 75 minute" timeout. And since directory authorities test reachability every 1280 seconds (around 21.3 minutes), that means it is expected that most relays will have duplicate canonical connections with directory authorities.
Possible fixes:
(A) Change the notice-level log to make it clearer that it's not scary, or at least it's not actionable. Maybe that means making it info-level so nobody will see it. Probably not the best option, assuming there *are* cases where we do want relay operators to hear it.
(B) In channel_check_for_duplicates(), change `MIN_RELAY_CONNECTIONS_TO_WARN 5` to a high enough number that even if we have 2 canonical conns per authority, plus a bit more, the log message still doesn't trigger.
(C) In channel_check_for_duplicates(), skip over connections to directory authorities in some way, since we know they will be special.
(D) Make connections to or from directory authorities expire quicker, on the theory that they don't really need the same level of padding protection as other connections.
(E) Your idea here?
I'd be fine with any of B,C,D. Whichever one can be done with an easy, short, and non-invasive patch is my favorite. Maybe that's "B, raise it to 30"? That would make the message trigger when we have connections to more than 30 relays and also we have more than 45 connections open. Or we could pick the more conservative "raise it to 40", on the theory that small numbers are more likely to have edge cases and less indicative of major network problems anyway.
And while we're at it, it might be smart to say in the log message what action we want the relay operator take, e.g. "Please report:".Nick MathewsonNick Mathewsonhttps://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/7869ntor-onion-key is padded with an equal sign2021-07-09T17:22:51ZRobert Ransomntor-onion-key is padded with an equal signReplying to [sonu](legacy/trac#7867):
>
```
ntor-onion-key Od2Sj3UXFyDjwESLXk6fhatqW9z/oBL/vAKJ+tbDqUU=
```
The unnecessary “`=`” at the end of that string needs to go away **now**, or every Tor client will have to download a thousand ...Replying to [sonu](legacy/trac#7867):
>
```
ntor-onion-key Od2Sj3UXFyDjwESLXk6fhatqW9z/oBL/vAKJ+tbDqUU=
```
The unnecessary “`=`” at the end of that string needs to go away **now**, or every Tor client will have to download a thousand or so of them every week forever.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/40003Ensure metrics-lib supports version 3.1 OnionPerf analysis files2021-07-06T13:06:36ZAna CusturaEnsure metrics-lib supports version 3.1 OnionPerf analysis filesAny results coming from new instances of Onionperf will not be parsed by metrics-lib (and won't appear in the website) unless we change the version checker to support version 5.0.
We've only added new fields to the analysis files, so I...Any results coming from new instances of Onionperf will not be parsed by metrics-lib (and won't appear in the website) unless we change the version checker to support version 5.0.
We've only added new fields to the analysis files, so I don't expect the parser to break.metrics-lib 2.16.0irlirlhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/33835Gmail's quoted response confuses BridgeDB's email autoresponder2021-07-01T17:47:15ZPhilipp Winterphw@torproject.orgGmail's quoted response confuses BridgeDB's email autoresponderWhen replying to a BridgeDB email in Gmail's web interface, one ends up sending an email like this:
```
On Mon, Apr 6, 2020 at 2:12 PM <bridges@torproject.org> wrote:
>
> [This is an automated email. Please do not reply.]
>
> Here are ...When replying to a BridgeDB email in Gmail's web interface, one ends up sending an email like this:
```
On Mon, Apr 6, 2020 at 2:12 PM <bridges@torproject.org> wrote:
>
> [This is an automated email. Please do not reply.]
>
> Here are your bridges:
>
> [redacted]
>
> Add these bridges to your Tor Browser by opening your browser
> preferences, clicking on "Tor", and then adding them to the "Provide a
> bridge" field.
>
> If these bridges are not what you need, reply to this email with one of
> the following commands in the message body:
>
> get bridges (Request unobfuscated Tor bridges.)
> get ipv6 (Request IPv6 bridges.)
> get transport TYPE (Request obfuscated bridges. Replace TYPE with
> 'obfs4'.)
> get key (Get a copy of BridgeDB's public GnuPG key.)
>
>
>
--000000000000dde1a205a2a60f3e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">get transport obfs4<br></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 6, 2020 at 2:12 PM <=
<a href=3D"mailto:bridges@torproject.org">bridges@torproject.org</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
[This is an automated email.=C2=A0 Please do not reply.]<br>
<br>
Here are your bridges:<br>
<br>
=C2=A0 [redacted]<br>
<br>
Add these bridges to your Tor Browser by opening your browser<br>
preferences, clicking on "Tor", and then adding them to the "=
;Provide a<br>
bridge" field.<br>
<br>
If these bridges are not what you need, reply to this email with one of<br>
the following commands in the message body:<br>
<br>
=C2=A0 get bridges=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Request unobfu=
scated Tor bridges.)<br>
=C2=A0 get ipv6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(Requ=
est IPv6 bridges.)<br>
=C2=A0 get transport TYPE=C2=A0 =C2=A0 =C2=A0(Request obfuscated bridges. R=
eplace TYPE with 'obfs4'.)<br>
=C2=A0 get key=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Get =
a copy of BridgeDB's public GnuPG key.)<br>
<br>
<br>
</blockquote></div>
--000000000000dde1a205a2a60f3e--
```
BridgeDB correctly ignores the commands that start with `>` but it doesn't ignore the commands that are encoded in quoted-printable. BridgeDB's email parser ends up [interpreting each line as command](https://gitweb.torproject.org/bridgedb.git/tree/bridgedb/distributors/email/request.py?h=develop&id=bca64964a255cf959489c7049c66e5eb70b5291c#n87), ending in "get key", which raises an exception, resulting in BridgeDB sending no response at all.
We should make sure that BridgeDB doesn't get confused by Gmail's quoted-printable response.Sponsor 30 - Objective 2.2Armin HuremagicArmin Huremagichttps://gitlab.torproject.org/tpo/core/tor/-/issues/40098Parallelize several tests to make hardened-build CI faster.2021-06-22T21:08:38ZNick MathewsonParallelize several tests to make hardened-build CI faster.Right now our hardened-build gitlab CI test is much slower than the others. It looks like when the build is hardened, `./src/test/test` is slowest.
As a solution, I think we should have the ability to launch the first 1/N of the tests ...Right now our hardened-build gitlab CI test is much slower than the others. It looks like when the build is hardened, `./src/test/test` is slowest.
As a solution, I think we should have the ability to launch the first 1/N of the tests in src/test/test in parallel with the second 1/N, the third 1/N, and so on.
I'm running an experiment to see if this helps.Nick MathewsonNick Mathewson