Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:11:46Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33612Tor Browser Overwrites torrc %include Option with Actual Included Options2020-06-16T01:11:46ZTracTor Browser Overwrites torrc %include Option with Actual Included OptionsIn Tor Browser 9.5a7 there is a problem after it opens and reads the torrc file.
It gets to the line `%include /path/to/folder/` and then rewrites the torrc file without the `%include` line, but with all the options it just read in.
T...In Tor Browser 9.5a7 there is a problem after it opens and reads the torrc file.
It gets to the line `%include /path/to/folder/` and then rewrites the torrc file without the `%include` line, but with all the options it just read in.
This has happened to me in the past, but this time it didn't honor the fact I'd already set up a `ClientOnionAuthDir` option. It overwrote my path with the default for macOS.
Taking advantage of [another person's troubleshooting](https://trac.torproject.org/projects/tor/ticket/31408#comment:10) I removed all "torrc" holding only comments.
That didn't fix the problem of the torrc being rewritten without the desired `%include`.
Thank you.
**Trac**:
**Username**: werdhttps://gitlab.torproject.org/legacy/trac/-/issues/17997ExitNodes and/or StrictNodes not working in 5.0.62020-06-15T23:32:08ZTracExitNodes and/or StrictNodes not working in 5.0.6I used to use an old version of TorBrowser where I could customize my exit nodes. I would have two separate TorBrowser folders with two separate standalone installations of TorBrowser, which of course had two separate torrc files that I ...I used to use an old version of TorBrowser where I could customize my exit nodes. I would have two separate TorBrowser folders with two separate standalone installations of TorBrowser, which of course had two separate torrc files that I could customize so as one would only use (for example) Finnish exit nodes and the other would use Canadian exit nodes. This worked very well.
I recently installed the latest version of Tor Browser for Windows (5.0.6) and replaced the blank torrc file with my previous customized torrc file. The torrc file specified Strict Nodes to be used and only to use Canadian exit nodes, but after trying more than a dozen times, it would always connect to non-Canadian exit nodes.
I then replaced the contents of the torrc-defaults file with the content of my old torrc file and tried again. TorBrowser then proceeded to successfully use ONLY Canadian exit nodes.
I then proceeded create another separate additional Tor Browser setup in a completely different folder but instead setup for only Finnish exit nodes. Again I customized torrc-defaults in the "Finnish Tor Browser" folder and it worked.
HOWEVER, when I closed the "Finnish Tor Browser" instance and went to run my "Canadian Tor Browser", I encountered a problem. The "Canadian Tor Browser" was now using random exit nodes again! I closed it down and tried again. The second time, my "Canadian Tor Browser" was now using Finnish exit nodes!
I thought this was bizarre because it does not happen with the older version I was using. I also noticed that a bookmark that I had put in the "Finnish Tor Browser" standalone folder was now present when I loaded up the "Canadian Tor Browser" - this means that my two apparently separate installations of Tor Browser are sharing some common files. I do not understand how this is possible seeing as my previous standalone installations of the previous version of Tor Browser, as far as I could tell, were independent of each other.
I would like to point out that, in case in makes a difference, I was NOT attempting to run the two Tor Browsers at the same time. I ran one, quit it, then ran the other.
If this is somehow intentional then please tell me how I can have separate installations of Tor Browser on the same machine but utilizing different customized torrc or torrc-default files.
**Trac**:
**Username**: thmprtorhttps://gitlab.torproject.org/legacy/trac/-/issues/30515support portal: update confguration examples with current config2020-06-13T17:36:46Zemmapeelsupport portal: update confguration examples with current configthe examples of configuration found at:
https://support.torproject.org/#operators
need to be updated to the current default configuration for torrcthe examples of configuration found at:
https://support.torproject.org/#operators
need to be updated to the current default configuration for torrcwaywardwaywardhttps://gitlab.torproject.org/legacy/trac/-/issues/29345Can't install TOR as a service on Windows 102020-06-13T17:36:42ZTracCan't install TOR as a service on Windows 10When trying to execute
```
tor.exe --service install --options -f C:\absolute\path\to\torrc
```
an <unformattable error> is given:
```
Running on a Post-Win2K OS, so we'll assume that the LocalService account exists.
Done with CreateSe...When trying to execute
```
tor.exe --service install --options -f C:\absolute\path\to\torrc
```
an <unformattable error> is given:
```
Running on a Post-Win2K OS, so we'll assume that the LocalService account exists.
Done with CreateService.
Service installed successfully
Service failed to start : <unformattable error>
```
This bug happens when there is something written in the torrc file, but on other attempts it was happening when using
```
HiddenServiceAuthorizeClient basic PCNAME
```
and so deleting this line it has been starting again.
If I leave the torrc file empty the error doesn't show up and the service is installed and working.
I tried to differently formatting torrc file, so using LF and CRLF, but the result is the same.
**Trac**:
**Username**: JohnnyFroghttps://gitlab.torproject.org/legacy/trac/-/issues/22391Add torrc.d configuration directory on deb packages2020-06-13T16:52:57ZJigsaw52Add torrc.d configuration directory on deb packagesA torrc.d style configuration directory could be added to the debian packages for version 0.3.1.1-alpha and above. Since #1922 is now implemented, it is easy to add this feature.
I attempted to add this feature on this branch: https://g...A torrc.d style configuration directory could be added to the debian packages for version 0.3.1.1-alpha and above. Since #1922 is now implemented, it is easy to add this feature.
I attempted to add this feature on this branch: https://github.com/Jigsaw52/debian-tor/tree/add-torrc.dweasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/legacy/trac/-/issues/32823support Android SharedPreferences xml as a torrc format2020-06-13T15:49:30Zeighthavesupport Android SharedPreferences xml as a torrc formatWith Tor Browser, Orbot, and other apps on Android, some Tor settings are managed via the `SharedPreferences`/`PreferenceFragment` Android classes. When used in their standard setup, these handle the whole lifecycle of preferences. Rig...With Tor Browser, Orbot, and other apps on Android, some Tor settings are managed via the `SharedPreferences`/`PreferenceFragment` Android classes. When used in their standard setup, these handle the whole lifecycle of preferences. Right now, we have to do a lot of tricks to get the settings from the Android classes, convert them to `torrc` format, then handle reloading Tor at the right time.
Android's `SharedPreferences` writes out to a standard xml file, e.g `/data/data/org.torproject.android/shared_prefs/org.torproject.android_preferences.xml`. This XML file has a simple format that has been the same since the beginning. If Tor can read this format as an optional `torrc` format, and also potentially automatically reload the config when that file changes, then the Android code will be drastically simpler. This will greatly improve the interaction around any kind of user-facing setting, like bridges, exit countries, pluggable transports, etc.
Here's an example of what the XML would look like:
```
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<boolean name="RunAsDaemon" value="true" />
<boolean name="AvoidDiskWrites" value="true" />
<string name="TransPort">auto</string>
<int name="DNSPort" value="5400" />
<string name="TransPort" value="auto" />
<string name="Bridges">obfs4 77.81.104.251:443 115C90EBD0EB631C177560A872535772215478D9 cert=UsuF7oN4KNKviZP54JOyTCoCphrdM5gwZK4vT8GnCAcmqLUJEJxyw1dpko9a/ii6He4iZg iat-mode=0,obfs4 5.249.146.133:80 FAF3A0073330D6AD92F3B4874B0D945562A633EF cert=TRe8bAODtjcGij7EPQaUayWEOqR99wDh2l3B4hFtCsn1JTJCph03pRZ9tx8wynpLYKWMQg iat-mode=0,meek_lite 0.0.2.0:2 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com</string>
</map>
```
We might want an alternate format for bridge lines, where would be a dedicated XML file for only bridge lines with the `name` specifying the line number:
```
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<string name="0">obfs4 77.81.104.251:443 115C90EBD0EB631C177560A872535772215478D9 cert=UsuF7oN4KNKviZP54JOyTCoCphrdM5gwZK4vT8GnCAcmqLUJEJxyw1dpko9a/ii6He4iZg iat-mode=0</string>
<string name="1">obfs4 5.249.146.133:80 FAF3A0073330D6AD92F3B4874B0D945562A633EF cert=TRe8bAODtjcGij7EPQaUayWEOqR99wDh2l3B4hFtCsn1JTJCph03pRZ9tx8wynpLYKWMQg iat-mode=0</string>
<string name="2">meek_lite 0.0.2.0:2 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com</string>
</map>
```
Yxml is a 6k C XML parser in a single file under an MIT license. It has been maintained since 2013. It would fit the bill quite nicely.
https://dev.yorhel.nl/yxml
Yes, XML is not an ideal format. We don't need the most problematic parts of XML for this, e.g. namespaces, custom entities, etc. and Yxml does not support them anyway.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22703Add a KeyDirectory option to override location of $datadir/keys, and/or a cac...2020-06-13T15:46:16ZNick MathewsonAdd a KeyDirectory option to override location of $datadir/keys, and/or a cachedir option to override location of cached files.It is at least mildly naughty how Tor currently uses the same DataDirectory for both persistent secret things (keys), persistent sensitive things (the state file), runtime stuff (the lock file), and cached objects (cached-*). Perhaps we...It is at least mildly naughty how Tor currently uses the same DataDirectory for both persistent secret things (keys), persistent sensitive things (the state file), runtime stuff (the lock file), and cached objects (cached-*). Perhaps we should provide options to split these up?
This might help a bit with memory usage on platforms where /var is a tmpfs. In #7176, there was an openwrt patch that changed the key directory to a hardcoded path, but that's obviously not mergeable in mainline tor.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30299Switch network interface2020-06-13T15:41:01ZTracSwitch network interfaceI have standalone Tor client listening on localhost port 53 for DNS UDP packets on a Ubuntu 18.04 VM environment. This is the equivalent to setting on /etc/tor/torrc:
DNSPort 127.0.0.1:53
I also have a DNS rule on network manager set t...I have standalone Tor client listening on localhost port 53 for DNS UDP packets on a Ubuntu 18.04 VM environment. This is the equivalent to setting on /etc/tor/torrc:
DNSPort 127.0.0.1:53
I also have a DNS rule on network manager set to redirect DNS packets to IP:
127.0.0.1
After following the standard OpenVPN configuration, I make a connection to the VPN server with:
openvpn --config /etc/openvpn/servers-conf/01.example.tcp.ovpn
The problem is Tor receives the DNS UDP packets, converts them to TCP packets and then attempts to send them through my main "naked" network interface to Tor relays, instead of using the secure tun0 interface. OpenVPN sees the TCP packet leaving the "naked" interface and thinks this is not safe and blocks them, which means I'm not able to resolve domain names as Tor's DNS TCP packets can't leave the system.
In order to fix this, I have to restart Tor using:
systemctl restart tor
This then updates Tor to connect to tun0 and everything works fine again however, it would make sense to have Tor update automatically or to have an option to specify a network interface order for Tor to connect to. Example:
InterfacePref: tun0, tun1, eth0
Similar to a bootloader selecting what to boot first, this means Tor would always try to connect to tun0 if available, if not it will try tun1 and else eth0. If at any time a better interface comes up Tor should switch to it automatically. A default value would still connect to the default interface as it does today.
**Trac**:
**Username**: enriquejr99Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29140Tor privdrop on (Open)BSD fails to reclaim capabilities of "User".2020-06-13T15:37:05ZTracTor privdrop on (Open)BSD fails to reclaim capabilities of "User".As summary states. Should Tor need invocation as superuser it will fail claim the capabilities of the target "User" in torrc. One statement that is therefore affected is e.g. "DisableAllSwap 1" which would either require Tor running as r...As summary states. Should Tor need invocation as superuser it will fail claim the capabilities of the target "User" in torrc. One statement that is therefore affected is e.g. "DisableAllSwap 1" which would either require Tor running as root or raising of superuser capabilities (this was never tested however). Both alternatives are unattractive.
Regarding option with "DisableAllSwap" I will give pretty obvious pointers from your own GitHub repositories:
L1510 @ src/app/config/config.c
L220 @ src/lib/process/setuid.c
L316 @ src/lib/process/setuid.c
And here is kdump format of a ktrace of faulty execution:
```
28446 tor CALL setegid(1000<"user">)
28446 tor RET setegid 0
28446 tor CALL setgid(1000<"user">)
28446 tor RET setgid 0
28446 tor CALL setuid(1000<"user">)
28446 tor RET setuid 0
28446 tor CALL seteuid(1000<"user">)
28446 tor RET seteuid 0
28446 tor CALL setgid(0<"wheel">)
28446 tor RET setgid -1 errno 1 Operation not permitted
28446 tor CALL setegid(0<"wheel">)
28446 tor RET setegid -1 errno 1 Operation not permitted
28446 tor CALL setuid(0<"root">)
28446 tor RET setuid -1 errno 1 Operation not permitted
28446 tor CALL seteuid(0<"root">)
28446 tor RET seteuid -1 errno 1 Operation not permitted
```
P.S. This applies to 0.3.4.9 but also to 0.3.5.7.
P.P.S. I am sorry I did not take the time to patch this myself yes. For anyone interested in this these are great resources:
man 2 setuid
man 2 seteuid
man 2 setgid
man 2 setegid
man 2 getrlimit
man 2 setrlimit
**Trac**:
**Username**: RatherAnonymousOneTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28361Allow few nodes-list options in torrc2020-06-13T15:33:54ZTracAllow few nodes-list options in torrcThere are many options in `torrc` which accept lists of nodes, countries, etc.:
```
ExcludeNodes node,node,...
ExcludeExitNodes node,node,...
ExitNodes node,node,...
EntryNodes node,node,...
NodeFamily node,node,...
Tor2webRendezvousPoi...There are many options in `torrc` which accept lists of nodes, countries, etc.:
```
ExcludeNodes node,node,...
ExcludeExitNodes node,node,...
ExitNodes node,node,...
EntryNodes node,node,...
NodeFamily node,node,...
Tor2webRendezvousPoints node,node,...
HSLayer2Nodes node,node,...
HSLayer3Nodes node,node,...
TestingDirAuthVoteExit node,node,...
TestingDirAuthVoteGuard node,node,...
TestingDirAuthVoteHSDir node,node,...
```
Maybe I have not list all of them. Values for these options may be very long lists. It would be very convenient to write it as, e.g.:
```
ExcludeNodes node0,nodeX
ExcludeNodes node1
ExcludeNodes node2
ExcludeNodes node3,nodeY,nodeZ
```
I cannot see any reason why only one such option can be specified in `torrc`. It makes management of long lists very hard, because one needs to add `\` symbols, take into account some restrictions on comments within these lists, etc.
**Trac**:
**Username**: wagonTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19665Should *Port_set count sockets?2020-06-13T15:25:32ZteorShould *Port_set count sockets?In parse_ports in 0.2.8-stable and earlier, we didn't count sockets as listeners when setting options->*Port_set.
This makes sense for server ports, is confusing for ControlPort/ControlSocket (because you can set a control socket using ...In parse_ports in 0.2.8-stable and earlier, we didn't count sockets as listeners when setting options->*Port_set.
This makes sense for server ports, is confusing for ControlPort/ControlSocket (because you can set a control socket using the ControlPort option, can't you?), and didn't matter for client ports, because those values were never used.
In #17178 I modified the client port options to count sockets.
But we should definitely review the control port situation some time.
I don't think it's serious, because the current code warns on ControlPorts and ControlSockets.
But it makes it easy to introduce subtle bugs.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25529Tor not reading torrc-defaults when started from command line, while it reads...2020-06-13T15:23:14ZTracTor not reading torrc-defaults when started from command line, while it reads it successfully when started from Tor BrowserI'm using this command in order to start Tor from command line (**_Windows 10_**):
```
cd "C:\Tor Browser\Browser\"
"C:\Tor Browser\Browser\TorBrowser\Tor\tor.exe" -f "C:\Tor Browser\Browser\TorBrowser\Data\Tor\torrc" | more
```
Some t...I'm using this command in order to start Tor from command line (**_Windows 10_**):
```
cd "C:\Tor Browser\Browser\"
"C:\Tor Browser\Browser\TorBrowser\Tor\tor.exe" -f "C:\Tor Browser\Browser\TorBrowser\Data\Tor\torrc" | more
```
Some times Tor is able to connect successfully, but many times problems occur. On the other side when starting Tor from Browser, the problems never happen and every thing go smoothly.
----
Comparison between my experience of starting Tor from command line and starting it from Tor Browser:
== When starting Tor from command line:
Connection hangs a lot. And when I have some request like:
```
curl --socks5-hostname localhost:9050 http://checkip.amazonaws.com/
```
I get:
```
curl: (7) Can't complete SOCKS5 connection to 0.0.0.0:0. (6)
```
== When starting Tor from Tor Browser:
Everything goes very smooth and no hanging happens. Even the same meek address is being used and hasn't changed.
So, I guess the problem isn't with the meek address, I think I'm missing something with the configuration when starting Tor from command line.
A log snippet of starting Tor **from command line**:
```
Mar 11 05:04:03.000 [notice] Tor 0.3.2.10 opening new log file.
Mar 11 05:04:03.000 [notice] Tor 0.3.2.10 running on Windows 8 with Libevent 2.0.22-stable, OpenSSL 1.0.2n, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
Mar 11 05:04:03.000 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 11 05:04:03.000 [notice] Read configuration file "C:\Tor Browser\Browser\TorBrowser\Data\Tor\torrc".
Mar 11 05:04:03.000 [notice] Scheduler type KISTLite has been enabled.
Mar 11 05:04:03.000 [notice] Opening Socks listener on 127.0.0.1:9050
Mar 11 05:04:03.000 [notice] Opening Control listener on 127.0.0.1:9051
Mar 11 05:04:03.000 [notice] Parsing GEOIP IPv4 file C:\Tor Browser\Browser\TorBrowser\Data\Tor\geoip.
Mar 11 05:04:04.000 [notice] Parsing GEOIP IPv6 file C:\Tor Browser\Browser\TorBrowser\Data\Tor\geoip6.
Mar 11 05:04:06.000 [notice] Bootstrapped 0%: Starting
Mar 11 05:04:10.000 [notice] Starting with guard context "bridges"
Mar 11 05:04:10.000 [notice] new bridge descriptor 'TorLandMeek' (cached): $A1A1234A123AB12345A1234A1A1234A123456789~TorLandMeek at 0.0.2.0
Mar 11 05:04:10.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Mar 11 05:04:12.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Mar 11 05:04:13.000 [notice] Delaying directory fetches: No running bridges
Mar 11 05:07:12.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Mar 11 05:07:39.000 [notice] Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
Mar 11 05:07:41.000 [notice] Delaying directory fetches: No running bridges
Mar 11 05:09:39.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Mar 11 05:09:49.000 [notice] Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
Mar 11 05:09:51.000 [notice] Delaying directory fetches: No running bridges
Mar 11 05:11:50.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
```
A log snippet of starting Tor **from Tor Browser**:
```
Mar 11 05:12:10.000 [notice] Tor 0.3.2.10 opening log file.
Mar 11 05:12:10.000 [notice] Tor 0.3.2.10 running on Windows 8 with Libevent 2.0.22-stable, OpenSSL 1.0.2n, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
Mar 11 05:12:10.000 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 11 05:12:10.000 [notice] Read configuration file "C:\Tor Browser\Browser\TorBrowser\Data\Tor\torrc-defaults".
Mar 11 05:12:10.000 [notice] Read configuration file "C:\Tor Browser\Browser\TorBrowser\Data\Tor\torrc".
Mar 11 05:12:10.000 [notice] Scheduler type KISTLite has been enabled.
Mar 11 05:12:10.000 [notice] Opening Control listener on 127.0.0.1:9051
Mar 11 05:12:10.000 [notice] Opening Control listener on 127.0.0.1:9151
Mar 11 05:12:10.000 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Mar 11 05:12:10.000 [notice] Parsing GEOIP IPv4 file C:\Tor Browser\Browser\TorBrowser\Data\Tor\geoip.
Mar 11 05:12:10.000 [notice] Parsing GEOIP IPv6 file C:\Tor Browser\Browser\TorBrowser\Data\Tor\geoip6.
Mar 11 05:12:11.000 [notice] Bootstrapped 0%: Starting
Mar 11 05:12:12.000 [notice] Starting with guard context "bridges"
Mar 11 05:12:12.000 [notice] new bridge descriptor 'TorLandMeek' (cached): $A1A1234A123AB12345A1234A1A1234A123456789~TorLandMeek at 0.0.2.0
Mar 11 05:12:12.000 [notice] Delaying directory fetches: DisableNetwork is set.
Mar 11 05:12:12.000 [notice] New control connection opened from 127.0.0.1.
Mar 11 05:12:13.000 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Mar 11 05:12:13.000 [notice] Tor 0.3.2.10 opening log file.
Mar 11 05:12:13.000 [notice] New control connection opened from 127.0.0.1.
Mar 11 05:12:13.000 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Mar 11 05:12:13.000 [notice] Tor 0.3.2.10 opening log file.
Mar 11 05:12:13.000 [notice] Opening Socks listener on 127.0.0.1:9150
Mar 11 05:12:13.000 [notice] Tor 0.3.2.10 opening log file.
Mar 11 05:12:14.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Mar 11 05:12:14.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Mar 11 05:12:17.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Mar 11 05:12:20.000 [notice] new bridge descriptor 'TorLandMeek' (fresh): $A1A1234A123AB12345A1234A1A1234A123456789~TorLandMeek at 0.0.2.0
Mar 11 05:12:25.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Mar 11 05:12:25.000 [notice] Bootstrapped 100%: Done
Mar 11 05:12:37.000 [notice] New control connection opened from 127.0.0.1.
```
I'm looking for making Tor (when started from command line) **work as smooth as** it is when started from Tor Browser.
**Trac**:
**Username**: omareg94https://gitlab.torproject.org/legacy/trac/-/issues/22700Stop relays using the Client*IPv6* options2020-06-13T15:10:30ZteorStop relays using the Client*IPv6* optionsSome operators add all the IPv6 options to their torrcs.
We should warn when they add client options on relays.Some operators add all the IPv6 options to their torrcs.
We should warn when they add client options on relays.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22469tor should probably reject "0x00" in port range specifications2020-06-13T15:09:55Ztoralftor should probably reject "0x00" in port range specificationssomething like
```
ExitPolicy reject6 [2a00:1450:4001:0815:0000:0000:0000:200e]:0x00
```
should spew an error message.something like
```
ExitPolicy reject6 [2a00:1450:4001:0815:0000:0000:0000:200e]:0x00
```
should spew an error message.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22417crash: double free or corruption (fasttop):2020-06-13T15:09:38Ztoralfcrash: double free or corruption (fasttop):stable hardened Gentoo Linux server with 0.3.1.1_alpha2 while reloading config (splitted torrc into smaller files) :
and again I had to attach the trace isntead just putting it here into ` ` b/c TRAC rejected the input as being spam :-/stable hardened Gentoo Linux server with 0.3.1.1_alpha2 while reloading config (splitted torrc into smaller files) :
and again I had to attach the trace isntead just putting it here into ` ` b/c TRAC rejected the input as being spam :-/Tor: 0.3.1.x-finalJigsaw52Jigsaw52https://gitlab.torproject.org/legacy/trac/-/issues/21975Refactor all the startup stuff in config.c, with dependencies in mind2020-06-13T15:07:58ZRoger DingledineRefactor all the startup stuff in config.c, with dependencies in mindMotivated by #21974:
"""
We sure have a bunch of stuff we do at startup now, and the dependency graph of what has to happen before what is complicated, and I bet there are bugs in the current order of things. It would be a swell project ...Motivated by #21974:
"""
We sure have a bunch of stuff we do at startup now, and the dependency graph of what has to happen before what is complicated, and I bet there are bugs in the current order of things. It would be a swell project for somebody to make a list of all the things we do at startup, and figure out their dependencies, and sort them into "waves" or something, and then refactor the stuff in config.c so it matches the new world order.
"""Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21281Allow process poll rate to be customized2020-06-13T15:05:34ZDamian JohnsonAllow process poll rate to be customizedHi Nick, I've been digging into Stem test performance with an aim of making them faster. Our tests regarding OwningControllerProcess take fifteen seconds each because that's the poll rate of the tor process. Looks like this is defined at...Hi Nick, I've been digging into Stem test performance with an aim of making them faster. Our tests regarding OwningControllerProcess take fifteen seconds each because that's the poll rate of the tor process. Looks like this is defined at...
https://gitweb.torproject.org/tor.git/tree/src/common/procmon.c#n165
Would you mind making this customizable (probably via a hidden double-underscore torrc options)? This will let me make our tests run faster for us both. :)
Thanks!Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21115Building Tor With Static SNI2020-06-13T15:05:04ZTracBuilding Tor With Static SNII want to have a static value of SNI in TOR in Https Connection. TOR currently uses Random SNI but Firewall is blocking it by checking random SNI.
I have changed crypto_random_hostname to a Static char* in /src/common/tortls.c to a fixed...I want to have a static value of SNI in TOR in Https Connection. TOR currently uses Random SNI but Firewall is blocking it by checking random SNI.
I have changed crypto_random_hostname to a Static char* in /src/common/tortls.c to a fixed string but after that it is not working.
**Trac**:
**Username**: mintu.juit@gmail.comTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19919If ORPort address is publicly routable, use it to guess Address2020-06-13T15:04:48ZteorIf ORPort address is publicly routable, use it to guess AddressSplitting this off from #13953: we'll warn in that ticket, and make the change to the address resolution order in this one.Splitting this off from #13953: we'll warn in that ticket, and make the change to the address resolution order in this one.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21043Make ClientUseIPv4 and ClientUseIPv6 equivalent to ReachableAddresses2020-06-13T15:04:47ZteorMake ClientUseIPv4 and ClientUseIPv6 equivalent to ReachableAddressesOnce #20996 is fixed, we should also make ClientUseIPv4 and ClientUseIPv6 work the same as the equivalent ReachableAddresses settings.
For example:
ClientUseIPv4 = accept/reject 0.0.0.0/0 = accept/reject *4
ClientUseIPv6 = accept/reject...Once #20996 is fixed, we should also make ClientUseIPv4 and ClientUseIPv6 work the same as the equivalent ReachableAddresses settings.
For example:
ClientUseIPv4 = accept/reject 0.0.0.0/0 = accept/reject *4
ClientUseIPv6 = accept/reject [::]/0 = accept6/reject6 * = accept/reject *6
Bootstrap and guards should also work if ReachableAddresses blocks almost all addresses of a particular type.Tor: unspecified