Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:02:19Zhttps://gitlab.torproject.org/legacy/trac/-/issues/1029Tor relay should log message when it's working again after marking as down2020-06-13T14:02:19ZTracTor relay should log message when it's working again after marking as downHi,
I'm running a Tor relay on a dynamic IP which changes once per day.
Sometimes there seems to be some problems and I get the following
error message:
We just marked ourself as down. Are your external addresses reachable?
Now th...Hi,
I'm running a Tor relay on a dynamic IP which changes once per day.
Sometimes there seems to be some problems and I get the following
error message:
We just marked ourself as down. Are your external addresses reachable?
Now this is no problem and the message is fine. But I would like to
be informed when the relay knows it's up again. Something like this:
We just marked ourself as up again.
So that I'm not worried when I see the first message and know (when
I see the second message) that my relay works fine. At the moment I
have have to do the check manually.
Thanks for your help,
Simon
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rudisTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1075reachability controller status events too liberal2020-06-13T14:02:33ZRoger Dingledinereachability controller status events too liberal<edmanm:#vidalia> arma: so i guess tor throws a REACHABILITY_FAILED event for
+every testing circuit that fails (but not necessarily a CHECKING_REACHABILITY
+event for every testing circuit it launches).
<edmanm:#vidalia> is there a part...<edmanm:#vidalia> arma: so i guess tor throws a REACHABILITY_FAILED event for
+every testing circuit that fails (but not necessarily a CHECKING_REACHABILITY
+event for every testing circuit it launches).
<edmanm:#vidalia> is there a particular threshold of failures at which tor
+decides "ok, i'm really not reachable. user needs to fix his network."?
<edmanm:#vidalia> or if i wait long enough will i finally get a
+REACHABILITY_FAILED event with an ERR severity?
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1099Spurious bootstrap warnings if no-route-to-host2020-06-13T14:02:40ZRoger DingledineSpurious bootstrap warnings if no-route-to-hostSep 19 22:42:11.251 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (No route to host; NOROUTE; count 1; recommendation warn)
$ telnet 89.54.142.227 443
Trying 89.54.142.227...
telnet: Unable to connect t...Sep 19 22:42:11.251 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (No route to host; NOROUTE; count 1; recommendation warn)
$ telnet 89.54.142.227 443
Trying 89.54.142.227...
telnet: Unable to connect to remote host: No route to host
This isn't a problem with my network, it's a problem with that host.
And it looks like Tor can't tell the difference:
$ grep END_OR_CONN_REASON_NO_ROUTE *.h
or.h:#define END_OR_CONN_REASON_NO_ROUTE 6 /* no route to host/net */
We should teach it the difference.
Step one is to do this in errno_to_orconn_end_reason(), which I think will
solve the particular issue here.
Step two would be to solve it in tls_error_to_orconn_end_reason(), but I
bet that might be trickier.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2594Excito needs a web interface to easily install and configure Tor2011-10-24T22:05:14ZAndrew LewmanExcito needs a web interface to easily install and configure TorThe best documentation of the current process to getting Tor installed is [here](http://isprins.blogspot.com/2010/12/excito-b3-and-internet-freedom.html). We need to integrate with the excito web interface so users can simply click to i...The best documentation of the current process to getting Tor installed is [here](http://isprins.blogspot.com/2010/12/excito-b3-and-internet-freedom.html). We need to integrate with the excito web interface so users can simply click to install Tor, and then choose bridge vs. relay (non-exit or exit) in a simple manner. Some basic feedback to the interface could include, client countries served and bandwidth used/provided over time.Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/legacy/trac/-/issues/3694Provide a status/addon bar button2020-06-13T16:26:09ZTracProvide a status/addon bar buttonIt would be nice if this Firefox addon could provide a button for the status/addon bar. Of course it should be functionally equivalent to the toolbar button.
**Trac**:
**Username**: herojokerIt would be nice if this Firefox addon could provide a button for the status/addon bar. Of course it should be functionally equivalent to the toolbar button.
**Trac**:
**Username**: herojokerPeter EckersleyPeter Eckersleyhttps://gitlab.torproject.org/legacy/trac/-/issues/4378Tor guesses IP address when Address is 127.0.0.12020-06-13T14:14:23ZLinus Nordberglinus@torproject.orgTor guesses IP address when Address is 127.0.0.1Setting Address to 127.0.0.1 should make Tor not guess IP address. Tor dislikes 127.0.0.1 (INFO level log) for not being public:
[info] resolve_my_address(): Address '127.0.0.1' resolves to private IP address '127.0.0.1'. Tor serve...Setting Address to 127.0.0.1 should make Tor not guess IP address. Tor dislikes 127.0.0.1 (INFO level log) for not being public:
[info] resolve_my_address(): Address '127.0.0.1' resolves to private IP address '127.0.0.1'. Tor servers that use the default DirServers must have public IP addresses.
Then it guesses:
[notice] Guessed our IP address as [scrubbed by linus] (source: 213.115.239.118).
1. it shouldn't guess
2. the warning should not be at INFO
Thanks weasel and armadev.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4590easy download page has sig for windows but not others2020-06-13T17:19:43ZTraceasy download page has sig for windows but not othershttps://www.torproject.org/download/download-easy.html
you can click to download the mac or linux bundle but to get the sig is a bunch more clicks in search of the real download page.
alternative suggestions:
1) for non-windows, link go...https://www.torproject.org/download/download-easy.html
you can click to download the mac or linux bundle but to get the sig is a bunch more clicks in search of the real download page.
alternative suggestions:
1) for non-windows, link goes to bundle page download section for chosen os.
2) add (sig) download link beside bundle download link for each os.
**Trac**:
**Username**: kebjmtodarojmtodarohttps://gitlab.torproject.org/legacy/trac/-/issues/4885Make all paths absolute2020-06-13T14:16:46ZNick MathewsonMake all paths absoluteThere are bunches of cases internally where it would make sense to have all the paths in Tor be absolute, and none (that I can think of) where taking paths as relative to the CWD actually helps us.
We could find things that should be ab...There are bunches of cases internally where it would make sense to have all the paths in Tor be absolute, and none (that I can think of) where taking paths as relative to the CWD actually helps us.
We could find things that should be absolute and make them so piecemeal, but that would invite missed cases. Better, we we could just turn all paths into absolute paths when we read them in from the configuration.
(See #1101 and #4881 for earlier work here. Marking this for 0.2.4.x, since 0.2.3.x is approaching feature freeze.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6010UpdateBridgesFromAuthority isn't actually usable2020-06-13T14:20:00ZNick MathewsonUpdateBridgesFromAuthority isn't actually usableThanks to the bug #1938 fix, UpdateBridgesFromAuthority only works if you can build a circuit to the authority. But if you're using bridges, you can't connect to the authority without bridges, so setting UpdateBridgesFromAuthority 1 is ...Thanks to the bug #1938 fix, UpdateBridgesFromAuthority only works if you can build a circuit to the authority. But if you're using bridges, you can't connect to the authority without bridges, so setting UpdateBridgesFromAuthority 1 is still not going to be a great idea unless you already have a bridge descriptor somehow.
What we should really do (according to comments on #1938 , which I agree with) is implement behavior where we can try the authority *or* try asking the bridges we know, falling back from one to the other intelligently.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6060add http proxy support to Tor2020-06-13T14:20:18Zproperadd http proxy support to TorMany applications, such as wget, apt-get, gpg, etc. do not speak socks, are unlikely to speak socks anytime soon, but support http.
Privoxy or polipo are of no help. They provides only one http port, with the one big drawback: all http ...Many applications, such as wget, apt-get, gpg, etc. do not speak socks, are unlikely to speak socks anytime soon, but support http.
Privoxy or polipo are of no help. They provides only one http port, with the one big drawback: all http connections will be presses through the same SocksPort (identity correlation).
torsocks is of no big help either. I think it has been designed, when identity correlation wasn't a big topic. By default torsocks uses /etc/torsocks.conf and also presses all applications started with usewithtor <app> into the same SocksPort (identity correlation again). To me it also looks like torsocks is practically unmaintained, there is a critical bug open, [IPv6 can leak real IP](https://code.google.com/p/torsocks/issues/detail?id=37), no progress for a very long time.
As a solution I propose a HttpPort directive for torrc. And stream isolate the same way, Tor stream isolates SocksPort. (Different HttpPorts get isolated, also isolate by http username or http password etc.)
I don't know how much effort it were to add a http proxy. You have already some very basic http support "Tor is not a http proxy". Can you translate the http proxy request and internally redirect it to your existing socks code?
,,
Imho "#2846 Patch GPG to support SOCKS proxies" does not make sense. Why patch individual applications, when you can support all of them by adding http proxy support to Tor... Another Related Ticket: #1667.Tor: unspecifiedRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/6228NSS module for .onion DNS name resolution2020-06-13T16:08:57ZTracNSS module for .onion DNS name resolutionFrom a usability point of view it'd be great to always have .onion addresses resolved via Tor - system wide, by default. It'd make .onion addresses a first-class citizen in the overall web browsing experience.
The idea is to provide a l...From a usability point of view it'd be great to always have .onion addresses resolved via Tor - system wide, by default. It'd make .onion addresses a first-class citizen in the overall web browsing experience.
The idea is to provide a libnss-tor module to by default always resolve .onion addresses via Tor, with no need for 'torify', proxy configurations within an application etc. Similar to what libnss-mdns does for .local addresses for instance.
Thanks to [this](https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy) I came up with the following setup to achieve the same thing:
* torrc with 'AutomapHostsOnResolve 1', 'DNSPort 53535' and 'TransPort 9040'
* dnsmasq with a 'server=/onion/127.0.0.1!#53535'
* iptables -t nat -A OUTPUT -p tcp -d 127.192.0.0/10 -j REDIRECT --to-ports 9040
* 'nameserver 127.0.0.1' in /etc/resolv.conf
However having a libnss-tor for that would remove the iptables/dnsmasq part, which should make it way more convinient for most people. It'd also make the mapaddress option in the torrc obsolete, I think.
Further things to consider:
* Security implications?
* Does something like libnss exist for other operating systems, too?
**Trac**:
**Username**: tuxhttps://gitlab.torproject.org/legacy/trac/-/issues/7457Add client-side log indicator that an obfsbridge works2020-06-13T14:24:52ZGeorge KadianakisAdd client-side log indicator that an obfsbridge worksBridge operators can be reasonably sure that obfsproxy works for them since they see the `Registered server transport` log message.
OTOH, clients can't be sure whether their obfsproxy works or whether they connected to a bridge with obf...Bridge operators can be reasonably sure that obfsproxy works for them since they see the `Registered server transport` log message.
OTOH, clients can't be sure whether their obfsproxy works or whether they connected to a bridge with obfsproxy.
I think we should add PT information to one of the "connected to bridge" log messages.
Specifically, to:
```
log_notice(LD_DIR, "Learned fingerprint %s for bridge %s"
```
or to
```
log_notice(LD_DIR, "new bridge descriptor '%s' (%s): %s"
```
IIUC the latter will appear in the logs everytime we connect to a bridge, even if we knew the bridge fingerprint.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7789Also display configuration file (torrc) location when running as Windows service2020-06-13T14:25:57ZTracAlso display configuration file (torrc) location when running as Windows serviceWhen normal running TOR on Windows, it prompts the reading configuration file location such as
```
Dec 23 05:31:11.523 [notice] Read configuration file "C:\Users\<USERNAME>\AppData\Roaming\tor\torrc".
```
But TOR does not prompt this lo...When normal running TOR on Windows, it prompts the reading configuration file location such as
```
Dec 23 05:31:11.523 [notice] Read configuration file "C:\Users\<USERNAME>\AppData\Roaming\tor\torrc".
```
But TOR does not prompt this location when running as Windows Service, and the torrc file is usually in a totally different location when running as service. TOR just prompt this service is started in command line.
```
D:\tor>tor --service start
Service started successfully
```
so it is hard to find which torrc file it is reading. Need a fix on this issue to make it a litter easier.
**Trac**:
**Username**: mosesofmasonTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7890meaningless error message displayed by tor at start up2020-06-13T14:26:19ZTracmeaningless error message displayed by tor at start upDuring tor start up, I get the following gem: "No specified non-excluded exit routers seem to be running: can't choose an exit."
The first one who could decipher that for me will get a pat on the back.
I figured out the cause, eventua...During tor start up, I get the following gem: "No specified non-excluded exit routers seem to be running: can't choose an exit."
The first one who could decipher that for me will get a pat on the back.
I figured out the cause, eventually - I have restricted tor to use exit node (via ExitNodes), but that node was unavailable for some reason.
**Trac**:
**Username**: mr-4Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/8205Stop this usability hell while using bridges (at least give more hints)2013-02-12T23:11:35ZcypherpunksStop this usability hell while using bridges (at least give more hints)1. What I am trying to do:
Going to https://bridges.torproject.org/ and building-up a basic layer of anger while solving the captcha (so far everything is alright) in order to get bridge addresses for Vidalia and Orbot to surf on the we...1. What I am trying to do:
Going to https://bridges.torproject.org/ and building-up a basic layer of anger while solving the captcha (so far everything is alright) in order to get bridge addresses for Vidalia and Orbot to surf on the web using a tor bridge.
2. What actually happens:
I'm copying and pasting the whole line starting with "bridge" - because that's what seems to be most intuitive - of course it doesn't work. But it's not explained on bridges.torproject.org (or in the automated mail) that this is the wrong thing to do, nor is it explained in Vidalia.
Vidalia gives a hint:
> > [Warning] We were supposed to connect to bridge '!12.345.67.890:1234' using pluggable transport 'bridge', but we can't find a pluggable transport proxy supporting 'bridge'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
While it's nice of Vidalia giving a hint why it fails to connect, this one is not easy enough to understand for beginners and people shouldn't even come to a point where they need to look into the message log.
Orbot shows a WARNing message in its log and tries to connect to the tor network without using this bridge.
3. It gets worse:
Suppose someone needs an obfs2 bridge and goes to https://bridges.torproject.org/?transport=obfs2
He's even more likely to go mad: How on earth should the poor soul know that he has to write
obfs2 !12.345.67.890:1235
without "bridge", but with "obfs2" prior the "!ip:port" part when using Vidalia?
Orbot seems to handle this in a better way as there are checkboxes, whether you want to use a bridge at all and whether this is an obfuscated bridge or not. And there's the hint "IP address and port of bridges" at the box where people have to write nothing more than "!ip:port". This seems to be a solution that's more obviously understandable.
4. It gets even worse:
In my experience it can easily happen that a setting in Vidalia isn't applied immediately (haven't tested when this happens exactly). So suppose someone is trying to figure out how the syntax of using different types of bridges with Vidalia looks like - such a person might get completely confused. Additional fun: Mix in errors such as mistyping a symbol, blocked ports and bridges which are offline.
5. Possible solutions:
I don't have a clue what's the best way to uniformly (regarding Vidalia, Orbot etc. as well as regarding new pluggable transports) solve this problem to make Tor more user-friendly. Surely it would be eased a lot by just writing some explanations in Vidalia or on bridges.torproject.org and into the automated mails.Tomas ToucedaTomas Toucedahttps://gitlab.torproject.org/legacy/trac/-/issues/8727ServerTransportListenAddr validation should validate that transport-name is w...2020-06-13T14:28:46ZGeorge KadianakisServerTransportListenAddr validation should validate that transport-name is well-formedSomeone put in his torrc:
```
ServerTransportListenAddr obfs2,obfs3 0.0.0.0:56831 0.0.0.0:56832
```
inspired by the format of ServerTransportPlugin. Unfortunately, this is not the correct way to use ServerTransportListenAddr. The correct...Someone put in his torrc:
```
ServerTransportListenAddr obfs2,obfs3 0.0.0.0:56831 0.0.0.0:56832
```
inspired by the format of ServerTransportPlugin. Unfortunately, this is not the correct way to use ServerTransportListenAddr. The correct way is:
```
ServerTransportListenAddr obfs2 0.0.0.0:56831
ServerTransportListenAddr obfs3 0.0.0.0:56832
```
We should at least validate that the first argument of the line is a pluggable transport name (C-identifier) to avoid stuff like "obfs2,obfs3".Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/8749Return information about the leaking application2020-06-13T14:28:50ZbastikReturn information about the leaking applicationLog from where the leaking request came.
When Tor says (in the Vidalia log):
> Potentially Dangerous Connection! - One of your applications established a connection through Tor to "!IP:PORT" using a protocol that may leak information a...Log from where the leaking request came.
When Tor says (in the Vidalia log):
> Potentially Dangerous Connection! - One of your applications established a connection through Tor to "!IP:PORT" using a protocol that may leak information about your destination. Please ensure you configure your applications to use only SOCKS4a or SOCKS5 with remote hostname resolution.
could Tor tell what port the connection was made from? Maybe the log could include SOCKS details (like username). I don't think it isn't able to identify the application.
Sure it's bad to use random stuff with Tor, but this information makes it easier to sort out applications that leak.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/8954Need a better convention for testing option variable names2020-06-13T14:29:21ZNick MathewsonNeed a better convention for testing option variable namesIn #6752, I noticed a troublesome point about some of our Testing* options. The convention is that these options can only take a non-default value when TestingTorNetwork is set. So we might have something like:
```
TestingBeVerySecu...In #6752, I noticed a troublesome point about some of our Testing* options. The convention is that these options can only take a non-default value when TestingTorNetwork is set. So we might have something like:
```
TestingBeVerySecure 0
```
to mean that we should turn off the security feature "BeVerySecure", and that this is an option you can only set when TestingTorNetwork is enabled.
But the trouble happens when you go to read the code and you see something like
```
if (options->TestingBeVerySecure) {
....
}
```
which gives the impression that the block will only be executed when some kind of Testing feature is enabled, which is not the case.
I think we need a better convention here.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9156BridgeDB: Users try to add obfsbridges to their normal TBB2020-06-13T18:26:44ZGeorge KadianakisBridgeDB: Users try to add obfsbridges to their normal TBBPhoul told me today that some users get bridges from the new BridgeDB page, and then try to add them to a normal Tor Browser Bundle (that doesn't understand PTs).
This means that those users completely ignored 'Step 1: Get the Pluggable...Phoul told me today that some users get bridges from the new BridgeDB page, and then try to add them to a normal Tor Browser Bundle (that doesn't understand PTs).
This means that those users completely ignored 'Step 1: Get the Pluggable Transports Tor Browser Bundle'. Can we help those users out somehow?
We could **force** users to download the bundle by making BridgeDB a wizard that actually requires you to do step 1 before proceeding to step 2. I'm not sure if this is a good idea though. It might infuriate users who know what they are doing.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/9323Option to start as a bridge by default, but change to relay if bw is super-high.2020-06-13T14:30:44ZGriffin BoyceOption to start as a bridge by default, but change to relay if bw is super-high.There are some minor ongoing problems with Tor speed, which has cascade effects in user adoption and accessibility.
If there were a type of node that starts as a middle relay and changes into a bridge if average speed in the past day we...There are some minor ongoing problems with Tor speed, which has cascade effects in user adoption and accessibility.
If there were a type of node that starts as a middle relay and changes into a bridge if average speed in the past day were unacceptably low, that could dramatically improve mean transfer time. And then, if conditions improved, a convertible node would change from a bridge back to a relay.
Given that bridges become unusable in the most high-risk areas in just a few days (Winter & Lindskag 2012), its side effect of increasing the bridge population would be a very positive thing.Tor: unspecifiedTomas ToucedaTomas Touceda