Re: [tor-bugs] #33651 [Core Tor/Tor]: Suspicious "fetched this many bytes" counts from #32720

[Tor Bug Tracker & Wiki]

#33651: Suspicious "fetched this many bytes" counts from #32720
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I should clarify that I'm running with safelogging 0.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #32720 [Core Tor/Tor]: How much bandwidth does a user use to bootstrap and maintain dir info? How has that changed over time?

[Tor Bug Tracker & Wiki]

#32720: How much bandwidth does a user use to bootstrap and maintain dir info? 
How
has that changed over time?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  prop312-can   |  Actual Points:
Parent ID:  #33049| Points:
 Reviewer:  ahf   |Sponsor:  Sponsor55-can
--+

Comment (by arma):

 I opened #33651 with what I suspect might be a bug on this code.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33637 [Circumvention/Snowflake]: Update license for Snowflake

[Tor Bug Tracker & Wiki]

#33637: Update license for Snowflake
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19409   | Points:  .1
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 I don't need to be named in a copyright notice. You can consider my
 contributions to be in the public domain.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33651 [Core Tor/Tor]: Suspicious "fetched this many bytes" counts from #32720

[Tor Bug Tracker & Wiki]

#33651: Suspicious "fetched this many bytes" counts from #32720
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Following #32720, now I have these log messages in my Tor client:
 {{{
 Mar 17 17:52:52.004 [notice] Bootstrapped 100% (done): Done
 Mar 17 23:52:49.170 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0
 circuits open. I've sent 166.22 MB and received 5.25 GB.
 Mar 17 23:52:49.178 [notice] While bootstrapping, fetched this many bytes:
 Mar 17 23:52:49.178 [notice] 542559 (consensus network-status fetch)
 Mar 17 23:52:49.178 [notice] While not bootstrapping, fetched this many
 bytes:
 Mar 17 23:52:49.178 [notice] 542559 (consensus network-status fetch)
 Mar 17 23:52:49.178 [notice] Average packaged cell fullness: 52.843%. TLS
 write overhead: 3%
 Mar 18 17:01:52.177 [notice] Your system clock just jumped 44387 seconds
 forward; assuming established circuits no longer work.
 Mar 18 18:12:33.010 [notice] Heartbeat: Tor's uptime is 11:59 hours, with
 0 circuits open. I've sent 166.25 MB and received 5.25 GB.
 Mar 18 18:12:33.011 [notice] While bootstrapping, fetched this many bytes:
 Mar 18 18:12:33.011 [notice] 542559 (consensus network-status fetch)
 Mar 18 18:12:33.011 [notice] While not bootstrapping, fetched this many
 bytes:
 Mar 18 18:12:33.011 [notice] 542559 (consensus network-status fetch)
 Mar 18 18:12:33.011 [notice] Average packaged cell fullness: 52.898%. TLS
 write overhead: 3%
 Mar 19 00:12:33.013 [notice] Heartbeat: Tor's uptime is 17:59 hours, with
 0 circuits open. I've sent 166.26 MB and received 5.25 GB.
 Mar 19 00:12:33.013 [notice] While bootstrapping, fetched this many bytes:
 Mar 19 00:12:33.013 [notice] 542559 (consensus network-status fetch)
 Mar 19 00:12:33.013 [notice] While not bootstrapping, fetched this many
 bytes:
 Mar 19 00:12:33.013 [notice] 542559 (consensus network-status fetch)
 Mar 19 00:12:33.013 [notice] Average packaged cell fullness: 52.953%. TLS
 write overhead: 3%
 }}}

 I'm running
 {{{
 Tor 0.4.4.0-alpha-dev (git-d4595b344a1a3254) running on Linux with
 Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and
 Libzstd N/A.
 }}}

 It is surprising to me that I have the same number while bootstrapping and
 while not bootstrapping, and that number doesn't seem to go up.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33650 [Core Tor/Tor]: Verify that intro2 cell extensions actually work

[Tor Bug Tracker & Wiki]

#33650: Verify that intro2 cell extensions actually work
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In the future we're going to want to transport end-to-end tokens, proofs
 of work, or other blobs from client to onion service. We should make sure
 that we can actually add these into the cells without anything going
 wrong, like surprising asserts or surprising length enforcement.

 (Now is the time to notice if things will go wrong, so we can fix them and
 deploy that fix, and then people will have upgraded by the time we're
 ready to actually use them.)

 So: let's make a branch that adds "hi mom" on the client side, and reads
 it out again on the service side.

 In spelunking through the code and the spec, I found that modern intro2
 cells have an "extensions" field inside their encrypted component, which
 seems perfectly suited for transporting arbitrary blobs from client to
 service. Here's how we set it currently on the client side:
 {{{
   /* Set extension data. None are used. */
   ext = trn_cell_extension_new();
   tor_assert(ext);
   trn_cell_extension_set_num(ext, 0);
   trn_cell_introduce_encrypted_set_extensions(enc_cell, ext);
 }}}

 So that 0 needs to become a 1, and then we need something new that makes
 and sets a new extension in ext (modeled maybe on
 {{{build_establish_intro_dos_extension()}}}, and something on the
 receiving end that invokes trn_cell_extension_parse() and reads it out to
 us.

 I am optimistic, because this thing is encrypted, so the intro point in
 the middle can't be looking at it very carefully. But if we have bugs on
 the client side or the service side, or surprise length enforcement in the
 middle, now is a great time to notice and fix them.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33157 [Circumvention/Snowflake]: Client generates SDP with "IN IP4 0.0.0.0", causing proxy to send "client_ip=0.0.0.0" and bridge to send "USERADDR 0.0.0.0:1"

[Tor Bug Tracker & Wiki]

#33157: Client generates SDP with "IN IP4 0.0.0.0", causing proxy to send
"client_ip=0.0.0.0" and bridge to send "USERADDR 0.0.0.0:1"
-+--
 Reporter:  dcf  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:4 arlolra]:
 > > I found it while testing proxy-go with a localhost client and a patch
 like:
 >
 > Something like that patch was useful when working on #19026 so would you
 consider merging,
 >
 
https://github.com/keroserene/snowflake/commit/dbd733e4b1430c046ec11e8052efdbac6010e58a

 It's okay with me but I would call the option `--unsafe-logging` instead
 of `--unsafeLogging` to match the style of the other options.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33617 [Core Tor/Tor]: Add a BandwidthStatistics option and consensus parameter

[Tor Bug Tracker & Wiki]

#33617: Add a BandwidthStatistics option and consensus parameter
---+---
 Reporter:  teor   |  Owner:  MrSquanchee
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop313, ipv6, outreachy-ipv6  |  Actual Points:
Parent ID:  #33052 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-can
---+---

Comment (by MrSquanchee):

 Hii teor,
 I completed stage 1 partially.
 You can check my branch at
 https://github.com/MrSquanchee/tor/commits/ticket%2333617 .
 Just added the BandwidthStatistics option and made it activate reporting
 of bandwidth statistics.
 Will add the tests in the next commit.
 And I don't have any idea on how to add a consensus parameter, any hint
 will do./
 And please do tell me if I went wrong in some way.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33519 [Circumvention/Snowflake]: Support multiple simultaneous SOCKS connections

[Tor Bug Tracker & Wiki]

#33519: Support multiple simultaneous SOCKS connections
-+
 Reporter:  dcf  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  turbotunnel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dcf):

 [https://github.com/xtaci/kcp-go/issues/166 Conversation] on the kcp-go
 issue tracker convinced me that what I was doing in comment:3 is the wrong
 approach. Two sessions sharing the same `PacketConn` will each be reading
 packets intended for the other, resulting in effectively 50% packet loss.
 (I think, unless quic-go has some special code to handle this case.)
 Retransmissions will probably make the connection work, but obviously
 performance will be bad.

 Instead, I have new commits that implement option 4 for both the KCP and
 QUIC branch.
   [https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h
 =turbotunnel-kcp=bb370f3f04c4fac256ec966b1e0d0fa969b7faa7 turbotunnel-
 kcp]
   [https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h
 =turbotunnel-quic=d36eed58c1aefc4903b3175d620830855c764152 turbotunnel-
 quic]

 The commits introduce a `sessionManager` object that creates a
 `PacketConn` and session on demand, and demand, and thereafter reuses the
 same `PacketConn` and session. If the session ever dies (which should be
 an unusual case), it tears down the `PacketConn` and allows a new
 `PacketConn` and session to be created on demand the next time they are
 needed. quic-go provides a nice channel that we can read to find out when
 the session dies; with kcp-go we poll the
 [https://godoc.org/github.com/xtaci/smux#Session.IsClosed IsClosed] method
 periodically.

 You'll be able to test the commits using the same procedure as in
 comment:3.

 I've started Tor Browser builds based on [https://blog.torproject.org/new-
 release-tor-browser-95a8 9.5a8].

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * actualpoints:  17 => 18


Comment:

 Updated patches to handle the case of bookmarks not being done with the
 memorable .tor.onion (https://github.com/acatarineu/tor-
 browser/commit/28005+2), and to show a tooltip in the circuit display on
 domain hover (https://github.com/acatarineu/torbutton/commit/28005+1),

 For the latter, I could not make the standard tooltip via `title` or `alt`
 attributes work with the HTML `span`, so I had to convert it to a XUL
 `html:span` element, and use the `tooltiptext` attribute.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33649 [Metrics/Consensus Health]: Show progress towards flags on consensus health

[Tor Bug Tracker & Wiki]

#33649: Show progress towards flags on consensus health
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:  network-health|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 Replying to [comment:3 teor]:
 > as far as I recall, relay search doesn't read votes, because Onionoo
 doesn't store votes.
 >
 > So we'd be implementing this feature on consensus health.

 Awesome. We can get both: if consensus-health learns to display these
 numbers for a relay, with a per-relay url, then relay-search can have a
 "more details" link that sends people to it.

 That said:
 https://collector.torproject.org/archive/relay-descriptors/votes/
 so they are definitely in there somewhere. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33649 [Metrics/Consensus Health]: Show progress towards flags on consensus health

[Tor Bug Tracker & Wiki]

#33649: Show progress towards flags on consensus health
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:  network-health|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 Replying to [comment:1 teor]:
 > As an alternative implementation, we could change tor so it:
 > * calculates a progress fraction towards each flag, for each relay
 > * puts the fractions for each flag in a line in its votes

 My slight preference would be toward publishing the raw input numbers in
 the votes, and doing the calculations externally.

 The calculations get complex when we consider that we'll change the
 threshold algorithms in various versions of Tor, and some dir auths change
 their torrc to set their own custom thresholds (e.g. moria1 sets
 "MinUptimeHidServDirectoryV2 24 hours"). I guess the external script will
 need to keep a growing list of "for this Tor version, this is how you
 combine those raw numbers into the fraction" algorithms.

 The thing that pushes me over the edge toward "do the calculations
 externally" is: what if we have bugs in the fraction calculations? If we
 only publish fraction calculations in votes, then when we discover bugs,
 we potentially invalid all published numbers so far. Whereas if we do the
 calculations externally, we still have the raw numbers and we can rerun
 new scripts over old numbers and get new results.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33649 [Metrics/Consensus Health]: Show progress towards flags on consensus health

[Tor Bug Tracker & Wiki]

#33649: Show progress towards flags on consensus health
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:  network-health|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 > (B) Visualize these things for relay operators somewhere, e.g. in relay-
 search or in consensus-health.

 I think there's a catch here: as far as I recall, relay search doesn't
 read votes, because Onionoo doesn't store votes.

 So we'd be implementing this feature on consensus health.
 (Which is used by more technical users.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33649 [Metrics/Consensus Health]: Show progress towards flags on consensus health

[Tor Bug Tracker & Wiki]

#33649: Show progress towards flags on consensus health
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:  network-health|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 I like this idea! I could imagine it as a "details" page for each relay
 that relay-search could serve too.

 There are two pieces to the idea, as I understand it from above:

 (A) Directory authorities would add another line to their votes about each
 relay, and include the input parameters that they used for making their
 decisions about the relay. There's no reason for a new consensus method,
 or for the consensus to change in any way. We'd basically just be
 exporting the internal directory authority state in a more useful and
 usable (and automatically archived) way.

 (B) Visualize these things for relay operators somewhere, e.g. in relay-
 search or in consensus-health.

 One important catch to consider, and that we'd want to communicate well in
 the visualization page, is that many of the thresholds are moving targets,
 e.g. your uptime could go up yet your percentage progress toward having
 enough uptime could go down. I think if we communicate it well, people
 could handle this concept though.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19251 [Applications/Tor Browser]: TorBrowser might want to have an error page specific to when .onion links fail

[Tor Bug Tracker & Wiki]

#19251: TorBrowser might want to have an error page specific to when .onion 
links
fail
+--
 Reporter:  cypherpunks |  Owner:  brade
 Type:  enhancement | Status:  needs_review
 Priority:  Low |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, TorBrowserTeam202003R  |  Actual Points:  6.7
Parent ID:  #30025  | Points:  6
 Reviewer:  acat,pospeselr  |Sponsor:
|  Sponsor27-must
+--

Comment (by pospeselr):

 I would say make diagramInfoMap a member variable of
 OnionServicesAboutNetError to avoid rebuilding it each time _insertDiagram
 is called. Apart from that, looks good to me.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33649 [Metrics/Consensus Health]: Show progress towards flags on consensus health

[Tor Bug Tracker & Wiki]

#33649: Show progress towards flags on consensus health
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:  network-health|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 As an alternative implementation, we could change tor so it:
 * calculates a progress fraction towards each flag, for each relay
 * puts the fractions for each flag in a line in its votes

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33649 [Metrics/Consensus Health]: Show progress towards flags on consensus health

[Tor Bug Tracker & Wiki]

#33649: Show progress towards flags on consensus health
--+
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:  network-health
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Relay operators often ask us why they don't have a particular flag. For
 example:
 https://lists.torproject.org/pipermail/tor-relays/2020-March/018253.html

 When a relay doesn't have a flag, we could show relay operators how close
 their relay is to getting that flag. Showing progress would also help us
 diagnose hard-to-find bugs in tor.

 This could be a project that we do in stages.

 Here's a sketch of the flag-thresholds and per-relay vote data we'd need:

 Fast:
 * bandwidth
   * w Measured
 * (what happens for relays that aren't measured?)
   * fast-speed

 Stable:
 * uptime
   * add an uptime line to votes in tor
   * stable-uptime
 * mtbf
   * add a mtbf line to votes in tor
   * stable-mtbf
 * show both uptime and mtbf fractions

 Guard:
 * needs Fast
 * needs Stable
 * wfu - same as uptime?
   * add a wfu line to votes in tor
   * guard-wfu
 * tk - what is this?
   * add a tk line to votes in tor
   * guard-tk
 * is there a bandwidth or mtbf requirement for guards?
 * show wfu and tk fractions
 * show if it needs Fast and Stable - are these flags implied by wfu and
 tk?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33447 [Internal Services/Tor Sysadmin Team]: migrate omeiense to the ganeti cluster, triggering an IP change

[Tor Bug Tracker & Wiki]

#33447: migrate omeiense to the ganeti cluster, triggering an IP change
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tpa-roadmap-march|  Actual Points:
Parent ID:  #33085   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 that was incorrect: a manual change was required in the nagios config, and
 has now been done.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33646 [Core Tor/Tor]: Wrong list of enabled modules

[Tor Bug Tracker & Wiki]

#33646: Wrong list of enabled modules
-+-
 Reporter:  Vort |  Owner:  dgoulet
 Type:  defect   | Status:
 |  assigned
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.3.2-alpha
 Severity:  Minor| Resolution:
 Keywords:  build, 043-must, 043-backport,   |  Actual Points:  0.1
  consider-backport-after-ci-passes  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * owner:  teor => dgoulet
 * actualpoints:   => 0.1


Comment:

 Hmm, turns out the variables are being expanded before they are set.

 I think this is one dgoulet will have to fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33646 [Core Tor/Tor]: Wrong list of enabled modules

[Tor Bug Tracker & Wiki]

#33646: Wrong list of enabled modules
-+-
 Reporter:  Vort |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.3.2-alpha
 Severity:  Minor| Resolution:
 Keywords:  build, 043-must, 043-backport,   |  Actual Points:
  consider-backport-after-ci-passes  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * owner:  dgoulet => teor


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33646 [Core Tor/Tor]: Wrong list of enabled modules

[Tor Bug Tracker & Wiki]

#33646: Wrong list of enabled modules
-+-
 Reporter:  Vort |  Owner:  dgoulet
 Type:  defect   | Status:
 |  assigned
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.3.2-alpha
 Severity:  Minor| Resolution:
 Keywords:  build, 043-must, 043-backport,   |  Actual Points:
  consider-backport-after-ci-passes  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => assigned
 * version:  Tor: 0.4.3.3-alpha => Tor: 0.4.3.2-alpha
 * keywords:  build => build, 043-must, 043-backport, consider-backport-
 after-ci-passes
 * points:   => 0.1
 * milestone:   => Tor: 0.4.3.x-final
 * owner:  (none) => dgoulet


Comment:

 Thanks!

 Looks like we're missing a $ in xenable_module_mname:
 {{{
 m4_foreach_w([mname], MODULES,
   [
 test "xenable_module_mname" != "xno" && value=1 || value=0
 PPRINT_PROP_BOOL([mname (--disable-module-mname)], $value)
   ]
 )
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33008 [Metrics/Relay Search]: Display a bridge's distribution bucket

[Tor Bug Tracker & Wiki]

#33008: Display a bridge's distribution bucket
-+-
 Reporter:  phw  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Relay Search |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s30-o24a1, anti-censorship-roadmap-  |  Actual Points:
  2020Q1 metrics-team-roadmap-2020Q1 |
Parent ID:  #31281   | Points:  2
 Reviewer:  cohosh   |Sponsor:
 |  Sponsor30-can
-+-

Comment (by phw):

 Replying to [comment:30 cohosh]:
 > The changes look good, phw! I like the new phrasing.
 [[br]]
 Thanks! Merged in
 
[https://gitweb.torproject.org/bridgedb.git/commit/?h=develop=f23c0213bb1f1e030eaae5d1ac2b26d2a91244e4
 f23c021] and now live [https://bridges.torproject.org/info here].
 [[br]]
 > My only comment is a super unimportant nit that a
 [https://github.com/NullHypothesis/bridgedb/compare/b39e576...enhancement/33008
 #diff-da8cb8ff8611ae66137826849e137287R330 few lines] have broken weirdly.
 [[br]]
 Ah, right. The file bridgedb.pot is automatically generated by running
 `python setup.py extract_messages`. We can ignore that because we never
 edit bridgedb.pot manually.

 Karsten, I'm leaving this ticket open for the remaining work on your side,
 ok?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33648 [Applications]: vanguards: What is the recommended value?

[Tor Bug Tracker & Wiki]

#33648: vanguards: What is the recommended value?
-+--
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Component:  Applications
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Since your default configuration & github document doesn't tell me much,
 I'd like to hear developer's opinion on this.


 vanguards.conf

 Bandguards:
 circ_max_age_hours = 1  (Mine is just simple WWW service without fancy
 WebSockets, downloads or videos)
 circ_max_hsdesc_kilobytes = 30
 circ_max_megabytes = 5


 Q1. Is using smaller value such as 1 for circ_max_age_hours have any
 problems regarding anonymity?

 Q2. You didn't mention default size of hidden service descriptor. What
 value is it? This is not OnionShare or onionbalance.
 (if you can do {circ_max_hsdesc_kilobytes != normal_desc_size
 kill_connection} that's great)

 Q3. You said "HTTP GET can resume if this limit is hit, HTTP POST will
 not" in circ_max_megabytes. You better add this text, don't you think: "If
 the client reach this limit, we close the connection and create another
 one to continue operation. Client will experience small downtime."

 Q4. Can you add an option to slow down packets on purpose, to prevent
 simple DDoS? e.g. 'limit_packets_per_seconds = 10' will allow 10 packets
 per seconds and delay exceeded packets (x) seconds

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31341 [Applications/TorBirdy]: TorBirdy does not support Thunderbird 68

[Tor Bug Tracker & Wiki]

#31341: TorBirdy does not support Thunderbird 68
--+-
 Reporter:  ozozoz|  Owner:  sukhbir
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/TorBirdy |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBirdy, Thunderbird 68  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 In my opinion, that doesn't mean this ticket can be closed.

 We should try to find a way to the turn the work done by Tails into a
 viable installable solution for non-Tails users.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  10
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by mcs):

 Replying to [comment:115 acat]:
 > Thanks for the reviews! Here are the revised patches:
 https://github.com/acatarineu/tor-browser/commit/21952+5 and
 https://github.com/acatarineu/torbutton/commit/21952+1. I took the
 suggested string changes for now, let's wait for the final string review.

 The changes look good. Just two comments:
 * UX: Now that clicking "Always Prioritize Onionsites" flips the pref for
 me, I expect that the redirect will be followed for that page without me
 doing more. Would it surprise people too much if we did that or would it
 be an improvement?
 * Kathy and I expected that `privacy.prioritizeonions.showNotification`
 would default to `true` to indicate that the notification should be
 displayed. That is what I meant in comment:111 when I said "reverse the
 meaning."

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23226 [Applications/GetTor]: GetTor help message could be more helpful

[Tor Bug Tracker & Wiki]

#23226: GetTor help message could be more helpful
-+-
 Reporter:  catalyst |  Owner:  cohosh
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1, ux-  |  Actual Points:
  team   |
Parent ID:  #9036| Points:  1
 Reviewer:  phw  |Sponsor:
-+-
Changes (by cohosh):

 * status:  needs_revision => needs_review


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23226 [Applications/GetTor]: GetTor help message could be more helpful

[Tor Bug Tracker & Wiki]

#23226: GetTor help message could be more helpful
-+-
 Reporter:  catalyst |  Owner:  cohosh
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1, ux-  |  Actual Points:
  team   |
Parent ID:  #9036| Points:  1
 Reviewer:  phw  |Sponsor:
-+-

Comment (by cohosh):

 Okay here's a merge request that includes also updates to the body message
 (with the specialized signature verification instructions built-in):
 https://gitlab.torproject.org/torproject/anti-censorship/gettor-
 project/gettor/merge_requests/3

 The result for osx is:
 {{{
 This is an automated email response from GetTor.

 You requested Tor Browser for osx.

 Step 1: Download Tor Browser

 First, try downloading Tor Browser from either GitLab or GitHub:


 gitlab:
 
https://gitlab.com/thetorproject/torbrowser-9.0.6-osx/raw/master/TorBrowser-9.0.6
 -osx64_en-US.dmg
 Signature file:
 
https://gitlab.com/thetorproject/torbrowser-9.0.6-osx/raw/master/TorBrowser-9.0.6
 -osx64_en-US.dmg.asc

 github: https://github.com/torproject/torbrowser-
 releases/releases/download/torbrowser-release/TorBrowser-9.0.6-osx64_en-
 US.dmg
 Signature file: https://github.com/torproject/torbrowser-
 releases/releases/download/torbrowser-release/TorBrowser-9.0.6-osx64_en-
 US.dmg.asc


 If you cannot download Tor Browser from GitLab or GitHub,
 try downloading the file TorBrowser-9.0.6-osx64_en-US.dmg
 from the following archives:

 Internet Archive: https://archive.org/details/@gettor

 Google Drive folder:
 https://drive.google.com/open?id=13CADQTsCwrGsIID09YQbNz2DfRMUoxUU

 Step 2: Verify the signature (Optional)

 Verifying the signature ensures that a certain package was
 generated by its
 developers, and has not been tampered with.  This email provides
 links to signature
 files that have the same name as the Tor Browser file, but end
 with ".asc" instead.

 If you are using macOS, you can install GPGTools. In order to
 verify the signature
 you will need to type a few commands in the Terminal (under
 "Applications").

 The Tor Browser team signs Tor Browser releases. Import the Tor
 Browser Developers
 signing key (0xEF6E286DDA85EA2A4BA7DE684E2C6E8793298290):

 gpg --auto-key-locate nodefault,wkd --locate-keys
 torbrow...@torproject.org

 This should show you something like:

 gpg: key 4E2C6E8793298290: public key "Tor Browser
 Developers (signing key) " imported
 gpg: Total number processed: 1
 gpg:   imported: 1
 pub   rsa4096 2014-12-15 [C] [expires: 2020-08-24]
   EF6E286DDA85EA2A4BA7DE684E2C6E8793298290
 uid   [ unknown] Tor Browser Developers (signing
 key) 
 sub   rsa4096 2018-05-26 [S] [expires: 2020-09-12]

 After importing the key, you can save it to a file (identifying it
 by fingerprint here):

 gpg --output ./tor.keyring --export
 0xEF6E286DDA85EA2A4BA7DE684E2C6E8793298290

 Next, you will need to download the corresponding ".asc" signature
 file and verify it
 with the command:

 gpgv --keyring ./tor.keyring ~/Downloads/TorBrowser-9.0.6
 -osx64_en-US.dmg{.asc,}

 The result of the command should produce something like this:

 gpgv: Signature made 07/08/19 04:03:49 Pacific Daylight
 Time
 gpgv:using RSA key EB774491D9FF06E2
 gpgv: Good signature from "Tor Browser Developers (signing
 key) "

 Step 3: Get Bridges (Optional)

 If you believe that Tor is blocked where you are, you can use
 bridges to connect
 to Tor.  Bridges are hidden Tor relays that can circumvent
 censorship.
 Tor Browser includes a list of built-in bridges, which you should
 try first.
 You can activate built-in bridges inside of Tor Browser's
 settings, under the
 "Tor" menu.  If built-in bridges don't work, try requesting
 different bridges,
 which you can also do in the "Tor" menu inside Tor Browser's
 settings.
 }}}

 For windows:
 {{{
 This is an automated email response from GetTor.

 You requested Tor Browser for windows.

 Step 1: Download Tor Browser

 First, try downloading Tor Browser 

Re: [tor-bugs] #19251 [Applications/Tor Browser]: TorBrowser might want to have an error page specific to when .onion links fail

[Tor Bug Tracker & Wiki]

#19251: TorBrowser might want to have an error page specific to when .onion 
links
fail
+--
 Reporter:  cypherpunks |  Owner:  brade
 Type:  enhancement | Status:  needs_review
 Priority:  Low |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, TorBrowserTeam202003R  |  Actual Points:  6.7
Parent ID:  #30025  | Points:  6
 Reviewer:  acat,pospeselr  |Sponsor:
|  Sponsor27-must
+--

Comment (by mcs):

 Thank you for the reviews. Kathy and I made the suggested changes: we
 moved the `this._insertStylesheet()` call later plus we addressed
 everything from comment:43. We also rebased both patches on top of the
 latest tor-browser and Torbutton code. There were no actual changes to the
 Torbutton patch. New patches:

 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug19251-03=800293b5af438df25f89bae6e8c9b0abf4845c7e

 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19251-03=7ce7e376fc8f3e51cf5de04f1a254c9190e3364b

 Please do another quick review.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23226 [Applications/GetTor]: GetTor help message could be more helpful

[Tor Bug Tracker & Wiki]

#23226: GetTor help message could be more helpful
-+-
 Reporter:  catalyst |  Owner:  cohosh
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1, ux-  |  Actual Points:
  team   |
Parent ID:  #9036| Points:  1
 Reviewer:  phw  |Sponsor:
-+-

Comment (by antonela):

 Looks good for me!

 When you have it live, I'll update
 `https://support.torproject.org/gettor/gettor-2/`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23226 [Applications/GetTor]: GetTor help message could be more helpful

[Tor Bug Tracker & Wiki]

#23226: GetTor help message could be more helpful
-+-
 Reporter:  catalyst |  Owner:  cohosh
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1, ux-  |  Actual Points:
  team   |
Parent ID:  #9036| Points:  1
 Reviewer:  phw  |Sponsor:
-+-

Comment (by cohosh):

 Okay, here's a commit that updates the help message:
 
https://gitlab.torproject.org/cohosh/gettor/commit/e4d9c30ef9979a8d757f4864fa30dd1a53d6c26b

 It will produce an email that looks like this (note there are some very
 minor adjustments):
 {{{
 This is an automated email response from GetTor.

 GetTor can send you download links for Tor Browser.
 Simply reply to this email and write the operating system you want to
 install Tor Browser on in your response. We support the following
 operating systems:

 windows
 linux
 osx

 GetTor will then respond with download instructions.

 If you want Tor Browser in a language other than English, mention one of
 the following language codes in your response:

 en-US
 es-ES
 pt-BR
 ar
 ca
 cs
 da
 de
 el
 es-AR
 fa
 fr
 ga-IE
 he
 hu
 id
 is
 it
 ja
 ka
 ko
 nb-NO
 nl
 pl
 ru
 sv-SE
 tr
 vi
 zh-CN
 zh-TW

 For example, if you want Tor Browser in Arabic your email content will
 look like:

 windows ar
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33647 [Circumvention/BridgeDB]: Minor updates to BridgeDB's dependencies

[Tor Bug Tracker & Wiki]

#33647: Minor updates to BridgeDB's dependencies
---+
 Reporter:  agix   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Component:  Circumvention/BridgeDB
  Version:  sbws: unspecified  |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
 Some minor errors occurred when trying to setup BridgeDB on a fresh
 system:

 The link to the get-pip script is outdated and no longer available.
 The new address would be: [https://bootstrap.pypa.io/get-pip.py]

 When setup.py is executed the following error occurs:
 error: The 'pyasn1' distribution was not found and is required by service-
 identity.
 Therefore i suggest adding pyasn1 to requirements.txt.

 Since BridgeDB's port seems as good as done, this might not be necessary
 but the pylint version 2.4.4  in .test.requirements.txt is only supporting
 Python 3.
 For the installation with Python 2.7, pylint version 1.9.5 would be
 required.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33646 [Core Tor/Tor]: Wrong list of enabled modules

[Tor Bug Tracker & Wiki]

#33646: Wrong list of enabled modules
+--
 Reporter:  Vort|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Low |  Component:  Core Tor/Tor
  Version:  Tor: 0.4.3.3-alpha  |   Severity:  Minor
 Keywords:  build   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 When I build tor 0.4.3.3-alpha with
 `./autogen.sh && ./configure --disable-unittests --disable-module-dirauth
 && make`
 line, I see following text:
 {{{
 Modules
   relay (--disable-module-relay):yes
   dirauth (--disable-module-dirauth):yes
   dircache (--disable-module-dircache):  yes
 }}}
 Which is wrong, since I have enabled relay and disabled dirauth.
 Looks like problem is located in commit
 
[https://gitweb.torproject.org/tor.git/commit/?id=9c33d36113447d38decd22d177e62fb225826d78
 9c33d36113447d38decd22d177e62fb225826d78].
 Related: #32230.
 Please recheck.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33343 [Applications/GetTor]: Update requirements.txt in GetTor

[Tor Bug Tracker & Wiki]

#33343: Update requirements.txt in GetTor
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:  phw  |Sponsor:
-+
Changes (by cohosh):

 * status:  merge_ready => closed
 * points:   => 1
 * resolution:   => fixed


Comment:

 Merged at
 
[https://gitweb.torproject.org/gettor.git/commit/?id=bd227cfc7544c0578349aa89c6943ada0d1ab96a
 0d1ab96a]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33645 [Internal Services/Service - trac]: Add new Sponsor 58 to trac

[Tor Bug Tracker & Wiki]

#33645: Add new Sponsor 58 to trac
--+
 Reporter:  pili  |  Owner:  qbi
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by qbi):

 * status:  new => closed
 * resolution:   => fixed


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33008 [Metrics/Relay Search]: Display a bridge's distribution bucket

[Tor Bug Tracker & Wiki]

#33008: Display a bridge's distribution bucket
-+-
 Reporter:  phw  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Relay Search |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s30-o24a1, anti-censorship-roadmap-  |  Actual Points:
  2020Q1 metrics-team-roadmap-2020Q1 |
Parent ID:  #31281   | Points:  2
 Reviewer:  cohosh   |Sponsor:
 |  Sponsor30-can
-+-
Changes (by cohosh):

 * status:  needs_review => merge_ready


Comment:

 The changes look good, phw! I like the new phrasing.

 My only comment is a super unimportant nit that a
 [https://github.com/NullHypothesis/bridgedb/compare/b39e576...enhancement/33008
 #diff-da8cb8ff8611ae66137826849e137287R330 few lines] have broken weirdly.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33644 [Circumvention/Snowflake]: Upgrade tor on Snowflake bridge for TROVE-2020-002

[Tor Bug Tracker & Wiki]

#33644: Upgrade tor on Snowflake bridge for TROVE-2020-002
-+
 Reporter:  dcf  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 [https://lists.torproject.org/pipermail/tor-
 announce/2020-March/000196.html New stable Tor releases: 0.3.5.10,
 0.4.1.9, and 0.4.2.7]
 > These releases fix a couple of denial-of-service vulnerabilities.
 Everybody running an older version should upgrade as packages become
 available.

 Upgrading tor may require an [https://www.debian.org/releases/buster/amd64
 /release-notes/ch-upgrading.en.html OS upgrade] from Debian stretch
 (oldstable) to buster (stable), and/or a switch to the
 [https://support.torproject.org/apt/tor-deb-repo/ torproject.org package
 repository]. Currently the bridge is on stretch. whose available version
 is [https://packages.debian.org/stretch/tor 0.2.9.16-1].

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33645 [Internal Services/Service - trac]: Add new Sponsor 58 to trac

[Tor Bug Tracker & Wiki]

#33645: Add new Sponsor 58 to trac
--+-
 Reporter:  pili  |  Owner:  qbi
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Hi,

 Can someone please add a new sponsor to trac:

 sponsor58-must
 sponsor58-can
 sponsor58

 Thank you :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31159 [Internal Services/Tor Sysadmin Team]: Monitor anti-censorship www services with prometheus

[Tor Bug Tracker & Wiki]

#31159: Monitor anti-censorship www services with prometheus
-+-
 Reporter:  phw  |  Owner:  hiro
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-february tpa-roadmap-|  Actual Points:
  march  |
Parent ID:  #30152   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by phw):

 Replying to [comment:12 hiro]:
 > This is all configured now. It is quite quick for us to add targets and
 as I mentioned maybe we can give up on using puppet for this and just give
 you the opportunity to edit the configuration file directly. Let's see how
 it goes.
 [[br]]
 Thanks!

 I took a look at the Grafana dashboard and found it difficult to interpret
 the data. For example, 146.57.248.225:22 is currently offline and the
 panels don't reveal that. I understand that one can add panels (I think I
 would like an "Alert List") but I'm struggling with creating one.

 I would like something similar to the following UI. Is this something you
 can help with?

 [[Image(mmonit.png, 70%)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31159 [Internal Services/Tor Sysadmin Team]: Monitor anti-censorship www services with prometheus

[Tor Bug Tracker & Wiki]

#31159: Monitor anti-censorship www services with prometheus
-+-
 Reporter:  phw  |  Owner:  hiro
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-february tpa-roadmap-|  Actual Points:
  march  |
Parent ID:  #30152   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by phw):

 * Attachment "mmonit.png" added.

 mmonit Web UI

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19409 [Circumvention/Snowflake]: Make a deb of snowflake and get into Debian

[Tor Bug Tracker & Wiki]

#19409: Make a deb of snowflake and get into Debian
-+--
 Reporter:  adrelanos|  Owner:  cohosh
 Type:  enhancement  | Status:  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by anarcat):

 >  honestly i'm a bit surprised more dependencies aren't coming up. Is
 dh_make_golang conservative in the dependencies it says are missing and
 we'll find more once we start building it?

 I'm not sure it recurses into those dependencies.

 Who's that "pion" anyways? :)

 >  I also noticed in this process that some of the dependencies are
 circular (e.g., pion/turn requires pion/stun and vice versa). Will this
 cause problems?

 There's a bootstrapping problem, for sure, as you need one source package
 to build the other. But if you can manage it locally, when both packages
 are uploaded at once, it should just work.

 >  There's also some cases where some dependencies require different
 versions of the same dependency (e.g., pion/rtp v1.3.2 and v1.3.0 are
 required).

 That's something that should be resolved upstream anyways, shouldn't it?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33593 [Circumvention/Snowflake]: Create versions and changelogs for Snowflake pieces

[Tor Bug Tracker & Wiki]

#33593: Create versions and changelogs for Snowflake pieces
-+--
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19409   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by phw):

 Replying to [comment:3 arlolra]:
 > > My proposal for this would be to
 >
 > Seems ok to me if others are on board.  As mentioned in the logs, it's
 important to me to maintain the git history.
 [[br]]
 Agreed on the proposal and on the importance of preserving our git
 history!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19409 [Circumvention/Snowflake]: Make a deb of snowflake and get into Debian

[Tor Bug Tracker & Wiki]

#19409: Make a deb of snowflake and get into Debian
-+--
 Reporter:  adrelanos|  Owner:  cohosh
 Type:  enhancement  | Status:  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 Replying to [comment:24 anarcat]:
 > >  Anarcat: one other thing you could do here that would be really
 helpful: give cohosh some intuition about how much future ongoing misery
 she's signing herself up for, by offering to help package/maintain the set
 of go libs she'll depend on. With that knowledge, the anti-censorship team
 should think about whether signing up for that commitment is the best use
 of their limited time -- or said another way, how to make things scale
 well enough for the future.
 >
 > I think that really depends on how popular those libs are and how many
 they are. I wouldn't commit to an answer before looking deeper into that.
 :)

 `dh_make_golang` is telling me we need to packetize the following:
 {{{
 itp-golang-github-pion-datachannel.txt
 itp-golang-github-pion-dtls.txt
 itp-golang-github-pion-ice.txt
 itp-golang-github-pion-logging.txt
 itp-golang-github-pion-mdns.txt
 itp-golang-github-pion-rtcp.txt
 itp-golang-github-pion-rtp.txt
 itp-golang-github-pion-sctp.txt
 itp-golang-github-pion-sdp.txt
 itp-golang-github-pion-srtp.txt
 itp-golang-github-pion-stun.txt
 itp-golang-github-pion-transport.txt
 itp-golang-github-pion-turn.txt
 itp-golang-github-pion-webrtc.txt
 itp-snowflake.git.txt
 }}}
 honestly i'm a bit surprised more dependencies aren't coming up. Is
 `dh_make_golang` conservative in the dependencies it says are missing and
 we'll find more once we start building it?

 I also noticed in this process that some of the dependencies are circular
 (e.g., pion/turn requires pion/stun and vice versa). Will this cause
 problems?

 There's also some cases where some dependencies require different versions
 of the same dependency (e.g., pion/rtp v1.3.2 and v1.3.0 are required).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33008 [Metrics/Relay Search]: Display a bridge's distribution bucket

[Tor Bug Tracker & Wiki]

#33008: Display a bridge's distribution bucket
-+-
 Reporter:  phw  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Relay Search |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s30-o24a1, anti-censorship-roadmap-  |  Actual Points:
  2020Q1 metrics-team-roadmap-2020Q1 |
Parent ID:  #31281   | Points:  2
 Reviewer:  cohosh   |Sponsor:
 |  Sponsor30-can
-+-

Comment (by phw):

 Replying to [comment:28 karsten]:
 > The delay between BridgeDB assigning a new bridge to a distributor and
 Relay Search learning about it is roughly linearly distributed from 1 to
 25 hours. For example, the bridge pool assignments file written by
 BridgeDB at 2020-03-16T00:01:45Z was archived by CollecTor at
 2020-03-17T00:09:00Z and would be processed by Onionoo at about
 2020-03-17T00:45:00Z. That's the worst case scenario, though. How about
 you write something vague like "usually within one day" and keep the "be
 patient" part? :)
 [[br]]
 Perfect, thanks Karsten.

 Cecylia, can you please review the following three commits?
 https://github.com/NullHypothesis/bridgedb/compare/b39e576...enhancement/33008

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33593 [Circumvention/Snowflake]: Create versions and changelogs for Snowflake pieces

[Tor Bug Tracker & Wiki]

#33593: Create versions and changelogs for Snowflake pieces
-+--
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19409   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arlolra):

 > My proposal for this would be to

 Seems ok to me if others are on board.  As mentioned in the logs, it's
 important to me to maintain the git history.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33643 [Core Tor/Tor]: Appveyor: OpenSSL version mismatch in unit tests, 2020 edition

[Tor Bug Tracker & Wiki]

#33643: Appveyor: OpenSSL version mismatch in unit tests, 2020 edition
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail, appveyor, windows,  |  Actual Points:
  035-backport, 041-backport, 042-backport,  |
  043-backport, consider-backport-after-ci-  |
  passes |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Description changed by teor:

Old description:

> It's happened again:
> {{{
> OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
> }}}
> https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
>
> Just like #32449, #28574, #28399 and #25942.
>
> We think our tests are fragile, because they are not copying the
> necessary libraries into `${env:build}/src/test` from `C:/mingw32/lib`:
> {{{
> ssl
> crypto
> lzma
> event
> zstd
> }}}
> at https://github.com/ahf/tor/blob/master/.appveyor.yml#L98-L99
>
> These libraries might have different dll prefixes or suffixes, for
> example, OpenSSL is:
> {{{
> /mingw32/bin/libcrypto-1_1.dll
> /mingw32/bin/libssl-1_1.dll
> }}}
> https://packages.msys2.org/package/mingw-w64-i686-openssl
>
> We might also want to copy these libraries into the same directory as the
> tor executable, before we run the tests that launch tor.

New description:

 It's happened again:
 {{{
 OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
 }}}
 
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380

 Just like #32449, #28574, #28399 and #25942.

 We think our tests are fragile, because they are not copying the necessary
 libraries into `${env:build}/src/test` from `C:/mingw32/lib`:
 {{{
 ssl
 crypto
 lzma
 event
 zstd
 }}}

 We already copy zlib and ssp at
 https://github.com/ahf/tor/blob/master/.appveyor.yml#L98-L99 .

 These libraries might have different dll prefixes or suffixes, for
 example, OpenSSL is:
 {{{
 /mingw32/bin/libcrypto-1_1.dll
 /mingw32/bin/libssl-1_1.dll
 }}}
 https://packages.msys2.org/package/mingw-w64-i686-openssl

 We might also want to copy these libraries into the same directory as the
 tor executable `${env:build}/src/app`, before we run the tests that launch
 tor.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33643 [Core Tor/Tor]: Appveyor: OpenSSL version mismatch in unit tests, 2020 edition

[Tor Bug Tracker & Wiki]

#33643: Appveyor: OpenSSL version mismatch in unit tests, 2020 edition
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-ci-fail, appveyor, windows,
 Severity:  Normal   |  035-backport, 041-backport, 042-backport,
 |  043-backport, consider-backport-after-ci-passes
Actual Points:   |  Parent ID:
   Points:  0.5  |   Reviewer:
  Sponsor:   |
-+-
 It's happened again:
 {{{
 OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
 }}}
 
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380

 Just like #32449, #28574, #28399 and #25942.

 We think our tests are fragile, because they are not copying the necessary
 libraries into `${env:build}/src/test` from `C:/mingw32/lib`:
 {{{
 ssl
 crypto
 lzma
 event
 zstd
 }}}
 at https://github.com/ahf/tor/blob/master/.appveyor.yml#L98-L99

 These libraries might have different dll prefixes or suffixes, for
 example, OpenSSL is:
 {{{
 /mingw32/bin/libcrypto-1_1.dll
 /mingw32/bin/libssl-1_1.dll
 }}}
 https://packages.msys2.org/package/mingw-w64-i686-openssl

 We might also want to copy these libraries into the same directory as the
 tor executable, before we run the tests that launch tor.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33613 [Applications/Tor Browser]: 811786

[Tor Bug Tracker & Wiki]

#33613: 811786
--+---
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202003  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

 * status:  merge_ready => needs_information
 * keywords:   => TorBrowserTeam202003


Comment:

 Okay, these were both merged onto their respective branches.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25309 [Metrics/CollecTor]: Use java8 datetime classes in bridgedesc module

[Tor Bug Tracker & Wiki]

#25309: Use java8 datetime classes in bridgedesc module
---+--
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID:  #23752 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by subha):

 Hello, I am applying for GSOC 2020 for your organisation and would like to
 work on this issue.
 Can you please explain a bit more about the issue?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33624 [Core Tor/Tor]: Static building tor with openssl does not work

[Tor Bug Tracker & Wiki]

#33624: Static building tor with openssl does not work
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  build static openssl  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Left a couple of comments on the branch.

 Also, for testing, could you give me detailed instructions for a command
 line that works with this patch, and does not work without it?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33633 [Core Tor/Tor]: Move extend and reachability code to the relay module

[Tor Bug Tracker & Wiki]

#33633: Move extend and reachability code to the relay module
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311, technical-debt  |  Actual Points:  1.0
Parent ID:  #33220 | Points:  0.5
 Reviewer:  nickm  |Sponsor:
   |  Sponsor55-must
---+---
Changes (by teor):

 * actualpoints:  0.5 => 1.0


Comment:

 Yes, I think you're right about the test coverage. I knew there was
 something I had forgotten!

 I'll need good test coverage here, because these are some of the functions
 I'll be modifying as part of Sponsor 55. (For IPv6 extends, and
 reachability checks.)

 And I don't want to depend on chutney to test all these special cases.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33633 [Core Tor/Tor]: Move extend and reachability code to the relay module

[Tor Bug Tracker & Wiki]

#33633: Move extend and reachability code to the relay module
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311, technical-debt  |  Actual Points:  0.5
Parent ID:  #33220 | Points:  0.5
 Reviewer:  nickm  |Sponsor:
   |  Sponsor55-must
---+---
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 (Also I left a note on the PR)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33624 [Core Tor/Tor]: Static building tor with openssl does not work

[Tor Bug Tracker & Wiki]

#33624: Static building tor with openssl does not work
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  build static openssl  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * reviewer:   => nickm


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33633 [Core Tor/Tor]: Move extend and reachability code to the relay module

[Tor Bug Tracker & Wiki]

#33633: Move extend and reachability code to the relay module
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311, technical-debt  |  Actual Points:  0.5
Parent ID:  #33220 | Points:  0.5
 Reviewer:  nickm  |Sponsor:
   |  Sponsor55-must
---+---

Comment (by nickm):

 Looks good on first glance. I need to take a second look at these commits,
 since they are nontrivial.
   * relay: Split link specifier checks from circuit_extend()
   * relay: Split out opening a connection for an extend

 In the mean time, is it reasonable to try to get test coverage here,
 particularly on the new check functions introduced in those two commits?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33633 [Core Tor/Tor]: Move extend and reachability code to the relay module

[Tor Bug Tracker & Wiki]

#33633: Move extend and reachability code to the relay module
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311, technical-debt  |  Actual Points:  0.5
Parent ID:  #33220 | Points:  0.5
 Reviewer:  nickm  |Sponsor:
   |  Sponsor55-must
---+---

Comment (by teor):

 It's not quite #32804, but I've added it to the list there, for my next
 email to Travis.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #32804 [Core Tor/Tor]: Travis CI hangs during compile or test

[Tor Bug Tracker & Wiki]

#32804: Travis CI hangs during compile or test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-rarely-fail, tor-test, hang,  |  Actual Points:
  tor-ci, 043-should |
Parent ID:  #29645   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Here's a Linux network timeout hang:
 https://travis-ci.org/github/torproject/tor/jobs/663854119#L203

 It would be nice if Travis wrapped its own apt-get in travis_retry.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33633 [Core Tor/Tor]: Move extend and reachability code to the relay module

[Tor Bug Tracker & Wiki]

#33633: Move extend and reachability code to the relay module
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311, technical-debt  |  Actual Points:  0.5
Parent ID:  #33220 | Points:  0.5
 Reviewer:  nickm  |Sponsor:
   |  Sponsor55-must
---+---

Comment (by nickm):

 (Looking now. There's a travis build failure, but it seems to be a bogus
 network timeout during apt-get.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33131 [Core Tor/Tor]: Bug: buf->datalen >= 0x7fffffff

[Tor Bug Tracker & Wiki]

#33131: Bug: buf->datalen >= 0x7fff
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by nickm):

 Replying to [comment:9 cypherpunks]:
 > Redid the branch a bit. Not sure how to test it.
 >
 > Replying to [comment:8 nickm]:
 >
 > Yeah, the logging shouldn't be in the final version. It would just help
 to confirm which number is the one that's extremely high: at_most, or
 buf->datalen.

 One possibility if you want to keep the logging is to use log_ratelim(),
 to prevent it from writing the message too often.

 > Logging would definitely be too loud, considering #31036 and #32022.
 >
 > (Historical note, this
 
[https://gitweb.torproject.org/tor.git/commit/?id=ee5471f9aab55269c8c480f1f90dfeb08803ac15
 particular check] was added in #21369.)
 >
 > So the high burst value, which becomes `at_most` later, is set in
 `connection_or_update_token_buckets_helper`. Doesn't it comes from the
 `BandwidthBurst` option, not `BandwidthRate`?

 Ultimately, yes, though I think there are other things that influence it.

 > As long as we add this sanity check, is there a problem with keeping
 this behavior of using that high value from the user's configuration?
 `at_most` serves as an upper bound on what can be read from the socket in
 one go, so it has to be limited by something like `BUF_MAX_LEN`, but the
 burst limit in the token bucket doesn't have to be limited by that. The
 burst limit persists across multiple calls to `connection_handle_read()`
 (and any draining of `inbuf` in between calls).

 Hm.  I guess this might not be a problem, though I'd be surprised if the
 code as it stands actually could deliver such a high burst.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31159 [Internal Services/Tor Sysadmin Team]: Monitor anti-censorship www services with prometheus

[Tor Bug Tracker & Wiki]

#31159: Monitor anti-censorship www services with prometheus
-+-
 Reporter:  phw  |  Owner:  hiro
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-february tpa-roadmap-|  Actual Points:
  march  |
Parent ID:  #30152   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Hi phw,
 This is all configured now. It is quite quick for us to add targets and as
 I mentioned maybe we can give up on using puppet for this and just give
 you the opportunity to edit the configuration file directly. Let's see how
 it goes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33642 [Core Tor/Tor]: Add *.a to .gitignore

[Tor Bug Tracker & Wiki]

#33642: Add *.a to .gitignore
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  build configure
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 Made a mistake to add a .a file while switching from 043 and master into a
 branch.

 I think adding `*.a` to .gitignore should be a reasonable idea since these
 files are always generated in our build system.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33458 [Core Tor/Tor]: Assertion desc failed in hs_client_close_intro_circuits_from_desc at src/feature/hs/hs_client.c: 2413

[Tor Bug Tracker & Wiki]

#33458: Assertion desc failed in hs_client_close_intro_circuits_from_desc at
src/feature/hs/hs_client.c: 2413
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs client-auth assert  043-must  |  Actual Points:  0.3
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Pushed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33624 [Core Tor/Tor]: Static building tor with openssl does not work

[Tor Bug Tracker & Wiki]

#33624: Static building tor with openssl does not work
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  build static openssl  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Appveyor CI appears to be failing with `cannot find -ldl`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33072 [Core Tor/Tor]: When under load, give 503 aggressively for dirport requests without compression

[Tor Bug Tracker & Wiki]

#33072: When under load, give 503 aggressively for dirport requests without
compression
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health 043-should consider-  |  Actual Points:
  backport-after-0434 042-backport 043-backport  |
Parent ID:  #33018   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 I'm not suggesting any complicated new features.

 The current logic is a bit complicated. And the code does not match the
 man page.

 At the moment, "always answer compressed" overrides
 AuthDirRejectRequestsUnderLoad. I don't think that's useful or necessary.
 And it's not documented.

 Here is what the code does now:

 * '''compressed requests''': always answer
* includes tor authorities, relays, clients: almost always compressed

 * if AuthDirRejectUncompressedRequests is:
   * '''1 - reject uncompressed''': all uncompressed requests will be
 rejected
   * '''0 - accept uncompressed''': uncompressed requests are handled based
 on other options (see below)

 * if AuthDirRejectRequestsUnderLoad is:
   * '''1 - reject under load''': depends on the write bucket load:
 * '''too much load''': we will reject uncompressed requests (usually
 bots)
 * '''room to answer''': we will answer uncompressed requests (usually
 bots)
   * '''0 - accept all''': we will answer uncompressed requests (usually
 bots)

 I don't think that's the design we want.

 So I suggest we delete these lines:
 {{{
   if (c_method != NO_METHOD) {
   /* Always answer compressed request. */
   return false;
 }
 }}}

 Here is what the code does after we delete those lines:

 * if AuthDirRejectUncompressedRequests is:
   * '''1 - reject uncompressed''': all uncompressed requests will be
 rejected
   * '''0 - accept uncompressed''': uncompressed requests are handled like
 compressed requests, based on other options (see below)

 * if AuthDirRejectRequestsUnderLoad is:
   * '''1 - reject under load''':
 * '''relay or authority''' always answer
 * '''client''': depends on the write bucket load:
   * '''too much load''': we will reject requests from clients
   * '''room to answer''': we will answer requests from clients
   * '''0 - accept all''': we will answer all requests

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33120 [Core Tor/Tor]: Resolve TROVE-2020-002

[Tor Bug Tracker & Wiki]

#33120: Resolve TROVE-2020-002
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  043-must 035-backport 041-backport   |  Actual Points:  3
  042-backport   |
Parent ID:   | Points:  1
 Reviewer:  ahf, asn, catalyst   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  043-must => 043-must 035-backport 041-backport 042-backport
 * status:  needs_review => closed
 * resolution:   => fixed
 * actualpoints:   => 3


Old description:



New description:

 This is the description I posted in the changelog:
 {{{
   TROVE-2020-002 is a vulnerability affecting
   all released Tor instances since 0.2.1.5-alpha. Using this
   vulnerability, an attacker could cause Tor instances to consume a huge
   amount of CPU, disrupting their operations for several seconds or
   minutes. This attack could be launched by anybody against a relay, or
   by a directory cache against any client that had connected to it. The
   attacker could launch this attack as much as they wanted, thereby
   disrupting service or creating patterns that could aid in traffic
   analysis. This issue was found by OSS-Fuzz, and is also tracked
   as CVE-2020-10592.
 }}}

 I will post a more detailed analysis in a week or so.

 This issue is fixed in today's Tor releases: 0.3.5.10, 0.4.1.9, 0.4.2.7,
 and 0.4.3.3-alpha.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33458 [Core Tor/Tor]: Assertion desc failed in hs_client_close_intro_circuits_from_desc at src/feature/hs/hs_client.c: 2413

[Tor Bug Tracker & Wiki]

#33458: Assertion desc failed in hs_client_close_intro_circuits_from_desc at
src/feature/hs/hs_client.c: 2413
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs client-auth assert  043-must  |  Actual Points:  0.3
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Ugh one final thing. This is missing a changes file!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33072 [Core Tor/Tor]: When under load, give 503 aggressively for dirport requests without compression

[Tor Bug Tracker & Wiki]

#33072: When under load, give 503 aggressively for dirport requests without
compression
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health 043-should consider-  |  Actual Points:
  backport-after-0434 042-backport 043-backport  |
Parent ID:  #33018   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by dgoulet):

 Replying to [comment:20 teor]:
 > Sounds like it will solve our current problem with uncompressed
 requests.
 > So we could merge as it is.
 >
 > But what if the DoS switches to compressed requests?

 In that case, we serve everything. This ticket was meant to improve the
 current situation instead of finding a long term fix and thus yes if the
 DoS switches, we have another problem.

 >
 > When we are rejecting uncompressed requests, can we look at the write
 limit for compressed client requests?

 That would mean a specific write limit for compressed client requests? Is
 this what you mean? Or if uncompressed requests, we should only reject if
 limit is too low?

 Right now, this only looks at the global write bucket. It would require
 significant changes to have limits per "type" of requests (client vs
 relay, compressed vs uncompressed, ...).

 Another reason for this is that only very old clients will request
 uncompressed and thus this patch would refuse them access to directory
 documents. But could also create some thundering herd maybe?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33072 [Core Tor/Tor]: When under load, give 503 aggressively for dirport requests without compression

[Tor Bug Tracker & Wiki]

#33072: When under load, give 503 aggressively for dirport requests without
compression
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health 043-should consider-  |  Actual Points:
  backport-after-0434 042-backport 043-backport  |
Parent ID:  #33018   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 Sounds like it will solve our current problem with uncompressed requests.
 So we could merge as it is.

 But what if the DoS switches to compressed requests?

 When we are rejecting uncompressed requests, can we look at the write
 limit for compressed client requests?
 Seems like a simple change that could be really useful.

 I don't think we need to be worried about the DoS switching to relay
 requests. That's a significant amount of error time for an attacker.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33545 [Core Tor/Tor]: assertion failure when "all zero" client auth key provided

[Tor Bug Tracker & Wiki]

#33545: assertion failure when "all zero" client auth key provided
--+
 Reporter:  mcs   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal| Resolution:  duplicate
 Keywords:  043-should|  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by asn):

 * status:  needs_review => closed
 * resolution:   => duplicate


Comment:

 This was fixed as part of #33137.

 Many thanks for the fix branch. The branch we merged as part of #33137 is
 equivalent. Feel free to review it if you'd like.

 Thanks! :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33069 [Core Tor/Tor]: Init sk if loaded from service blob to be on the curve

[Tor Bug Tracker & Wiki]

#33069: Init sk if loaded from service blob to be on the curve
--+
 Reporter:  saibato   |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:  duplicate
 Keywords:  backport? 043-should  |  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by asn):

 * status:  needs_review => closed
 * resolution:   => duplicate


Comment:

 This was fixed as part of #33137.

 Thanks for the report! :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33072 [Core Tor/Tor]: When under load, give 503 aggressively for dirport requests without compression

[Tor Bug Tracker & Wiki]

#33072: When under load, give 503 aggressively for dirport requests without
compression
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health 043-should consider-  |  Actual Points:
  backport-after-0434 042-backport 043-backport  |
Parent ID:  #33018   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by dgoulet):

 With this, and #33029, everything coming from dirauth and relays is served
 as in the authority ignores the write limit.

 So vote are _always_ served and anything coming from relays.

 Thus this patch only applies to client requests. If compressed, they are
 served but if not, we look at the write limit and send back 503. Before
 this, dirauth would just answer everything regardless of write limit.

 Is that sufficient or you still think we should prioritize. There is a
 challenge with prioritizing because that means we need to spool together
 the inbound requests and order it?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23226 [Applications/GetTor]: GetTor help message could be more helpful

[Tor Bug Tracker & Wiki]

#23226: GetTor help message could be more helpful
-+-
 Reporter:  catalyst |  Owner:  cohosh
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1, ux-  |  Actual Points:
  team   |
Parent ID:  #9036| Points:  1
 Reviewer:  phw  |Sponsor:
-+-

Comment (by antonela):

 Replying to [comment:21 cohosh]:
 > Okay great, so the next step is to implement it then? If so, I'll move
 forward with a patch!

 I think so, Thanks!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33640 [Core Tor/Tor]: Add PATH_BIAS_TESTING purpose to specs

[Tor Bug Tracker & Wiki]

#33640: Add PATH_BIAS_TESTING purpose to specs
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, 044-should  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  tor-spec => tor-spec, 044-should
 * points:   => 0.5
 * milestone:   => Tor: 0.4.4.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33641 [Core Tor/Tor]: Spurious coverity unreachable warning after all bugs are fatal test skip

[Tor Bug Tracker & Wiki]

#33641: Spurious coverity unreachable warning after all bugs are fatal test skip
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core  |Version:
  Tor/Tor |
 Severity:  Normal|   Keywords:  044-must, coverity, false-positive
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 There's a spurious coverity warning about unreachable code, in tests that
 we're skipping when ALL_BUGS_ARE_FATAL is defined.

 I guess we need to wrap those skips in `#ifndef COVERITY`.

 {{{
 ** CID 1460753:  Control flow issues  (UNREACHABLE)
 /src/test/test_dir.c: 4998 in
 test_dir_purpose_needs_anonymity_returns_true_by_default()


 

 *** CID 1460753:  Control flow issues  (UNREACHABLE)
 /src/test/test_dir.c: 4998 in
 test_dir_purpose_needs_anonymity_returns_true_by_default()
 4992   (void)arg;
 4993
 4994 #ifdef ALL_BUGS_ARE_FATAL
 4995   tt_skip();
 4996 #endif
 4997
CID 1460753:  Control flow issues  (UNREACHABLE)
This code cannot be reached: "tor_capture_bugs_(1);".
 4998   tor_capture_bugs_(1);
 4999   setup_full_capture_of_logs(LOG_WARN);
 5000   tt_int_op(1, OP_EQ, purpose_needs_anonymity(0, 0, NULL));
 5001   tt_int_op(1, OP_EQ,
 smartlist_len(tor_get_captured_bug_log_()));
 5002   expect_single_log_msg_containing("Called with dir_purpose=0");
 5003

 ** CID 1460752:  Control flow issues  (UNREACHABLE)
 /src/test/test_circuitbuild.c: 123 in test_new_route_len_unhandled_exit()


 

 *** CID 1460752:  Control flow issues  (UNREACHABLE)
 /src/test/test_circuitbuild.c: 123 in test_new_route_len_unhandled_exit()
 117 #ifdef ALL_BUGS_ARE_FATAL
 118   tt_skip();
 119 #endif
 120
 121   MOCK(count_acceptable_nodes, mock_count_acceptable_nodes);
 122
CID 1460752:  Control flow issues  (UNREACHABLE)
This code cannot be reached: "tor_capture_bugs_(1);".
 123   tor_capture_bugs_(1);
 124   setup_full_capture_of_logs(LOG_WARN);
 125   r = new_route_len(CIRCUIT_PURPOSE_CONTROLLER, _ei,
 _nodes);
 126   tt_int_op(DEFAULT_ROUTE_LEN + 1, OP_EQ, r);
 127   tt_int_op(smartlist_len(tor_get_captured_bug_log_()), OP_EQ, 1);
 128   tt_str_op(smartlist_get(tor_get_captured_bug_log_(), 0), OP_EQ,
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33639 [Core Tor/Tor]: Add CHANNEL_CLOSED reason to specs

[Tor Bug Tracker & Wiki]

#33639: Add CHANNEL_CLOSED reason to specs
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, 044-should  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by gk):

 Replying to [comment:1 gk]:
 > It's relevant for `REMOTE_REASON`, too, which might merit an own ticket
 as it is missing whatsoever in the control spec.

 Actually, that's wrong. The control spec at least is taking care of that.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33640 [Core Tor/Tor]: Add PATH_BIAS_TESTING purpose to specs

[Tor Bug Tracker & Wiki]

#33640: Add PATH_BIAS_TESTING purpose to specs
--+--
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Similar to #33639 I found
 {{{
 2020-03-17 21:26:35,977 stem [INFO] CIRC event had an unrecognized purpose
 (PATH_BIAS_TESTING). Maybe a new addition to the control protocol? Full
 Event: 'CIRC 322 CLOSED
 
$8E915C44FD55A433CCAFACF4902BF1B2B16DD36C~snap277,$ECE90C4159D916921F7C8DDF4D088AC3808C521D~piss
 PURPOSE=PATH_BIAS_TESTING TIME_CREATED=2020-03-17T20:26:15.358481
 REASON=FINISHED'
 }}}
 in my `stem` logs and it seems `PATH_BIAS_TESTING` needs to get added to
 the specs as a "new" `PURPOSE` so `stem` can pick this up, too.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33639 [Core Tor/Tor]: Add CHANNEL_CLOSED reason to specs

[Tor Bug Tracker & Wiki]

#33639: Add CHANNEL_CLOSED reason to specs
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, 044-should  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  tor-spec => tor-spec, 044-should
 * points:   => 0.5
 * milestone:   => Tor: 0.4.4.x-final


Comment:

 Let us know if this ticket is part of a sponsor :-)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33639 [Core Tor/Tor]: Add CHANNEL_CLOSED reason to specs

[Tor Bug Tracker & Wiki]

#33639: Add CHANNEL_CLOSED reason to specs
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 It's relevant for `REMOTE_REASON`, too, which might merit an own ticket as
 it is missing whatsoever in the control spec.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #33639 [Core Tor/Tor]: Add CHANNEL_CLOSED reason to specs

[Tor Bug Tracker & Wiki]

#33639: Add CHANNEL_CLOSED reason to specs
--+--
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I was recently looking at stem debug logs and found
 {{{
 2020-03-17 21:10:58,838 stem [INFO] CIRC event had an unrecognized
 remote_reason (CHANNEL_CLOSED). Maybe a new addition to the control
 protocol? Full Event: 'CIRC 6 FAILED
 $0CDD60E4015EBF2C3B5D32A2B9CC8FE6C98A5C33~UnivUtah3 PURPOSE=GENERAL
 TIME_CREATED=2020-03-17T20:10:25.388134 REASON=DESTROYED
 REMOTE_REASON=CHANNEL_CLOSED'
 }}}
 I am not sure how the `stem` workflow works but I guess it's an
 implementation based on the spec(s) (not what is actually used/allowed in
 the tor code).

 Thus, we should fix the spec(s) first so we can add the respective `stem`
 part later on.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33633 [Core Tor/Tor]: Move extend and reachability code to the relay module

[Tor Bug Tracker & Wiki]

#33633: Move extend and reachability code to the relay module
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311, technical-debt  |  Actual Points:  0.5
Parent ID:  #33220 | Points:  0.5
 Reviewer:  nickm  |Sponsor:
   |  Sponsor55-must
---+---

Comment (by teor):

 Did a bit more refactoring, and added a changes file.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs