The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:03:31Zhttps://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/applications/tor-browser/-/issues/10573`nsILocalFile` should be replaced with `nsIFile` in our extensions2020-06-27T14:42:22Zcypherpunks`nsILocalFile` should be replaced with `nsIFile` in our extensions```
Warning: Starting with Gecko 14, `nsILocalFile` inherits all functions and attributes from `nsIFile`, meaning that you no longer need to use `nsILocalFile`. If your add-on doesn't support versions older than 14, you should use `nsIFi...```
Warning: Starting with Gecko 14, `nsILocalFile` inherits all functions and attributes from `nsIFile`, meaning that you no longer need to use `nsILocalFile`. If your add-on doesn't support versions older than 14, you should use `nsIFile` instead of `nsILocalFile`.
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=682360 for more information.
components/tl-protocol.js
{
var file = Cc['@mozilla.org/file/local;1'].createInstance(Ci.nsILocalFile);
file.initWithPath(aPath);
```https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10559BridgeDB writes `keyid=` before fingerprints2020-06-27T13:43:18ZIsis LovecruftBridgeDB writes `keyid=` before fingerprintsWhile testing for legacy/trac#9499, I realised that if I request https://127.0.0.1:6789/bridges?transport=obfs3 (localhost because it's a local test instance) then BridgeDB hands back bridge lines like this:
```
obfs3 245.102.100.252:236...While testing for legacy/trac#9499, I realised that if I request https://127.0.0.1:6789/bridges?transport=obfs3 (localhost because it's a local test instance) then BridgeDB hands back bridge lines like this:
```
obfs3 245.102.100.252:23619 keyid=59ca743e89b508e16b8c7c6d2290efdfd14eea98
```
which is wrong and will need to be fixed before we hand out fingerprints. This should be easy, just figure out where this string is getting added and kill it with fire.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/10534Let's not advertise help desk emails directly2020-06-27T14:42:22ZLunarLet's not advertise help desk emails directlyTor Browser 3.5 now advertises support help desk emails more prominently. While showing our users how to get help is a great idea, giving them an help desk address directly puts a severe load on the support assistants that could partiall...Tor Browser 3.5 now advertises support help desk emails more prominently. While showing our users how to get help is a great idea, giving them an help desk address directly puts a severe load on the support assistants that could partially be avoided.
I think we should rather point them to a web page with the following:
* List of Tor Browser known issues.
* Frequently Asked Questions related to Tor Browser
* Frequently Asked Questions related to Tor
* The help desk emails
That list can be refined over time.
The ticket should probably be split in multiple things, as it concerns Tor Browser release management (for the list of known issues) and the website.Mike PerryMike Perryhttps://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/anti-censorship/bridgedb/-/issues/10446BridgeDB is/was using a GeoIP module which is incompatible with virtualenvs2020-06-27T13:43:18ZIsis LovecruftBridgeDB is/was using a GeoIP module which is incompatible with virtualenvs```
04:07 [ (isis) ) sysrqb: i realised yesterday that we're actually using the wrong GeoIP module in bridgedb's requirements.txt
04:08 [ (isis) ) although the one we're using, pygeoip.GeoIP, is compatible (at least it has all the same f...```
04:07 [ (isis) ) sysrqb: i realised yesterday that we're actually using the wrong GeoIP module in bridgedb's requirements.txt
04:08 [ (isis) ) although the one we're using, pygeoip.GeoIP, is compatible (at least it has all the same functions we're using from the the GeoIP one)
04:09 [ (isis) ) i am thinking that perhaps we should keep using the "wrong" one, since it is compatible
04:10 [ (isis) ) because the "wrong" one (the pygeoip one) installs cleanly in a virtualenv, while the other one does not
04:10 [ (isis) ) i think they both require the same underlying deps, libgeoip-dev and geoip-database in Debian
04:11 [ (isis) ) which means that my README instructions which said that bridgedb requires tor-geoipdb were also wrong
```Isis LovecruftIsis Lovecrufthttps://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**: GITNEhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10027Tor Windows service should be installed with the NetworkService account2021-07-09T17:21:59ZRoger DingledineTor Windows service should be installed with the NetworkService account```
<GITNE> nickm: I have checked running Tor under the NetworkService account.
Works fine. The problem I had the last time was a missing write permission on
the log file.
<GITNE> nickm: So it should probably be safe to change GENSRV_USE...```
<GITNE> nickm: I have checked running Tor under the NetworkService account.
Works fine. The problem I had the last time was a missing write permission on
the log file.
<GITNE> nickm: So it should probably be safe to change GENSRV_USERACCT to "NT
AUTHORITY\NetworkService"
> gitne: was that because the log file was trying to go somewhere it
shouldn't? or what
> gitne: also, does that change work for every windows, or only some of them?
<GITNE> armadev: those three predefinded accounts LocalSystem, LocalService,
and NetworkService are available since Windows 2000 so Tor should be safe
with that.
```https://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/9971for_discovery option in add_an_entry_guard() is confusingly named2021-09-16T14:35:28ZRoger Dingledinefor_discovery option in add_an_entry_guard() is confusingly namedIn legacy/trac#9946 I added a new argument "for_discovery" to add_an_entry_guard(). Nick prefers "provisional" or "probationary".
In parallel, I think we should probably rename the made_contact field in entry guard t, to be *why* we're ...In legacy/trac#9946 I added a new argument "for_discovery" to add_an_entry_guard(). Nick prefers "provisional" or "probationary".
In parallel, I think we should probably rename the made_contact field in entry guard t, to be *why* we're remembering that we've made contact, rather than simply that we have.
And lastly, we should do something about the godawful number of int arguments that add_an_entry_guard() now takes.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9926Stop being willing to build 2-hop circuits when there aren't 3 relays2020-06-27T14:03:46ZRoger DingledineStop being willing to build 2-hop circuits when there aren't 3 relaysnew_route_len() ends with
```
if (num_acceptable_routers < 2) {
log_info(LD_CIRC,
"Not enough acceptable routers (%d). Discarding this circuit.",
num_acceptable_routers);
return -1;
}
if (num_acce...new_route_len() ends with
```
if (num_acceptable_routers < 2) {
log_info(LD_CIRC,
"Not enough acceptable routers (%d). Discarding this circuit.",
num_acceptable_routers);
return -1;
}
if (num_acceptable_routers < routelen) {
log_info(LD_CIRC,"Not enough routers: cutting routelen from %d to %d.",
routelen, num_acceptable_routers);
routelen = num_acceptable_routers;
}
```
We should replace this with the simpler
```
if (num_acceptable_routers < 3) {
log_info(LD_CIRC,
"Not enough acceptable routers (%d). Discarding this circuit.",
num_acceptable_routers);
return -1;
}
```
to simplify things.
Note that the "oh hey let's just use two hops" case doesn't trigger in a real Tor network, because we won't be willing to make circuits if we don't have at least x% of the descriptors, so this code only comes into play when the consensus says there are 5 or something relays total.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9860junk log messages every time SETCONF changes the set of ORPorts2021-07-09T17:21:59ZZack Weinbergjunk log messages every time SETCONF changes the set of ORPortsEvery time you use SETCONF (from a controller) to change the set of ORPorts, Tor emits log messages like this:
```
Sep 30 23:45:59.000 [notice] Opening OR listener on 0.0.0.0:9022
Sep 30 23:45:59.000 [notice] Tor 0.2.4.17-rc-dev (git-00...Every time you use SETCONF (from a controller) to change the set of ORPorts, Tor emits log messages like this:
```
Sep 30 23:45:59.000 [notice] Opening OR listener on 0.0.0.0:9022
Sep 30 23:45:59.000 [notice] Tor 0.2.4.17-rc-dev (git-00fb525+ace95c5+0e691f1) opening log file.
Sep 30 23:46:00.000 [notice] Your Tor server's identity key fingerprint is 'tbbscraperentry 73EFD4FE8D5D2466ECBDCFAC11894A72A322FD3C'
Sep 30 23:47:42.000 [notice] Opening OR listener on 0.0.0.0:9023
Sep 30 23:47:42.000 [notice] Tor 0.2.4.17-rc-dev (git-00fb525+ace95c5+0e691f1) opening log file.
Sep 30 23:47:42.000 [notice] Your Tor server's identity key fingerprint is 'tbbscraperentry 73EFD4FE8D5D2466ECBDCFAC11894A72A322FD3C'
Sep 30 23:50:40.000 [notice] Closing no-longer-configured OR listener on 0.0.0.0:9008
Sep 30 23:50:40.000 [notice] Tor 0.2.4.17-rc-dev (git-00fb525+ace95c5+0e691f1) opening log file.
Sep 30 23:50:40.000 [notice] Closing old OR listener on 0.0.0.0:9008
Sep 30 23:50:40.000 [notice] Your Tor server's identity key fingerprint is 'tbbscraperentry 73EFD4FE8D5D2466ECBDCFAC11894A72A322FD3C'
Sep 30 23:50:45.000 [notice] Closing no-longer-configured OR listener on 0.0.0.0:9012
Sep 30 23:50:45.000 [notice] Tor 0.2.4.17-rc-dev (git-00fb525+ace95c5+0e691f1) opening log file.
Sep 30 23:50:45.000 [notice] Closing old OR listener on 0.0.0.0:9012
Sep 30 23:50:45.000 [notice] Your Tor server's identity key fingerprint is 'tbbscraperentry 73EFD4FE8D5D2466ECBDCFAC11894A72A322FD3C'
```
The "opening log file" and "Your Tor server's identity key fingerprint is" lines should not be printed for every configuration change. And I'm not sure why it tells me it's closing a listener twice.https://gitlab.torproject.org/tpo/core/tor/-/issues/9841Faster implementation for circuit_get_by_rend_token_and_purpose()2020-06-27T14:03:48ZNick MathewsonFaster implementation for circuit_get_by_rend_token_and_purpose()According to https://lists.torproject.org/pipermail/tor-relays/2013-September/002715.html , https://lists.torproject.org/pipermail/tor-relays/2013-September/002715.html can be 6% of a relay's runtime.
This is another function that does ...According to https://lists.torproject.org/pipermail/tor-relays/2013-September/002715.html , https://lists.torproject.org/pipermail/tor-relays/2013-September/002715.html can be 6% of a relay's runtime.
This is another function that does a linear search when a hashtable lookup would be more appropriate.
We'll need to be a little careful, since there's nothing preventing collisions here: An intro circuit and a rendezvous circuit can have the same "token" pretty easily.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9839man page doesn't document cached-certs file2020-06-27T14:03:49ZRoger Dingledineman page doesn't document cached-certs fileThe man page has a FILES section at the end that talks about things you'll find in your DataDirectory. It looks like we never documented the cached-certs file.
(Are we missing anything else?)The man page has a FILES section at the end that talks about things you'll find in your DataDirectory. It looks like we never documented the cached-certs file.
(Are we missing anything else?)Tor: 0.2.5.x-final