The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:18:46Zhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/25829Make chutney ignore "Valid-After times do not match"2020-06-27T13:18:46ZteorMake chutney ignore "Valid-After times do not match"We need to ignore this Tor warning in chutney:
Warning: Unable to add signatures to consensus: Valid-After times do not match when adding detached signatures to consensus Number: 2
It's not a bug, it only happens occasionally, and...We need to ignore this Tor warning in chutney:
Warning: Unable to add signatures to consensus: Valid-After times do not match when adding detached signatures to consensus Number: 2
It's not a bug, it only happens occasionally, and only in tor 0.3.3 and later.https://gitlab.torproject.org/tpo/tpa/team/-/issues/25796Update spec.torproject.org for new specs2020-06-27T14:18:18ZteorUpdate spec.torproject.org for new specsThere are 4 new specs, and one has moved.
It would also be nice to map proposals/
Is this an automated process, or does it need a manual patch?There are 4 new specs, and one has moved.
It would also be nice to map proposals/
Is this an automated process, or does it need a manual patch?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25786Policies for HTTPTunnelPort2021-09-16T14:30:52ZTracPolicies for HTTPTunnelPortFor SocksPort/Socks5Port one can configure SocksPolicy.
There should be corresponding option for HTTPTunnelPort.
**Trac**:
**Username**: pyhedgehogFor SocksPort/Socks5Port one can configure SocksPolicy.
There should be corresponding option for HTTPTunnelPort.
**Trac**:
**Username**: pyhedgehoghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25784Misleading error message when asking for IPv6 in a network with no IPv6-capab...2020-07-28T19:09:59ZpastlyMisleading error message when asking for IPv6 in a network with no IPv6-capable exitsI created a small test Tor network. 3 authorities, 7 relays, 3 exits. Great.
I didn't set `IPv6Exit 1` on any of the exits.
I had a client try to request `::1` over this Tor network on a hand crafted circuit (it makes sense to ask an e...I created a small test Tor network. 3 authorities, 7 relays, 3 exits. Great.
I didn't set `IPv6Exit 1` on any of the exits.
I had a client try to request `::1` over this Tor network on a hand crafted circuit (it makes sense to ask an exit to connect to localhost when this is all local ... trust me). I got the following confusing error message on the client.
> [warn] I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's not going to work. Did you perhaps ask for an IPv6 address on an IPv4Only port, or vice versa?
I think it's important to point out (again) that I was hand crafting these circuits and was not considering IPv6 support. That said, I don't know what Tor would do if I let it make the circuit for me and it couldn't find an IPv6-supporting exit.
As you can see, I'm talking myself out of this being a bug and it just being me screwing things up for myself. I was encouraged to make a ticket though, so here we are.
If rewriting the error message is the solution, maybe after fixing the "fulfil" typo, we should add "It's also possible we couldn't find any exits supporting the IP version you want to use"
I'm picking 0.3.5.x-final just because I've been told you have to pick a milestone or else your tickets generally fall through the cracks. :)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25720man: RephistTrackTime is not a dirauth only option2021-07-22T16:20:51ZDavid Gouletdgoulet@torproject.orgman: RephistTrackTime is not a dirauth only optionWe should move the `RephistTrackTime` man page entry to the server side options because every node use it when dumping stats on a SIGUSR1.We should move the `RephistTrackTime` man page entry to the server side options because every node use it when dumping stats on a SIGUSR1.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25661RendPostPeriod and HiddenServiceAuthorizeClient are v2 only2021-09-30T13:46:29ZteorRendPostPeriod and HiddenServiceAuthorizeClient are v2 onlyRendPostPeriod and HiddenServiceAuthorizeClient only apply to v2 onion services. We should update the man page so this is clearer.RendPostPeriod and HiddenServiceAuthorizeClient only apply to v2 onion services. We should update the man page so this is clearer.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/25660Remove "New Private Window" option from Tor Browser or make it a separate ses...2023-02-02T09:30:38ZstephwRemove "New Private Window" option from Tor Browser or make it a separate sessionIt doesn't do anything that I can tell. If it does, we should have more of an explanation to set user expectation.
For instance, I thought perhaps when I was logged into Twitter in another tab, it might isolate a separate session, but i...It doesn't do anything that I can tell. If it does, we should have more of an explanation to set user expectation.
For instance, I thought perhaps when I was logged into Twitter in another tab, it might isolate a separate session, but it does not. If I go to twitter.com in a "New Private Window", I am still logged into the same account.https://gitlab.torproject.org/tpo/core/tor/-/issues/25645n_possible variable goes unused in channel_get_for_extend()2020-06-27T13:53:50ZRoger Dingledinen_possible variable goes unused in channel_get_for_extend()```
$ grep n_possible *.c
channel.c: int n_noncanonical = 0, n_possible = 0;
channel.c: ++n_possible;
```
All we do is start it off at 0, and increment it sometimes.
Maybe it had a purpose once, but it doesn't anymore.```
$ grep n_possible *.c
channel.c: int n_noncanonical = 0, n_possible = 0;
channel.c: ++n_possible;
```
All we do is start it off at 0, and increment it sometimes.
Maybe it had a purpose once, but it doesn't anymore.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25618Document ISO_STREAM in the tor man page2021-07-22T16:20:50ZteorDocument ISO_STREAM in the tor man pageTor applies stream isolation by default: each new origin stream gets a new circuit.
This means that the default behaviour of Tor is stricter than IsolateDestAddr and IsolateDestPort, because each different destination address or port ne...Tor applies stream isolation by default: each new origin stream gets a new circuit.
This means that the default behaviour of Tor is stricter than IsolateDestAddr and IsolateDestPort, because each different destination address or port needs a new stream.
We should document this in the tor man page under the SOCKSPort option.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25530Closing Tor cleanly from command line (when started from command line) on win322020-07-28T18:48:06ZTracClosing Tor cleanly from command line (when started from command line) on win32When I close Tor after a session being started through Tor Browser, I see the log:
```
Mar 11 02:21:08.000 [notice] Owning controller connection has closed -- exiting now.
Mar 11 02:21:08.000 [notice] Catching signal TERM, exiting clean...When I close Tor after a session being started through Tor Browser, I see the log:
```
Mar 11 02:21:08.000 [notice] Owning controller connection has closed -- exiting now.
Mar 11 02:21:08.000 [notice] Catching signal TERM, exiting cleanly.
```
I think there's some operations Tor does in order to close it self cleanly.
I usually run Tor over command line (_**Windows 10**_) through:
```
cd "C:\Tor Browser\Browser\"
"C:\Tor Browser\Browser\TorBrowser\Tor\tor.exe" -f "C:\Tor Browser\Browser\TorBrowser\Data\Tor\torrc" | more
```
I just kill the _tor.exe_ process in order to close it. I don't get those two logs.
How could I close Tor cleanly through command line?
**Trac**:
**Username**: omareg94Tor: unspecifiedhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25472snowflake-client's `-url` option is intolerant of a missing path2020-06-27T13:40:39ZDavid Fifielddcf@torproject.orgsnowflake-client's `-url` option is intolerant of a missing pathI was following [server-webrtc's README](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/server-webrtc/README.md?id=ff8f3851082e8f7f8b4c8b99b161be35020aeb67) and I made a small mistake in the client torrc. Instead o...I was following [server-webrtc's README](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/server-webrtc/README.md?id=ff8f3851082e8f7f8b4c8b99b161be35020aeb67) and I made a small mistake in the client torrc. Instead of
```
-url http://127.0.0.1:8080/
```
I had (no trailing slash):
```
-url http://127.0.0.1:8080
```
This caused the client to fail with this error:
```
2018/03/13 03:10:40 Negotiating via BrokerChannel...
Target URL:
Front URL: 127.0.0.1:8080
2018/03/13 03:10:40 BrokerChannel Error: dial tcp: unknown port tcp/8080client
2018/03/13 03:10:40 Failed to retrieve answer. Retrying in 10 seconds
```
This is because the URL to request is built using string concatenation. It built the string `"http://127.0.0.1:8080client"` instead of `"http://127.0.0.1:8080/client"`.
https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/rendezvous.go?id=ff8f3851082e8f7f8b4c8b99b161be35020aeb67#n83
```
request, err := http.NewRequest("POST", bc.url.String()+"client", data)
```https://gitlab.torproject.org/tpo/core/tor/-/issues/25432remove router.c internal functions from router.h2021-09-16T14:31:19ZTracremove router.c internal functions from router.hThese functions (group A):
```
A
const char *router_get_description(char *buf, const routerinfo_t *ri);
const char *node_get_description(char *buf, const node_t *node);
const char *routerstatus_get_description(char *buf, const routerstat...These functions (group A):
```
A
const char *router_get_description(char *buf, const routerinfo_t *ri);
const char *node_get_description(char *buf, const node_t *node);
const char *routerstatus_get_description(char *buf, const routerstatus_t *rs);
const char *extend_info_get_description(char *buf, const extend_info_t *ei);
```
Do the same as these (group B):
```
B
const char *router_describe(const routerinfo_t *ri);
const char *node_describe(const node_t *node);
const char *routerstatus_describe(const routerstatus_t *ri);
const char *extend_info_describe(const extend_info_t *ei);
```
With the difference that those last allocate a buffer, instead of forcing the caller to create and pass the buffer as a parameter.
The functions from group B are an abstraction to the ones from group A: they are better because they always generate buffers of enough size (the size is NODE_DESC_BUF_LEN). So, we should avoid using group A.
By now, both groups are declared in the header, and there is only one use of a function of group A (router_get_description is used on dirserv.c).
Also, all those functions are abstractions to format_node_description, that should also not be used externally, so we could also remove this one from the header.
The constant NODE_DESC_BUF_LEN is not necessary externally either.
**Trac**:
**Username**: valentecaioTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25416[warn] Received http status code 404 ("Consensus is too old") from server '19...2022-06-16T15:31:48Ztoralf[warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.the local time is ok :
```
date -u
Sat Mar 3 16:18:01 UTC 2018
cat </dev/tcp/time.nist.gov/13
ntpdate -q 2.de.pool.ntp.org
server 2a01:4f8:172:326b::2, stratum 2, offset -0.000140, delay 0.02594
server 2a01:4f8:221:3b02::101:1, strat...the local time is ok :
```
date -u
Sat Mar 3 16:18:01 UTC 2018
cat </dev/tcp/time.nist.gov/13
ntpdate -q 2.de.pool.ntp.org
server 2a01:4f8:172:326b::2, stratum 2, offset -0.000140, delay 0.02594
server 2a01:4f8:221:3b02::101:1, stratum 2, offset -0.000601, delay 0.02594
server 2a01:238:439c:1900::3:1, stratum 2, offset 0.000477, delay 0.04520
server 2a02:16d0:0:4::4, stratum 2, offset -0.002245, delay 0.03976
server 90.187.7.5, stratum 2, offset -0.002271, delay 0.04788
server 129.70.132.36, stratum 2, offset 0.002152, delay 0.04262
server 145.239.3.131, stratum 2, offset 0.001487, delay 0.03177
server 85.236.36.4, stratum 2, offset -0.000501, delay 0.03650
3 Mar 17:18:09 ntpdate[18195]: adjust time server 2a01:4f8:221:3b02::101:1 offset -0.000601 sec
```
And I still get once a day or so _:
```
Mar 03 17:18:01.000 [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.
Mar 03 17:18:01.000 [notice] Tor 0.3.4.0-alpha-dev (git-efc105716283bbdf) opening log file.
Mar 03 17:18:02.000 [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.
```
tor version is 0.3.4-alpha-devhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25412TrackHostExits option in torrc file not working as documented2021-07-22T16:20:50ZTracTrackHostExits option in torrc file not working as documented1. Shut down Tor
2. Edit torrc file at c:\Program Files (x86)\Tor Browser\Browser\TorBrowser\Data\Tor\torrc so that it has the line:
TrackHostExits .
According to docs, this should mean to use the same exit node for all websites.
3. L...1. Shut down Tor
2. Edit torrc file at c:\Program Files (x86)\Tor Browser\Browser\TorBrowser\Data\Tor\torrc so that it has the line:
TrackHostExits .
According to docs, this should mean to use the same exit node for all websites.
3. Launch Tor, and open any two websites - let's say https://duckduckgo.com/ and https://www.nasa.gov/
4. Note that the exit node for each website may differ. If not reproducing, try using the IP addresses rather than URLs.
Why is this a problem? Some sites will generate a link that only works from the same IP as the original page. (In my case, one link is an IP that cannot be resolved to a URL, so using a URL isn't an option.)
Version: Tor 7.5 (The versions in the picker are massively out of date - not a good sign.)
**Trac**:
**Username**: LittleTorFanAnnieTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25398tests fail if COMPAT_HAS_MMAN_AND_PAGESIZE is not set2020-06-27T13:54:00ZAlex Xutests fail if COMPAT_HAS_MMAN_AND_PAGESIZE is not set`tor_mmap_file` doesn't check for empty files if `COMPAT_HAS_MMAN_AND_PAGESIZE` is not set, causes `test_util_mmap` to fail`tor_mmap_file` doesn't check for empty files if `COMPAT_HAS_MMAN_AND_PAGESIZE` is not set, causes `test_util_mmap` to failTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25290refactor to use should_record_bridge_info() more2021-09-16T14:31:19ZRoger Dingledinerefactor to use should_record_bridge_info() moreWe have this function
`should_record_bridge_info`
which simply checks
`options->BridgeRelay && options->BridgeRecordUsageByCountry`.
But in geoip_note_client_seen(), where we just added the DoS mitigation stuff, we don't use the functio...We have this function
`should_record_bridge_info`
which simply checks
`options->BridgeRelay && options->BridgeRecordUsageByCountry`.
But in geoip_note_client_seen(), where we just added the DoS mitigation stuff, we don't use the function, instead choosing to check the variables directly. We make the same choice in the options_need_geoip_info() function.
We should refactor things so we use the function in all cases.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25284hidden-service-dir description in dir-spec should reference HSDir protovers2021-09-30T13:50:08Zteorhidden-service-dir description in dir-spec should reference HSDir protoversSince 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified...Since 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified, it defaults to version 2 descriptors"Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25269Set codegen-units to 1 in src/rust/Cargo.toml to eke out every last drop of p...2020-07-28T18:41:01ZcypherpunksSet codegen-units to 1 in src/rust/Cargo.toml to eke out every last drop of performanceRust 1.24 now sets codegen-units to 16 by default to speed up compilation time but it makes the final binary slower https://blog.rust-lang.org/2018/02/15/Rust-1.24
> For maximum speed, setting `codegen-units` to `1` in your `Cargo.toml`...Rust 1.24 now sets codegen-units to 16 by default to speed up compilation time but it makes the final binary slower https://blog.rust-lang.org/2018/02/15/Rust-1.24
> For maximum speed, setting `codegen-units` to `1` in your `Cargo.toml` is needed to eke out every last drop of performance.
So [src/rust/Cargo.toml](https://gitweb.torproject.org/tor.git/tree/src/rust/Cargo.toml) should be changed with that to squeeze the most perf.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25203document max. value of SigningKeyLifetime2021-07-22T16:21:37Zcypherpunksdocument max. value of SigningKeyLifetimetor's manpage says:
> SigningKeyLifetime N days|weeks|months
> For how long should each Ed25519 signing key be valid? Tor uses a permanent master identity key that can be kept
> offline, and periodically generates new "signing" keys tha...tor's manpage says:
> SigningKeyLifetime N days|weeks|months
> For how long should each Ed25519 signing key be valid? Tor uses a permanent master identity key that can be kept
> offline, and periodically generates new "signing" keys that it uses online. This option configures their lifetime.
> (Default: 30 days)
It does not include information about what is the biggest acceptable value. Tor simply fails to start if the given value is to big:
```
[warn] Interval 'XX months' is too long
[warn] Failed to parse/validate config: Interval 'SigningKeyLifetime XX months' is malformed or out of bounds.
```
Please also mention if there is a value for SigningKeyLifetime where it is actually less safe than running in non-OfflineMasterKey mode (maybe it is less safe to set it to 10y in OfflineMasterKey mode than to run in non-OfflineMasterKey mode?) and if it makes any sense to modify this value in non-OfflineMasterKey mode (because that is apparently possible).Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25116hs: circuit_log_ancient_one_hop_circuits() should probably not log single oni...2021-09-30T13:50:08ZDavid Gouletdgoulet@torproject.orghs: circuit_log_ancient_one_hop_circuits() should probably not log single onion service rendezvous circuitAssume an email server where clients often keep a connection open and regularly exchange traffic on them.
Making that email server an .onion, RP circuits will stay open for a while and more than 1800 seconds which is the cutoff of `circ...Assume an email server where clients often keep a connection open and regularly exchange traffic on them.
Making that email server an .onion, RP circuits will stay open for a while and more than 1800 seconds which is the cutoff of `circuit_log_ancient_one_hop_circuits()` to log single hop circuits.
I think we want to ignore to log anything service related in there. Some v3 services have started seeing that heartbeat more and more in the last days.
Related: legacy/trac#8387Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org