The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:02:54Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12226Make Strict{Entry,Exit}Nodes obsolete, rather than synonym for StrictNodes?2020-06-27T14:02:54ZRoger DingledineMake Strict{Entry,Exit}Nodes obsolete, rather than synonym for StrictNodes?Right now if you type "StrictExitNodes 1" you quietly get the behavior that a) this line is ignored for your ExitNodes selection, but b) if you set ExcludeNodes then it interprets it fanatically.
Since StrictExitNodes and StrictEntryNod...Right now if you type "StrictExitNodes 1" you quietly get the behavior that a) this line is ignored for your ExitNodes selection, but b) if you set ExcludeNodes then it interprets it fanatically.
Since StrictExitNodes and StrictEntryNodes have been non-functional in this way for a while, should we make them OBSOLETE() rather than a synonym for a different (albeit similar sounding) config option?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12194rend_client_note_connection_attempt_ended() gets called redundantly2020-06-27T14:02:56ZAndrea Shepardrend_client_note_connection_attempt_ended() gets called redundantlyWhen hidden service connection attempts fail, rend_client_note_connection_attempt_ended() can get called once from connection_mark_unattached_ap() and then again from rend_client_desc_trynow() after it returns. See the log snippet in le...When hidden service connection attempts fail, rend_client_note_connection_attempt_ended() can get called once from connection_mark_unattached_ap() and then again from rend_client_desc_trynow() after it returns. See the log snippet in legacy/trac#10616 for an example.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11679Download status for consensus scheduled as generic2020-06-27T14:03:03ZcypherpunksDownload status for consensus scheduled as genericCurrently download status scheduled as generic (DL_SCHED_GENERIC = 0);
```
/** Download status for the current consensus networkstatus. */
static download_status_t consensus_dl_status[N_CONSENSUS_FLAVORS];
```
Before [implementing](https...Currently download status scheduled as generic (DL_SCHED_GENERIC = 0);
```
/** Download status for the current consensus networkstatus. */
static download_status_t consensus_dl_status[N_CONSENSUS_FLAVORS];
```
Before [implementing](https://gitweb.torproject.org/tor.git/commitdiff/851a980065e6b2df8d7cb35a22d0675b8918214b) of consensus for md it was DL_SCHED_CONSENSUS:
```
static download_status_t consensus_dl_status = { 0, 0, DL_SCHED_CONSENSUS };
```
That means unfriendly schedule for client with fragile network connection.
```
/** Schedule for when clients should download things in general. */
static const int client_dl_schedule[] = {
0, 0, 60, 60*5, 60*10, INT_MAX
};
```
vs.
```
/** Schedule for when clients should download consensuses. */
static const int client_consensus_dl_schedule[] = {
0, 0, 60, 60*5, 60*10, 60*30, 60*60, 60*60, 60*60, 60*60*3, 60*60*6, 60*60*12
};
```
Tor will reset download status by `networkstatus_reset_download_failures` once a hour so client will have a chance to retry, so no unresolved state actually.
Is it worth to initialize download status for consensus schedule? Or to rename schedule if planned to use it for certs only?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11543Clarify libseccomp "platform not supported" warning.2020-06-27T14:03:07ZNick MathewsonClarify libseccomp "platform not supported" warning.Here's an unhelpful thing: "Sandboxing is not implemented for your platform. The feature is currently disabled".
Probably better to distinguish whether sandboxing would work if we had a different kernel (old linux), or if we had libsecc...Here's an unhelpful thing: "Sandboxing is not implemented for your platform. The feature is currently disabled".
Probably better to distinguish whether sandboxing would work if we had a different kernel (old linux), or if we had libseccomp (new linux, built without libseccomp), or not at all (freebsd etc).Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11542Add a new logging domain for transport proxies2020-06-27T14:03:07ZwfnAdd a new logging domain for transport proxiesvelope suggested (and nickm is not against the idea of) adding a new logging domain for all the stuff to do with transport proxies / PTs. It would sure be nice to have transport proxy output like legacy/trac#9957 go to that specific doma...velope suggested (and nickm is not against the idea of) adding a new logging domain for all the stuff to do with transport proxies / PTs. It would sure be nice to have transport proxy output like legacy/trac#9957 go to that specific domain; it would make debugging PT things easier, I think.
Does this make sense, or is there simply no need for it, really?Tor: 0.4.0.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11452undef DEAD_CERT_LIFETIME too in trusted_dirs_remove_old_certs()2020-06-27T14:03:12ZRoger Dingledineundef DEAD_CERT_LIFETIME too in trusted_dirs_remove_old_certs()In trusted_dirs_remove_old_certs() we have
```
#define DEAD_CERT_LIFETIME (2*24*60*60)
#define OLD_CERT_LIFETIME (7*24*60*60)
[...use them...]
#undef OLD_CERT_LIFETIME
```
Shouldn't we undef both (or neither)?
Introduced in git commit ...In trusted_dirs_remove_old_certs() we have
```
#define DEAD_CERT_LIFETIME (2*24*60*60)
#define OLD_CERT_LIFETIME (7*24*60*60)
[...use them...]
#undef OLD_CERT_LIFETIME
```
Shouldn't we undef both (or neither)?
Introduced in git commit 8157b8b7.Tor: unspecifiedhttps://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/11325RFE: Adhere to XDB base directory specification2020-06-27T14:03:15ZTracRFE: Adhere to XDB base directory specificationAs noted by a Fedora user [1], when running Tor as a regular user it creates "$HOME/.tor" instead of "$XDG_CACHE_HOME/.tor", which is advised by the XDG specification [2] for user-specific non-essential (cached) data. Would you consider ...As noted by a Fedora user [1], when running Tor as a regular user it creates "$HOME/.tor" instead of "$XDG_CACHE_HOME/.tor", which is advised by the XDG specification [2] for user-specific non-essential (cached) data. Would you consider adhering to this specification?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=968163
[2] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
**Trac**:
**Username**: jamielinuxTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11279Quiet some warns for protocol errors setting rendezvous points2020-06-27T14:03:17ZRoger DingledineQuiet some warns for protocol errors setting rendezvous pointsIn https://lists.torproject.org/pipermail/tor-relays/2014-March/004031.html we see a relay operator reporting lots of "Invalid length on ESTABLISH_RENDEZVOUS" errors.
The code in question is in rend_mid_establish_rendezvous():
```
if ...In https://lists.torproject.org/pipermail/tor-relays/2014-March/004031.html we see a relay operator reporting lots of "Invalid length on ESTABLISH_RENDEZVOUS" errors.
The code in question is in rend_mid_establish_rendezvous():
```
if (request_len != REND_COOKIE_LEN) {
log_warn(LD_PROTOCOL, "Invalid length on ESTABLISH_RENDEZVOUS.");
```
Seems to me that log_warn should be a log_protocol_warn, since there's nothing the relay operator should do about some client not obeying the protocol.
Are there other log_warns in this vicinity that we should change also? I looked around a bit and didn't see others.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11060socks-extensions.txt says username/password are ignored2021-07-22T16:26:02ZRoger Dingledinesocks-extensions.txt says username/password are ignoredIn torspec's socks-extensions.txt, we say
```
and as of Tor 0.2.3.2-alpha, the "USERNAME/PASSWORD" (SOCKS5)
authentication method [02] is supported too. Any credentials passed to
the latter are ignored.
```
But don't we use ...In torspec's socks-extensions.txt, we say
```
and as of Tor 0.2.3.2-alpha, the "USERNAME/PASSWORD" (SOCKS5)
authentication method [02] is supported too. Any credentials passed to
the latter are ignored.
```
But don't we use them for stream isolation now?
Also (hit-and-run two-bugs-in-one-ticket faux pas, sorry), the Tor man page says:
```
IsolateSOCKSAuth
Don’t share circuits with streams for which different SOCKS
authentication was provided. (On by default; you can disable it
with NoIsolateSOCKSAuth.)
```
which makes it sound like we look at SOCKS4 username too -- maybe we should change SOCKS to SOCKS5 in this man page stanza?Tor: 0.2.5.x-finalhttps://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/10614pt-spec.txt describes using `keyid=fingerprint` in torrc `Bridge` lines2020-06-27T14:03:31ZIsis Lovecruftpt-spec.txt describes using `keyid=fingerprint` in torrc `Bridge` linesdcf pointed out in [this comment](https://trac.torproject.org/projects/tor/ticket/10559#comment:1) on legacy/trac#10559 that `pt-spec.txt` claims that little-t tor's parsing of `Bridge` lines was extended to support `keyid=fingerprint` (...dcf pointed out in [this comment](https://trac.torproject.org/projects/tor/ticket/10559#comment:1) on legacy/trac#10559 that `pt-spec.txt` claims that little-t tor's parsing of `Bridge` lines was extended to support `keyid=fingerprint` (where `fingerprint` is the digest of the bridge's ID key).
Little-t tor does not support this `keyid=` prefix. I've tested it; see [comment 3](https://trac.torproject.org/projects/tor/ticket/9499#comment:3) and [comment 4](https://trac.torproject.org/projects/tor/ticket/9499#comment:4) on legacy/trac#9449. Since it wasn't ever implemented, the `keyid=` prefix to bridge fingerprints should be removed from `pt-spec.txt` [L27](https://gitweb.torproject.org/torspec.git/blob/782dacf43035892a0025b252f99018a6a1082b0e:/pt-spec.txt#l27).Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/10485Heartbeat doesn't include 'circuit stats since last time'2020-06-27T14:03:34ZcypherpunksHeartbeat doesn't include 'circuit stats since last time'This message is shown every 30 minutes, as per my HeartbeatPeriod.
```
[NOTICE] Heartbeat: Tor's uptime is xxx hours, with xxx circuits open. I've sent xxx and received xxx GB.
```
This message is not (and I don't know how to control ho...This message is shown every 30 minutes, as per my HeartbeatPeriod.
```
[NOTICE] Heartbeat: Tor's uptime is xxx hours, with xxx circuits open. I've sent xxx and received xxx GB.
```
This message is not (and I don't know how to control how frequently it is shown).
```
[NOTICE] Circuit handshake stats since last time: x/x TAP, x/x NTor.
```
How can I make the latter message as frequent/infrequent as I like? Can it be merged into the HeartbeatPeriod?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10451Allow me to have a short HeartBeatPeriod2020-06-27T14:03:35ZcypherpunksAllow me to have a short HeartBeatPeriod```
Dec 20 20:07:47.000 [warn] HeartbeatPeriod option is too short; raising to 1800 seconds.
```
```
HeartbeatPeriod 5 minutes
```
```
Tor version 0.2.4.19 (git-9a83ee5e4d3cece4).
```
Please let me have a short HeartbeatPeriod! It'd be ...```
Dec 20 20:07:47.000 [warn] HeartbeatPeriod option is too short; raising to 1800 seconds.
```
```
HeartbeatPeriod 5 minutes
```
```
Tor version 0.2.4.19 (git-9a83ee5e4d3cece4).
```
Please let me have a short HeartbeatPeriod! It'd be appreciated. Sometimes, I can't run tor-arm but I want frequent status updates.https://gitlab.torproject.org/tpo/core/tor/-/issues/10427Point operators of new relay to the lifecycle document2020-06-27T14:03:36ZLunarPoint operators of new relay to the lifecycle documentIt's quite often that operators of new relays wonder why they are not seeing all their bandwidth used immediately. I wonder if it would help to add a log message like: _You are running a new relay. Thanks for helping the Tor network! If ...It's quite often that operators of new relays wonder why they are not seeing all their bandwidth used immediately. I wonder if it would help to add a log message like: _You are running a new relay. Thanks for helping the Tor network! If you wish to know what will happen in the upcoming weeks regarding its usage, have a look at https://blog.torproject.org/blog/lifecycle-of-a-new-relay_Tor: 0.2.6.x-finalhttps://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/10168Use monotonic clocks for time as appropriate2020-07-24T15:21:57ZNick MathewsonUse monotonic clocks for time as appropriateIn some places, like or or, we want to use wall-clock time. But in others, like timers and so forth, we should be using a monotonic timer so we just don't have to worry about time moving backwards.
Libevent 2.1 has a subsystem for this...In some places, like or or, we want to use wall-clock time. But in others, like timers and so forth, we should be using a monotonic timer so we just don't have to worry about time moving backwards.
Libevent 2.1 has a subsystem for this; we could just use it as needed. Or we could snarf the code and adapt it for our uses.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10060allow tor to start if torrc does not exist2020-06-27T14:03:41ZMark Smithallow tor to start if torrc does not existFor TBB 3.x, we now put all of the default settings in a torrc-defaults file. The torrc file within the Tor data directory will be reserved for the user's custom settings. The goal is to not overwrite the user's settings when they (or ...For TBB 3.x, we now put all of the default settings in a torrc-defaults file. The torrc file within the Tor data directory will be reserved for the user's custom settings. The goal is to not overwrite the user's settings when they (or our future automatic updater) overlays a new version of TBB on top of an existing installation, while still providing a way to include default settings.
But tor will not start up if the -f command line option points to a torrc file that does not exist. Here is a proposal: if a torrc-defaults file is provided, do not require that torrc exist. If this is too difficult to implement or distasteful in some way, we could probably instead modify the programs and scripts that start the TBB browser to create an empty torrc before starting anything. That would be a little more fragile though.Tor: 0.2.5.x-finalNick MathewsonNick Mathewsonhttps://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**: GITNE