[tor-bugs] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm,
 Severity:  Normal   |  TorBrowserTeam201812,
 |  GeorgKoppen201812
Actual Points:   |  Parent ID:  #28238
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The mingw-w64 project is currently GCC based. We should start creating a
 parallel project, mingw-w64-clang, that helps us introducing this new
 toolchain step by step to all the other components we need for the Windows
 bundles.

--
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] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201812,   |  Actual Points:
  GeorgKoppen201812  |
Parent ID:  #28238   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * priority:  Medium => High


--
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] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201812,   |  Actual Points:
  GeorgKoppen201812  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-rbm => tbb-rbm, TorBrowserTeam201812, GeorgKoppen201812


--
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] #28697 [Applications/Tor Browser]: Our QA and testing .apks are signed with a key per build

[Tor Bug Tracker & Wiki]

#28697: Our QA and testing .apks are signed with a key per build
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201812  |  Actual Points:
Parent ID:  #25164| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sisbell):

 When we sign with the apk, the generated META-INF directory contains a
 timestamp on the files. This causes the apk checksums to be different. I'm
 looking into how fix 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

[tor-bugs] #28715 [Core Tor/sbws]: Some torrc options don't have an argument

[Tor Bug Tracker & Wiki]

#28715: Some torrc options don't have an argument
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 In stem.py, sbws requires extra torrc options to have a keyword and an
 argument. But an empty list is a valid value for some torrc options.

 For example:
 {{{
 LongLivedPorts
 ExitPolicy
 }}}

 Tentatively assigning to sbws 1.0, because this kind of bug could really
 annoy operators.

--
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] #27049 [Core Tor/Tor]: "No circuits are opened" messages with onion services

[Tor Bug Tracker & Wiki]

#27049: "No circuits are opened" messages with onion services
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  033-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by teor):

 I opened #28714 for the controller 1- and 2-hop circuit case.

--
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] #17359 [Core Tor/Tor]: __DisablePredictedCircuits causes bootstrap to hang at "Connecting to Tor Network"

[Tor Bug Tracker & Wiki]

#17359: __DisablePredictedCircuits causes bootstrap to hang at "Connecting to 
Tor
Network"
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-hs bootstrap sponsor8-maybe  |  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 This issue is related to #28714, but #28714 probably won't fix 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] #28639 [Core Tor/sbws]: After several days, most of the circuits timeout

[Tor Bug Tracker & Wiki]

#28639: After several days, most of the circuits timeout
--+
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:
  |  needs_information
 Priority:  Medium|  Milestone:  sbws:
  |  1.0.x-final
Component:  Core Tor/sbws |Version:
 Severity:  Normal| Resolution:
 Keywords:  sbws-1.0-must-moved-20181128  |  Actual Points:
Parent ID:  #25925| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 This issue is an instance of #27049: sbws does not open any 3-hop
 circuits, so it stalls when all 3-hop circuits time out.

 One quick fix is to enable predicted circuits (#28701).

 I opened a tor ticket for this issue (#28714).

--
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] #28701 [Core Tor/sbws]: Try enabling predicted circuits in sbws

[Tor Bug Tracker & Wiki]

#28701: Try enabling predicted circuits in sbws
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28639 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 We can set these options to reduce the number of circuits that tor builds:
 {{{
 LongLivedPorts
 PredictedPortsRelevanceTime 0 seconds
 LearnCircuitBuildTimeout 0
 }}}
 https://trac.torproject.org/projects/tor/ticket/17359#comment: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] #28714 [Core Tor/Tor]: "No circuits are opened" on controllers that DisablePredictedCircuits and build 2-hop circuits

[Tor Bug Tracker & Wiki]

#28714: "No circuits are opened" on controllers that DisablePredictedCircuits 
and
build 2-hop circuits
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-bwauth, tor-bootstrap
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 sbws sets `DisablePredictedCircuits 0` after bootstrap, then builds 2-hop
 circuits using a controller. After a few days, once all the 3-hop circuits
 time out, sbws stalls (#28639).

 We can fix this issue by considering all controller circuits to be opened
 circuits, regardless of length. The relevant code is in
 circuit_any_opened_circuits().

 On most clients, Tor's predicted circuits code keeps opening enough
 circuits to avoid a stall.

--
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] #27049 [Core Tor/Tor]: "No circuits are opened" messages with onion services

[Tor Bug Tracker & Wiki]

#27049: "No circuits are opened" messages with onion services
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  033-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by teor):

 I left a question on the pull request about intro and rend circuits.

 I think we should backport to 0.2.9, because this bug can cause clients to
 stall (see #28639, same bug, different trigger).

--
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] #28706 [Core Tor/sbws]: Maybe implement resolving destination domain using Tor's RESOLVE and ADDRMAP events

[Tor Bug Tracker & Wiki]

#28706: Maybe implement resolving destination domain using Tor's RESOLVE and
ADDRMAP events
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 This change might slow down sbws, because it adds an extra step for each
 exit connection.
 Maybe we should just let tor exits do DNS resolution?

 If we do get a lot of failures, we will need to make sure that the failure
 reason is EXITPOLICY. Otherwise this change won't work.

 It might be easier and more reliable to implement #28463, or just use
 failed exits as entries if their failure rate is too high.

--
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] #25925 [Core Tor/sbws]: bwauth improvements (ex-parent ticket for SoP planned tasks)

[Tor Bug Tracker & Wiki]

#25925: bwauth improvements (ex-parent ticket for SoP planned tasks)
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:8 juga]:
 > I think this parent would be more useful to track only Core-Tor tickets,
 since sbws can be track by component.
 > If you agree, i'll remove the children that are sbws and leave only the
 Core-Tor ones.

 Ok, that works.

 Or you can just use a keyword to track Core Tor tickets. Whatever is
 easier for 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] #26770 [Core Tor/Tor]: Implement proposal 293: "Other ways for relays to know when to publish"

[Tor Bug Tracker & Wiki]

#26770: Implement proposal 293: "Other ways for relays to know when to publish"
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop293, prop275, 040-roadmap-   |  Actual Points:  .1
  proposed   |
Parent ID:  #21642   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me, I'll leave it to you to open a ticket for the extra
 tests.

--
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] #28713 [- Select a component]: Disabled Network is set

[Tor Bug Tracker & Wiki]

#28713: Disabled Network is set
-+--
 Reporter:  seamusf  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  - Select a component
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 tried using a socks proxy to see how they worked and managed to disable my
 tor browser. ive unistalled and reinstalled multiple times and it has not
 worked at all.

--
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] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * owner:  neel => teor
 * status:  needs_review => assigned


Comment:

 Ok, I think we're good here. I'll do the rebase and squash once I have my
 dev environment working again.

--
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] #28229 [Core Tor/Tor]: Possible race condition opening SOCKS Port in test_rebind.py

[Tor Bug Tracker & Wiki]

#28229: Possible race condition opening SOCKS Port in test_rebind.py
-+
 Reporter:  teor |  Owner:  rl1987
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, 035-can  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me, but it's a diagnostic, so we shouldn't close the ticket.

--
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] #28601 [Core Tor/sbws]: sbws.rtfd.io does not show the contents of the API

[Tor Bug Tracker & Wiki]

#28601: sbws.rtfd.io does not show the contents of the API
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  teor   |Sponsor:
---+---
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Looks fine 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] #28646 [Core Tor/sbws]: Disable adaptive circuit timeouts

[Tor Bug Tracker & Wiki]

#28646: Disable adaptive circuit timeouts
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28692 | Points:
 Reviewer:  teor   |Sponsor:
---+---
Changes (by teor):

 * status:  needs_review => needs_information
 * parent:  #28639 => #28692


Comment:

 Looks good, but I'd like to merge the two different option tables in
 #28692.
 Then we won't need these comments.

--
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] #28479 [Core Tor/Tor]: Update "ReleasingTor.md" to match current practice

[Tor Bug Tracker & Wiki]

#28479: Update "ReleasingTor.md" to match current practice
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Still 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] #28664 [Core Tor/Tor]: Describe consensus digest calculation

[Tor Bug Tracker & Wiki]

#28664: Describe consensus digest calculation
---+
 Reporter:  atagar |  Owner:  teor
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-spec, doc  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * owner:  (none) => teor
 * status:  needs_revision => assigned


Comment:

 I will do this at some point.

--
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] #28692 [Core Tor/sbws]: sbws should set ConnectionPadding 0

[Tor Bug Tracker & Wiki]

#28692: sbws should set ConnectionPadding 0
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  teor   |Sponsor:
---+---
Changes (by teor):

 * status:  needs_review => needs_revision
 * reviewer:   => teor


Comment:

 This patch makes the torrc options in sbws even more complicated.

 Here's what sbws has right now:
 1. a list of hard-coded torrc options in globals.py:
 https://github.com/torproject/sbws/blob/master/sbws/globals.py#L10
 2. a list of configured torrc options in stem.py, and the hard-coded
 option `LearnCircuitBuildTimeout 0`:
 https://github.com/torproject/sbws/blob/master/sbws/util/stem.py#L127
 3. a custom list of torrc options that the user can configure for launch:
 https://github.com/torproject/sbws/blob/master/sbws/util/stem.py#L142
 4. a list of hard-coded torrc options in stem.py, that can't be set until
 after sbws has bootstrapped:
 https://github.com/torproject/sbws/blob/master/sbws/util/stem.py#L197

 Then the pull request adds custom code to ignore the ConnectionPadding
 option if tor doesn't support it. This code is more complicated than it
 needs to be, and it has bugs.

 Here's a simpler design:
 * a list of torrc options in stem.py, containing 1., 2. and 4., with a
 flag saying when the option should be applied to tor (1. and 2. on launch,
 4. after launch)
 * a custom list of torrc options that the user can configure for launch
 (same as 3.)

 (There's an even simpler design in #28712 that makes 3. into a torrc file,
 but it's a breaking change.)

 Once we refactor the torrc option code, we can add:
 * a flag to ignore failures when applying the option after launch
 * a torrc option table entry: ConnectionPadding, 0, apply after launch,
 ignore failures

--
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] #28712 [Core Tor/sbws]: Make conf['tor']['extra_lines'] into a torrc file

[Tor Bug Tracker & Wiki]

#28712: Make conf['tor']['extra_lines'] into a torrc file
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 sbws tries to parse extra torrc options from its config file, and add them
 to the existing options. But this code is buggy: it tries to merge extra
 options with existing options with the same name. That doesn't work if the
 option is only allowed to occur once in the torrc file.

 Tor can get options from these places, in this order:
 * torrc-defaults file
 * torrc file
 * command-line (stem's launch command)
 * control port (stem's control port command)

 Here's a better design for sbws:
 * hard-coded options in a torrc-defaults file
 * extra user options in a torrc file
 * configured options on the command-line
 * runtime options over the control port

 This means that:
 * users can override hard-coded options using the torrc file
 * users can modify configured options using the sbws config.ini
 * users can't modify runtime options (for simplicity)

--
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] #28612 [Core Tor/Tor]: Tor start via Windows service fails

[Tor Bug Tracker & Wiki]

#28612: Tor start via Windows service fails
-+-
 Reporter:  Vort |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  windows nt-service regression|  Actual Points:
  035-backport 035-rc-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * priority:  Medium => High


--
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] #28614 [Core Tor/Tor]: Can't parse networkstatus consensus time

[Tor Bug Tracker & Wiki]

#28614: Can't parse networkstatus consensus time
-+
 Reporter:  Vort |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  040-rc-must, regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 Is there a way to reproduce this easily?  Is there a Tor version where it
 always happens, and one where it never happens?

 I wonder if the mmap-related changes of #27244 could be responsible here.

--
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] #28675 [Core Tor/Tor]: Deprecate standard cookie authentication

[Tor Bug Tracker & Wiki]

#28675: Deprecate standard cookie authentication
+--
 Reporter:  wagon   |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 Replying to [comment:12 nickm]:
 > We should warn in 0.3.5, and remove only once we're sure nobody still
 requires the old authentication method.

 Or at least, we should know what we are breaking before we remove the old
 method. :)

--
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] #28675 [Core Tor/Tor]: Deprecate standard cookie authentication

[Tor Bug Tracker & Wiki]

#28675: Deprecate standard cookie authentication
+--
 Reporter:  wagon   |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 We should warn in 0.3.5, and remove only once we're sure nobody still
 requires the old authentication method.

--
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] #27049 [Core Tor/Tor]: "No circuits are opened" messages with onion services

[Tor Bug Tracker & Wiki]

#27049: "No circuits are opened" messages with onion services
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  033-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 Yikes sorry I dropped this for so long. Fixups are on the PR comment.

 I'm not sure if 0.2.9 backport is worth it -- I and others refactored bits
 of circuit_expire_building() in 0.3.3 to handle vanguards and improved HS
 timeout behavior, among other things. At a glance, I could just patch the
 pre-refactored code similarly, but this seems not serious enough for that.

 Unless you think this message is very common in the wild?

--
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] #28458 [Core Tor/sbws]: Stop resolving domains locally and check same flags for the 2nd hop

[Tor Bug Tracker & Wiki]

#28458: Stop resolving domains locally and check same flags for the 2nd hop
--+
 Reporter:  juga  |  Owner:  juga
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  sbws:
  |  1.0.x-final
Component:  Core Tor/sbws |Version:  sbws: 1.0.0
 Severity:  Normal| Resolution:  fixed
 Keywords:  sbws-1.0-must-moved-20181128  |  Actual Points:
Parent ID:| Points:
 Reviewer:  pastly|Sponsor:
--+
Changes (by juga):

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


Comment:

 I removed what you proposed and created #28706 to implement resolving IPs
 using Tor itself, at a later stage.
 Merged

--
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] #28471 [Core Tor/sbws]: Refactor sbws exit checking so it is consistent

[Tor Bug Tracker & Wiki]

#28471: Refactor sbws exit checking so it is consistent
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  sbws:
  |  1.0.x-final
Component:  Core Tor/sbws |Version:  sbws: 1.0.0
 Severity:  Normal| Resolution:  implemented
 Keywords:  sbws-1.0-must-moved-20181128  |  Actual Points:
Parent ID:  #28458| Points:
 Reviewer:|Sponsor:
--+
Changes (by juga):

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


Comment:

 Implemented in #28471

--
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] #28711 [Applications/Tor Browser]: Store Arraybuffer Metadata in its own Arena

[Tor Bug Tracker & Wiki]

#28711: Store Arraybuffer Metadata in its own Arena
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #28707
   Points:|   Reviewer:
  Sponsor:|
--+--
 The bug tracks backporting and landing
 https://bugzilla.mozilla.org/show_bug.cgi?id=1474659 to move ArrayBuffer
 metadata (including length) into its own jemalloc arena.  This will
 hopefully make it harder to write exploits that fiddle the length of
 ArrayBuffers.

--
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] #28710 [Applications/Tor Browser]: Randomize small allocations in mozjemalloc

[Tor Bug Tracker & Wiki]

#28710: Randomize small allocations in mozjemalloc
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #28707
   Points:|   Reviewer:
  Sponsor:|
--+--
 This bug tracks backporting
 https://bugzilla.mozilla.org/show_bug.cgi?id=1376408 to Tor Browser.

 This will increase memory usage and fragmentation, but will make memory
 allocation slightly more unpredictable and hopefully make it more
 difficult to exploit certain types of vulnerabilities.

--
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] #28709 [Applications/Tor Browser]: Backport Fuzzyfox

[Tor Bug Tracker & Wiki]

#28709: Backport Fuzzyfox
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #28707
   Points:|   Reviewer:
  Sponsor:|
--+--
 Fuzzyfox is a new timer mitigation technique currently in Nightly.
 https://bugzilla.mozilla.org/show_bug.cgi?id=fuzzyfox

 There are some open issues on it that would be best to solve before
 enabling it by default, but this bug can serve as a tracker for either
 backporting it or evaluating 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

[tor-bugs] #28708 [Applications/Tor Browser]: TBA 8.5a5 - about:tor is not the default homepage after upgrade

[Tor Bug Tracker & Wiki]

#28708: TBA 8.5a5 - about:tor is not the default homepage after upgrade
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I'm preemptively opening this in case anyone wonders why this is
 happening.

 This will be fixed with the next release, assuming #28685 is solved. The
 new preferences weren't copied because the app didn't detect it was
 updated because the buildid didn't change since the previous release. This
 was partially solved in #28640, but it wasn't entirely solved.

--
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] #28707 [Applications/Tor Browser]: [meta] Backport Mozilla Secuity Patches

[Tor Bug Tracker & Wiki]

#28707: [meta] Backport Mozilla Secuity Patches
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This bug is to serve as a meta bug for backporting in-development or
 landed security patches to Tor Browser.

--
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] #27362 [Core Tor/sbws]: (sub-)packages outside of core (cli) should not need to know about confs and args

[Tor Bug Tracker & Wiki]

#27362: (sub-)packages outside of core (cli) should not need to know about confs
and args
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28684 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * cc: pastly (removed)
 * parent:   => #28684


Comment:

 This is also part of #28684.

--
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] #28282 [Core Tor/sbws]: Refactor bandwidth file generation code

[Tor Bug Tracker & Wiki]

#28282: Refactor bandwidth file generation code
--+---
 Reporter:  juga  |  Owner:  juga
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  sbws: unspecified
Component:  Core Tor/sbws |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactor, technical-debt  |  Actual Points:
Parent ID:  #28684| Points:
 Reviewer:|Sponsor:
--+---
Changes (by juga):

 * parent:   => #28684


Comment:

 This is also part of #28684

--
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] #25925 [Core Tor/sbws]: bwauth improvements (ex-parent ticket for SoP planned tasks)

[Tor Bug Tracker & Wiki]

#25925: bwauth improvements (ex-parent ticket for SoP planned tasks)
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 I think this parent would be more useful to track only Core-Tor tickets,
 since sbws can be track by component.
 If you agree, i'll remove the children that are sbws and leave only the
 Core-Tor ones.

--
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] #28706 [Core Tor/sbws]: Maybe implement resolving destination domain using Tor's RESOLVE and ADDRMAP events

[Tor Bug Tracker & Wiki]

#28706: Maybe implement resolving destination domain using Tor's RESOLVE and
ADDRMAP events
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * component:  Core Tor/Tor => Core Tor/sbws


Comment:

 Component is sbws

--
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] #28706 [Core Tor/Tor]: Maybe implement resolving destination domain using Tor's RESOLVE and ADDRMAP events

[Tor Bug Tracker & Wiki]

#28706: Maybe implement resolving destination domain using Tor's RESOLVE and
ADDRMAP events
--+---
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  sbws: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 In #28458 the domain of the destination was being resolved locally to
 check whether and exit policy allows to exit to the IP, which had 2
 problems:
 - in the case that the destination is a CDN, the IP resolved locally would
 be different to the IP resolved by the exit.
 - it was returning the first IP found, without checking whether the
 scanner supported IPv6.
 The correct way would be to resolve the domain via Tor itself using
 RESOLVE and ADDRMAP events with that exit.
 While there are not too many circuits that fails (because the policy
 doesn't allow to exit to the destination IP), this is not a priority

--
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] #28686 [Internal Services/Service - lists]: Please create a tor-employees@ list

[Tor Bug Tracker & Wiki]

#28686: Please create a tor-employees@ list
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by ewyatt):

 Thank you all! I reeeally appreciate it.

 @Atagar - yes, if you could please configure it to match tor-internal for
 now, that would be great. 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] #28591 [Core Tor/Tor]: Accept a future consensus for bootstrap

[Tor Bug Tracker & Wiki]

#28591: Accept a future consensus for bootstrap
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew, tor-guard,|  Actual Points:
  usability, ux, s8-errors, 035-roadmap- |
  subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #23605   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Thanks! Mostly looks good, but I haven't tested it yet. I left a minor
 comment on the pull request about a build failure that I get. When you fix
 that, I can try to do some manual tests. I can also try to fix it up
 myself later if you don't have the time.

--
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] #28588 [Core Tor/sbws]: SBWS 'bw_torflow_scale' does not appear to honor relay MaxAdvertisedBandwidth

[Tor Bug Tracker & Wiki]

#28588: SBWS 'bw_torflow_scale' does not appear to honor relay
MaxAdvertisedBandwidth
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  sbws:
  |  1.0.x-final
Component:  Core Tor/sbws |Version:  sbws: 1.0.0
 Severity:  Normal| Resolution:  fixed
 Keywords:  sbws-1.0-must-moved-20181128  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by juga):

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


Comment:

 #28598 is now merged 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] #28598 [Core Tor/sbws]: Should torflow scaling use the consensus bandwidth when it is measured?

[Tor Bug Tracker & Wiki]

#28598: Should torflow scaling use the consensus bandwidth when it is measured?
--+
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  sbws:
  |  1.0.x-final
Component:  Core Tor/sbws |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  sbws-1.0-must-moved-20181128  |  Actual Points:
Parent ID:  #28588| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by juga):

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


Comment:

 Squashed in https://github.com/juga0/sbws/commits/bug28598_squashed.
 Added one more commit to be able to parse old results. Didn't put it in
 needs_review again to don't create more work.

--
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] #26770 [Core Tor/Tor]: Implement proposal 293: "Other ways for relays to know when to publish"

[Tor Bug Tracker & Wiki]

#26770: Implement proposal 293: "Other ways for relays to know when to publish"
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop293, prop275, 040-roadmap-   |  Actual Points:  .1
  proposed   |
Parent ID:  #21642   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Okay, should be fixed and ready for 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] #28705 [Applications/Tor Browser]: Don't leak File URI during download on Android

[Tor Bug Tracker & Wiki]

#28705: Don't leak File URI during download on Android
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201812  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8
--+--
Changes (by sysrqb):

 * cc: igt0 (added)


--
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] #28692 [Core Tor/sbws]: sbws should set ConnectionPadding 0

[Tor Bug Tracker & Wiki]

#28692: sbws should set ConnectionPadding 0
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * status:  new => needs_review


Comment:

 https://github.com/torproject/sbws/pull/305

--
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] #26770 [Core Tor/Tor]: Implement proposal 293: "Other ways for relays to know when to publish"

[Tor Bug Tracker & Wiki]

#26770: Implement proposal 293: "Other ways for relays to know when to publish"
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop293, prop275, 040-roadmap-   |  Actual Points:  .1
  proposed   |
Parent ID:  #21642   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Ooh, CI is busted.  I need to fix this before it's ready for 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

[tor-bugs] #28705 [Applications/Tor Browser]: Don't leak File URI during download on Android

[Tor Bug Tracker & Wiki]

#28705: Don't leak File URI during download on Android
-+-
 Reporter:  sysrqb   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-mobile,
 Severity:  Normal   |  TorBrowserTeam201812
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:  Sponsor8 |
-+-
 This is already patched upstream in FF62, but the backport is not-small.
 Maybe we can get away with a smaller patch that solves the main problem.

 Summary:
 In #27701 we solved the bug where torbutton prevents downloading a file on
 Android.
 In #28051 we solved the problem where notifications weren't working on
 newer versions of Android.

 Now we have a problem that on newer versions of Android, the runtime
 prevents "leaking" file URIs from one app to another. In particular, this
 is happening when Tor Browser is downloading a file, the browser creates a
 notification with the URI of the local destination file embedded in it.

 This results in an exception stacktrace like:
 {{{
 D AndroidRuntime: Shutting down VM
 E AndroidRuntime: FATAL EXCEPTION: main
 E AndroidRuntime: Process: org.torproject.torbrowser_alpha, PID: 18167
 E AndroidRuntime: android.os.FileUriExposedException:
 file:///storage/emulated/0/Download/tor-browser-8.5a5-android-armv7.apk
 exposed beyond app through Intent.getData()
 E AndroidRuntime:at
 android.os.StrictMode.onFileUriExposed(StrictMode.java:1960)
 E AndroidRuntime:at
 android.net.Uri.checkFileUriExposed(Uri.java:2356)
 E AndroidRuntime:at
 android.content.Intent.prepareToLeaveProcess(Intent.java:9881)
 E AndroidRuntime:at
 android.content.Intent.prepareToLeaveProcess(Intent.java:9835)
 E AndroidRuntime:at
 android.app.PendingIntent.getActivity(PendingIntent.java:342)
 E AndroidRuntime:at
 android.app.PendingIntent.getActivity(PendingIntent.java:304)
 E AndroidRuntime:at
 
org.mozilla.gecko.notifications.NotificationHelper.showNotification(NotificationHelper.java:298)
 E AndroidRuntime:at
 
org.mozilla.gecko.notifications.NotificationHelper.handleMessage(NotificationHelper.java:120)
 E AndroidRuntime:at
 org.mozilla.gecko.EventDispatcher$2.run(EventDispatcher.java:337)
 E AndroidRuntime:at
 android.os.Handler.handleCallback(Handler.java:790)
 E AndroidRuntime:at
 android.os.Handler.dispatchMessage(Handler.java:99)
 E AndroidRuntime:at android.os.Looper.loop(Looper.java:164)
 E AndroidRuntime:at
 android.app.ActivityThread.main(ActivityThread.java:6494)
 E AndroidRuntime:at java.lang.reflect.Method.invoke(Native Method)
 E AndroidRuntime:at
 
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
 E AndroidRuntime:at
 com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
 }}}

 This was patched upstream:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1450449

 Crash report:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1476681

--
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] #26770 [Core Tor/Tor]: Implement proposal 293: "Other ways for relays to know when to publish"

[Tor Bug Tracker & Wiki]

#26770: Implement proposal 293: "Other ways for relays to know when to publish"
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop293, prop275, 040-roadmap-   |  Actual Points:  .1
  proposed   |
Parent ID:  #21642   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Hi!  I've answered your questions, made some changes, and written some
 tests!

--
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] #28681 [Metrics/Relay Search]: reflected XSS metrics.torproject.org

[Tor Bug Tracker & Wiki]

#28681: reflected XSS metrics.torproject.org
---+--
 Reporter:  0x539h |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Relay Search   |Version:
 Severity:  Major  | Resolution:
 Keywords:  xss, cross-site scripting  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

 * priority:  High => Medium


Comment:

 It is a bug, but it's not particularly scary as there is nothing you can
 get at that would be privileged here.

 0x539h: the code is at https://gitweb.torproject.org/metrics-
 web.git/tree/src/main/resources/web/js/rs

 It would probably be best to clean the inputs in the router:

 https://gitweb.torproject.org/metrics-
 web.git/tree/src/main/resources/web/js/rs/router.js

 Would you like to make a patch?

--
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] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library

[Tor Bug Tracker & Wiki]

#27609: TBA: Evaluate Tor Onion Proxy Library
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sisbell):

 One area we should discuss is breaking out the Android tor installer from
 tor-onion-proxy/orbot.  An Android installer could be a separate Android
 project library and would be related to #28704 which creates the native
 libraries.

--
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] #25164 [Applications/Tor Browser]: Reproducible Tor Browser for Android builds

[Tor Bug Tracker & Wiki]

#25164: Reproducible Tor Browser for Android builds
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201812  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8
--+--

Comment (by sisbell):

 I verified from my side that the classes.dex files are the same between
 two different apk builds on my linux laptop. The problem I was seeing
 earlier is no longer an issue for 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] #28616 [Core Tor/Tor]: TLS internal error running Tor 0.3.4.9 on Debian Buster (OpenSSL 1.1.1a)

[Tor Bug Tracker & Wiki]

#28616: TLS internal error running Tor 0.3.4.9 on Debian Buster (OpenSSL 1.1.1a)
--+
 Reporter:  filippo   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by PsiBlade):

 Can confirm manually regressing ec0c5f5 works perfectly.

--
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] #28664 [Core Tor/Tor]: Describe consensus digest calculation

[Tor Bug Tracker & Wiki]

#28664: Describe consensus digest calculation
---+
 Reporter:  atagar |  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-spec, doc  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 > It turns out that this information is already in directory-signature at
 the end of 3.4.1

 Good eye!

 > Alternately, we could move the info about digests from 3.4.1 to 1.3

 Personally I'm a more inclined for that because section 3.4.1 is huge and
 as such not a great spot for other fields to reference.

 > Do you think we should say "network-status-version" instead of "the
 beginning of the document"?

 Up to you. It's synonymous in this case because 'network-status-version'
 is defined as being the start of the document, so that cannot change
 without violating backward compatibility.

--
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] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by atagar):

 > Could you reply also on my question about tor versions?

 Sounds like your other ticket's covering that. If you need something from
 me let me know.

--
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] #28479 [Core Tor/Tor]: Update "ReleasingTor.md" to match current practice

[Tor Bug Tracker & Wiki]

#28479: Update "ReleasingTor.md" to match current practice
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Whoops. Looks like I added another commit to fix your comments 13 days
 ago, but forgot to put the ticket back into needs_review.  Doing now.

--
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] #28275 [Core Tor/Tor]: hs-v3: Rotate intro points and close RP circuits when removing client auth service side

[Tor Bug Tracker & Wiki]

#28275: hs-v3: Rotate intro points and close RP circuits when removing client 
auth
service side
---+---
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Very High  |  Milestone:  Tor:
   |  0.3.5.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.5.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-doc, tor-hs, 035-must  |  Actual Points:
Parent ID: | Points:
 Reviewer:  asn|Sponsor:
---+---
Changes (by dgoulet):

 * status:  new => needs_review
 * reviewer:   => asn


Comment:

 Man page changes about this: `ticket28275_035_01`

--
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] #27919 [Applications/Tor Browser]: Backport SSL status API to Tor Browser alpha

[Tor Bug Tracker & Wiki]

#27919: Backport SSL status API to Tor Browser alpha
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201812R,   |  Actual Points:
  GeorgKoppen201811  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks. Merged to `tor-browser-60.3.0esr-8.5-1` (commits
 c1774ae7fc74bef7956caca4fe1b8de1365f5d48,
 1935dcf38ca112f9fbc9fe42c2289d77e4f95932,
 1305066f21439675842aad91844e6b490df8c3e0,
 05cbc6e53b30707e32af750eb082a90f715cbf95,
 b81fe53f5fe1ecd749ca900ccfc1a00ae1fd9328, and
 b3d74f7db1cc0ddf54771e3e9e5de4b8549b0c88).

 This will be available in 8.5a6, if nothing explodes.

--
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] #27919 [Applications/Tor Browser]: Backport SSL status API to Tor Browser alpha

[Tor Bug Tracker & Wiki]

#27919: Backport SSL status API to Tor Browser alpha
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201812R,   |  Actual Points:
  GeorgKoppen201811  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=brade, r=mcs
 Kathy and I checked the dependencies and we think you got them all. We
 also checked the accuracy of the backported patches and everything looks
 good to us.

--
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] #28680 [Internal Services/Schleuder]: Change teor's email address on network-team-security

[Tor Bug Tracker & Wiki]

#28680: Change teor's email address on network-team-security
-+
 Reporter:  teor |  Owner:  hiro
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Schleuder  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  new => closed
 * cc: dgoulet@… (removed)
 * resolution:   => fixed


Comment:

 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] #28668 [Core Tor/Tor]: If a Tor unit test causes a BUG log, it should fail

[Tor Bug Tracker & Wiki]

#28668: If a Tor unit test causes a BUG log, it should fail
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by dgoulet):

 Replying to [comment:2 teor]:
 > In that ticket, we fixed all the bug warnings, but *didn't* make tests
 fail on BUG().
 >
 > This time, we should fix all the bug warnings, and make the tests fail
 on BUG().

 +1.

 (Just to be clear, `BUG()` _and_ `log_warn(LD_BUG, ...)` should fail
 unless we expect them). #28660 had a `LD_BUG` since 0.2.8 that we never
 noticed :S...

--
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] [Tor Bug Tracker & Wiki] Batch modify: #28662, #28661

[Tor Bug Tracker & Wiki]

Batch modification to #28662, #28661 by dgoulet:
reviewer to mikeperry

--
Tickets 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] [Tor Bug Tracker & Wiki] Batch modify: #28646, #28601

[Tor Bug Tracker & Wiki]

Batch modification to #28646, #28601 by dgoulet:
reviewer to teor

--
Tickets 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] [Tor Bug Tracker & Wiki] Batch modify: #28660, #28619

[Tor Bug Tracker & Wiki]

Batch modification to #28660, #28619 by dgoulet:
reviewer to asn

--
Tickets 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] #28560 [Core Tor/Tor]: hs: Mention in the manpage that Sandbox and adding a service with the control port fails

[Tor Bug Tracker & Wiki]

#28560: hs: Mention in the manpage that Sandbox and adding a service with the
control port fails
---+
 Reporter:  dgoulet|  Owner:  rl1987
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, tor-doc, easy  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:
---+
Changes (by dgoulet):

 * reviewer:   => dgoulet


--
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] [Tor Bug Tracker & Wiki] Batch modify: #28649, #28648

[Tor Bug Tracker & Wiki]

Batch modification to #28649, #28648 by dgoulet:
reviewer to nickm

--
Tickets 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] #27402 [Core Tor/Tor]: stop reporting "internal paths" during bootstrap

[Tor Bug Tracker & Wiki]

#27402: stop reporting "internal paths" during bootstrap
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s8-bootstrap, tor-spec,  |  Actual Points:  0.1
  035-deferred-20180930  |
Parent ID:  #28018   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  Sponsor8-can
-+-
Changes (by dgoulet):

 * 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] #28591 [Core Tor/Tor]: Accept a future consensus for bootstrap

[Tor Bug Tracker & Wiki]

#28591: Accept a future consensus for bootstrap
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew, tor-guard,|  Actual Points:
  usability, ux, s8-errors, 035-roadmap- |
  subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #23605   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by dgoulet):

 * reviewer:   => catalyst


--
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] [Tor Bug Tracker & Wiki] Batch modify: #28182, #28181

[Tor Bug Tracker & Wiki]

Batch modification to #28182, #28181 by dgoulet:
reviewer to ahf

--
Tickets 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] #28660 [Core Tor/Tor]: rend_cache_decrement_allocation(): Bug: Underflow in rend_cache_decrement_allocation (On Windows build)

[Tor Bug Tracker & Wiki]

#28660: rend_cache_decrement_allocation(): Bug: Underflow in
rend_cache_decrement_allocation (On Windows build)
--+
 Reporter:  rl1987|  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-test  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:4 nickm]:
 > What version is this a bug fix on?  Is it a backport candidate?

 The test was introduced in 0.2.8 and the `log_warn(LD_BUG...)` in 0.2.7 so
 for maintained versions, 0.2.9 is the oldest. I just tested it and indeed
 we have the `Bug:` warning...

 This only affects the output, the test still is working fine so I'm ok
 keeping that in 040. If we do backport #28668 then we have to backport
 this for sure. I think maybe going back to 035 is fine?

--
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] #28266 [Core Tor/Tor]: Implement proposal 298-canonical-families.txt

[Tor Bug Tracker & Wiki]

#28266: Implement proposal 298-canonical-families.txt
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  prop298   |  Actual Points:  .3
Parent ID:| Points:  1
 Reviewer:  asn   |Sponsor:  Sponsor8
--+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM!

--
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] #28618 [Applications/Tor Browser]: Set MOZILLA_OFFICIAL on Windows builds

[Tor Bug Tracker & Wiki]

#28618: Set MOZILLA_OFFICIAL on Windows builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-8.0-issues, tbb-|  Actual Points:
  regression, TorBrowserTeam201811,  |
  GeorgKoppen201812  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 I got the 64-bit version working over the weekend but it seems we need yet
 another patch for 32-bit...

--
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] #28142 [Core Tor/Tor]: Merge original WTF-PAD branch

[Tor Bug Tracker & Wiki]

#28142: Merge original WTF-PAD branch
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding|
Parent ID:  #28631   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-

Comment (by asn):

 Hello, pushed three test commits in
 https://github.com/torproject/tor/pull/547.

 The tests cover the remaining removal token functions that were not
 covered, and also give a bit more coverage to the global rate limiting
 test (based on coverage analysis).

--
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] #28704 [Applications/Tor Browser]: Compile Tor and dependencies on our own for Android

[Tor Bug Tracker & Wiki]

#28704: Compile Tor and dependencies on our own for Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-mobile, tbb-rbm => tbb-mobile, tbb-rbm,
   TorBrowserTeam201812
 * priority:  Medium => High
 * cc: sisbell (added)


--
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] #28696 [Applications/Tor Browser]: Changing paths to Gradle dependencies are included in build

[Tor Bug Tracker & Wiki]

#28696: Changing paths to Gradle dependencies are included in build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:  #25164   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-mobile, TorBrowserTeam201812 => tbb-mobile, tbb-rbm,
 TorBrowserTeam201812


--
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] #28704 [Applications/Tor Browser]: Compile Tor and dependencies on our own for Android

[Tor Bug Tracker & Wiki]

#28704: Compile Tor and dependencies on our own for Android
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile, tbb-
  |  rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Currently we are building just Orbot in `tor-browser-build` and fetching
 the dependencies as we need them. We should at least build Tor and its
 dependencies on our own, integrating Android specific build logic into our
 projects we already have (like OpenSSL, Libevent etc.).

 This is the parent ticket for that task.

--
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] #28458 [Core Tor/sbws]: Stop resolving domains locally and check same flags for the 2nd hop

[Tor Bug Tracker & Wiki]

#28458: Stop resolving domains locally and check same flags for the 2nd hop
--+
 Reporter:  juga  |  Owner:  juga
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  sbws:
  |  1.0.x-final
Component:  Core Tor/sbws |Version:  sbws: 1.0.0
 Severity:  Normal| Resolution:
 Keywords:  sbws-1.0-must-moved-20181128  |  Actual Points:
Parent ID:| Points:
 Reviewer:  pastly|Sponsor:
--+
Changes (by pastly):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

 Recommendations:

 - remove `Relay.can_exit_to(...)` after verifying it will be unused upon
 applying this patch.
 - remove `resolve(...)` after verifying it will be unused upon applying
 this patch.

 Your choice on whether to act on those recommendations. merge_ready if you
 decide to not act.

--
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] #21377 [Core Tor/Tor]: DirAuths should expose bwauth bandwidth files

[Tor Bug Tracker & Wiki]

#21377: DirAuths should expose bwauth bandwidth files
-+-
 Reporter:  tom  |  Owner:  juga
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, metrics, tor-bwauth,|  Actual Points:
  035-removed-20180711, 040-roadmap-proposed |
Parent ID:  #25925   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by juga):

 I put them in code comments. Created also a pastebin with logs only for
 that test and log level debug: https://paste.debian.net/1054163/

--
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] #28458 [Core Tor/sbws]: Stop resolving domains locally and check same flags for the 2nd hop

[Tor Bug Tracker & Wiki]

#28458: Stop resolving domains locally and check same flags for the 2nd hop
--+
 Reporter:  juga  |  Owner:  juga
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  sbws:
  |  1.0.x-final
Component:  Core Tor/sbws |Version:  sbws: 1.0.0
 Severity:  Normal| Resolution:
 Keywords:  sbws-1.0-must-moved-20181128  |  Actual Points:
Parent ID:| Points:
 Reviewer:  pastly|Sponsor:
--+
Changes (by pastly):

 * reviewer:  teor => pastly


Comment:

 As requested. Doing it now.

--
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] #28699 [Applications/Tor Launcher]: Tor Browser is not properly shutting down tor

[Tor Bug Tracker & Wiki]

#28699: Tor Browser is not properly shutting down tor
---+---
 Reporter:  gk |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * cc: tbb-team (added)


--
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] #28012 [Core Tor/Tor]: shellcheck: updateRustDependencies.sh issues

[Tor Bug Tracker & Wiki]

#28012: shellcheck: updateRustDependencies.sh issues
+
 Reporter:  rl1987  |  Owner:  (none)
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  asn |Sponsor:
+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM!

--
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] #28229 [Core Tor/Tor]: Possible race condition opening SOCKS Port in test_rebind.py

[Tor Bug Tracker & Wiki]

#28229: Possible race condition opening SOCKS Port in test_rebind.py
-+
 Reporter:  teor |  Owner:  rl1987
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, 035-can  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+
Changes (by rl1987):

 * status:  new => 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] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:  teor |Sponsor:
-+-
Changes (by neel):

 * status:  needs_revision => needs_review


Comment:

 I have made and pushed the changes. Setting as 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] #28703 [Core Tor/Tor]: bootstrapping very slow with filtered network

[Tor Bug Tracker & Wiki]

#28703: bootstrapping very slow with filtered network
+--
 Reporter:  weasel  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: 0.3.4.9
 Severity:  Normal  | Resolution:
 Keywords:  s8-bootstrap-maybe  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  Sponsor8-can
+--
Changes (by teor):

 * sponsor:   => Sponsor8-can


--
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] #28560 [Core Tor/Tor]: hs: Mention in the manpage that Sandbox and adding a service with the control port fails

[Tor Bug Tracker & Wiki]

#28560: hs: Mention in the manpage that Sandbox and adding a service with the
control port fails
---+
 Reporter:  dgoulet|  Owner:  rl1987
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, tor-doc, easy  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by rl1987):

 * status:  accepted => needs_review


Comment:

 https://github.com/torproject/tor/pull/561

--
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] #28703 [Core Tor/Tor]: bootstrapping very slow with filtered network

[Tor Bug Tracker & Wiki]

#28703: bootstrapping very slow with filtered network
--+--
 Reporter:  weasel|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by weasel:

Old description:

> Hi!
>
> Tor 0.3.4.9, on Debian stretch (thus linked against libssl
> 1.1.0f-3+deb9u2) bootstraps very slowly if network access is limited.
>
> Network access is filtered, to only allow outgoing TCP connections to
> ports 80 and 443.  All other network connections are DROPped, i.e. from
> an application point of few, connection attempts will just time out.  Tor
> is not told about this network restriction (i.e., no FirewallFirwall
> configuration).
>
> The times in the following samples are times (in seconds) from process
> launch (with a non-existing data directory) until PROGRESS=100 is
> reported in a getinfo status/bootstrap-phase:
>

> ''>>150, 12, 135, 137, 131, 143, >>250, >>250, >>250, >>250, 12, 133,
> 153, 135, >>250, 132, 153, 192, >>250, 134, 12, 133, 137, >>250, 135,
> 142, >>250, 135, 9, >>250, >>250, 135, 134, 135, 132, 136, 133, 7, 133,
> 134, >>250, 131, 136, 133, 135, 8, 133, >>250, 133, >>250, >>250, 12,
> >>250, 6, >>250, >>250, 144, 132, 133, 139, 134, >>250, 12, >>250, 135,
> >>250, 135, 133, 133, 134, 11, 133, 133, >>250, >>250
>
> (>>x indicates that the bootstrap process was not finished after x
> seconds and the test has been aborted.)
>
> The chances of bootstrapping in under two minutes (which is for instance
> the timeout that onionbalance uses) are not very good.
>
> It'd be nice if Tor had a way to deal with this better.

New description:

 Hi!

 Tor 0.3.4.9, on Debian stretch (thus linked against libssl
 1.1.0f-3+deb9u2), bootstraps very slowly if network access is limited.

 Network access is filtered, to only allow outgoing TCP connections to
 ports 80 and 443.  All other network connections are DROPped, i.e. from an
 application point of few, connection attempts will just time out.  Tor is
 not told about this network restriction (i.e., no FirewallFirwall
 configuration).

 The times in the following samples are times (in seconds) from process
 launch (with a non-existing data directory) until PROGRESS=100 is reported
 in a getinfo status/bootstrap-phase:


 ''>>150, 12, 135, 137, 131, 143, >>250, >>250, >>250, >>250, 12, 133, 153,
 135, >>250, 132, 153, 192, >>250, 134, 12, 133, 137, >>250, 135, 142,
 >>250, 135, 9, >>250, >>250, 135, 134, 135, 132, 136, 133, 7, 133, 134,
 >>250, 131, 136, 133, 135, 8, 133, >>250, 133, >>250, >>250, 12, >>250, 6,
 >>250, >>250, 144, 132, 133, 139, 134, >>250, 12, >>250, 135, >>250, 135,
 133, 133, 134, 11, 133, 133, >>250, >>250

 (>>x indicates that the bootstrap process was not finished after x seconds
 and the test has been aborted.)

 The chances of bootstrapping in under two minutes (which is for instance
 the timeout that onionbalance uses) are not very good.

 It'd be nice if Tor had a way to deal with this better.

--

--
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] #28703 [Core Tor/Tor]: bootstrapping very slow with filtered network

[Tor Bug Tracker & Wiki]

#28703: bootstrapping very slow with filtered network
+--
 Reporter:  weasel  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: 0.3.4.9
 Severity:  Normal  | Resolution:
 Keywords:  s8-bootstrap-maybe  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * keywords:   => s8-bootstrap-maybe
 * milestone:   => Tor: unspecified


--
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] #28702 [Core Tor/Tor]: bootstrapping slow at times

[Tor Bug Tracker & Wiki]

#28702: bootstrapping slow at times
+--
 Reporter:  weasel  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: 0.3.4.9
 Severity:  Normal  | Resolution:
 Keywords:  s8-bootstrap-maybe  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  Sponsor8-can
+--
Changes (by teor):

 * keywords:   => s8-bootstrap-maybe
 * sponsor:   => Sponsor8-can
 * milestone:   => Tor: unspecified


--
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] #28703 [Core Tor/Tor]: bootstrapping very slow with filtered network

[Tor Bug Tracker & Wiki]

#28703: bootstrapping very slow with filtered network
--+--
 Reporter:  weasel|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by weasel:

Old description:

> Hi!
>
> Tor 0.3.4.9, on Debian stretch (thus linked against libssl
> 1.1.0f-3+deb9u2)
> bootstraps very slowly if network access is limited.
>
> Network access is filtered, to only allow outgoing TCP connections to
> ports 80 and 443.  All other network connections are DROPped, i.e. from
> an application point of few, connection attempts will just time out.  Tor
> is not told about this network restriction (i.e., no FirewallFirwall
> configuration).
>
> The times in the following samples are times (in seconds) from process
> launch (with a non-existing data directory) until PROGRESS=100 is
> reported in a getinfo status/bootstrap-phase:
>

> ''>>150, 12, 135, 137, 131, 143, >>250, >>250, >>250, >>250, 12, 133,
> 153, 135, >>250, 132, 153, 192, >>250, 134, 12, 133, 137, >>250, 135,
> 142, >>250, 135, 9, >>250, >>250, 135, 134, 135, 132, 136, 133, 7, 133,
> 134, >>250, 131, 136, 133, 135, 8, 133, >>250, 133, >>250, >>250, 12,
> >>250, 6, >>250, >>250, 144, 132, 133, 139, 134, >>250, 12, >>250, 135,
> >>250, 135, 133, 133, 134, 11, 133, 133, >>250, >>250
>
> (>>x indicates that the bootstrap process was not finished after x
> seconds and the test has been aborted.)
>
> The chances of bootstrapping in under two minutes (which is for instance
> the timeout that onionbalance uses) are not very good.
>
> It'd be nice if Tor had a way to deal with this better.

New description:

 Hi!

 Tor 0.3.4.9, on Debian stretch (thus linked against libssl
 1.1.0f-3+deb9u2) bootstraps very slowly if network access is limited.

 Network access is filtered, to only allow outgoing TCP connections to
 ports 80 and 443.  All other network connections are DROPped, i.e. from an
 application point of few, connection attempts will just time out.  Tor is
 not told about this network restriction (i.e., no FirewallFirwall
 configuration).

 The times in the following samples are times (in seconds) from process
 launch (with a non-existing data directory) until PROGRESS=100 is reported
 in a getinfo status/bootstrap-phase:


 ''>>150, 12, 135, 137, 131, 143, >>250, >>250, >>250, >>250, 12, 133, 153,
 135, >>250, 132, 153, 192, >>250, 134, 12, 133, 137, >>250, 135, 142,
 >>250, 135, 9, >>250, >>250, 135, 134, 135, 132, 136, 133, 7, 133, 134,
 >>250, 131, 136, 133, 135, 8, 133, >>250, 133, >>250, >>250, 12, >>250, 6,
 >>250, >>250, 144, 132, 133, 139, 134, >>250, 12, >>250, 135, >>250, 135,
 133, 133, 134, 11, 133, 133, >>250, >>250

 (>>x indicates that the bootstrap process was not finished after x seconds
 and the test has been aborted.)

 The chances of bootstrapping in under two minutes (which is for instance
 the timeout that onionbalance uses) are not very good.

 It'd be nice if Tor had a way to deal with this better.

--

--
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] #28703 [Core Tor/Tor]: bootstrapping very slow with filtered network

[Tor Bug Tracker & Wiki]

#28703: bootstrapping very slow with filtered network
--+--
 Reporter:  weasel|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by weasel:

Old description:

> Hi!
>
> Tor 0.3.4.9, on Debian stretch (Thus linked against libssl
> 1.1.0f-3+deb9u2), sometimes bootstraps slowly.
>
> Network access is filtered, to only allow outgoing TCP connections to
> ports 80 and 443.  All other network connections are DROPped, i.e. from
> an application point of few, connection attempts will just time out.  Tor
> is not told about this network restriction (i.e., no FirewallFirwall
> configuration).
>
> The times in the following samples are times (in seconds) from process
> launch (with a non-existing data directory) until PROGRESS=100 is
> reported in a getinfo status/bootstrap-phase:
>

> ''>>150, 12, 135, 137, 131, 143, >>250, >>250, >>250, >>250, 12, 133,
> 153, 135, >>250, 132, 153, 192, >>250, 134, 12, 133, 137, >>250, 135,
> 142, >>250, 135, 9, >>250, >>250, 135, 134, 135, 132, 136, 133, 7, 133,
> 134, >>250, 131, 136, 133, 135, 8, 133, >>250, 133, >>250, >>250, 12,
> >>250, 6, >>250, >>250, 144, 132, 133, 139, 134, >>250, 12, >>250, 135,
> >>250, 135, 133, 133, 134, 11, 133, 133, >>250, >>250
>
> (>>x indicates that the bootstrap process was not finished after x
> seconds and the test has been aborted.)
>
> The chances of bootstrapping in under two minutes (which is for instance
> the timeout that onionbalance uses) are not very good.
>
> It'd be nice if Tor had a way to deal with this better.

New description:

 Hi!

 Tor 0.3.4.9, on Debian stretch (thus linked against libssl
 1.1.0f-3+deb9u2)
 bootstraps very slowly if network access is limited.

 Network access is filtered, to only allow outgoing TCP connections to
 ports 80 and 443.  All other network connections are DROPped, i.e. from an
 application point of few, connection attempts will just time out.  Tor is
 not told about this network restriction (i.e., no FirewallFirwall
 configuration).

 The times in the following samples are times (in seconds) from process
 launch (with a non-existing data directory) until PROGRESS=100 is reported
 in a getinfo status/bootstrap-phase:


 ''>>150, 12, 135, 137, 131, 143, >>250, >>250, >>250, >>250, 12, 133, 153,
 135, >>250, 132, 153, 192, >>250, 134, 12, 133, 137, >>250, 135, 142,
 >>250, 135, 9, >>250, >>250, 135, 134, 135, 132, 136, 133, 7, 133, 134,
 >>250, 131, 136, 133, 135, 8, 133, >>250, 133, >>250, >>250, 12, >>250, 6,
 >>250, >>250, 144, 132, 133, 139, 134, >>250, 12, >>250, 135, >>250, 135,
 133, 133, 134, 11, 133, 133, >>250, >>250

 (>>x indicates that the bootstrap process was not finished after x seconds
 and the test has been aborted.)

 The chances of bootstrapping in under two minutes (which is for instance
 the timeout that onionbalance uses) are not very good.

 It'd be nice if Tor had a way to deal with this better.

--

--
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] #28703 [Core Tor/Tor]: bootstrapping very slow with filtered network

[Tor Bug Tracker & Wiki]

#28703: bootstrapping very slow with filtered network
--+--
 Reporter:  weasel|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Hi!

 Tor 0.3.4.9, on Debian stretch (Thus linked against libssl
 1.1.0f-3+deb9u2), sometimes bootstraps slowly.

 Network access is filtered, to only allow outgoing TCP connections to
 ports 80 and 443.  All other network connections are DROPped, i.e. from an
 application point of few, connection attempts will just time out.  Tor is
 not told about this network restriction (i.e., no FirewallFirwall
 configuration).

 The times in the following samples are times (in seconds) from process
 launch (with a non-existing data directory) until PROGRESS=100 is reported
 in a getinfo status/bootstrap-phase:


 ''>>150, 12, 135, 137, 131, 143, >>250, >>250, >>250, >>250, 12, 133, 153,
 135, >>250, 132, 153, 192, >>250, 134, 12, 133, 137, >>250, 135, 142,
 >>250, 135, 9, >>250, >>250, 135, 134, 135, 132, 136, 133, 7, 133, 134,
 >>250, 131, 136, 133, 135, 8, 133, >>250, 133, >>250, >>250, 12, >>250, 6,
 >>250, >>250, 144, 132, 133, 139, 134, >>250, 12, >>250, 135, >>250, 135,
 133, 133, 134, 11, 133, 133, >>250, >>250

 (>>x indicates that the bootstrap process was not finished after x seconds
 and the test has been aborted.)

 The chances of bootstrapping in under two minutes (which is for instance
 the timeout that onionbalance uses) are not very good.

 It'd be nice if Tor had a way to deal with this better.

--
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] #28702 [Core Tor/Tor]: bootstrapping slow at times

[Tor Bug Tracker & Wiki]

#28702: bootstrapping slow at times
--+--
 Reporter:  weasel|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Hi!

 Tor 0.3.4.9, on Debian stretch (Thus linked against libssl
 1.1.0f-3+deb9u2), sometimes bootstraps slowly.

 The times in the following samples are times (in seconds) from process
 launch (with a non-existing data directory) until PROGRESS=100 is reported
 in a getinfo status/bootstrap-phase:

 9, 9, 7, 45, 11, 16, 17, 9, 21, 6, 10, 15, 44, 15, 15, 15, 7, 14, 7, 8,
 12, 8, 14, 13, 8, 8, 11, 6, 8, 8, 35, 16, 11, 7, 7, 9, 7, 8, 13, 10, 8,
 10, 14, 12, 15, 6, 7, 8, 91, 24, 13, 10, 10, 10

 Most of the bootstraps are quite comfortable in the sub 20s, but there are
 a few outliers well above 30 seconds.

 This is on an unfiltered network, with low latency and plenty of
 bandwidth.

--
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] #21377 [Core Tor/Tor]: DirAuths should expose bwauth bandwidth files

[Tor Bug Tracker & Wiki]

#21377: DirAuths should expose bwauth bandwidth files
-+-
 Reporter:  tom  |  Owner:  juga
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, metrics, tor-bwauth,|  Actual Points:
  035-removed-20180711, 040-roadmap-proposed |
Parent ID:  #25925   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by teor):

 Ah, the tests are here:
 https://travis-ci.org/juga0/tor/builds/462787217

--
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] #21377 [Core Tor/Tor]: DirAuths should expose bwauth bandwidth files

[Tor Bug Tracker & Wiki]

#21377: DirAuths should expose bwauth bandwidth files
-+-
 Reporter:  tom  |  Owner:  juga
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, metrics, tor-bwauth,|  Actual Points:
  035-removed-20180711, 040-roadmap-proposed |
Parent ID:  #25925   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:37 juga]:
 > Replying to [comment:36 teor]:
 >
 > > > If i call detect_compression_method, as
 test_dir_handle_get_status_vote_current_consensus_ns is doing:
 
https://github.com/torproject/tor/blob/8020d6fb05d9477e77c6ca554dc1288873f6115c/src/test/test_dir_handle_get.c#L1875,
 it will say the compression method is UNKNOWN_METHOD, instead of
 ZLIB_METHOD. What i'm doing wroing?
 > >
 > > I don't understand what you mean here.
 > > If you're calling the new code in the test, you have to add headers to
 the request.
 > > Otherwise, the new code should return NO_METHOD.
 > >
 > > I don't understand how you are getting UNKNOWN_METHOD.
 > > Please show me the code you are using, and the logs of the results.
 >
 >
 
https://github.com/torproject/tor/commit/b03091842bc4590e11e3ac026daae8ed6d8f7554

 I can't find the logs of the results. Can you put them in a pastebin?

--
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] #28137 [Metrics/Statistics]: Modify "Total consensus weights across bandwidth authorities" graph to only include relays that end up in the consensus

[Tor Bug Tracker & Wiki]

#28137: Modify "Total consensus weights across bandwidth authorities" graph to 
only
include relays that end up in the consensus
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  irl |Sponsor:
+--
Changes (by irl):

 * reviewer:   => irl


--
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] #28353 [Metrics/Website]: Use Guard & Exit, Guard only, Exit only, and Middle only on all bandwidth by flag graphs

[Tor Bug Tracker & Wiki]

#28353: Use Guard & Exit, Guard only, Exit only, and Middle only on all 
bandwidth
by flag graphs
-+--
 Reporter:  teor |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #28328   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 I like the area plot. For looking at colors, see [[https://contrast-
 ratio.com/#%23fff-on-%2300|this website]]. Just put the colors in
 either side and it will calculate the contrast ratio.

 W3C guidelines: https://www.w3.org/TR/WCAG/#contrast-minimum

--
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] #28560 [Core Tor/Tor]: hs: Mention in the manpage that Sandbox and adding a service with the control port fails

[Tor Bug Tracker & Wiki]

#28560: hs: Mention in the manpage that Sandbox and adding a service with the
control port fails
---+
 Reporter:  dgoulet|  Owner:  rl1987
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, tor-doc, easy  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by rl1987):

 * owner:  (none) => rl1987
 * status:  new => accepted


--
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] #21377 [Core Tor/Tor]: DirAuths should expose bwauth bandwidth files

[Tor Bug Tracker & Wiki]

#21377: DirAuths should expose bwauth bandwidth files
-+-
 Reporter:  tom  |  Owner:  juga
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, metrics, tor-bwauth,|  Actual Points:
  035-removed-20180711, 040-roadmap-proposed |
Parent ID:  #25925   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by juga):

 Replying to [comment:36 teor]:

 > > If i call detect_compression_method, as
 test_dir_handle_get_status_vote_current_consensus_ns is doing:
 
https://github.com/torproject/tor/blob/8020d6fb05d9477e77c6ca554dc1288873f6115c/src/test/test_dir_handle_get.c#L1875,
 it will say the compression method is UNKNOWN_METHOD, instead of
 ZLIB_METHOD. What i'm doing wroing?
 >
 > I don't understand what you mean here.
 > If you're calling the new code in the test, you have to add headers to
 the request.
 > Otherwise, the new code should return NO_METHOD.
 >
 > I don't understand how you are getting UNKNOWN_METHOD.
 > Please show me the code you are using, and the logs of the results.

 
https://github.com/torproject/tor/commit/b03091842bc4590e11e3ac026daae8ed6d8f7554

--
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] #28229 [Core Tor/Tor]: Possible race condition opening SOCKS Port in test_rebind.py

[Tor Bug Tracker & Wiki]

#28229: Possible race condition opening SOCKS Port in test_rebind.py
-+
 Reporter:  teor |  Owner:  rl1987
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, 035-can  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+

Comment (by rl1987):

 One more pull request for diagnostics:
 https://github.com/torproject/tor/pull/560
 * This time, let's use `getsockopt()` to check if new listener is actually
 listening.
 * Let's log some stuff when socket rebinding is supposed to happen.
 * Let's log the proper error message when `socket.connect_ex()` fails on
 Python side.

--
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