Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:01:05Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20066Make test-memwipe work better on OpenBSD2020-06-13T15:01:05ZTracMake test-memwipe work better on OpenBSDWhere "work" means access freed buffers without exploding.
It currently segfaults 100% of the time but it could be "fixed" by setting the malloc.conf options in the program to turn off some of the protections.
's' will turn off malloc ...Where "work" means access freed buffers without exploding.
It currently segfaults 100% of the time but it could be "fixed" by setting the malloc.conf options in the program to turn off some of the protections.
's' will turn off malloc canaries (among other things). This stops it segfaulting. 'c' would do the same thing but would break on releases older than 5.9 which didn't have that option. 's' also means any new protections that are enabled by default will be turned off, which might help this keep working in the future.
Junking has two levels, so it needs 2x 'j' to guarantee it's turned off. This makes the warning about unreliable results go away.
Freelist and unmap protection aren't on by default but it will crash if it is, so a 'u' and 'f' will ensure it's off (it does nothing if it's already off).
**Trac**:
**Username**: rubiateTor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20064When allowing private addresses, assign Exit flag if 10.0.0.0/8 is exited to2020-06-13T16:03:39ZSebastian HahnWhen allowing private addresses, assign Exit flag if 10.0.0.0/8 is exited toIn a Tor network deployed in a custom network, none of the nodes get an Exit flag even tho they should qualify according to the spec. This is because internal addresses are skipped.In a Tor network deployed in a custom network, none of the nodes get an Exit flag even tho they should qualify according to the spec. This is because internal addresses are skipped.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20063Permit sched_yield in sandbox2020-06-13T15:01:05ZNick MathewsonPermit sched_yield in sandboxTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20038Fix typo in tor man page (ControlPort description)2020-06-13T15:00:56ZGeorg KoppenFix typo in tor man page (ControlPort description)The description for `ControlPort` contains a typo: "eithermethod".The description for `ControlPort` contains a typo: "eithermethod".Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20012Stop upgrading client to intro connections to ntor2020-06-13T15:00:49ZteorStop upgrading client to intro connections to ntorSplit off from #19163, placed in the same milestone.
Clients inadvertently upgrade to ntor when the hidden service descriptor does not have a TAP onion key. This is a client discriminator that can be used by hidden services to discover ...Split off from #19163, placed in the same milestone.
Clients inadvertently upgrade to ntor when the hidden service descriptor does not have a TAP onion key. This is a client discriminator that can be used by hidden services to discover which consensus a client has.
This bug was inadvertently introduced along with ntor in 0.2.4.8-alpha.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/20002Never include non-Valid nodes in consensus.2020-06-13T15:00:45ZNick MathewsonNever include non-Valid nodes in consensus.Right now, we don't include non-Running nodes. Let's make it so we never include non-Valid nodes either.Right now, we don't include non-Running nodes. Let's make it so we never include non-Valid nodes either.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19998Stop allowing 3DES in TLS ciphersuites2020-06-13T15:00:42ZNick MathewsonStop allowing 3DES in TLS ciphersuitesThanks to the SWEET32 attack, 3des is getting lots of attention.
Right now, Tor is willing in principle to negotiate a 3DES TLS connection.
But the good news is (I think) that two non-obsolete Tor instances will never actually do so. ...Thanks to the SWEET32 attack, 3des is getting lots of attention.
Right now, Tor is willing in principle to negotiate a 3DES TLS connection.
But the good news is (I think) that two non-obsolete Tor instances will never actually do so. Here is my reasoning:
* Our source code has always preferred AES to 3DES. So the only way to get 3DES would be if one party didn't support AES.
* OpenSSL began supporting AES in version 0.9.7.
* Tor has required OpenSSL 0.9.7 or later since 7da93b80ca7a6ba , which was in 0.2.0.10-alpha.
So this cipher shouldn't get negotiated, unless you're doing something very very weird.
I suggest that the best fix is to stop servers from ever choosing it.
I suggest that as an additional fix, clients should reject a connection to any server that _does_ choose it.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19972prop224: Proposal fixes from implementation of HSDir support2020-06-13T15:00:32ZDavid Gouletdgoulet@torproject.orgprop224: Proposal fixes from implementation of HSDir supportWith the implementation work of #17238, we ended up changing small pieces of proposal 224. This is the ticket to address those.With the implementation work of #17238, we ended up changing small pieces of proposal 224. This is the ticket to address those.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19902Dual-install of libevent 1 and libevent 2 on openbsd confuses our autoconf logic2020-06-13T15:00:13ZNick MathewsonDual-install of libevent 1 and libevent 2 on openbsd confuses our autoconf logicTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18693New SOCKS port restriction to only allow connections to .onion2020-06-13T14:55:57ZJacob AppelbaumNew SOCKS port restriction to only allow connections to .onionWhile working on Ricochet to make it the a post-TCP/IP IM client, special and I have been considering ways to sandbox it further. We decided it would be nice to have a way to mark a given tor SOCKS (unix socket) listener as only allowing...While working on Ricochet to make it the a post-TCP/IP IM client, special and I have been considering ways to sandbox it further. We decided it would be nice to have a way to mark a given tor SOCKS (unix socket) listener as only allowing connections to .onion addresses.
This is similar to setting the option to not allow IPv4 - except we don't want DNS, IPv6 or any connection except to an onion service.Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/17178Rendezvous Single Onion Services: One-Hop Intro Point and Rendezvous2020-06-13T15:00:56ZteorRendezvous Single Onion Services: One-Hop Intro Point and RendezvousThe following patch enables one-hop intro point and rendezvous connections for onion service servers. It is compatible with current tor clients and relays.
Use the following torrc lines to make intro point and rendezvous point connectio...The following patch enables one-hop intro point and rendezvous connections for onion service servers. It is compatible with current tor clients and relays.
Use the following torrc lines to make intro point and rendezvous point connections one-hop on the server:
```
__OnionSrvIntroRouteLength 1
__OnionSrvRendRouteLength 0
```
Branch: hs-route-len-v2
Repository: https://github.com/teor2345/tor.gitTor: 0.2.9.x-finalteorteor