The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-07-24T15:39:50Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11448Dirauths must support multiple relay identity keys at once2020-07-24T15:39:50ZRobert RansomDirauths must support multiple relay identity keys at onceAs discussed on [https://blog.torproject.org/blog/openssl-bug-cve-2014-0160], directory authorities must rotate their relay identity keys in order to recover from possible exposure due to the ‘Heartbleed’ bug. (A dirauth's relay identit...As discussed on [https://blog.torproject.org/blog/openssl-bug-cve-2014-0160], directory authorities must rotate their relay identity keys in order to recover from possible exposure due to the ‘Heartbleed’ bug. (A dirauth's relay identity key could be used by a MITM attacker to feed clients an outdated consensus, for example.)
There are two requirements in order to do this without causing a network meltdown:
* A dirauth must be able to sign relay descriptors using multiple relay identity keys at once.
* A dirauth must be able to operate multiple ORPorts at once, with (possibly) different relay identity keys.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11447Find a better value for MAX_REND_FAILURES2020-06-27T14:03:12ZNick MathewsonFind a better value for MAX_REND_FAILURESFor a while, MAX_REND_FAILURES was set to 30. That's clearly wrong; in legacy/trac#4241 we set it to 8. But is 8 the right value? We should investigate actual failure rates and pick a value that's more in tune with what we're actually ...For a while, MAX_REND_FAILURES was set to 30. That's clearly wrong; in legacy/trac#4241 we set it to 8. But is 8 the right value? We should investigate actual failure rates and pick a value that's more in tune with what we're actually seeing in the wild.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11446Remove Windows CE support2021-09-16T14:35:28ZNick MathewsonRemove Windows CE supportLong ago we merged some patches to support WinCE. I am pretty sure that nobody actually uses Tor on WinCE now, and I doubt that the code works any more. We should just strip it out.Long ago we merged some patches to support WinCE. I am pretty sure that nobody actually uses Tor on WinCE now, and I doubt that the code works any more. We should just strip it out.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11445Drop support for Windows XP2021-09-16T14:35:28ZNick MathewsonDrop support for Windows XPWindows XP hit its end-of-life today (April 8, 2014).
We should identify and drop support code for Windows XP. This is mainly going to be a matter of identifying cases where we use LoadLibrary and GetProcAddress to find always-present-...Windows XP hit its end-of-life today (April 8, 2014).
We should identify and drop support code for Windows XP. This is mainly going to be a matter of identifying cases where we use LoadLibrary and GetProcAddress to find always-present-functions in always-present DLLs, and looking for opportunities to move from old busted APIs to fresh new ones.
I'm making this a separate ticket from legacy/trac#11444 (removing support from pre-XP versions) since the timing on the two can be argued to be separate. Nonetheless, if we agree to do both at once, that might be clever.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11444Drop support for long-obsolete versions of Windows2021-09-16T14:35:28ZNick MathewsonDrop support for long-obsolete versions of WindowsWhen we started writing Tor, Windows 98 was still a going concern. Now... it is less so.
We should identify and drop support code for all windows versions before Windows XP. This is mainly going to be a matter of identifying cases whe...When we started writing Tor, Windows 98 was still a going concern. Now... it is less so.
We should identify and drop support code for all windows versions before Windows XP. This is mainly going to be a matter of identifying cases where we use LoadLibrary and GetProcAddress to find always-present-functions in always-present DLLs, and looking for opportunities to move from old busted APIs to fresh new ones.
(Dropping support for windows XP is a separate ticket.)https://gitlab.torproject.org/tpo/core/tor/-/issues/11440Cannot get Tor to work2020-06-27T14:03:12ZTracCannot get Tor to workHello, I have been trying all day to get it going without success Can you please help? It says wsaenetunreach. Here is the log file:
9/04/2014 14:29:00 PM.885 [NOTICE] Bridge at '24.212.241.19:9001' isn't reachable by our firewall policy...Hello, I have been trying all day to get it going without success Can you please help? It says wsaenetunreach. Here is the log file:
9/04/2014 14:29:00 PM.885 [NOTICE] Bridge at '24.212.241.19:9001' isn't reachable by our firewall policy. Skipping.
9/04/2014 14:29:00 PM.885 [NOTICE] Bridge at '88.198.108.251:8443' isn't reachable by our firewall policy. Skipping.
9/04/2014 14:29:00 PM.885 [NOTICE] Bootstrapped 5%: Connecting to directory server.
9/04/2014 14:29:00 PM.886 [WARN] connection_connect(): Bug: Tried to open a socket with DisableNetwork set.
9/04/2014 14:29:00 PM.887 [WARN] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 1; recommendation warn)
**Trac**:
**Username**: 81shadowhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11438Update ciphers.inc to match ciphers from a recent firefox2020-06-27T14:03:12ZNick MathewsonUpdate ciphers.inc to match ciphers from a recent firefoxI hear that firefox has added a bunch of new ciphersuites since we last updated ciphers.inc. We should re-run get_mozilla_ciphers.py on the most recent stable firefox and openssl, to generate a new cipehrs.inc for Tor 0.2.5. We should ...I hear that firefox has added a bunch of new ciphersuites since we last updated ciphers.inc. We should re-run get_mozilla_ciphers.py on the most recent stable firefox and openssl, to generate a new cipehrs.inc for Tor 0.2.5. We should fix get_mozilla_ciphers if it needs it; the code may have rotted a bit.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11437Memory leak on successful PTR lookup2020-06-27T14:03:13ZNick MathewsonMemory leak on successful PTR lookupIn inform_pending_connections, set_exitconn_info_from_resolve() is allowed to set hostname to a newly allocated string... but nothing actually frees hostname.
This is coverity CID 1198198.In inform_pending_connections, set_exitconn_info_from_resolve() is allowed to set hostname to a newly allocated string... but nothing actually frees hostname.
This is coverity CID 1198198.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11426Can't compile, endian.h not part of SunOS / Solaris2020-06-27T14:03:13ZTracCan't compile, endian.h not part of SunOS / SolarisI can't compile tor-0.2.5.3-alpha on SunOS / Solaris 5.10 anymore because Solaris
does not have a header file "endian.h", which is now required in "src/ext/csiphash.c"
This issue was not with tor-0.2.5.2-alpha.
Can this be fixed?
gmake...I can't compile tor-0.2.5.3-alpha on SunOS / Solaris 5.10 anymore because Solaris
does not have a header file "endian.h", which is now required in "src/ext/csiphash.c"
This issue was not with tor-0.2.5.2-alpha.
Can this be fixed?
gmake
gmake all-am
gmake[1]: Entering directory `/usr/local/lib/tor-0.2.5.3-alpha'
CC src/common/address.oCC src/common/backtrace.oCC src/common/compat.oCC src/common/container.oCC src/common/di_ops.oCC src/common/log.oCC src/common/memarea.oCC src/common/mempool.oCC src/common/procmon.o
src/common/procmon.c: In function `tor_process_monitor_poll_cb':
src/common/procmon.c:327: warning: int format, pid_t arg (arg 4)
CC src/common/util.o
src/common/util.c: In function `tor_get_exit_code':
src/common/util.c:4127: warning: int format, pid_t arg (arg 5)
src/common/util.c:4133: warning: int format, pid_t arg (arg 5)
CC src/common/util_codedigest.oCC src/common/sandbox.oCC src/ext/csiphash.o
src/ext/csiphash.c:55:24: endian.h: No such file or directory
src/ext/csiphash.c: In function `siphash24':
src/ext/csiphash.c:106: warning: implicit declaration of function `le64toh'
gmake[1]: *** [src/ext/csiphash.o] Error 1
gmake[1]: Leaving directory `/usr/local/lib/tor-0.2.5.3-alpha'
gmake: *** [all] Error 2
**Trac**:
**Username**: RainerTor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11403tor dns + bind = lame name-server2020-06-27T14:03:13ZTractor dns + bind = lame name-serverHello,
I've been trying for a couple of hours now to make this work .. a part went ok .. but there still seems to be a problem.
My named/bind setup looks like this:
zone "onion" IN {
type forward;
forwarders {
...Hello,
I've been trying for a couple of hours now to make this work .. a part went ok .. but there still seems to be a problem.
My named/bind setup looks like this:
zone "onion" IN {
type forward;
forwarders {
127.0.0.2;
};
};
My ~/.torrc
#Log debug
User dexter
DataDirectory /home/dexter/.tor/
SocksListenAddress 127.0.0.1
SocksListenAddress 192.168.1.95
SocksPolicy accept 127.0.0.1/32
SocksPolicy accept 192.168.1.0/24
SocksPolicy reject *
NewCircuitPeriod 99999
KeepalivePeriod 60
DNSPort 127.0.0.2:53
TransPort 9040
AutomapHostsOnResolve 1
VirtualAddrNetwork 10.192.0.0/10
HiddenServiceDir /home/dexter/.tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80
My resolv.conf
nameserver 127.0.0.1
Bind listens on 127.0.0.1:53
Here's what happens:
$ dig +short a pcl5dt2boqqvmpk7.onion @127.0.0.2
10.206.233.205
$ dig +short a pcl5dt2boqqvmpk7.onion @127.0.0.2
10.206.233.205
$ dig +short a pcl5dt2boqqvmpk7.onion @127.0.0.2
10.206.233.205
So tor's dns server is ok...
$ dig +short a pcl5dt2boqqvmpk7.onion @127.0.0.1
10.206.233.205
$ dig +short a pcl5dt2boqqvmpk7.onion @127.0.0.1
10.206.233.205
$ dig +short a pcl5dt2boqqvmpk7.onion @127.0.0.1
10.206.233.205
So my bind forwards ok. Now watch this:
$ dig +short aaaa pcl5dt2boqqvmpk7.onion @127.0.0.1
$ dig +short a pcl5dt2boqqvmpk7.onion @127.0.0.1
$ dig +short a pcl5dt2boqqvmpk7.onion @127.0.0.1
$ dig +short a pcl5dt2boqqvmpk7.onion @127.0.0.2
10.206.233.205
So, as soon as named asks for something, the tor dns doesn't answer correctly answering with an A for an AAAA instead of giving an empty AAAA with NOERROR ( I think this is the problem ) and gets marked as a lame-server and will cache it like this for 600 seconds I think.
Named's logs show this:
queries: info: client 127.0.0.1#55980 (pcl5dt2boqqvmpk7.onion): view internal: query: pcl5dt2boqqvmpk7.onion IN A +E (127.0.0.1)
queries: info: client 127.0.0.1#37020 (pcl5dt2boqqvmpk7.onion): view internal: query: pcl5dt2boqqvmpk7.onion IN A +E (127.0.0.1)
queries: info: client 127.0.0.1#40132 (pcl5dt2boqqvmpk7.onion): view internal: query: pcl5dt2boqqvmpk7.onion IN A +E (127.0.0.1)
queries: info: client 127.0.0.1#47246 (pcl5dt2boqqvmpk7.onion): view internal: query: pcl5dt2boqqvmpk7.onion IN AAAA +E (127.0.0.1)
resolver: notice: DNS format error from 127.0.0.2#53 resolving pcl5dt2boqqvmpk7.onion/AAAA for client 127.0.0.1#47246: reply has no answer
lame-servers: info: error (FORMERR) resolving 'pcl5dt2boqqvmpk7.onion/AAAA/IN': 127.0.0.2#53
queries: info: client 127.0.0.1#59716 (pcl5dt2boqqvmpk7.onion): view internal: query: pcl5dt2boqqvmpk7.onion IN A +E (127.0.0.1)
queries: info: client 127.0.0.1#55020 (pcl5dt2boqqvmpk7.onion): view internal: query: pcl5dt2boqqvmpk7.onion IN A +E (127.0.0.1)
Any ideas on how to solve this ?
Thanks in advance.
**Trac**:
**Username**: d3xt3r01Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11397Keep using too-dirty circuits if no new circuit can be built?2021-08-23T15:19:20ZTracKeep using too-dirty circuits if no new circuit can be built?When behind a firewall that not only lets only a few ports through but that also validates that only the expected protocol is passing through, it may take dozens of seconds to build a new circuit. In the meantime, new connections will t...When behind a firewall that not only lets only a few ports through but that also validates that only the expected protocol is passing through, it may take dozens of seconds to build a new circuit. In the meantime, new connections will timeout before new circuits are built.
This behavior deserves some attention. Perhaps until a new circuit is built, an old circuit should continue to be used or after a few seconds of waiting for the new circuit.
However, if there's no connection alive, there might not even be old circuits to fall back to. Then, the user might be given the choice to always keep an old circuit open, even if idle, until a new circuit is built.
**Trac**:
**Username**: evandroTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11396Detect maximum memory at runtime to allow lower default than 8GB2020-06-27T14:03:13ZNick MathewsonDetect maximum memory at runtime to allow lower default than 8GBThe default value for MaxMemInQueues is 8 GB, which means that for many users, there simply won't be any support for OOM prevention.
I think we can do better than that by detecting the physical memory and picking a default MaxMemInQueue...The default value for MaxMemInQueues is 8 GB, which means that for many users, there simply won't be any support for OOM prevention.
I think we can do better than that by detecting the physical memory and picking a default MaxMemInQueues based on a percentage of that. Of course, the user should still be able to override that value.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11394So I'm a newbie to Tor, but, um, conspicuous hostnames?2020-06-27T14:03:13ZTracSo I'm a newbie to Tor, but, um, conspicuous hostnames?I was just assigned to an exit with A and PTR records resolving to torrouter.ml-ext.ucar.edu. It seems like this might be, um, very easy to blacklist? Shouldn't this flag as a poor configuration choice or something?
**Trac**:
**Userna...I was just assigned to an exit with A and PTR records resolving to torrouter.ml-ext.ucar.edu. It seems like this might be, um, very easy to blacklist? Shouldn't this flag as a poor configuration choice or something?
**Trac**:
**Username**: g--nhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11378The Tor software encountered an internal bug.2020-06-27T14:03:13ZTracThe Tor software encountered an internal bug.microdesc_free_(): Bug: microdesc_free() called from ../src/or/microdesc.c:377, but md was still referenced 1 node(s); held_by_nodes == 1
**Trac**:
**Username**: ndiggitymicrodesc_free_(): Bug: microdesc_free() called from ../src/or/microdesc.c:377, but md was still referenced 1 node(s); held_by_nodes == 1
**Trac**:
**Username**: ndiggityTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11376Provide Privileged and Unprivileged control ports2020-06-27T14:03:13ZMatthew FinkelProvide Privileged and Unprivileged control ports(This may be a duplicate because I know this has been discussed before, but I couldn't find the original if it exists)
The control port has the potential ability to pass sensitive information (legacy/trac#3521, legacy/trac#5976, legacy/...(This may be a duplicate because I know this has been discussed before, but I couldn't find the original if it exists)
The control port has the potential ability to pass sensitive information (legacy/trac#3521, legacy/trac#5976, legacy/trac#1949). There may be situations where one controller only needs the ability to query and receive a limited amount of information and another controller handles the sensitive information. These two processes should be able to connect/authenticate to different sockets and and thus prevent the first process from receiving sensitive information.
Alternatively, this same isolation can be achieved using the chosen authentication mechanism.
Whichever is better (or if both, or another, are chosen), the capabilities of the connection should also be configurable via torrc and control port. For example, whether a connection is allowed to SETCONF or only GETCONF and SETEVENTS, etc. A high level of granularity would be ideal.https://gitlab.torproject.org/tpo/core/tor/-/issues/11363QR,DIR ports bind to 0.0.0.0 even when I tell tor otherwise.2020-06-27T14:03:14ZTracQR,DIR ports bind to 0.0.0.0 even when I tell tor otherwise.Hello,
I am running a tor middle relay on a high bandwidth connection but an running into a problem which is causing me more frustration then needed.
I have multiple virtual ip's on my servers NIC. I only want ports 9030,443 and outgo...Hello,
I am running a tor middle relay on a high bandwidth connection but an running into a problem which is causing me more frustration then needed.
I have multiple virtual ip's on my servers NIC. I only want ports 9030,443 and outgoing connections to be available on 1 virtual IP. In order to accomplish that I have added the following configuration to Vidalia.
# This file was generated by Tor; if you edit it, comments will not be preserved
# The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it
AccountingMax 11811160064000
AccountingStart month 1 00:00
ContactInfo tor-relay-harrry at comcast dot net
ControlPort 9051
DataDirectory C:/Users/jt/AppData/Roaming/tor
DirPort 192.223.27.139:9030
DirReqStatistics 0
ExitPolicy reject *:*
HashedControlPassword 16:0FD1F531889C1EA360F45BB687F6635983F68D781254B999BC7EDB0200
Log notice stdout
Nickname BeefTits
ORPort 192.223.27.139:443
OutboundBindAddress 192.223.27.139
RelayBandwidthBurst 30720000
RelayBandwidthRate 10240000
SocksPolicy reject *
SocksPort 9050
The problem is TOR.exe looks for the ports on my default NIC ip address of 63.251.20.61:443 and 63.251.20.61:9031
=====================================================================
Mar 29 00:03:59.678 [Notice] Now checking whether ORPort 63.251.20.61:443 and DirPort 63.251.20.61:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success)
======================================================================
Because I have communication blocked on these ports the reach-ability test fails.
======================================================================
Mar 29 00:23:58.649 [Warning] Your server (63.251.20.61:443) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
Mar 29 00:23:58.650 [Warning] Your server (63.251.20.61:9030) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
======================================================================
Is is possible for the service to only use the ports that I am specifying? If I leave the default ports open then port 443 is open on my main server ip which I do not want.
Additionally if I have the configuration setup with the default ports set i.e not specifying an ip:port in the config in vadalia, when I click on settings/sharing the box relay traffic inside the to network (non-exit relay) is checked as expected.
As soon as I edit the configuration like I have above and specify the ip:port allocations the button goes to run as client only by itself, and it over-writes the configuration I added and defaults the configuration to specify just the ports 443 and 9031 which means bind to 0.0.0.0 i.e 63.251.20.61
Question is there a way to specify outgoing and incoming port allocations to one virtual ip on the IP Stack?
Why is it using the default ip when I am specifically telling it not to do so.
I also see the ports being used in the sniffer output so the software is ignoring my configuration for port:ip bindings.
Thanks,
Justin
**Trac**:
**Username**: jplhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11360Listen on IPv6 by default for SocksPort *:Port2021-06-18T18:20:31ZDavid Gouletdgoulet@torproject.orgListen on IPv6 by default for SocksPort *:PortThat would be very useful if tor could listen on both IPv4 and IPv6 for the SocksPort. One use case is for Torsocks to work seamlessly with v4 and v6 without having to configure a v6 port in the configuration file and restart the daemon....That would be very useful if tor could listen on both IPv4 and IPv6 for the SocksPort. One use case is for Torsocks to work seamlessly with v4 and v6 without having to configure a v6 port in the configuration file and restart the daemon.
One way to fix that would be to change the function parse_port_config() in _src/or/config.c_ to allow multiple default values adding v6 defaults (which would benefit other ports as well).
Else, having a check somewhere that adds other defaults for specific ports but not sure that it's a good idea nor makes sense in the long run in terms of maintainability.
I thought also about bringing back legacy/trac#4760 by default and setting the ipv6 only option only and only if the user has defined an option in the torrc explicitly. For instance, this in the torrc would ONLY allow v6 (remove dual stack).
```
SocksPort [::1]:9050
```
Thoughts?https://gitlab.torproject.org/tpo/core/tor/-/issues/11358Tor should consider more addresses as invalid2020-06-27T14:03:14ZYawning AngelTor should consider more addresses as invalidThere's a few more address blocks that should never appear on the public internet that do not appear to be checked for when processing the exit policy (Belong in `private_nets`) or in `tor_addr_is_internal()`.
From RFC 5735:
* 192.0.2....There's a few more address blocks that should never appear on the public internet that do not appear to be checked for when processing the exit policy (Belong in `private_nets`) or in `tor_addr_is_internal()`.
From RFC 5735:
* 192.0.2.0/24 TEST-NET-1
* 198.51.100.0/24 TEST-NET-2
* 203.0.113.0/24 TEST-NET-3
* 198.18.0.0/15 Network Interconnect Device Benchmark Testing
From RFC 5156:
* 2001:db8::/32 Documentation Prefix
* 2001:10::/28 ORCHID
Traffic containing these addresses have no business being on the public internet, so the code should be updated to check for them and reject them where appropriate. Since `tor_addr_is_internal()` is used for things other than rejection, this probably should be done as a separate function that is checked when the code means "Reject things that should not be used" (most of the code) vs "Explicitly need a local address" (`warn_nonlocal_client_ports()` for example).https://gitlab.torproject.org/tpo/core/tor/-/issues/11351Make sandbox code work with chutney, strong enough to be plausible2020-06-27T14:03:14ZNick MathewsonMake sandbox code work with chutney, strong enough to be plausibleUsing the sandbox code with chutney crashes.
Also, it doesn't restrict rename(), which makes restrictions on open() kind of pointless.Using the sandbox code with chutney crashes.
Also, it doesn't restrict rename(), which makes restrictions on open() kind of pointless.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11342dump_desc() can trigger "write_str_to_file(): Bug: We're writing a text strin...2020-06-27T14:03:14ZRoger Dingledinedump_desc() can trigger "write_str_to_file(): Bug: We're writing a text string that already contains a CR" on Windowsdump_desc() calls write_str_to_file() with bin==0, which on Windows causes an LD_BUG warn if the thing you're writing has a \r in it.
In this case, we're writing the thing because it came from the network and we couldn't parse it. So we...dump_desc() calls write_str_to_file() with bin==0, which on Windows causes an LD_BUG warn if the thing you're writing has a \r in it.
In this case, we're writing the thing because it came from the network and we couldn't parse it. So we could totally give a Windows relay or client a thing that they can't parse which has a \r in it, causing this LD_BUG log to trigger.
Noticed by looking at legacy/trac#11233. Unclear if it's the same location as was triggered in that bug though.Tor: 0.2.5.x-final