Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:38:15Zhttps://gitlab.torproject.org/legacy/trac/-/issues/29521Update test descriptors, and work out how to keep them updated2020-06-13T15:38:15ZteorUpdate test descriptors, and work out how to keep them updatedTor's unit tests contain a bunch of test descriptors: router descriptors, extrainfo descriptors, votes, and onion service descriptors.
But these descriptors go out of date over time, because we don't keep them updated.
For example, EX_...Tor's unit tests contain a bunch of test descriptors: router descriptors, extrainfo descriptors, votes, and onion service descriptors.
But these descriptors go out of date over time, because we don't keep them updated.
For example, EX_EI_MAXIMAL in src/test/example_extrainfo.inc is no longer maximal, because we added PaddingStatistics (and maybe other statistics).
Ideally, we need:
1. tests for the oldest supported minimal and maximal descriptors
2. tests for significant changes in the minimal and maximal descriptors
3. tests for the current version's minimal and maximal descriptors
4. a test that fails if we forget to update the test descriptors for a new feature
We could implement 1 & 2 by storing minimal and maximal descriptors from each supported Tor version. We could test 3 by generating and parsing the descriptors as part of the test, and 4 by checking for new fields in the generated descriptor, that are missing from the latest stored descriptor.
Maybe we also want a test that old versions can parse newer descriptors?
We could store an archive of supported descriptors, and test it against every supported Tor version using CI and a (Travis) cron job.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29494Optimize interaction between circuitmux and circuitpadding2020-06-13T15:38:10ZMike PerryOptimize interaction between circuitmux and circuitpaddingIn #29204, we realized that we needed to inspect the circuit queue to prevent the circuit padding system from queuing too much padding. For that ticket, we're going to do the simple fix -- we don't schedule padding if the circuit's cell ...In #29204, we realized that we needed to inspect the circuit queue to prevent the circuit padding system from queuing too much padding. For that ticket, we're going to do the simple fix -- we don't schedule padding if the circuit's cell queue already has a window full of cells on it. In that case, we just lie to circpad and tell the machine we sent padding even though we did not.
However, we should determine if we want to have a more complicated interaction, such as delaying our padding until the queue drains. We should also examine creating alternate machine events for when cells are dequeued from circuitmux vs when they are sent locally. This has pluses and minuses for machine interaction.Tor: unspecifiedMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/29298Explicitly specify histogram bin endpoints/widths2020-06-13T15:41:38ZMike PerryExplicitly specify histogram bin endpoints/widthsGeorge has convinced me that we should explicitly specify the bin labels of our histograms rather than rely on a formula and lots of special cases for short histogram lengths.
The most straight-forward thing is to let researchers specif...George has convinced me that we should explicitly specify the bin labels of our histograms rather than rely on a formula and lots of special cases for short histogram lengths.
The most straight-forward thing is to let researchers specify a list of bin labels.. It might be more compact to encode if this list is a list of widths, but that may just be an encoding decision for the consensus. We should probably choose simplest possible representation here.Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29277Look into getting default Tor bridges scanned by external reachability tests2020-06-13T18:35:33ZCecylia BocovichLook into getting default Tor bridges scanned by external reachability testsTalk to Roya or Paul about tests available for checking the blocking of default bridges.
First determine where development/research is at with Spooky Scan or possibly Censored planet (https://censoredplanet.org/).
These systems check f...Talk to Roya or Paul about tests available for checking the blocking of default bridges.
First determine where development/research is at with Spooky Scan or possibly Censored planet (https://censoredplanet.org/).
These systems check for blocking remotely and so might tell us something different from OONI.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/29276Make a release of BridgeDB2020-06-13T18:29:24ZAlexander Færøyahf@torproject.orgMake a release of BridgeDBAs far as we understand here at the hackmeeting in Brussels there is currently no software release of the BridgeDB codebase. We should make a 0.0.1 release (or whatever we decide as initial version number).As far as we understand here at the hackmeeting in Brussels there is currently no software release of the BridgeDB codebase. We should make a 0.0.1 release (or whatever we decide as initial version number).Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/29272Assess Marionette for interation with Tor2020-06-13T18:35:30ZCecylia BocovichAssess Marionette for interation with TorSee first what stage Marionette is in and evaluate as a new PT for Tor. Important considerations are:
- the capacity of the transport and its ability to avoid blocking (take a look at the Oakland SoK by Tschantz et al.)
- Assess the boot...See first what stage Marionette is in and evaluate as a new PT for Tor. Important considerations are:
- the capacity of the transport and its ability to avoid blocking (take a look at the Oakland SoK by Tschantz et al.)
- Assess the bootstrapping needed by Marionette
- Take lessons from its modularity, which will likely come in handy for future PT designs
- Take a look at the recent source code and compare it to the most recent white paper
- See how much engineering effort is needed to get it to interface with Torhttps://gitlab.torproject.org/legacy/trac/-/issues/29263prop289: add bidirectional data transfers to chutney2020-06-13T13:30:44Zteorprop289: add bidirectional data transfers to chutneyTo test authenticated sendmes, we need to send data in both directions.To test authenticated sendmes, we need to send data in both directions.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29249Assessment of moat for bridges2020-06-13T18:29:23ZGabagaba@torproject.orgAssessment of moat for bridgesWhat is the status? What do we need to do?What is the status? What do we need to do?https://gitlab.torproject.org/legacy/trac/-/issues/29245Tor 0.4 eventually hits "Delaying directory fetches: No running bridges" afte...2020-06-13T15:37:40ZTracTor 0.4 eventually hits "Delaying directory fetches: No running bridges" after some period of inactivity with bridges```
Tor NOTICE: Delaying directory fetches: No running bridges
Tor NOTICE: Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
Tor NOTICE: Delaying directory fetches: No runni...```
Tor NOTICE: Delaying directory fetches: No running bridges
Tor NOTICE: Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
Tor NOTICE: Delaying directory fetches: No running bridges
Tor NOTICE: Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
Tor NOTICE: Delaying directory fetches: No running bridges
Tor NOTICE: Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
```
Tested on latest Tor Browser alpha with snowflake bridge.
**Trac**:
**Username**: ArmalsLoveArmalsLifeTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29226Automate application of C formatting to code2020-06-13T15:43:38ZNick MathewsonAutomate application of C formatting to codeWe have never applied a C formatter to our code. Doing so will hurt -- once. After that we might be much happier. We have the opportunity to
This has the potential to be a major bikeshed point, though: we should try to come up with ...We have never applied a C formatter to our code. Doing so will hurt -- once. After that we might be much happier. We have the opportunity to
This has the potential to be a major bikeshed point, though: we should try to come up with a set of standards that all the active developers can tolerate, and a mainstream well-supported tool can support.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29224Abstractions and best practices for disabled modules2020-06-13T15:37:33ZNick MathewsonAbstractions and best practices for disabled modulesWe arrived at some of these when we started making directory authority code optional; we can do more once we have more of our modularity designs in pace.
We may need additional code and tooling here.We arrived at some of these when we started making directory authority code optional; we can do more once we have more of our modularity designs in pace.
We may need additional code and tooling here.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29215Document target, modular tor architecture2020-06-13T15:37:26ZNick MathewsonDocument target, modular tor architectureWe'll be working during sponsor31 to make sure that we are moving towards a nice modular architecture. We should document what we're actually trying to achieve, and what our target architecture is, so that we can tell people "do it like ...We'll be working during sponsor31 to make sure that we are moving towards a nice modular architecture. We should document what we're actually trying to achieve, and what our target architecture is, so that we can tell people "do it like X, not necessarily like Tor does it now."
The official deliverable here is "Architectural documentation for how Tor modules work with one another, covering both the actuality and the refactored architecture". The "actuality" is under #29214.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29214Update 'tor-guts' archictecture documentation to describe current (actual, as...2020-06-13T15:37:26ZNick MathewsonUpdate 'tor-guts' archictecture documentation to describe current (actual, as-built) architecture.The official deliverable here is "Architectural documentation for how Tor modules work with one another, covering both the actuality and the refactored architecture". The "refactored architecture" is under #29215.The official deliverable here is "Architectural documentation for how Tor modules work with one another, covering both the actuality and the refactored architecture". The "refactored architecture" is under #29215.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29207New design for broker -- proxy protocol for snowflakes2020-06-13T18:19:33ZCecylia BocovichNew design for broker -- proxy protocol for snowflakes This is related to the Snowflake protocol design tickets #29206 and #29293.
We want to write these protocols in a way that is not Snowflake-specific but allows any type of bridge to connect to or poll our broker/BridgeDB bridge distrib... This is related to the Snowflake protocol design tickets #29206 and #29293.
We want to write these protocols in a way that is not Snowflake-specific but allows any type of bridge to connect to or poll our broker/BridgeDB bridge distribution service.
The idea is that in the beginning we will start with very reliable "bridge" (which could be snowflakes) that perhaps rotate IP addresses every month or so. After that we can collect measurements and move towards more ephemeral "bridges".
Some things to keep in mind are the types of information that the snowflakes give to the broker (such as proxy version/type) to allow for metrics. This information might change so we'll want a flexible and extensible protocol.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/29204Inspect circuit queue during padding decisions2020-06-13T15:37:17ZMike PerryInspect circuit queue during padding decisionsWe need to inspect the circuit queue or the channel outbuf in some way during padding decisions. The problem is that if a guard stops reading on a channel, and padding keeps getting scheduled by the middle, it will overflow the circuit q...We need to inspect the circuit queue or the channel outbuf in some way during padding decisions. The problem is that if a guard stops reading on a channel, and padding keeps getting scheduled by the middle, it will overflow the circuit queue and/or outbuf for the channel and eventually oom.
Ideally, we would make our padding decision based on the EWMA values for the circuit rather than just checking if there were queued cells in the outbuf, but at minimum we need some kind of throttling so we don't keep adding cells to an circuit queue or outbuf above a certain length.
We may also want to use the circuit queue activity to update our last packet sent timers..Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28970tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_ke...2020-06-13T15:42:46ZTractor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertionIf this is duplicate I'm sorry, but I found nothing similar in old tickets. `Sandbox` is 1 in `torrc`. Set priority and severity of this ticket to appropriate values if it is not so critical.
```
Jan 01 05:31:32.000 [notice] Received rel...If this is duplicate I'm sorry, but I found nothing similar in old tickets. `Sandbox` is 1 in `torrc`. Set priority and severity of this ticket to appropriate values if it is not so critical.
```
Jan 01 05:31:32.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jan 01 05:31:32.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jan 01 05:31:32.000 [notice] Read configuration file "/etc/tor/torrc".
Jan 01 05:31:32.000 [notice] Tor 0.3.4.9 (git-074ca2e0054fded1) opening log file.
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: Non-fatal assertion !(desc == NULL) failed in setup_intro_circ_auth_key at ../src/or/hs_client.c:624. Stack trace: (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x56345cea26e2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x56345cebd587] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_circuit_has_opened+0x2ca) [0x56345ce8027a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_send_next_onion_skin+0x372) [0x56345cdfd192] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x78fc3) [0x56345cd92fc3] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x311) [0x56345cd95211] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(command_process_cell+0x280) [0x56345ce126f0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x273) [0x56345cdf4493] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x11de1c) [0x56345ce37e1c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x892) [0x56345ce2e822] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x53a61) [0x56345cd6da61] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f2c7be623dc] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x25f) [0x56345cd6fe3f] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1165) [0x56345cd72315] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x56345cd6a32a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x56345cd6a099] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f2c7a7e6b45] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x500e9) [0x56345cd6a0e9] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:443: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at ../src/or/hs_client.c:443. Stack trace: (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x56345cea26e2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x56345cebd587] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_send_introduce1+0x352) [0x56345ce7fda2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_ap_handshake_attach_circuit+0x33c) [0x56345ce1126c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_ap_attach_pending+0x1a0) [0x56345ce31cb0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_receive_rendezvous_acked+0x79) [0x56345ce803c9] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(rend_process_relay_cell+0x28b) [0x56345cd9c2cb] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x791f7) [0x56345cd931f7] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x311) [0x56345cd95211] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(command_process_cell+0x280) [0x56345ce126f0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x273) [0x56345cdf4493] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x11de1c) [0x56345ce37e1c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x892) [0x56345ce2e822] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x53a61) [0x56345cd6da61] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f2c7be623dc] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x25f) [0x56345cd6fe3f] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1165) [0x56345cd72315] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x56345cd6a32a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x56345cd6a099] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f2c7a7e6b45] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x500e9) [0x56345cd6a0e9] (on Tor 0.3.4.9 )
```
Tor on Linux. Is it related to #27471 or #19926?
**Trac**:
**Username**: torcrashTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28942Evaluate pion WebRTC2020-06-16T01:26:17ZTracEvaluate pion WebRTCWe've made a pure Go WebRTC port over at [pions/webrtc](https://github.com/pions/webrtc). This may provide a viable alternative to libwebrtc.
_Disadvantages_
- We've not done much work on security yet. However, we definitely intend to w...We've made a pure Go WebRTC port over at [pions/webrtc](https://github.com/pions/webrtc). This may provide a viable alternative to libwebrtc.
_Disadvantages_
- We've not done much work on security yet. However, we definitely intend to work on this since hardening the security will be a requirement for many other use-cases.
- Not entirely feature complete but this seems less important for your use-case.
- We don't support TURN yet. We currently plan to build this for our next release.
_Advantages_
- It is fully go-gettable, fixing the horrible built process. In addition, it should run everywhere Go runs.
- We've tested our data channel implementation against multiple targets, including Chrome, Firefox and NodeJS and aim to automate these in the future.
- It will give you more freedom to make changes to the WebRTC stack and even allow experimentation, E.g.: to reduce fingerprinting.
- It may solve/invalidate some of your other problems, including #19026, #19315, #19569, #22718 and #25483.
- We're working on exposing an idiomatic API based on the io.ReadWriteCloser.
- We have an active community and development team. We're more than happy to fix any problems that may arise. We're also open to prioritizing any features you conciser blocking. Lastly, we have great PR response times.
I'm also interested in collaborating on NAT testing as mentioned in #25595.
**Trac**:
**Username**: backkemCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/28780circpadding: Add machine flag for not closing circuit if machine is active2020-06-13T15:42:10ZGeorge Kadianakiscircpadding: Add machine flag for not closing circuit if machine is activeSee https://github.com/torproject/tor/pull/461#discussion_r231546320 for more details .
Related to #28634.See https://github.com/torproject/tor/pull/461#discussion_r231546320 for more details .
Related to #28634.Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28638Serialize state machines in the torrc2020-06-13T15:34:49ZGeorge KadianakisSerialize state machines in the torrcFigure out how to serialize state machines in the torrc and consensus to make it easire to specify state machines for researchers (and for common users).
Perhaps it's fine to do this after 0.4.0 since the WTF-PAD code in 0.4.0 is mainly...Figure out how to serialize state machines in the torrc and consensus to make it easire to specify state machines for researchers (and for common users).
Perhaps it's fine to do this after 0.4.0 since the WTF-PAD code in 0.4.0 is mainly for research purposes and not inteded to be used by a wide audience. The researchers can perhaps write code of their own that instantiates the padding machines if we write a good enough doc to do so.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28391Make BridgeDB website mirrorable2020-06-13T18:29:17ZanadahzMake BridgeDB website mirrorableIt will be very useful to be able to deploy mirrors of the [BridgeDB website](https://bridges.torproject.org).
Adding this ticket to track down what is needed to make this happen.
Reference to previous discussion: https://lists.torproje...It will be very useful to be able to deploy mirrors of the [BridgeDB website](https://bridges.torproject.org).
Adding this ticket to track down what is needed to make this happen.
Reference to previous discussion: https://lists.torproject.org/pipermail/tor-mirrors/2018-November/001193.html