Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-03-22T13:02:42Zhttps://gitlab.torproject.org/legacy/trac/-/issues/7028Implement Adaptive Padding or some variant and measure overhead vs accuracy2022-03-22T13:02:42ZMike PerryImplement Adaptive Padding or some variant and measure overhead vs accuracyAs a defense against Website Traffic Fingerprinting, we should implement a tunable cover traffic defense that we could set from the consensus with a value dependent upon available Guard bandwidth relative to Exit capacity.
My favorite f...As a defense against Website Traffic Fingerprinting, we should implement a tunable cover traffic defense that we could set from the consensus with a value dependent upon available Guard bandwidth relative to Exit capacity.
My favorite from the research literature is http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf, because it appears to be tunable in this fashion.
The "BUFLO" variant proposed by this paper is better specified, but it's not clear it actually performs better for a given overhead quantity: http://www.cs.sunysb.edu/~xcai/fp.pdf
This is likely a research task. People who attempt it should also read http://www.raid-symposium.org/raid99/PAPERS/Axelsson.pdf (Slides: http://www.cse.psu.edu/~tjaeger/cse543-f06/presents/Kiran_baserate.pdf)Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21377DirAuths should expose bwauth bandwidth files2022-02-16T21:12:43ZTom Rittertom@ritter.vgDirAuths should expose bwauth bandwidth filesCurrently, DirAuths that vote on bwauth files do not expose the raw voting file they used. This data would be good to archive for debugging and transparency purposes.Currently, DirAuths that vote on bwauth files do not expose the raw voting file they used. This data would be good to archive for debugging and transparency purposes.Tor: 0.4.0.x-finaljugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/28805ControlPort has undocumented behavior2020-06-16T01:13:04ZTracControlPort has undocumented behavior== Problem 1
`ControlPort`'s value can be set to address:port though `man torrc` says that only port can be specified.
== Problem 2
Option `ControlPort` can be set few times to bind to different "address:port"s. This is also not docum...== Problem 1
`ControlPort`'s value can be set to address:port though `man torrc` says that only port can be specified.
== Problem 2
Option `ControlPort` can be set few times to bind to different "address:port"s. This is also not documented. Other options which can be set multiple times are explicitly documented with a statement like
```
This directive can be specified multiple times to bind to multiple addresses/ports
```
for `SocksPort`.
Original comment about these issues is [[http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28676#comment:15|here]].
**Trac**:
**Username**: wagonTor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28624Should we remember dormant state on restart?2020-06-16T01:00:03ZRoger DingledineShould we remember dormant state on restart?One of the core ideas of #2149 was for Tor to remember its dormancy across restarts. As of the finishing of #2149, Tor will go dormant 24 hours after startup if it's seen no activity -- but if you start it again, it'll be active for 24 h...One of the core ideas of #2149 was for Tor to remember its dormancy across restarts. As of the finishing of #2149, Tor will go dormant 24 hours after startup if it's seen no activity -- but if you start it again, it'll be active for 24 hours again. So people who restart their computers, or their Tor-including apps, will continue putting load on the Tor network.
So I am opening this ticket to not forget that second piece of it.
The first question is around the engineering side: when we go dormant, do we write that fact into our state file? And when we change our mind, I guess we clear it? Do we also write it when the controller commands us to go dormant? I guess yes.
The second question is about how thorough we want to be. Specifically, if we're expecting that people will restart their Tor, what about people who never leave their Tor going for a full 24 hours? Those people will never switch to a dormant state. Is that ok? The fix would be to record "partial progress towards going dormant" in the state file, which is kind of ugly but also doable.
The third question is around how to handle it when we start up and the state file says we were dormant. Continuing to stay dormant seems like the clear right behavior -- because after all, we can wake up and start bootstrapping if we actually get an application level request. But I guess that means we don't even try to bootstrap? Are there controller apps like Tor Launcher and Nyx that wait for the 100% bootstrap message and tell you that your Tor is broken if it doesn't happen? Is there something we can give those apps instead that will satisfy them that Tor is "acting as intended"? Is there some simple "connect to a relay and do a handshake with it once" thing that we can do instead on startup, to satisfy ourselves that Tor *could* work if we wanted it to? Or should we stay totally isolated from the network when we start up in dormant state?
I think some of these are ux questions, and answering them might be easier if we pick a couple of specific use cases for dormant mode. Here are two:
(1) What if some linux distro includes a Tor client package by default, and users can configure their apps to use it but many users don't. In that case we'd have thousands or millions of Tor clients installed but not usefully using the Tor network. And our primary goal there would be to make those Tors go totally quiet after a while. This was the original motivation for #2149.
(2) ...I was going to use an example here of Tor bundled with an app, like Brave or Briar, but I think in this case the app should be responsible for making Tor behave politely to the Tor network.
So I think use case (1) is the one to focus on, and that also simplifies the ux questions.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/27239TB team feedback on jump-to-80% work2020-06-16T00:49:21ZIsabela FernandesTB team feedback on jump-to-80% workHello TB team,
we would like your feedback on this work, and let us know if there is anything we need to know regarding this on Tor Browser side.Hello TB team,
we would like your feedback on this work, and let us know if there is anything we need to know regarding this on Tor Browser side.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28181spec: Add to pt-spec.txt control messages going back to main process (tor)2020-06-13T18:35:29ZDavid Gouletdgoulet@torproject.orgspec: Add to pt-spec.txt control messages going back to main process (tor)As part of #28180, we want to have a PT to report back events, mainly connection to the bridge events for now, to the parent process which is tor in our case.
This ticket is for adding those to pt-spec.txt.
We'll concentrate on connect...As part of #28180, we want to have a PT to report back events, mainly connection to the bridge events for now, to the parent process which is tor in our case.
This ticket is for adding those to pt-spec.txt.
We'll concentrate on connection messages reporting the status of a connection to a Bridge at first to narrow down a bit this work.Tor: 0.4.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28179Handle output from PT processes with the event loop2020-06-13T18:35:29ZAlexander Færøyahf@torproject.orgHandle output from PT processes with the event loopCurrently the output from stdout/stderr of a PT process is only read during the startup of the process. The reading process uses read() on a non-blocking socket, which currently seems to work, but have proved to be flaky.
We should ensu...Currently the output from stdout/stderr of a PT process is only read during the startup of the process. The reading process uses read() on a non-blocking socket, which currently seems to work, but have proved to be flaky.
We should ensure that PT processes' output can be read all the time.
On Windows we cannot attach the pipes to the main loop because of limitations of the `select()` API, so we have to do something slightly worse such as reading from the stdout/stderr handle via a timer as long as the processes are alive.Tor: 0.4.0.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25502Report intermediate PT bootstrapping status2020-06-13T18:35:28ZAlexander Færøyahf@torproject.orgReport intermediate PT bootstrapping statusParent ticket for all tickets about reporting intermediate PT bootstrap progress.Parent ticket for all tickets about reporting intermediate PT bootstrap progress.Tor: 0.4.0.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/27167track "first" OR_CONN2020-06-13T17:44:18ZTaylor Yutrack "first" OR_CONNRight now the first stages of the "first" OR_CONN get reported as `BOOTSTRAP_STATUS_CONN_DIR` and `BOOTSTRAP_STATUS_HANDSHAKE` (the latter is a special bootstrap phase that gets translated into `BOOTSTRAP_STATUS_HANDSHAKE_DIR` or `BOOTST...Right now the first stages of the "first" OR_CONN get reported as `BOOTSTRAP_STATUS_CONN_DIR` and `BOOTSTRAP_STATUS_HANDSHAKE` (the latter is a special bootstrap phase that gets translated into `BOOTSTRAP_STATUS_HANDSHAKE_DIR` or `BOOTSTRAP_STATUS_HANDSHAKE_OR` depending on how much progress was previously reported. The logic in functions that report these events should be moved up to a new abstraction so lower level code has to track less high-level state.
This also eliminates some logic in `control_event_bootstrap()` that tries to figure out whether a given handshake attempt corresponds to a directory connection or an application circuit connection.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/22266gather info on jump-to-80% issues2020-06-13T17:43:43ZTaylor Yugather info on jump-to-80% issuesThis ticket is now for gathering additional info and feedback about the category of jump-to-80% bootstrap reporting problems.
background:
If enough existing directory information is available, the bootstrap progress as reported to the ...This ticket is now for gathering additional info and feedback about the category of jump-to-80% bootstrap reporting problems.
background:
If enough existing directory information is available, the bootstrap progress as reported to the logs and the control connection jumps from 0% to 80% almost immediately. This is misleading and causes user frustration, as reported by Linda's study.
When bootstrapping with existing directory information, we should rescale the progress numbers so they advance on something resembling a linear time scale, which is probably closer to what users expect to see.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/29691Builds from master fail on Jenkins mingw builder2020-06-13T16:57:02ZTracBuilds from master fail on Jenkins mingw builderOn https://jenkins.torproject.org/view/tor/ the builds from git master for tor-ci-mingwcross-master builder are failing for a long time (Last successful build (# 2226), 2 mo 20 days ago )
A failing build log e.g. https://jenkins.torproj...On https://jenkins.torproject.org/view/tor/ the builds from git master for tor-ci-mingwcross-master builder are failing for a long time (Last successful build (# 2226), 2 mo 20 days ago )
A failing build log e.g. https://jenkins.torproject.org/view/tor/job/tor-ci-mingwcross-master/lastCompletedBuild/ARCHITECTURE=amd64,SUITE=stretch/consoleFull#-16059184715da2eb1d-1267-4376-8b22-f5f143383dc7
```
21:28:05 + cp src/test/test-child.exe /srv/jenkins-workspace/workspace/tor-ci-mingwcross-master/ARCHITECTURE/amd64/SUITE/stretch/RESULT/bin/
21:28:05 cp: cannot stat 'src/test/test-child.exe': No such file or directory
21:28:05 + rc=1
```
There are no usable artifacts as a result, for those who wish to use them. Aside, no artifacts are kept on Appveyor too.
**Trac**:
**Username**: harigTor: 0.4.0.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/29101Configure the push hook from git.tpo to github for fallback-scripts2020-06-13T16:56:17ZteorConfigure the push hook from git.tpo to github for fallback-scriptsWe need to:
* create a repository for fallback-scripts on https://github.com/torproject
* give phoul and teor and network-team and the pusher permissions
* configure the pusher on the git.torproject.org endWe need to:
* create a repository for fallback-scripts on https://github.com/torproject
* give phoul and teor and network-team and the pusher permissions
* configure the pusher on the git.torproject.org endTor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24786Rebuild the fallback list in 20182020-06-13T16:21:09ZteorRebuild the fallback list in 2018We need to rebuild the list of fallbacks in late 2018 or early 2019.
We usually do this when 25% or more go down.
(This is tracked in #tor-bots on IRC.)
Here are the instructions for running a rebuild:
https://trac.torproject.org/projec...We need to rebuild the list of fallbacks in late 2018 or early 2019.
We usually do this when 25% or more go down.
(This is tracked in #tor-bots on IRC.)
Here are the instructions for running a rebuild:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrorsTor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28085Update key/values in the bandwidth file spec2020-06-13T16:14:11ZjugaUpdate key/values in the bandwidth file specTo scale as Torflow, it was added `relay_observed_bandwidth` and `relay_average_bandwidth`.
I think we should also come up with some policy to add/remove key/values.
Even if all the ones we have so far seem useful, we are not using it. ...To scale as Torflow, it was added `relay_observed_bandwidth` and `relay_average_bandwidth`.
I think we should also come up with some policy to add/remove key/values.
Even if all the ones we have so far seem useful, we are not using it.
For instance, do we have tickets of cases where these key/values were needed/requested?.Tor: 0.4.0.x-finaljugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/28768Update fallback script to match Tor bootstrap changes2020-06-13T16:06:33ZteorUpdate fallback script to match Tor bootstrap changesIn #24661, we make clients bootstrap from reasonably old consensuses (expired in the last 24 hours).
In #28591, we make clients accept future consensuses as long as they're reasonably future consensuses (valid up to 24 hours in the futu...In #24661, we make clients bootstrap from reasonably old consensuses (expired in the last 24 hours).
In #28591, we make clients accept future consensuses as long as they're reasonably future consensuses (valid up to 24 hours in the future), and relays serve those consensuses.
We need to change the fallback checks to match these changes in Tor.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/27914Extract fallback-scripts to its own git repository2020-06-13T16:06:32ZNick MathewsonExtract fallback-scripts to its own git repositoryThis would let us give teor and phoul direct commit permissions here.This would let us give teor and phoul direct commit permissions here.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24953In check_existing mode, log "fallback list", not "whitelist"2020-06-13T16:06:26ZteorIn check_existing mode, log "fallback list", not "whitelist"This confused at least one relay operator.This confused at least one relay operator.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24804Run an opt-in process for relay operators to become fallbacks in 20182020-06-13T16:06:25ZteorRun an opt-in process for relay operators to become fallbacks in 2018This involves mailing tor-relays and asking if stable relay operators want to become fallbacks.This involves mailing tor-relays and asking if stable relay operators want to become fallbacks.Tor: 0.4.0.x-finalColin ChildsColin Childshttps://gitlab.torproject.org/legacy/trac/-/issues/27490When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a...2020-06-13T15:49:50ZNeel Chauhanneel@neelc.orgWhen ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomSuggested by teor at #17835:
>1. Make ClientPreferIPv6ORPort into an autobool
>2. When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomSuggested by teor at #17835:
>1. Make ClientPreferIPv6ORPort into an autobool
>2. When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomTor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32108tor can overrun its accountingmax if it enters soft hibernation first2020-06-13T15:46:45ZRoger Dingledinetor can overrun its accountingmax if it enters soft hibernation firstI'll put the punchline first: second_elapsed_callback(), which is where we check if it's time to go dormant for hibernation, is no longer called when we've entered soft hibernation.
I assume this is because of the new "periodic event fl...I'll put the punchline first: second_elapsed_callback(), which is where we check if it's time to go dormant for hibernation, is no longer called when we've entered soft hibernation.
I assume this is because of the new "periodic event flag" feature, where we try to avoid calling callbacks when we're in a state that won't need them. See the "online and active" note here:
```
/* This is a legacy catch-all callback that runs once per second if
* we are online and active. */
CALLBACK(second_elapsed, NET_PARTICIPANT,
FL(NEED_NET)|FL(RUN_ON_DISABLE)),
```
The impact is limited, since we stop accepting new connections and new circuits when we enter soft hibernation, but it can still be bad: existing connections and circuits can last for a long time and use a lot of bandwidth.
A secondary impact is that accounting_run_housekeeping() never gets called, which means that the state file never gets updated after we've entered soft hibernation, which means these bandwidth overspends are never recorded to disk.
I think the bug went in during commit 4bf79fa4f which is part of Tor 0.4.0.1-alpha.
The PERIODIC_EVENT_FLAG_NEED_NET flag (what FL(NEED_NET) expands into) checks net_is_disabled(), but there is another function right after net_is_disabled in netstatus.c called net_is_completely_disabled(), and the only difference is that it checks we_are_fully_hibernating() vs we_are_hibernating().
I confirmed the overall bug happens in practice: there's a relay operator in #tor who hit soft hibernation, and then saw his tor proceed to use more bytes than expected. I had him do a 'gdb attach' to his tor and break on 'second_elapsed_callback' and the function never got called.
It seems like the immediate fix, and best backport plan, would be to resume calling second_elapsed_callback even when net_is_disabled(). The longer term plan can be to audit our calls to net_is_disabled() and net_is_completely_disabled() and we_are_hibernating(), with an eye towards "should we be doing this behavior while soft hibernating", and see what other bugs we find.Tor: 0.4.0.x-finalRoger DingledineRoger Dingledine