The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-06-18T18:25:22Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4696add OutboundBindInterface option to torrc2021-06-18T18:25:22ZTracadd OutboundBindInterface option to torrcFirst, I am well-aware that there is OutboundBindAddress option in tor.
I am also aware that tor "automatically" chooses an IP address/interface to bind to (if OutboundBindAddress is not specified) based on the current routing table.
...First, I am well-aware that there is OutboundBindAddress option in tor.
I am also aware that tor "automatically" chooses an IP address/interface to bind to (if OutboundBindAddress is not specified) based on the current routing table.
There are quite a few instances where OutboundBindAddress option is not suitable, particularly where the IP address changes frequently (vpn as well as most dhcp-dependant interfaces).
Whether I use OutboundBindAddress or just leave tor to make a decision which address to bind to is not suitable (at least) in the following two cases:
1. When I temporarily loose my IP address which tor has used up until now due to dhcp client renewing its lease (and receive a new IP address) and that doesn't happen - for whatever reason - instantly.
This results in one of two possible - wrong - outcomes: a) in case of absence of OutboundBindAddress option, Tor decides that my IP address "has changed" and tries to bind to the default interface, which may not be the one I have used previously; or b) when OutboundBindAddress is specified, tor just sits there trying to use the "old" address specified, resulting in a stall.
2. When I temporarily loose my current IP address due to vpn connection becoming (temporarily) unstable and it takes a bit of time for my machine to renew its IP address (this may take from a minute to up to 20+ minutes depending on the status of the vpn server at the other end) the outcome is exactly the same as I listed above - tor either tries to use the default interface (wrong!) or tries to bind to the IP address I specified with OutboundBindAddress (wrong again).
With the introduction of this new (OutboundBindInterface) option, tor can follow the IP address on the specified *interface* (regardless of what that might be) and the above - erroneous - outcome could be avoided.
**Trac**:
**Username**: mr-4https://gitlab.torproject.org/tpo/core/tor/-/issues/4391`GETINFO ns/all` doesn't return 'p' lines -- make something that does!2021-06-18T18:25:22ZTrac`GETINFO ns/all` doesn't return 'p' lines -- make something that does!The ns/all GETINFO controller command doesn't send any p lines. The spec doesn't actually require them, but they'd be helpful to have.
**Trac**:
**Username**: katmagicThe ns/all GETINFO controller command doesn't send any p lines. The spec doesn't actually require them, but they'd be helpful to have.
**Trac**:
**Username**: katmagichttps://gitlab.torproject.org/tpo/core/tor/-/issues/4386Requesting better "too slow" warning message2021-06-18T18:25:22ZTracRequesting better "too slow" warning messageOver an 18-hour period Tor v0.2.2.34 logged 5 instances of "Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy...Over an 18-hour period Tor v0.2.2.34 logged 5 instances of "Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy." with several hundred more messages suppressed.
Since I've never seen these message before and because I've changed nothing in the 10 days since I updated to v0.2.2.34, I feel pretty confident I can blow off these warnings.
The message, though, give no indication of how far I am from being able to handle the number of pending requests. How would I know what value to configure MaxAdvertisedBandwidth with? How much more restrictive does the exit policy need to be? The problem is that I don't know if it was a single connection that couldn't be accomplished or 10,000 connections. If the former it makes sense to tweak my config; if the latter I can safely dismiss the warnings as resulting from some sort of attempted attack.
So... can we get more info in the "too slow" warning messages?
Thanks.
**Trac**:
**Username**: tmpname0901https://gitlab.torproject.org/tpo/core/tor/-/issues/2282Publish router descriptors rejected by the authorities or omitted from the co...2021-06-18T18:25:21ZRobert RansomPublish router descriptors rejected by the authorities or omitted from the consensusRight now, if a relay is dropped from the consensus, or its descriptor is rejected outright by the directory authorities, we won't find out that it has happened unless someone notices that their relay isn't working and tells us, and we c...Right now, if a relay is dropped from the consensus, or its descriptor is rejected outright by the directory authorities, we won't find out that it has happened unless someone notices that their relay isn't working and tells us, and we can't find out why it happened unless we read the directory authorities' log files.
The directory authorities should:
* archive _all_ descriptors that are published to them, even if they are rejected or not included in the consensus;
* if a descriptor is rejected, record the reason in that archive; and
* if a relay is omitted from the consensus, record the reason in the archive.
The directory authority operators should:
* examine a sample of the descriptors that are not included in the consensus, for whatever reason;
* if the descriptors in the sample do not contain particularly sensitive information, begin publishing these otherwise unpublished descriptors.
Having this information available would make it easier to find relays that were disabled by legacy/trac#2204 and inform their operators that they need to upgrade Tor, for example.https://gitlab.torproject.org/tpo/core/tor/-/issues/11059Nodes' country codes should be "definite" and "possible"2021-06-18T18:21:29ZNick MathewsonNodes' country codes should be "definite" and "possible"It would maybe be a good idea if nodes' country codes could have different statues, like "definitely in CC" or "possibly in CC". For example, if a country is "possibly in CC", then "ExcludeNodes {CC}" should exclude it, but "EntryNodes ...It would maybe be a good idea if nodes' country codes could have different statues, like "definitely in CC" or "possibly in CC". For example, if a country is "possibly in CC", then "ExcludeNodes {CC}" should exclude it, but "EntryNodes {CC}" should not include it.
This would also let us provide the feature that some operators have asked for of being able to specify their country. (I'd say that if you specify that you are in C1, but geoip says you are in C2, then you should count as "maybe in C1" and "maybe in C2" but not as definitely in either.)
See legacy/trac#11054 for another motivating example.
Is this a good idea?https://gitlab.torproject.org/tpo/core/tor/-/issues/11010add ClientConnectPolicy config option2021-06-18T18:21:28Zcypherpunksadd ClientConnectPolicy config optionThere should be a config option called ClientExitPolicy which specifies which destinations clients are allowed to build circuits to. The default value should be "accept *:*".
This will deprecate the RejectPlaintextPorts option as it wil...There should be a config option called ClientExitPolicy which specifies which destinations clients are allowed to build circuits to. The default value should be "accept *:*".
This will deprecate the RejectPlaintextPorts option as it will be able to provide the same functionality.
I am beginning to work on a patch for this.https://gitlab.torproject.org/tpo/core/tor/-/issues/10186Backtrace support for windows2021-06-18T18:21:28ZNick MathewsonBacktrace support for windowsWith legacy/trac#9299, we added backtrace support for nearly all operating systems. Naturally, this doesn't include windows, because Windows Is Different.
We should use StackWalk64 to walk the stack, and we should use SetUnhandledExcept...With legacy/trac#9299, we added backtrace support for nearly all operating systems. Naturally, this doesn't include windows, because Windows Is Different.
We should use StackWalk64 to walk the stack, and we should use SetUnhandledException filtuer to detect crashes, or whatever the preferred mechanisms are.https://gitlab.torproject.org/tpo/core/tor/-/issues/10052Tor Windows service should reload its configuration on SERVICE_CONTROL_PARAMC...2021-06-18T18:21:28ZTracTor Windows service should reload its configuration on SERVICE_CONTROL_PARAMCHANGE control codeThe Tor Windows service does not currently support reloading its configuration without stopping or restarting. This functionality is provided on other operating systems by sending the `SIGHUP` signal to a Tor process.
Windows services i...The Tor Windows service does not currently support reloading its configuration without stopping or restarting. This functionality is provided on other operating systems by sending the `SIGHUP` signal to a Tor process.
Windows services implement this kind of functionality by [registering](http://msdn.microsoft.com/en-us/library/ms685054%28v=vs.85%29.aspx) to the service manager to [listen](http://msdn.microsoft.com/en-us/library/ms683240%28v=vs.85%29.aspx) for control codes. Therefore the Tor Windows service should implement reloading its configuration on `SERVICE_CONTROL_PARAMCHANGE`.
**NOTE:** Because service control codes are only supported since Windows XP, it does not need to be implemented for Windows 2000.
**NOTE 2:** Functionality that is provided by sending other signals to a Tor process on other operating systems should be implemented as user defined control codes. Initial documentation on implementing every single one of those control codes should be recorded as separate trac tickets while probably being a child of this ticket.
**Trac**:
**Username**: GITNEhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9998resolve "localhost", "host", "hostname" and "host.localdomain" to 127.0.0.12021-06-18T18:21:28Zproperresolve "localhost", "host", "hostname" and "host.localdomain" to 127.0.0.1I would be useful, if Tor would resolve:
* localhost
* host
* hostname
* host.localdomain
to 127.0.0.1.
For example, webhttrac wants to open http://host:8080/. Why not resolve host to 127.0.0.1? There are also other web interfaces (i2...I would be useful, if Tor would resolve:
* localhost
* host
* hostname
* host.localdomain
to 127.0.0.1.
For example, webhttrac wants to open http://host:8080/. Why not resolve host to 127.0.0.1? There are also other web interfaces (i2p, yacy, etc.) which may use http://localhost:someport/ etc.
At least Tails and Whonix [reached consensus](https://labs.riseup.net/code/issues/5655) using ["host" as hostname (and so forth)](https://mailman.boum.org/pipermail/tails-dev/2013-January/002486.html).
Unless you're seeing any security issues with that, of course.https://gitlab.torproject.org/tpo/core/tor/-/issues/9982Use a better password-based KDF for controller passwords, authority identity ...2021-06-18T18:21:28ZNick MathewsonUse a better password-based KDF for controller passwords, authority identity key encryption, and moreWith the ed25519 key transition, we'll want to start bringing offline identity keys to regular relay operators (and ideally hidden service operators too somehow, if we can figure out a non-stupid way for it to interact with legacy/trac#8...With the ed25519 key transition, we'll want to start bringing offline identity keys to regular relay operators (and ideally hidden service operators too somehow, if we can figure out a non-stupid way for it to interact with legacy/trac#8106).
As we do this, we'll want a better password-based KDF. Right now we have the very silly "NID_pbe_WithSHA1And3_Key_TripleDES_CBC" for protecting authority keys, and the very silly OpenPGP KDF for hashing controller passwords. Let's do something from the 21st century.
This is a bikeshed discussion. I nominate: "Derive keys with scrypt-jane, with salsa20/8 and SHA512."https://gitlab.torproject.org/tpo/core/tor/-/issues/8749Return information about the leaking application2021-06-18T18:21:28ZbastikReturn 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.https://gitlab.torproject.org/tpo/core/tor/-/issues/8278Wrap conditionally-compiled C files in #ifdefs2021-06-18T18:21:28ZNick MathewsonWrap conditionally-compiled C files in #ifdefsFor people editing Tor with an IDE, it can be helpful to have the files which won't get built surrounded with appropriate #ifdef blocks. That way, their IDE won't complain that the file is uncompileable when in fact it's not even suppos...For people editing Tor with an IDE, it can be helpful to have the files which won't get built surrounded with appropriate #ifdef blocks. That way, their IDE won't complain that the file is uncompileable when in fact it's not even supposed to get built.
This is also an issue for people writing their own build scripts/tools for Tor and getting it wrong, but I'm less interested in handling that case.
This ticket is more or less in "Lorax" status. ("Unless someone like you cares a whole awful lot / nothing is going to get better. It's not.") I'll take a clean patch for it in 0.2.5 or later if somebody writes one.https://gitlab.torproject.org/tpo/core/tor/-/issues/7798Use directory guards even when consensus isn't live2021-06-18T18:21:27ZNick MathewsonUse directory guards even when consensus isn't liveOur initial directory guard implementation only works when we have a live consensus to find out the directory guards' IP addresses. So it's an improvement, but it's hardly a perfect solution.
We should instead remember our guards' IP a...Our initial directory guard implementation only works when we have a live consensus to find out the directory guards' IP addresses. So it's an improvement, but it's hardly a perfect solution.
We should instead remember our guards' IP addresses in our state file, and try to use our directory guards even when we don't have a consensus. This will require consideration about handling our guards being down and handling the network being down.https://gitlab.torproject.org/tpo/core/tor/-/issues/11360Listen on IPv6 by default for SocksPort *:Port2021-06-18T18:20:31ZDavid Gouletdgoulet@torproject.orgListen on IPv6 by default for SocksPort *:PortThat would be very useful if tor could listen on both IPv4 and IPv6 for the SocksPort. One use case is for Torsocks to work seamlessly with v4 and v6 without having to configure a v6 port in the configuration file and restart the daemon....That would be very useful if tor could listen on both IPv4 and IPv6 for the SocksPort. One use case is for Torsocks to work seamlessly with v4 and v6 without having to configure a v6 port in the configuration file and restart the daemon.
One way to fix that would be to change the function parse_port_config() in _src/or/config.c_ to allow multiple default values adding v6 defaults (which would benefit other ports as well).
Else, having a check somewhere that adds other defaults for specific ports but not sure that it's a good idea nor makes sense in the long run in terms of maintainability.
I thought also about bringing back legacy/trac#4760 by default and setting the ipv6 only option only and only if the user has defined an option in the torrc explicitly. For instance, this in the torrc would ONLY allow v6 (remove dual stack).
```
SocksPort [::1]:9050
```
Thoughts?https://gitlab.torproject.org/tpo/core/tor/-/issues/17233MinMeasuredBWsForAuthToIgnoreAdvertised should be lower for Testing networks?2021-06-18T18:15:52ZRoger DingledineMinMeasuredBWsForAuthToIgnoreAdvertised should be lower for Testing networks?```
config.c: V(MinMeasuredBWsForAuthToIgnoreAdvertised, INT, "500"),
```
weasel points out that maybe this should be 0 for testing tor networks?```
config.c: V(MinMeasuredBWsForAuthToIgnoreAdvertised, INT, "500"),
```
weasel points out that maybe this should be 0 for testing tor networks?https://gitlab.torproject.org/tpo/core/tor/-/issues/17134Add a way to say "Use this option only if supported" in torrc2021-06-18T18:15:52ZNick MathewsonAdd a way to say "Use this option only if supported" in torrcIt would be nice to have a torrc that sets some option _when Tor supports that option_, but not otherwise (eg when older versions of Tor read it).
There are two ways to do this I can think of:
1. **Future-compatible only**
We could ha...It would be nice to have a torrc that sets some option _when Tor supports that option_, but not otherwise (eg when older versions of Tor read it).
There are two ways to do this I can think of:
1. **Future-compatible only**
We could have a new syntax, something like `?Option Value`. Meaning: if the option is prefixed with a question mark, it does not cause an error when unrecognized. (It _should_ cause a warning.)
2. **Backward-compatible too, kinda ugly**
We could have a syntax that old Tor versions interpret as a comment, but which new Tor versions interpret as above. My first thought is to use some magic string like `#$%^option value`. This could cause problems if anybody is actually writing comments like that.https://gitlab.torproject.org/tpo/core/tor/-/issues/16785Only build/use ed25519-donna.2021-06-18T18:15:52ZYawning AngelOnly build/use ed25519-donna.More a long term thing so I don't forget about it, but once we are sure we like `ed25519-donna`, we can/should remove the `ref10` code from builds, along with the paranoid initialization/runtime sanity checking, as well as only using the...More a long term thing so I don't forget about it, but once we are sure we like `ed25519-donna`, we can/should remove the `ref10` code from builds, along with the paranoid initialization/runtime sanity checking, as well as only using the donna Curve25519 keypair generation code.
I'd be ok with keeping the code around as part of the test suite to catch mysterious breakage. Tentatively setting this to `0.2.8.x-final` since I don't think enough people run the alpha build for us to catch discrepancies between the two codebases if any exist.https://gitlab.torproject.org/tpo/core/tor/-/issues/16636Add AccountingSetBytesRead/Written2021-06-18T18:15:52ZteorAdd AccountingSetBytesRead/WrittenA relay operator asked for the ability to reset the state file's `AccountingBytesReadInInterval` and `AccountingBytesWrittenInInterval` values.
While a workaround is to edit or delete the state file, perhaps command-line arguments `Acco...A relay operator asked for the ability to reset the state file's `AccountingBytesReadInInterval` and `AccountingBytesWrittenInInterval` values.
While a workaround is to edit or delete the state file, perhaps command-line arguments `AccountingSetRead` and `AccountingSetWritten` could be useful.
See also legacy/trac#15989 for `AccountingRule` `in` and `out`, as well as the `AccountingEnableDirPort` override.https://gitlab.torproject.org/tpo/core/tor/-/issues/13738Make worker handle introduction point crypto2021-06-18T18:15:52ZDavid Gouletdgoulet@torproject.orgMake worker handle introduction point cryptoLinked to legacy/trac#13737 to send crypto related task to worker.Linked to legacy/trac#13737 to send crypto related task to worker.https://gitlab.torproject.org/tpo/core/tor/-/issues/19321controller: Ensure events exist for all guard state transitions2021-06-18T18:13:21ZNick Mathewsoncontroller: Ensure events exist for all guard state transitions