The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:39:23Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18691Switch rbm VMs for Windows to those used for our macOS cross-builds2020-06-27T14:39:23ZGeorg KoppenSwitch rbm VMs for Windows to those used for our macOS cross-buildsWe should switch the `rbm` VMs for Windows to the ones used for our macOS cross-builds. This should simplify our setup and would provide us with better build tools.We should switch the `rbm` VMs for Windows to the ones used for our macOS cross-builds. This should simplify our setup and would provide us with better build tools.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18690Switch Gitian VMs to Debian Wheezy for OS X2020-06-27T14:39:23ZGeorg KoppenSwitch Gitian VMs to Debian Wheezy for OS XNow, after legacy/trac#18127 landed, we should start getting rid of our Ubuntu Precise VMs for OS X and Windows as well. This would simplify a bunch of things in our setup and would provide us with slightly newer build tools.
This is th...Now, after legacy/trac#18127 landed, we should start getting rid of our Ubuntu Precise VMs for OS X and Windows as well. This would simplify a bunch of things in our setup and would provide us with slightly newer build tools.
This is the OS X ticket.https://gitlab.torproject.org/tpo/core/tor/-/issues/18689Fallback Directory Selection should exclude down relays earlier2020-06-27T13:59:19ZteorFallback Directory Selection should exclude down relays earlierThe updateFallbackDirs.py script uses OnionOO to find a list of candidate directory mirrors, then checks the consensus download speed from each mirror.
Previously, the script allowed relays that had a good uptime history, but just happe...The updateFallbackDirs.py script uses OnionOO to find a list of candidate directory mirrors, then checks the consensus download speed from each mirror.
Previously, the script allowed relays that had a good uptime history, but just happened to be down right now.
But this doesn't work any more, because those relays can't provide a consensus, so we exclude them in the final consensus download check.
We could be smarter, and avoid the effort of that check by eliminating relays that aren't running right now from the list of fallback candidates.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18688Relays should disable DirPort if RelayBandwidthRate is less than 50kb/s2020-06-27T13:59:19ZteorRelays should disable DirPort if RelayBandwidthRate is less than 50kb/sWhile I was checking fallback directory mirrors for legacy/trac#17158, I encountered some relays that took more than a minute to serve a consensus.
Most took 150 seconds, which could be caused by a RelayBandwidthRate of 10 kilobytes a s...While I was checking fallback directory mirrors for legacy/trac#17158, I encountered some relays that took more than a minute to serve a consensus.
Most took 150 seconds, which could be caused by a RelayBandwidthRate of 10 kilobytes a second.
I suggest that we disable the DirPort on relays with a RelayBandwidthRate less than 50 kilobytes a second (30s to serve a consensus).
This is an incomplete list, starting with those with the highest consensus weight:
217.198.117.122:80
212.47.250.44:80
158.69.112.86:80
50.7.178.34:80
191.101.251.172:80
51.254.249.177:80
188.165.232.40:80
104.236.38.231:8080
89.163.225.184:9030
185.31.230.69:9030
81.7.14.227:9030
62.210.238.33:9030
164.132.56.137:9030
212.107.149.145:9030
94.23.165.33:9031
I'm using this python function from scripts/maint/updateFallbackDirs.py (not yet merged to master) to find them:
```
from stem.descriptor.remote import DescriptorDownloader
def fallback_consensus_dl_speed(dirip, dirport, nickname, max_time):
download_failed = False
downloader = DescriptorDownloader()
start = datetime.datetime.utcnow()
# some directory mirrors respond to requests in ways that hang python
# sockets, which is why we long this line here
logging.info('Initiating consensus download from %s (%s:%d).', nickname,
dirip, dirport)
# there appears to be about 1 second of overhead when comparing stem's
# internal trace time and the elapsed time calculated here
TIMEOUT_SLOP = 1.0
try:
downloader.get_consensus(endpoints = [(dirip, dirport)],
timeout = (max_time + TIMEOUT_SLOP)).run()
except Exception, stem_error:
logging.info('Unable to retrieve a consensus from %s: %s', nickname,
exc)
download_failed = True
elapsed = (datetime.datetime.utcnow() - start).total_seconds()
if elapsed > max_time:
status = 'too slow'
level = logging.WARNING
download_failed = True
else:
status = 'ok'
level = logging.DEBUG
logging.log(level, 'Consensus download: %0.1fs %s from %s (%s:%d), ' +
'max download time %0.1fs.', elapsed, status, nickname,
dirip, dirport, max_time)
return download_failed
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18686tor port forwarding claims to kill long-dead forwarder2020-06-27T13:59:19ZTractor port forwarding claims to kill long-dead forwarderMar 30 09:36:07 h Tor[1243]: tor_check_port_forwarding(): Started port forwarding helper (.../bin/tor-fw-helper) with pid '5936'
Mar 30 09:36:09 h Tor[1243]: notify_waitpid_callback_by_pid(): Child process 5936 has exited; running callba...Mar 30 09:36:07 h Tor[1243]: tor_check_port_forwarding(): Started port forwarding helper (.../bin/tor-fw-helper) with pid '5936'
Mar 30 09:36:09 h Tor[1243]: notify_waitpid_callback_by_pid(): Child process 5936 has exited; running callback.
Mar 30 09:41:13 h Tor[1243]: Failed to terminate process with PID '5936' ('Success').
Mar 30 09:41:13 h Tor[1243]: tor_check_port_forwarding(): Started port forwarding helper (...bin/tor-fw-helper) with pid '5985'
Mar 30 09:41:15 h Tor[1243]: notify_waitpid_callback_by_pid(): Child process 5985 has exited; running callback.
Mar 30 09:46:19 h Tor[1243]: Failed to terminate process with PID '5985' ('Success').
Mar 30 09:46:19 h Tor[1243]: tor_check_port_forwarding(): Started port forwarding helper (.../bin/tor-fw-helper) with pid '6052'
Mar 30 09:46:21 h Tor[1243]: notify_waitpid_callback_by_pid(): Child process 6052 has exited; running callback.
Mar 30 09:51:25 h Tor[1243]: Failed to terminate process with PID '6052' ('Success').
Mar 30 09:51:25 h Tor[1243]: tor_check_port_forwarding(): Started port forwarding helper (.../bin/tor-fw-helper) with pid '8784'
Mar 30 09:51:27 h Tor[1243]: notify_waitpid_callback_by_pid(): Child process 8784 has exited; running callback.
Mar 30 09:56:31 h Tor[1243]: Failed to terminate process with PID '8784' ('Success').
Mar 30 09:56:31 h Tor[1243]: tor_check_port_forwarding(): Started port forwarding helper (.../bin/tor-fw-helper) with pid '8848'
Mar 30 09:56:33 h Tor[1243]: notify_waitpid_callback_by_pid(): Child process 8848 has exited; running callback.
Mar 30 10:01:37 h Tor[1243]: Failed to terminate process with PID '8848' ('Bad file descriptor').
tor_check_port_forwarding in util.c keeps a static process_handle_t . Before spawning the forwarder helper, it says it tries to kill previously-running instances.
The cause is that the killing function doesn't distinguish between between not needing to kill versus attempted and failed.
The resulting error message has a ugly, wrong error reason too.
**Trac**:
**Username**: chadmillerTor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18685Fire a`STATUS_SERVER` event when the hibernation state changes.2020-06-27T13:59:19ZYawning AngelFire a`STATUS_SERVER` event when the hibernation state changes.Most of the hibernation related information is already exposed in a useful manner via `GETINFO`. As far as I can tell the only really other useful thing to do here is to fire an event whenever we enter/exit hibernation so that controlle...Most of the hibernation related information is already exposed in a useful manner via `GETINFO`. As far as I can tell the only really other useful thing to do here is to fire an event whenever we enter/exit hibernation so that controllers don't have to poll continuously via `GETINFO`.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18681Include and activate "Self-Destructing Cookies" Firefox add-on by default in TBB2020-06-27T14:39:24ZcypherpunksInclude and activate "Self-Destructing Cookies" Firefox add-on by default in TBBVery relevant, extremely compact (<100kB), GPLv2 Firefox add-on that does not negatively affect clickprint (I think). Purges cookies from closed tabs after a specified number of seconds (default is 10 I believe). Can optionally display a...Very relevant, extremely compact (<100kB), GPLv2 Firefox add-on that does not negatively affect clickprint (I think). Purges cookies from closed tabs after a specified number of seconds (default is 10 I believe). Can optionally display a small notification of this purging event, which I disable.
https://addons.mozilla.org/en-US/firefox/addon/self-destructing-cookies/
I think that bundling this Add-On would be a big win for Tor Browser users and for privacy online.
Questions:
1. How does it behave between "Private Browsing"/"Never remember history" mode and normal browsing mode? In Firefox? In Tor Browser?
2. Are there any meaningful ways that this could create a UX problem? Obviously "Undo Close Tab" might suffer on a small minority of websites (probably VERY small), but this "problem" is not necessarily out of users' expectations anyway.
3. Are there any meaningful ways that this could be a privacy problem a la Panopticlick? "Normal" web browsers obviously soak up tracking cookies with abandon. One potential problem situation would be, say, on an e-commerce website, where a user adds items to their Cart and is identified both by cookie(s) and a unique coded URL, and they close the tab, then do Undo Close Tab back to their unique URL. That is obviously unusual behavior for a browser, from the site's perspective, but then, so is coming from a known Tor Exit Node. As long as all Tor Browser users behave more or less consistently, it shouldn't be a problem (akin to window size profiling issues). And even in edge cases, an adversary is not provided with many data points that can correlate or extrapolate to other websites or browser tabs readily.
With those questions in mind, I remain convinced that this would be a highly beneficial add-on to include in Tor Browser.
Action items:
1. Test the behavior of the Self-Destructing Cookies add-on in Tor Browser, in both History-saving mode and Never Remember History mode. Compare add-on notifications against local cookie jar directly (verify purging).
2. Brainstorm and seek out meaningful examples of when this behavior might negatively affect UX or user privacy. I cannot conceive of many, if any.
3. Make sure the thing doesn't actually try to use the network itself, or if it does, that it respects SOCKS and fails closed.
4. What do other people think? Is this actually a terrible idea for some reason?https://gitlab.torproject.org/tpo/core/tor/-/issues/18680Don't declare the symbol "incoming queue" in every file including channel.h2020-06-27T13:59:19ZNick MathewsonDon't declare the symbol "incoming queue" in every file including channel.hAccording to nm, we have the symbol "incoming_queue" defined in all kinds of tor files. Why? Because of this line in channel.h:
```
TOR_SIMPLEQ_HEAD(chan_cell_queue, cell_queue_entry_s) incoming_queue;
```
Trivial fix in my branch inc...According to nm, we have the symbol "incoming_queue" defined in all kinds of tor files. Why? Because of this line in channel.h:
```
TOR_SIMPLEQ_HEAD(chan_cell_queue, cell_queue_entry_s) incoming_queue;
```
Trivial fix in my branch incoming_queue_symbol_fixTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18679javascript: hrefs don't run at medium-high security level, even on an HTTPS page2020-06-27T14:39:24ZDavid Fifielddcf@torproject.orgjavascript: hrefs don't run at medium-high security level, even on an HTTPS pageOn this page, at the medium-high security level, the "Enter promotional code" link doesn't work. It's supposed to cause another DOM element to become visible.
https://www.eventbrite.com/e/rightscon-silicon-valley-2016-tickets-191580231...On this page, at the medium-high security level, the "Enter promotional code" link doesn't work. It's supposed to cause another DOM element to become visible.
https://www.eventbrite.com/e/rightscon-silicon-valley-2016-tickets-19158023163
It's because the link, rather than using an onclick handler or something, uses a javascript: URL in the href:
```
<a href="javascript: Hide('discountDiv1'); Show('discountDiv');">Enter promotional code</a>
```
They use the same technique for some other buttons, which are also broken. The JS actually works, as I can paste it into the browser console and it does what it's supposed to do.
It works if I reduce the security level to medium-low, so I suspect it's caused by Tor Browser not considering the javascript: URL to be in an HTTPS context or something.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18678FR: minus random number of pixels for full screen2020-06-27T14:39:24ZTracFR: minus random number of pixels for full screenwhen i maximize Tor to fullscreen, i get the message about leaving Tor at original size to prevent being tracked by my browser window size etc. when its fullscreen.
The problem is, by default the Tor window is not ideal for most pages d...when i maximize Tor to fullscreen, i get the message about leaving Tor at original size to prevent being tracked by my browser window size etc. when its fullscreen.
The problem is, by default the Tor window is not ideal for most pages display, so i still always need to increase the width of the window.
Would there not be a way to have a random size fullscreen mode, that just deducts a few pixels from actual fullscreen resolution,
say minus a random number between 1-50 pixels, so it gives a different browser window size each time.
not sure if i explain clear enough but i am sure you will get the picture
for example (without taking taskbars into account)
actual screen size 1920 x 1080
click Tor maximize
Tor expands to 1883 x 1062
click minimize then maximize again
and tor expands to 1907 x 1054
something like that,
this would allow users to have nearly fullscreen use, whilst always providing random browser window size to prevent tracking
**Trac**:
**Username**: gt5https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18677feature request: temporarily disable circuit isolation, because cloudflare2020-06-27T14:39:24Zcypherpunksfeature request: temporarily disable circuit isolation, because cloudflareI would like to be able to browse site B with the same exit and cookie jar etc as it would use if site B resources were included from site A.
Usecase:
* site A is archive.is (which is useful for bypassing cloudflare captchas)
* site B i...I would like to be able to browse site B with the same exit and cookie jar etc as it would use if site B resources were included from site A.
Usecase:
* site A is archive.is (which is useful for bypassing cloudflare captchas)
* site B is archive.li (which uses cloudflare itself, and is where archive.is hosts its images)
Lately I frequently see broken images on archive.is. When I right click and view image, sometimes the image loads and sometimes I get a captcha. I think I've solved the captcha and subsequently had images work on archive.is, but now that isn't happening and in retrospect I don't know how it could have because it would be violating the tab isolation feature if my captcha solving with archive.li in the location bar was able to make the broken images start working on archive.is.
So maybe there is some edge case where this feature is broken already, but I can't reproduce it.
But in any case I would like to be able to temporarily disable the rules (or perhaps be able to specify that I always want to use the archive.is context when archive.li is in my URL bar).https://gitlab.torproject.org/tpo/tpa/team/-/issues/18676relocate media.tp.o2020-06-27T14:19:31ZRoger Dingledinerelocate media.tp.oweasel asked for a volunteer to take responsibility for media.tp.o.
I think this is just a pile of files somewhere, right?
I want it to keep existing. I could even add files to it every so often.
So I think I am an ok maintainer for i...weasel asked for a volunteer to take responsibility for media.tp.o.
I think this is just a pile of files somewhere, right?
I want it to keep existing. I could even add files to it every so often.
So I think I am an ok maintainer for it.
Since Lunar has some outreach materials there too, maybe we should sign up Lunar as a second maintainer?
What needs to happen? I need a few more permissions, and we need to change a wiki page?
Does anybody know if there are cron jobs or anything that interact with media?
Is it backed up consistently?https://gitlab.torproject.org/tpo/core/tor/-/issues/18674Tor rejects [::]/8 and [::]/127 explicitly, but the latter is sometimes elimi...2020-07-27T19:10:04ZSebastian HahnTor rejects [::]/8 and [::]/127 explicitly, but the latter is sometimes eliminatedI suspect the rules that try to eliminate duplicates are at play here. I figured this out while trying to add tests for some getinfo exit-policy queries.I suspect the rules that try to eliminate duplicates are at play here. I figured this out while trying to add tests for some getinfo exit-policy queries.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18673Memory leak with TestingEnableCellStatsEvent2020-06-27T13:59:19ZNick MathewsonMemory leak with TestingEnableCellStatsEventRunning chutney with asan, I see:
```
=================================================================
==13895==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1040 byte(s) in 65 object(s) allocated from:
#0 0x55db7087d...Running chutney with asan, I see:
```
=================================================================
==13895==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1040 byte(s) in 65 object(s) allocated from:
#0 0x55db7087dacb in __interceptor_malloc llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
#1 0x55db70d23dd2 in tor_malloc_ /home/nickm/src/tor/src/common/util.c:171:12
#2 0x55db70cf4847 in smartlist_new /home/nickm/src/tor/src/common/container.c:34:21
#3 0x55db7093e34d in channel_flush_from_first_active_circuit /home/nickm/src/tor/src/or/relay.c:2652:38
#4 0x55db70a6bd22 in channel_flush_some_cells /home/nickm/src/tor/src/or/channel.c:2215:30
#5 0x55db70a35810 in scheduler_run /home/nickm/src/tor/src/or/scheduler.c:421:13
#6 0x55db70a35060 in scheduler_evt_callback /home/nickm/src/tor/src/or/scheduler.c:234:3
#7 0x7f8baa215178 in event_base_loop (/lib64/libevent-2.0.so.5+0x10178)
Indirect leak of 37376 byte(s) in 23 object(s) allocated from:
#0 0x55db7087de1e in realloc llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:61:3
#1 0x55db70d242dc in tor_realloc_ /home/nickm/src/tor/src/common/util.c:259:12
#2 0x55db70d24550 in tor_reallocarray_ /home/nickm/src/tor/src/common/util.c:280:10
#3 0x55db70cf509f in smartlist_ensure_capacity /home/nickm/src/tor/src/common/container.c:87:16
#4 0x55db70cf4df1 in smartlist_add /home/nickm/src/tor/src/common/container.c:101:3
#5 0x55db7093e3ac in channel_flush_from_first_active_circuit /home/nickm/src/tor/src/or/relay.c:2653:9
#6 0x55db70a6bd22 in channel_flush_some_cells /home/nickm/src/tor/src/or/channel.c:2215:30
#7 0x55db70a35810 in scheduler_run /home/nickm/src/tor/src/or/scheduler.c:421:13
#8 0x55db70a35060 in scheduler_evt_callback /home/nickm/src/tor/src/or/scheduler.c:234:3
#9 0x7f8baa215178 in event_base_loop (/lib64/libevent-2.0.so.5+0x10178)
Indirect leak of 18636 byte(s) in 4659 object(s) allocated from:
#0 0x55db7087dacb in __interceptor_malloc llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
#1 0x55db70d23dd2 in tor_malloc_ /home/nickm/src/tor/src/common/util.c:171:12
#2 0x55db70d23f6f in tor_malloc_zero_ /home/nickm/src/tor/src/common/util.c:197:18
#3 0x55db7093e195 in channel_flush_from_first_active_circuit /home/nickm/src/tor/src/or/relay.c:2645:11
#4 0x55db70a6bd22 in channel_flush_some_cells /home/nickm/src/tor/src/or/channel.c:2215:30
#5 0x55db70a35810 in scheduler_run /home/nickm/src/tor/src/or/scheduler.c:421:13
#6 0x55db70a35060 in scheduler_evt_callback /home/nickm/src/tor/src/or/scheduler.c:234:3
#7 0x7f8baa215178 in event_base_loop (/lib64/libevent-2.0.so.5+0x10178)
Indirect leak of 5376 byte(s) in 42 object(s) allocated from:
#0 0x55db7087dacb in __interceptor_malloc llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
#1 0x55db70d23dd2 in tor_malloc_ /home/nickm/src/tor/src/common/util.c:171:12
#2 0x55db70d240a4 in tor_malloc_zero_ /home/nickm/src/tor/src/common/util.c:197:18
#3 0x55db70d240a4 in tor_calloc_ /home/nickm/src/tor/src/common/util.c:235
#4 0x55db70cf48f7 in smartlist_new /home/nickm/src/tor/src/common/container.c:37:14
#5 0x55db7093e34d in channel_flush_from_first_active_circuit /home/nickm/src/tor/src/or/relay.c:2652:38
#6 0x55db70a6bd22 in channel_flush_some_cells /home/nickm/src/tor/src/or/channel.c:2215:30
#7 0x55db70a35810 in scheduler_run /home/nickm/src/tor/src/or/scheduler.c:421:13
#8 0x55db70a35060 in scheduler_evt_callback /home/nickm/src/tor/src/or/scheduler.c:234:3
#9 0x7f8baa215178 in event_base_loop (/lib64/libevent-2.0.so.5+0x10178)
SUMMARY: AddressSanitizer: 62428 byte(s) leaked in 4789 allocation(s).
```
Now, this only seems to happen with TestingEnableCellStatsEvent enabled, so it's not a showstopper on the real network, but it's no fun. We should fix this leak.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18672Make test-network and test-stem begin with asan turned on2020-06-27T13:59:19ZNick MathewsonMake test-network and test-stem begin with asan turned onWhen I `--enable-expensive-hardening`, there are are some memory leaks in the helper commands that prevent the test scripts from starting.When I `--enable-expensive-hardening`, there are are some memory leaks in the helper commands that prevent the test scripts from starting.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18670Tor Browser unresponsive2020-06-27T14:39:24ZTracTor Browser unresponsiveTor Browser becomes unresponsive when visiting certain webpages.
Example: blog.tenstringguitar.info
**Trac**:
**Username**: jfsaiTor Browser becomes unresponsive when visiting certain webpages.
Example: blog.tenstringguitar.info
**Trac**:
**Username**: jfsaihttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18669Tor Browser unresponsive, at certain websites2020-06-27T14:39:24ZTracTor Browser unresponsive, at certain websitesCertain websites (primarily blogs) make the Tor Browser completely unresponsive.
Example: http://blog.tenstringguitar.info/
**Trac**:
**Username**: jfsaiCertain websites (primarily blogs) make the Tor Browser completely unresponsive.
Example: http://blog.tenstringguitar.info/
**Trac**:
**Username**: jfsaihttps://gitlab.torproject.org/tpo/core/tor/-/issues/18668Numerous WSAStartup warnings in unit tests on windows2020-06-27T13:59:20ZNick MathewsonNumerous WSAStartup warnings in unit tests on windowsHead on over to Jenkins, and look at the windows builder output. It's complaining a lot that we aren't calling WSAStartup. We should fix that.
It's not causing bugs or preventing the tests from passing, but it sure is ugly.Head on over to Jenkins, and look at the windows builder output. It's complaining a lot that we aren't calling WSAStartup. We should fix that.
It's not causing bugs or preventing the tests from passing, but it sure is ugly.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18667Manual on website doesn't render ipv6 addresses right2020-06-27T13:59:20ZSebastian HahnManual on website doesn't render ipv6 addresses rightI couldn't immediately reproduce the issue locally, will have to investigate. To see what I mean:
```
To specify all IPv4 and IPv6 internal and link-local networks (including 0.0.0.0/8, 169.254.0.0/16, 127.0.0.0/8, 192.168.0.0/16, 10.0....I couldn't immediately reproduce the issue locally, will have to investigate. To see what I mean:
```
To specify all IPv4 and IPv6 internal and link-local networks (including 0.0.0.0/8, 169.254.0.0/16, 127.0.0.0/8, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, [::]/8, /7, /10, /10, /8, and [::]/127), you can use the "private" alias instead of an address. ("private" always produces rules for IPv4 and IPv6 addresses, even when used with accept6/reject6.)
```Tor: 0.2.9.x-finalSebastian HahnSebastian Hahnhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18665Make test_util_time pieces pass on windows2022-06-17T18:43:09ZNick MathewsonMake test_util_time pieces pass on windowsThere are some pieces in test_util_time that I disabled to make the tests pass. Presumably these never worked on Windows; but we should re-enable them and make them work.There are some pieces in test_util_time that I disabled to make the tests pass. Presumably these never worked on Windows; but we should re-enable them and make them work.