Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-03-22T13:28:40Zhttps://gitlab.torproject.org/legacy/trac/-/issues/2681brainstorm ways to let Tor clients use yesterday's consensus more safely2022-03-22T13:28:40ZRoger Dingledinebrainstorm ways to let Tor clients use yesterday's consensus more safelyRight now Tor clients won't use a consensus that's 25 hours old. But if the directory authorities don't agree on a consensus for a day, things can go bad. We need to investigate other tradeoffs in this space than the one we've currently ...Right now Tor clients won't use a consensus that's 25 hours old. But if the directory authorities don't agree on a consensus for a day, things can go bad. We need to investigate other tradeoffs in this space than the one we've currently picked.
For instance: if you got your directory consensus info when it was valid, but you haven't been able to get any new consensus, perhaps you should be more forgiving about the timestamp on the consensus you have. That's a slightly different scenario than believing a new consensus that's 48 hours old.
Another option is just to change 24 to 48, which probably doesn't put clients at much greater harm, but gives us a lot more breathing room for mistakes.
The implementation side of this will be tricky, because we'll need to make sure that clients can handle descriptors that are 36 hours out of date too. We started implementing that feature several times, but I think we've never finished it.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2915Explore options to reduce binary size of Tor2020-06-13T14:09:45ZSebastian HahnExplore options to reduce binary size of TorOur bundles are pretty big, so we could benefit from "free" optimizations of binary size (those that don't incur a performance hit). Experimentation with ld's -deadcode flag (OS X) or -ffunction-sections, -fdata-sections together with -g...Our bundles are pretty big, so we could benefit from "free" optimizations of binary size (those that don't incur a performance hit). Experimentation with ld's -deadcode flag (OS X) or -ffunction-sections, -fdata-sections together with -gc-sections have led to space savings of up to 25%, which seems well worthwhile.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/5298Relay does not pick the right IP addr of local node when multiple interfaces ...2020-06-13T14:25:51ZTracRelay does not pick the right IP addr of local node when multiple interfaces are availableMy laptop has two network interfaces: eth0, statically configured, in use when I'm wired in my office; and ppp0, dynamically configured, when I'm abroad and use a 3G wireless interface.
When I'm on eth0 (LAN), the tor relay works regula...My laptop has two network interfaces: eth0, statically configured, in use when I'm wired in my office; and ppp0, dynamically configured, when I'm abroad and use a 3G wireless interface.
When I'm on eth0 (LAN), the tor relay works regularly.
When I'm on the ppp0 (3G wireless), the tor relay works too but the ORPort and DirPort are not reachable from the outside, because the relay still picks the IP address associated to eth0 instead of ppp0.
This problem affects both on the stable release (0.2.2.35) and the latest git snapshot (and probably many other releases).
With the stable release, I've tracked the bug down to
src/or/config.c:resolve_my_address(), a rather messy piece of code which mistakenly resolves via hostname rather than picking the IP address based on the actual route default. I had to rewrite that function almost from scratch, and now it works.
With the latest snapshot, same problem in
src/or/config.c:resolve_my_address(), plus another issue in
src/common/address.c:get_interface_address6(): here a list of all net devices available is built, but then the first valid one is picked, regardless of it being the one in use or not (on my laptop it always chooses eth0). Solved by disabling the list of net devices, thus falling back to the default "discovery" mechanism (the only one implemented in the stable release).
I have patches, if needed.
**Trac**:
**Username**: ciaccioTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6939Missing IPv6 ORPort reachability check2020-06-13T14:23:06ZshamrockMissing IPv6 ORPort reachability checkIssue:
Tor does not log (or does not perform) a test to determine if an IPv6 ORPort is reachable.
Tor does log a corresponding test for an IPv4 ORPort.
Environment:
Debian squeeze amd64, latest patches
Tor version 0.2.4.2-alpha (git-05...Issue:
Tor does not log (or does not perform) a test to determine if an IPv6 ORPort is reachable.
Tor does log a corresponding test for an IPv4 ORPort.
Environment:
Debian squeeze amd64, latest patches
Tor version 0.2.4.2-alpha (git-0537dc6364594474)
How to reproduce:
- configure Tor with both IPv4 and IPv6 IP addresses and OrPorts.
- start Tor
- the Tor log file will show a test to determine if the IPv4 OrPort is reachable, but not if the IPv6 ORPort is reachable.
- (this particular system was configured as a bridge)
Expected Behavior:
The user might expect to see a log entry for IPv6 that corresponds to the following log entry for IPv4:
"Sep 22 11:09:21.000 [notice] Now checking whether ORPort [host's IPv4 address]:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)"Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7176Adapt and update AccessLabs' patches for reduced Tor memory consumption for e...2020-06-13T15:10:34ZcypherpunksAdapt and update AccessLabs' patches for reduced Tor memory consumption for embedded devicesThese are a set of patches written by Access Labs. They claim that these patches reduce memory usage on small low memory devices.
The patches are in several different areas:
* using anonymous mmap() for storing large chunks of data (i...These are a set of patches written by Access Labs. They claim that these patches reduce memory usage on small low memory devices.
The patches are in several different areas:
* using anonymous mmap() for storing large chunks of data (instead of tempfiles)
* persisting the keys into /etc/tor/keys, rather than putting them in /var (tmpfs on OpenWRT)
* using fixed values for should_rebuild_md_cache() && router_should_rebuild_store()
* reducing the age of microdesc (changing the compile time defines)
* using gzipped files for storing cache
I am including the files here as one ticket item rather than 5, but it might make sense to break them up into separate issues.
The source for these changes is the TorWRT package from Access Labs: https://accesslabs.org/wiki/TorWRTTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/7590[PATCH] New option LocalOutboundBindAddress2020-06-13T14:25:18ZTrac[PATCH] New option LocalOutboundBindAddressLocalOutboundBindAddress works just like OutboundBindAddress, but instead of excluding connections to loopback addresses, it affects only connections to loopback addresses.
(This is a patch to the git head.)
[1/2] https://lists.torproj...LocalOutboundBindAddress works just like OutboundBindAddress, but instead of excluding connections to loopback addresses, it affects only connections to loopback addresses.
(This is a patch to the git head.)
[1/2] https://lists.torproject.org/pipermail/tor-dev/2012-November/004177.html
[2/2] https://lists.torproject.org/pipermail/tor-dev/2012-November/004176.html
**Trac**:
**Username**: acTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7747SENDME doesn't need to trigger packaging so aggressively2020-06-13T14:25:43ZNick MathewsonSENDME doesn't need to trigger packaging so aggressivelyRight now when we process a relay sendme cell, that triggers an attempt to package the stream's inbuf. But that's needlessly aggressive. We could instead have it only attempt to package the stream's inbuf when the window was previously...Right now when we process a relay sendme cell, that triggers an attempt to package the stream's inbuf. But that's needlessly aggressive. We could instead have it only attempt to package the stream's inbuf when the window was previously 0, right?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/8453Alter flag-weight balancing equations2020-06-13T14:30:44ZMike PerryAlter flag-weight balancing equationsI have a few things I want to do to the flag-weight equations. This ticket will eventually be the parent ticket, but for now it's just a brain-dump:
1. I definitely want to correct the balancing issues discussed in #8240.
2. I might wan...I have a few things I want to do to the flag-weight equations. This ticket will eventually be the parent ticket, but for now it's just a brain-dump:
1. I definitely want to correct the balancing issues discussed in #8240.
2. I might want to account for changes due to directory guards (#7757).
3. I might want to factor in an optional Guard/Middle padding parameter. (#7028)
4. I might want to factor in an estimate of hidden service traffic somehow.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/8897Faster curve25519 implementation for ntor2020-06-13T14:29:13ZNick MathewsonFaster curve25519 implementation for ntorFloodberry's curve25519 implementations at https://github.com/floodyberry/curve25519-donna are mostly C, and claim to be faster still than the ones we're using now, especially on intel cpus. We should evaluate them and consider switchin...Floodberry's curve25519 implementations at https://github.com/floodyberry/curve25519-donna are mostly C, and claim to be faster still than the ones we're using now, especially on intel cpus. We should evaluate them and consider switching.
Also, if we find an ed25519 implementation we like and wind up using it, we should evaluate using its component pieces to build an optimized curve25519 implementation for calculations on the base point as per http://www.imperialviolet.org/2013/05/10/fastercurve25519.html ; Adam has some example code based on one of the amd64 assembly implementations.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/12377Prefer default route when checking local interface addresses2020-06-13T14:36:49Zrl1987Prefer default route when checking local interface addressesFirst, let us assume that all network interfaces for IP host that runs Tor instance are internal as judged by `tor_addr_is_internal()` function.
There is the following code in `get_interface_address6()` function.
```
/* Try to do thi...First, let us assume that all network interfaces for IP host that runs Tor instance are internal as judged by `tor_addr_is_internal()` function.
There is the following code in `get_interface_address6()` function.
```
/* Try to do this the smart way if possible. */
if ((addrs = get_interface_addresses_raw(severity))) {
int rv = -1;
SMARTLIST_FOREACH_BEGIN(addrs, tor_addr_t *, a) {
if (family != AF_UNSPEC && family != tor_addr_family(a))
continue;
if (tor_addr_is_loopback(a) ||
tor_addr_is_multicast(a))
continue;
tor_addr_copy(addr, a);
rv = 0;
/* If we found a non-internal address, declare success. Otherwise,
* keep looking. */
if (!tor_addr_is_internal(a, 0))
break;
} SMARTLIST_FOREACH_END(a);
SMARTLIST_FOREACH(addrs, tor_addr_t *, a, tor_free(a));
smartlist_free(addrs);
return rv;
}
```
Caller will get the last entry from a interface address smartlist. Is this okay?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/12600Save retrieved bridge information in our state file2020-06-13T14:37:31ZGeorge KadianakisSave retrieved bridge information in our state fileCurrently, Tor clients don't remember anything about bridges after a restart.
So for example, if there was a torrc Bridge line without a fingerprint specified, and Tor retrieves the fingerprint from the descriptor, it won't save it on th...Currently, Tor clients don't remember anything about bridges after a restart.
So for example, if there was a torrc Bridge line without a fingerprint specified, and Tor retrieves the fingerprint from the descriptor, it won't save it on the disk.
Or, if a bridge changed IP:PORT, but we managed to get its new ip:port using the bridge authority (see #12599), we will not save this down either.
Fortunately, Sebastian wrote proposal192 about this issue:
https://gitweb.torproject.org/torspec.git/tree/proposals/192-store-bridge-information.txt
We should re-read the proposal, revise it as needed and implement it.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/13112Some things are probably broken when we advertise multiple ORPorts and only s...2020-06-13T14:38:30ZAndrea ShepardSome things are probably broken when we advertise multiple ORPorts and only some are reachableObservations on reachability testing made while fixing #12160:
- We only have a 1-bit notion of reachability; if we get an incoming non-local connection, we assume reachability in onionskin_answer() and call router_orport_found_reachab...Observations on reachability testing made while fixing #12160:
- We only have a 1-bit notion of reachability; if we get an incoming non-local connection, we assume reachability in onionskin_answer() and call router_orport_found_reachable() to publish a descriptor.
- We should have a reachability bit per *advertised* ORPort to determine its inclusion in the published descriptor, and publish if and only if we have one or more reachable ORPorts.
- To implement this, we need a way to link incoming testing circuits to a particular advertised ORPort; we don't know this from the port the underlying channel was listening on because reverse proxies might make this not one-to-one in general.
- Arma suggests in IRC that netinfo cells know the IP the connection was attempted on and if they were extended with a port number they might provide a sufficient mechanism.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/13258Keep stats on effectiveness of consensus diffs2020-06-13T14:39:07ZSebastian HahnKeep stats on effectiveness of consensus diffsWe could have all dir mirrors report how many clients they've seen requesting diffs to a consensus X hours old. That way, we could fine-tune the amount of time dir mirrors have to store old diffs, and we could estimate how much of a win ...We could have all dir mirrors report how many clients they've seen requesting diffs to a consensus X hours old. That way, we could fine-tune the amount of time dir mirrors have to store old diffs, and we could estimate how much of a win they are in general.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/14039Many unnecessary CPU wakeups per second2020-06-13T14:41:23ZTracMany unnecessary CPU wakeups per secondPowerTOP shows Tor waking up 10 times per second even when it’s doing nothing. This is bad for power usage on a laptop because it prevents the CPU from entering its deepest sleep states. It looks like the reason is the default TokenBuc...PowerTOP shows Tor waking up 10 times per second even when it’s doing nothing. This is bad for power usage on a laptop because it prevents the CPU from entering its deepest sleep states. It looks like the reason is the default TokenBucketRefillInterval of 100 msec (#3630). Perhaps this logic can be refactored so that `refill_timer` is only activated when there are buckets to be refilled.
**Trac**:
**Username**: anderskTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15059Allow UI to identify servers by Ed25519 keys2020-06-13T14:43:49ZNick MathewsonAllow UI to identify servers by Ed25519 keysEverything that currently allows users to identify servers by fingerprint, such as various torrc options and the .exit syntax, should allow Ed25519 keys as well.Everything that currently allows users to identify servers by fingerprint, such as various torrc options and the .exit syntax, should allow Ed25519 keys as well.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15940Make a standard transition plan for killing off a client version2020-06-13T14:45:53ZteorMake a standard transition plan for killing off a client versionParent ticket for transitioning current and future client versions off the tor network with a minimal amount of pain.Parent ticket for transitioning current and future client versions off the tor network with a minimal amount of pain.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15941Form a plan for killing off client versions which assume they'll live forever2020-06-13T14:45:54ZteorForm a plan for killing off client versions which assume they'll live foreverFrom at least 0.2.4 to 0.2.6, tor client versions assume that they will keep on using the network forever. They have no "request to stop" code or other mechanisms that prevent them becoming a drain on the network.
It would help to plan ...From at least 0.2.4 to 0.2.6, tor client versions assume that they will keep on using the network forever. They have no "request to stop" code or other mechanisms that prevent them becoming a drain on the network.
It would help to plan their transition out at some point, so we can work out what to do to make version obsolescence in future.
See #15233 for killing off 0.2.2 and 0.2.3Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16106Sandbox causes crash when creating a hidden service through the control port2020-06-13T15:34:26ZMicah LeeSandbox causes crash when creating a hidden service through the control portI'm trying to squash a bug with running OnionShare in Tails and I've narrowed it down to a bug in the Tor server in sandbox mode. Here's the related OnionShare issue: https://github.com/micahflee/onionshare/issues/179
Here's a simple sc...I'm trying to squash a bug with running OnionShare in Tails and I've narrowed it down to a bug in the Tor server in sandbox mode. Here's the related OnionShare issue: https://github.com/micahflee/onionshare/issues/179
Here's a simple script that creates a hidden service using the Tor control port, with stem and flask:
```
import os
from stem.control import Controller
from flask import Flask
def main():
# set up flask
app = Flask("example")
@app.route('/')
def index():
return "<h1>Testing Tor sandbox!</h1>"
# set up hidden service
controller = Controller.from_port()
controller.authenticate()
hs_dir = '/tmp/bugtest'
print "Creating our hidden service in %s" % hs_dir
controller.set_options([
('HiddenServiceDir', hs_dir),
('HiddenServicePort', '80 127.0.0.1:5000')
])
onion = open(hs_dir + "/hostname", "r").read().strip()
print 'Running on {0}'.format(onion)
# start web app
app.run(port=5000)
if __name__ == '__main__':
main()
```
(Note that you need to manually delete /tmp/bugtest before running this script a second time.)
If you set "Sandbox 0" in torrc and run this script, it works great, and the output looks like this:
```
user@dev:~/code/tor-sandbox-hs-bug$ sudo python tor-sandbox-hs-bug.py
Creating our hidden service in /tmp/bugtest
Running on 3ekculjvzye6zr6s.onion
* Running on http://127.0.0.1:5000/
127.0.0.1 - - [18/May/2015 15:37:56] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2015 15:37:59] "GET /favicon.ico HTTP/1.1" 404 -
```
But if you set "Sandbox 1" in torrc and run the same script again, the script throws an exception and tor crashes:
```
user@dev:~/code/tor-sandbox-hs-bug$ sudo python tor-sandbox-hs-bug.py
Creating our hidden service in /tmp/bugtest
Traceback (most recent call last):
File "tor-sandbox-hs-bug.py", line 32, in <module>
main()
File "tor-sandbox-hs-bug.py", line 22, in main
('HiddenServicePort', '80 127.0.0.1:5000')
File "/usr/lib/python2.7/dist-packages/stem/control.py", line 1859, in set_options
response = self.msg(query)
File "/usr/lib/python2.7/dist-packages/stem/control.py", line 469, in msg
raise exc
stem.SocketClosed: Received empty socket content.
```
Here's what ends up in the tor log:
```
May 18 15:38:48.000 [notice] New control connection opened from 127.0.0.1.
May 18 15:38:48.000 [notice] Tor 0.2.5.12 (git-3731dd5c3071dcba) opening log file.
May 18 15:38:48.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /tmp/bugtest
May 18 15:38:48.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /tmp/bugtest/private_key
May 18 15:38:48.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /tmp/bugtest/private_key.tmp
============================================================ T= 1431988728
(Sandbox) Caught a bad syscall attempt (syscall open)
/usr/bin/tor(+0x128176)[0x7f1391729176]
/lib/x86_64-linux-gnu/libpthread.so.0(open64+0x10)[0x7f13901fa1d0]
/lib/x86_64-linux-gnu/libpthread.so.0(open64+0x10)[0x7f13901fa1d0]
/usr/bin/tor(tor_open_cloexec+0x40)[0x7f1391715380]
/usr/bin/tor(start_writing_to_file+0xf2)[0x7f1391724182]
/usr/bin/tor(+0x1232eb)[0x7f13917242eb]
/usr/bin/tor(+0x123438)[0x7f1391724438]
/usr/bin/tor(crypto_pk_write_private_key_to_filename+0xcb)[0x7f1391731b6b]
/usr/bin/tor(init_key_from_file+0x172)[0x7f1391668302]
/usr/bin/tor(+0x5a36e)[0x7f139165b36e]
/usr/bin/tor(rend_service_load_all_keys+0x81)[0x7f139165d451]
/usr/bin/tor(set_options+0xc5f)[0x7f13916bff5f]
/usr/bin/tor(options_trial_assign+0xbb)[0x7f13916c14fb]
/usr/bin/tor(+0xdbe2e)[0x7f13916dce2e]
/usr/bin/tor(connection_control_process_inbuf+0x776)[0x7f13916e1056]
/usr/bin/tor(+0xcbd95)[0x7f13916ccd95]
/usr/bin/tor(+0x34a21)[0x7f1391635a21]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc)[0x7f1390c8a3dc]
/usr/bin/tor(do_main_loop+0x194)[0x7f1391637204]
/usr/bin/tor(tor_main+0x1705)[0x7f139163a035]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f138fc5fb45]
/usr/bin/tor(+0x3279b)[0x7f139163379b]
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16387Improve reachability of hidden services on mobile phones2020-06-13T14:59:04ZGeorge KadianakisImprove reachability of hidden services on mobile phonesMobile phones are unstable and their IP changes all the time. Hidden services don't work well on them.
Here are some things that can go wrong when the mobile phone (and hence the HS) loses network or changes its IP address:
- The circu...Mobile phones are unstable and their IP changes all the time. Hidden services don't work well on them.
Here are some things that can go wrong when the mobile phone (and hence the HS) loses network or changes its IP address:
- The circuits to the intro points get broken, the HS establishes new intro points and republishes its descriptor. Its clients are not aware of the new intro points, and keep on trying the old ones. This is #8239 which might be fixed soon.
- The rendezvous circuits to current clients get broken, and the HS does not reestablish them. Then clients keep on trying the same broken rendezvous point on and on, instead of re-introducing themselves (or fetching a new descriptor entirely). We should verify that this behavior is broken, and think of better ones here.
A related thread can be found on [tor-dev] here:
https://lists.torproject.org/pipermail/tor-dev/2015-May/008841.htmlTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17193Don't print bridge IPs/fingerprints in WARN/NOTICE log messages2020-06-13T14:49:42ZIsis LovecruftDon't print bridge IPs/fingerprints in WARN/NOTICE log messagesBy default, we currently print out bridge IP:ports and fingerprints in tor's log messages at the notice and warn levels. Users often [copy+paste these logs to various public places](https://lists.torproject.org/pipermail/tor-talk/2015-Se...By default, we currently print out bridge IP:ports and fingerprints in tor's log messages at the notice and warn levels. Users often [copy+paste these logs to various public places](https://lists.torproject.org/pipermail/tor-talk/2015-September/039143.html) when trying to debug why their connection isn't working.
I understand that this is probably useful information to give to the support desk for debugging why tor isn't working… but would it be doable to have the support people ask, _"Hey could you add `SafeLogging 0` to your torrc?"_ or something?
I think the default should be to sanitise bridge IP:ports and fingerprints at these levels.Tor: unspecified