Re: [tor-bugs] #23396 [Applications/Tor Browser]: Update the msvcr100.dll we ship in Tor Browser

[Tor Bug Tracker & Wiki]

#23396: Update the msvcr100.dll we ship in Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-security,|  Actual Points:
  TorBrowserTeam201709R, tbb-backported  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-security, TorBrowserTeam201709R, tbb-backport => tbb-
 security, TorBrowserTeam201709R, tbb-backported


Comment:

 This got backported to 7.0.10 with commit
 50545b66c03d4fc8fb54b48ee6a34287516d43b7 on `maint-7.0` in the `tor-
 browser-bundle` repo.

--
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] #16678 [Applications/Tor Browser]: Enhance KeyboardEvent fingerprinting protection for unusual characters

[Tor Bug Tracker & Wiki]

#16678: Enhance KeyboardEvent fingerprinting protection for unusual characters
-+-
 Reporter:  arthuredelstein  |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201711   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-fingerprinting, TorBrowserTeam201711R => tbb-
 fingerprinting, TorBrowserTeam201711


--
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] #23582 [Applications/Tor Browser]: Increased crash rate due to disabled Windows DLL blocklist

[Tor Bug Tracker & Wiki]

#23582: Increased crash rate due to disabled Windows DLL blocklist
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201709,|  Actual Points:
  GeorgKoppen201709, tbb-backported  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201709, GeorgKoppen201709, tbb-backport =>
 TorBrowserTeam201709, GeorgKoppen201709, tbb-backported


Comment:

 Backported with commit 979accc19fb297b0e73c515924d5dfe5c8236be4 on `tor-
 browser-52.4.1esr-7.0-1`. This will make it into Tor Browser 7.0.10.

--
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] #24159 [Applications/Tor Browser]: The Torbutton version check does not deal properly with platform specific checks

[Tor Bug Tracker & Wiki]

#24159: The Torbutton version check does not deal properly with platform 
specific
checks
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-torbutton, TorBrowserTeam201711  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:1 mcs]:
 > We could use Services.appinfo.OS, but it returns strings like Darwin and
 WINNT.

 Well, we could easily translate that into "MacOS" and "Windows". I think
 we should make only client side changes, i.e. in Torbutton. For one this
 makes the fix less complex. And secondly, there might be third parties
 relying on the recommended versions file as it is right 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] #24172 [Applications/Tor Browser]: donation banner clobbers tor browser version string

[Tor Bug Tracker & Wiki]

#24172: donation banner clobbers tor browser version string
--+--
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #23925| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * parent:   => #23925


--
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] #23925 [Applications/Tor Browser]: 2018 Tor Browser banner

[Tor Bug Tracker & Wiki]

#23925: 2018 Tor Browser banner
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * type:  defect => 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] #21393 [Core Tor/Torflow]: bwauths use FastFirstHopPK, which is deprecated.

[Tor Bug Tracker & Wiki]

#21393: bwauths use FastFirstHopPK, which is deprecated.
-+-
 Reporter:  Sebastian|  Owner:  tom
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Torflow |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  tor-dirauth try-and-find-out |  Actual Points:
  deprecated |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by Sebastian):

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


--
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] #21393 [Core Tor/Torflow]: bwauths use FastFirstHopPK, which is deprecated.

[Tor Bug Tracker & Wiki]

#21393: bwauths use FastFirstHopPK, which is deprecated.
-+-
 Reporter:  Sebastian|  Owner:  tom
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Torflow |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth try-and-find-out deprecated  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 Oh okay, cool. I'll measure something else then!

--
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] #24010 [Core Tor/Torflow]: Make bandwidth authorities use DNS, not IP addresses

[Tor Bug Tracker & Wiki]

#24010: Make bandwidth authorities use DNS, not IP addresses
--+
 Reporter:  teor  |  Owner:  aagbsn
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #21394| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by Sebastian):

 https://trac.torproject.org/projects/tor/ticket/21394#comment:70

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

Re: [tor-bugs] #24010 [Core Tor/Torflow]: Make bandwidth authorities use DNS, not IP addresses

[Tor Bug Tracker & Wiki]

#24010: Make bandwidth authorities use DNS, not IP addresses
--+
 Reporter:  teor  |  Owner:  aagbsn
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #21394| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by Sebastian):

 This doesn't seem to actually do anything other than drastically slow down
 measurement of fast relays.

--
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] #21393 [Core Tor/Torflow]: bwauths use FastFirstHopPK, which is deprecated.

[Tor Bug Tracker & Wiki]

#21393: bwauths use FastFirstHopPK, which is deprecated.
-+-
 Reporter:  Sebastian|  Owner:  tom
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Torflow |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth try-and-find-out deprecated  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:6 tom]:
 > It sounds like (since bwauths aren't generally using 0.3.1) that this
 _could_ cause some change so we should measure, correct?

 It shouldn't make any change. The bwauths were early adopters of the value
 0 for this option, and in the many years since they started using 0, the
 rest of Tor caught up and everybody starting using zero. Then recently we
 took out the ability to choose anything other than 0.

 (In earlier Tor versions, the networkstatus_get_param("usecreatefast")
 defaulted to 1, and in more recent Tor versions, it defaults to 0. But in
 either case, it uses the param set by the consensus, which has been 0 for
 years.)

 tl;dr I think this is not a big deal, just delete the line and move on.

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

[tor-bugs] #24172 [Applications/Tor Browser]: donation banner clobbers tor browser version string

[Tor Bug Tracker & Wiki]

#24172: donation banner clobbers tor browser version string
--+--
 Reporter:  arma  |  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:|
--+--
 When I run my tor browser these days, I get the donation banner at the top
 of about:tor. Cool. But I can't see what Tor Browser version I'm running
 anymore.

 When I set extensions.torbutton.donation_banner2017.shown_count to 50, and
 reload about:tor, I get to see the tor browser version again.

 Next time we do a banner, we should think about how to show me my tor
 browser version still.

--
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] #24171 [Applications/Tor Browser Sandbox]: sandboxed tor browser debian oldstable fails to start with "Can't mkdir /home/amnesia/sandboxed-tor-browser/tor-browser/Browser/TorBrowser/Dat

[Tor Bug Tracker & Wiki]

#24171: sandboxed tor browser debian oldstable fails to start with "Can't mkdir
/home/amnesia/sandboxed-tor-browser/tor-
browser/Browser/TorBrowser/Data/Browser/Caches"
--+-
 Reporter:  arma  |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 thanks!

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

Re: [tor-bugs] #24138 [Applications/Tor Browser]: Older version of Tor Browser not updating

[Tor Bug Tracker & Wiki]

#24138: Older version of Tor Browser not updating
--+---
 Reporter:  lizzard   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by tom):

 Sorry to be a nag, but are you certain that this won't happen in the
 future under similar circumstances?

 To address pinned cert rollover, most browsers will not enforce pins N
 months after the build date of the browser.

 To address the 'several version update' FF does just that. We will tag
 watershed releases that all users must update through. So if you're on
 firefox 20 you may have to upgrade through (hypothetical example)  20 ->
 28 -> 35 -> 42 -> 50 -> 56.  Watersheds aren't planned, they just occur
 when they're necessary for things like mandatory SSE2 support, signing key
 rollover, etc.

--
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] #24171 [Applications/Tor Browser Sandbox]: sandboxed tor browser debian oldstable fails to start with "Can't mkdir /home/amnesia/sandboxed-tor-browser/tor-browser/Browser/TorBrowser/Dat

[Tor Bug Tracker & Wiki]

#24171: sandboxed tor browser debian oldstable fails to start with "Can't mkdir
/home/amnesia/sandboxed-tor-browser/tor-
browser/Browser/TorBrowser/Data/Browser/Caches"
--+-
 Reporter:  arma  |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

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


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

Re: [tor-bugs] #21393 [Core Tor/Torflow]: bwauths use FastFirstHopPK, which is deprecated.

[Tor Bug Tracker & Wiki]

#21393: bwauths use FastFirstHopPK, which is deprecated.
-+-
 Reporter:  Sebastian|  Owner:  tom
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Torflow |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth try-and-find-out deprecated  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 I've removed 'FastFirstHopPK 0' from my torrcs and HUPed, so in a week
 we'll have some data on this.

--
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] #21394 [Core Tor/Tor]: connection timeouts are affecting Tor Browser usability

[Tor Bug Tracker & Wiki]

#21394: connection timeouts are affecting Tor Browser usability
-+-
 Reporter:  arthuredelstein  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 030-backport|  Actual Points:
  031-backport tbb-performance, tbb-usability,   |
  performance, tbb-needs |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 https://ritter.vg/misc/stuff/tor-bwauth-dns-comparison-01.png

 I ran two bwauths, that had no differences between them, and calculated
 the average difference between two sets of relays for each consensus: the
 set of all relays, and the set of relays where the bw measurement was
 above 100 in both bwauths.

 That data (the blue and green lines) are the control.

 Then I changed one bwauth to connect to the final destination using an IP
 address and left the other one connecting using a DNS name. That data is
 the the orange and red lines.

 I don't see much of a difference. So it seems that bwauth measurements
 were not affected by this issue.

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

Re: [tor-bugs] #24171 [Applications/Tor Browser Sandbox]: sandboxed tor browser debian oldstable fails to start with "Can't mkdir /home/amnesia/sandboxed-tor-browser/tor-browser/Browser/TorBrowser/Dat

[Tor Bug Tracker & Wiki]

#24171: sandboxed tor browser debian oldstable fails to start with "Can't mkdir
/home/amnesia/sandboxed-tor-browser/tor-
browser/Browser/TorBrowser/Data/Browser/Caches"
--+-
 Reporter:  arma  |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 Yep, that fixes 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] #24171 [Applications/Tor Browser Sandbox]: sandboxed tor browser debian oldstable fails to start with "Can't mkdir /home/amnesia/sandboxed-tor-browser/tor-browser/Browser/TorBrowser/Dat

[Tor Bug Tracker & Wiki]

#24171: sandboxed tor browser debian oldstable fails to start with "Can't mkdir
/home/amnesia/sandboxed-tor-browser/tor-
browser/Browser/TorBrowser/Data/Browser/Caches"
--+-
 Reporter:  arma  |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 https://gitweb.torproject.org/tor-browser/sandboxed-tor-
 browser.git/commit/?id=4feaed188124f94458aec2da05893196bc5767c4

 Probably fixes 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] #24087 [Internal Services/Service - git]: Add teor as a torflow maintainer

[Tor Bug Tracker & Wiki]

#24087: Add teor as a torflow maintainer
-+
 Reporter:  teor |  Owner:  tor-gitadm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by Sebastian):

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


Comment:

 [x]

--
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] #24171 [Applications/Tor Browser Sandbox]: sandboxed tor browser debian oldstable fails to start with "Can't mkdir /home/amnesia/sandboxed-tor-browser/tor-browser/Browser/TorBrowser/Data/Br

[Tor Bug Tracker & Wiki]

#24171: sandboxed tor browser debian oldstable fails to start with "Can't mkdir
/home/amnesia/sandboxed-tor-browser/tor-
browser/Browser/TorBrowser/Data/Browser/Caches"
--+-
 Reporter:  arma  |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Another release, another fun buglet. :) I was on 7.0.8, it updated to
 7.0.9, now when it tries to start, it says
 {{{
 [...]
 2017/11/07 23:23:30 tor: Nov 08 04:23:30.000 [notice] Bootstrapped 85%:
 Finishing handshake with first hop
 2017/11/07 23:23:30 tor: Nov 08 04:23:30.000 [notice] Bootstrapped 90%:
 Establishing a Tor circuit
 2017/11/07 23:23:31 tor: Nov 08 04:23:31.000 [notice] Tor has successfully
 opened a circuit. Looks like client functionality is working.
 2017/11/07 23:23:31 tor: Nov 08 04:23:31.000 [notice] Bootstrapped 100%:
 Done
 2017/11/07 23:23:31 tor: Opened SOCKS passthrough listener: 127.0.0.1:9150
 2017/11/07 23:23:31 launch: Starting Tor Browser.
 2017/11/07 23:23:31 firefox: Can't mkdir /home/amnesia/sandboxed-tor-
 browser/tor-browser/Browser/TorBrowser/Data/Browser/Caches
 2017/11/07 23:23:31 firefox: : Read-only file system
 2017/11/07 23:23:31 launch: Complete.
 2017/11/07 23:23:31 tor: Nov 08 04:23:31.000 [notice] Catching signal
 TERM, exiting cleanly.
 2017/11/07 23:23:31 failed to accept control conn: accept unix
 /run/user/1000/sandboxed-tor-browser/control: use of closed network
 connection
 2017/11/07 23:23:31 failed to accept SOCKS conn: accept unix
 /run/user/1000/sandboxed-tor-browser/socks: use of closed network
 connection
 }}}
 and then it exits.

--
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] #24170 [Core Tor/Tor]: Log the actual bandwidth total when logging "Generated weighted bandwidths"

[Tor Bug Tracker & Wiki]

#24170: Log the actual bandwidth total when logging "Generated weighted 
bandwidths"
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  path-selection, 029-backport,|  Actual Points:  0.1
  030-backport, 031-backport |
Parent ID:  #23318   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:
 path-selection, 029-backport, 030-backport, 031-backport, review-
 group-24
 => path-selection, 029-backport, 030-backport, 031-backport
 * status:  new => needs_review


Comment:

 #23318 has a branch with a commit that fixes this.

--
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] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  path-selection, 029-backport,|  Actual Points:
  030-backport, 031-backport, review-group-24|
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  SponsorQ
-+-

Comment (by teor):

 Please see my branch bug23318-redux, which fixes the issue with
 frac_nodes_with_descriptors(), and the logging issue in #24170.

--
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] #24170 [Core Tor/Tor]: Log the actual bandwidth total when logging "Generated weighted bandwidths"

[Tor Bug Tracker & Wiki]

#24170: Log the actual bandwidth total when logging "Generated weighted 
bandwidths"
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core |Version:  Tor: 0.2.4.3-alpha
  Tor/Tor|   Keywords:  path-selection, 029-backport,
 Severity:  Normal   |  030-backport, 031-backport, review-group-24
Actual Points:  0.1  |  Parent ID:  #23318
   Points:  0.1  |   Reviewer:
  Sponsor:   |
-+-
 Now that we're calculating the bandwidth total, we should log 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] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  path-selection, 029-backport,|  Actual Points:
  030-backport, 031-backport, review-group-24|
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  SponsorQ
-+-
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 The underlying issue here is how tor deals with a consensus that has all-
 zero bandwidths.

 Before the original patch:
 1. Tor calculates 1 as the weighted bandwidth for all the nodes
 2. frac_nodes_with_descriptors() returns a sensible value, so Tor
 bootstraps
 3. node_sl_choose_by_bandwidth() returns a badly-weighted value (I split
 off #24169 to deal with this), but Tor works anyway

 After the original patch:
 1. Tor calculates 0 as the weighted bandwidth for all the nodes
 2. frac_nodes_with_descriptors() returns 0, so Tor fails to bootstrap

--
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] #24169 [Core Tor/Tor]: When all consensus bandwidths are zero, should Tor still respect bandwidth weights?

[Tor Bug Tracker & Wiki]

#24169: When all consensus bandwidths are zero, should Tor still respect 
bandwidth
weights?
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.4.3-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-client, path-selection  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * keywords:  tor-client => tor-client, path-selection


Comment:

 (I don't think we need to backport this, it only affects test networks.)

--
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] #24169 [Core Tor/Tor]: When all consensus bandwidths are zero, should Tor still respect bandwidth weights?

[Tor Bug Tracker & Wiki]

#24169: When all consensus bandwidths are zero, should Tor still respect 
bandwidth
weights?
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.4.3-alpha
 Severity:  Normal|   Keywords:  tor-client
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:|
--+
 In test networks with all-zero bandwidths, Tor chooses nodes uniformly at
 random. Instead, Tor should probably respect the bandwidth weights for
 guards, middles and exits.

 We could do this by modifying smartlist_choose_node_by_bandwidth_weights()
 and compute_weighted_bandwidths() to act as if all bandwidth weights are N
 rather than zero. N should be chosen so that typical bandwidth weights are
 preserved (typical weights in this case are 1, 1/3, and 0). So let's
 choose 3, like the existing non-bandwidth code.

 Split off #23318.

--
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] #24168 [Core Tor/Tor]: Generated a networkstatus consensus we couldn't parse

[Tor Bug Tracker & Wiki]

#24168: Generated a networkstatus consensus we couldn't parse
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-auth  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * Attachment "nodes.1510106682.zip" added.

 Chutney network directory

--
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] #24168 [Core Tor/Tor]: Generated a networkstatus consensus we couldn't parse

[Tor Bug Tracker & Wiki]

#24168: Generated a networkstatus consensus we couldn't parse
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.3-alpha
 Severity:  Normal|   Keywords:  tor-auth
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 During `make test-network`, seems to be timing dependent:
 {{{
 Warning: Couldn't generate a microdesc consensus at all! Number: 1
 Warning: Couldn't generate a ns consensus at all! Number: 1
 Warning: Couldn't generate any consensus flavors at all. Number: 1
 Warning: Couldn't store my own vote! (I told myself, 'Bad valid-after
 time'.) Number: 1
 Warning: ID on signature on network-status document does not match any
 declared directory source. Number: 2
 Warning: Rejecting vote from 127.0.0.1 with valid-after time of 2017-11-08
 02:05:40; we were expecting 2017-11-08 02:05:35 Number: 1
 Warning: networkstatus_compute_consensus: Bug: Generated a networkstatus
 consensus we couldn't parse. (on Tor 0.3.2.4-alpha c58471325a48f818)
 Number: 2
 }}}

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

Re: [tor-bugs] #17252 [Applications/Tor Browser]: Confirm TLS session resumption/ID are isolated to the URL bar domain, and re-enable them

[Tor Bug Tracker & Wiki]

#17252: Confirm TLS session resumption/ID are isolated to the URL bar domain, 
and
re-enable them
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, ff52-esr,   |  Actual Points:
  TorBrowserTeam201711, tbb-performance  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 I just noticed that the pref "security.enable_tls_session_tickets" was
 removed from Firefox in 2013:
 https://bugzilla.mozilla.org/show_bug.cgi?id=917049. So we can definitely
 remove that pref from `browser/app/profile/000-tor-browser.js`.

 Fortunately, the pref we uplifted in 2014,
 "security.ssl.disable_session_identifiers" is still present in Firefox,
 and is [https://bugzilla.mozilla.org/show_bug.cgi?id=967977 designed to
 disable both session IDs and session tickets]. The question remains
 whether we should remove this pref as well.

--
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] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  path-selection, 029-backport,|  Actual Points:
  030-backport, 031-backport, review-group-24|
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  SponsorQ
-+-

Comment (by nickm):

 Reverted with 3dc61a5d71423e.

 We should fix 01e984870a7e1db2722e85fe43af7bcb4755c2d4 so that it doesn't
 break test-networks, and then reapply.

--
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] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  path-selection, 029-backport,|  Actual Points:
  030-backport, 031-backport, review-group-24|
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  SponsorQ
-+-
Changes (by nickm):

 * status:  merge_ready => needs_revision
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 This seems to have broken test-network-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] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  path-selection, 029-backport,|  Actual Points:
  030-backport, 031-backport, review-group-24|
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  SponsorQ
-+-

Comment (by teor):

 This change breaks all chutney networks: we should run `make test-network`
 on our changes before we merge them.

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

Re: [tor-bugs] #21031 [Core Tor/Tor]: Please don't remove ClientDNSRejectInternalAddresses

[Tor Bug Tracker & Wiki]

#21031: Please don't remove ClientDNSRejectInternalAddresses
-+
 Reporter:  Sebastian|  Owner:  Sebastian
 Type:  defect   | Status:  reopened
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-23  |  Actual Points:  .1
Parent ID:   | Points:  .5
 Reviewer:  dgoulet  |Sponsor:
-+
Changes (by teor):

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


Comment:

 Commit 5a46074e55 in this branch also re-added this unrelated deprecation:
 {{{
 +  { "AllowDotExit", "Unrestricted use of the .exit notation can be used
 for "
 +"a wide variety of application-level attacks." },
 }}}

--
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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 bug23817_v2_032_squashed now fixes some of the above issues, but still
 needs rebasing onto 0.3.0.

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

Re: [tor-bugs] #23751 [Core Tor/Tor]: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.

[Tor Bug Tracker & Wiki]

#23751: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.
+--
 Reporter:  Felixix |  Owner:  dgoulet
 Type:  defect  | Status:  accepted
 Priority:  High|  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-channel, tor-sched, tor-buffer  |  Actual Points:
Parent ID:  #23993  | Points:
 Reviewer:  |Sponsor:  SponsorV
+--

Comment (by Felixix):

 Hi everybody

 It's back. Anything I can do ?

 {{{
 src/common/buffers.c:694: buf_add: Non-fatal assertion
 src/or/scheduler_kist.c:405: update_socket_written: Non-fatal assertion
 src/or/scheduler_kist.c:373: socket_can_write: Non-fatal assertion
 }}}

 Tor memory usage is about 5 GB according to:
 {{{
 MaxMemInQueues 5 GB
 }}}

 It's following and may-be connected to the new #24167.

 {{{
 Tor 0.3.2.3-alpha (git-023d756bfc04c244) running on FreeBSD with Libevent
 2.1.8-stable, OpenSSL LibreSSL 2.5.4, Zlib 1.2.8, Liblzma 5.2.2, and
 Libzstd 1.3.2.
 }}}

 {{{
 Nov 07 12:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 18:59
 hours, with 53232 circuits open. I've sent 6686.25 GB and received 6617.58
 GB.
 Nov 07 12:45:27.000 [notice] Circuit handshake stats since last time:
 41165/41165 TAP, 477460/477460 NTor.
 Nov 07 12:45:27.000 [notice] Since startup, we have initiated 0 v1
 connections, 0 v2 connections, 3 v3 connections, and 309567 v4
 connections; and received 2417 v1 connections, 51314 v2 connections,
 124479 v3 connections, and 969907 v4 connections.
 Nov 07 13:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 19:59
 hours, with 345744 circuits open. I've sent 6721.03 GB and received
 6653.43 GB.
 Nov 07 13:45:27.000 [notice] Circuit handshake stats since last time:
 47784/47784 TAP, 481668/481668 NTor.
 Nov 07 13:45:27.000 [notice] Since startup, we have initiated 0 v1
 connections, 0 v2 connections, 3 v3 connections, and 310352 v4
 connections; and received 2427 v1 connections, 51608 v2 connections,
 125265 v3 connections, and 974807 v4 connections.
 Nov 07 14:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 20:59
 hours, with 460213 circuits open. I've sent 6756.65 GB and received
 6688.85 GB.
 Nov 07 14:45:27.000 [notice] Circuit handshake stats since last time:
 91852/91852 TAP, 464777/464777 NTor.
 Nov 07 14:45:27.000 [notice] Since startup, we have initiated 0 v1
 connections, 0 v2 connections, 3 v3 connections, and 310990 v4
 connections; and received 2442 v1 connections, 51934 v2 connections,
 126196 v3 connections, and 979302 v4 connections.
 Nov 07 15:32:50.000 [warn] tor_bug_occurred_: Bug:
 src/common/buffers.c:694: buf_add: Non-fatal assertion !(buf->datalen >=
 INT_MAX - string_len) failed. (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: Non-fatal assertion !(buf->datalen >=
 INT_MAX - string_len) failed in buf_add at src/common/buffers.c:694. Stack
 trace: (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x11a2cd8  at
 /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x11bd93c  at
 /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x11a446b  at
 /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x1129402
  at /usr/local/bin/tor (on Tor
 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x10f2a98
  at /usr/local/bin/tor (on Tor
 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x10e7a6b
  at /usr/local/bin/tor (on Tor
 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x10e8078
  at /usr/local/bin/tor (on Tor
 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x109e1fa
  at /usr/local/bin/tor (on
 Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x10e88a2
  at /usr/local/bin/tor (on Tor
 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x10db2f6
  at /usr/local/bin/tor (on Tor 0.3.2.3-alpha
 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x10d9a22  at
 /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x801b38a96
  at /usr/local/lib/libevent-2.1.so.6
 (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x801b34cfe  at
 /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug: 0x1072eb5  at
 /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 07 15:32:50.000 [warn] Bug:  

[tor-bugs] #24167 [- Select a component]: connection_check_event: Bug: Event missing on connection

[Tor Bug Tracker & Wiki]

#24167: connection_check_event: Bug: Event missing on connection
--+
 Reporter:  Felixix   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hi everybody

 The following bug appeared:
 connection_check_event: Bug: Event missing on connection

 It's before hand a #23751 bug which is re-opened for it.

 {{{
 Tor 0.3.2.3-alpha (git-023d756bfc04c244) running on FreeBSD with Libevent
 2.1.8-stable, OpenSSL LibreSSL 2.5.4, Zlib 1.2.8, Liblzma 5.2.2, and
 Libzstd 1.3.2.
 }}}

 Tor memory is about 5 GB according to:
 {{{
 MaxMemInQueues 5 GB
 }}}

 {{{
 Nov 06 20:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 2:59 hours,
 with 89916 circuits open. I've sent 6246.15 GB and received 6171.99 GB.
 Nov 06 20:45:27.000 [notice] Circuit handshake stats since last time:
 31997/31997 TAP, 402465/402465 NTor.
 Nov 06 20:45:27.000 [notice] Since startup, we have initiated 0 v1
 connections, 0 v2 connections, 3 v3 connections, and 297718 v4
 connections; and received 2284 v1 connections, 47407 v2 connections,
 113778 v3 connections, and 907883 v4 connections.
 Nov 06 21:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 3:59 hours,
 with 156766 circuits open. I've sent 6284.75 GB and received 6211.71 GB.
 Nov 06 21:45:27.000 [notice] Circuit handshake stats since last time:
 34286/34286 TAP, 399076/399076 NTor.
 Nov 06 21:45:27.000 [notice] Since startup, we have initiated 0 v1
 connections, 0 v2 connections, 3 v3 connections, and 298544 v4
 connections; and received 2290 v1 connections, 47654 v2 connections,
 114327 v3 connections, and 911591 v4 connections.
 Nov 06 22:32:42.000 [warn] connection_check_event: Bug: Event missing on
 connection 0x80f227b00 [OR;open]. socket=-1. linked=0. is_dns_request=0.
 Marked_for_close=src/or/connection.c:3894 (on Tor 0.3.2.3-alpha
 023d756bfc04c244)
 Nov 06 22:32:42.000 [warn] Bug: Backtrace attached.. Stack trace: (on Tor
 0.3.2.3-alpha 023d756bfc04c244)
 Nov 06 22:32:42.000 [warn] Bug: 0x11a2cd8  at
 /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 06 22:32:42.000 [warn] Bug: 0x1071f21
  at /usr/local/bin/tor (on Tor 0.3.2.3-alpha
 023d756bfc04c244)
 Nov 06 22:32:42.000 [warn] Bug: 0x1071870
  at /usr/local/bin/tor (on Tor
 0.3.2.3-alpha 023d756bfc04c244)
 Nov 06 22:32:42.000 [warn] Bug: 0x1127408
  at /usr/local/bin/tor (on Tor
 0.3.2.3-alpha 023d756bfc04c244)
 Nov 06 22:32:42.000 [warn] Bug: 0x1073c8d  at
 /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 06 22:32:42.000 [warn] Bug: 0x801b38d3e
  at /usr/local/lib/libevent-2.1.so.6
 (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 06 22:32:42.000 [warn] Bug: 0x801b34cfe  at
 /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 06 22:32:42.000 [warn] Bug: 0x1072eb5  at
 /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 06 22:32:42.000 [warn] Bug: 0x10752a9  at
 /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 06 22:32:42.000 [warn] Bug: 0x1070d09  at
 /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 06 22:32:42.000 [warn] Bug: 0x1070c01 <_start+0x1a1> at
 /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 Nov 06 22:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 4:59 hours,
 with 221777 circuits open. I've sent 6323.37 GB and received 6252.10 GB.
 Nov 06 22:45:27.000 [notice] Circuit handshake stats since last time:
 97470/97470 TAP, 379601/379601 NTor.
 Nov 06 22:45:27.000 [notice] Since startup, we have initiated 0 v1
 connections, 0 v2 connections, 3 v3 connections, and 299180 v4
 connections; and received 2303 v1 connections, 47866 v2 connections,
 114911 v3 connections, and 915142 v4 connections.
 Nov 06 23:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 6:00 hours,
 with 87446 circuits open. I've sent 6350.85 GB and received 6278.68 GB.
 Nov 06 23:45:27.000 [notice] Circuit handshake stats since last time:
 21046/21046 TAP, 409042/409042 NTor.
 Nov 06 23:45:27.000 [notice] Since startup, we have initiated 0 v1
 connections, 0 v2 connections, 3 v3 connections, and 300082 v4
 connections; and received 2314 v1 connections, 48042 v2 connections,
 115432 v3 connections, and 918682 v4 connections.
 Nov 07 00:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 6:59 hours,
 with 298896 circuits open. I've sent 6373.37 GB and received 6302.57 GB.
 Nov 07 00:45:27.000 [notice] Circuit handshake stats since last time:
 206885/206885 TAP, 394540/394540 NTor.
 Nov 07 00:45:27.000 [notice] Since startup, we have initiated 0 v1

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Also, it looks like it's going to fail all the chutney tests:
 {{{
 FAIL: basic-min
 FAIL: bridges-min
 ...
 }}}

 And it logs very noisy warnings that start like this:
 {{{
 Warning: Bug: Non-fatal assertion
 !(router_get_trusteddirserver_by_digest(relay_digest)) failed in
 microdesc_note_outdated_dirserver at src/or/microdesc.c:114. Stack trace:
 (on Tor 0.3.3.0-alpha-dev fd33f85c044310ba) Number: 1
 }}}

 This might need a rethink.

--
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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I've got the 0.3.2 changes squashed and rebased as
 bug23817_v2_032_squashed, including a fix for the warning teor notes
 above.

--
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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 {{{
 ./changes/bug23817:
 Don't use a # before ticket numbers. ('bug 1234' not '#1234')
 Ticket marked as bugfix, but does not say 'Fixes bug XXX'
 }}}

--
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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Also, rst in the unit tests needs to be declared before any gotos, and set
 to NULL at declaration time:

 {{{
 src/test/test_entrynodes.c:1810:3: error: variable 'rst' is used
 uninitialized
   whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
   tt_ptr_op(g2, OP_EQ, g);
   ^~~
 ./src/ext/tinytest_macros.h:166:2: note: expanded from macro 'tt_ptr_op'
 tt_assert_test_type(a,b,#a" "#op" "#b,const void*,  \
 ^
 ./src/ext/tinytest_macros.h:144:2: note: expanded from macro
   'tt_assert_test_type'
 tt_assert_test_fmt_type(a,b,str_test,type,test,type,fmt,\
 ^
 ./src/ext/tinytest_macros.h:136:7: note: expanded from macro
   'tt_assert_test_fmt_type'
 if (!tt_status_) {  \
 ^~~
 src/test/test_entrynodes.c:1820:32: note: uninitialized use occurs here
   entry_guard_restriction_free(rst);
 }}}

--
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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  merge_ready => needs_revision


Comment:

 This fails to compile in recent clang with:
 {{{
 src/or/microdesc.c:85:14: error: no previous extern declaration for non-
 static
   variable 'outdated_dirserver_list'
 }}}

 {{{
 $ clang --version
 Apple LLVM version 9.0.0 (clang-900.0.38)
 Target: x86_64-apple-darwin16.7.0
 ...
 }}}

 (I have no idea what non-Apple clang version that corresponds to.)

--
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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Ok, the fixup looks good to me, let's get this 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] #23650 [Core Tor/Tor]: Tor source code has many typos

[Tor Bug Tracker & Wiki]

#23650: Tor source code has many typos
--+
 Reporter:  cypherpunks   |  Owner:  arma
 Type:  defect| Status:  assigned
 Priority:  Very Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 We need to check each of these in context, because I bet this one is
 actually a misspelling of "relay":
 {{{
 src/or/dns.c:22:38: "rela" is a misspelling of "real"
 }}}

--
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] #24135 [Core Tor/Fallback Scripts]: fluxe4 (a fallback dir) has stable ipv6

[Tor Bug Tracker & Wiki]

#24135: fluxe4 (a fallback dir) has stable ipv6
---+---
 Reporter:  Sebastian  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22321 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * component:  Core Tor/Tor => Core Tor/Fallback Scripts
 * parent:   => #22321
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 The next fallback update is scheduled for 0.3.3

--
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] #22321 [Core Tor/Fallback Scripts]: Update fallback directory whitelist based on relay changes

[Tor Bug Tracker & Wiki]

#22321: Update fallback directory whitelist based on relay changes
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22271 | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 fluxe4 also needs an IPv6 address added, see #24135

--
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] #21394 [Core Tor/Tor]: connection timeouts are affecting Tor Browser usability

[Tor Bug Tracker & Wiki]

#21394: connection timeouts are affecting Tor Browser usability
-+-
 Reporter:  arthuredelstein  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 030-backport|  Actual Points:
  031-backport tbb-performance, tbb-usability,   |
  performance, tbb-needs |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 I have a script running every 24 hours to check exits for DNS timeouts.
 I'll be posting the results at https://arthuredelstein.net/exits

--
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] #23863 [Core Tor/Tor]: When our directory guards don't have each others' microdescs, we should mark some dead

[Tor Bug Tracker & Wiki]

#23863: When our directory guards don't have each others' microdescs, we should
mark some dead
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Here's what we could do:
 1. Try some directory mirrors
 2. Try a fallback
 3. Try an authority
 4. If we still don't have mds for one or more primary guards, mark them
 dead until the next consensus

 This deals with the scenario where:
 1. Authorities make new consensus with new mds (hh:00)
 2. Client bootstraps and downloads consensus from authorities (either at
 random because they are part of the fallback list, or due to options)
 3. Client chooses directory guards
 4. Client tries directory guards for new mds
 5. Directory guards are waiting for a random time between hh:00 and hh:30
 to fetch new consensus and new mds
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3240

--
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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I am ok to merge this as-is, but let's think about the remaining issues in
 other tickets.

 Also, this comment is misleading:

 {{{
 /* Is our guard an outdated dirserver? */
 }}}

 It would be better as:

 {{{
 /* Last time we tried to fetch microdescs, was this directory mirror
 missing any we asked for? */
 }}}

 Replying to [comment:18 asn]:
 > OK, I pushed a branch `bug23817_v2` with the following changes:
 >
 > - It's now rebased on latest master (I will also prepare an 032 branch)

 Should we prepare an 030 branch instead/as well?

 > - Renames `relay_digest` to `dir_id` in `directory.c`.
 > - Adds a log message for failed mds.
 > - Does not add dirauths as outdated dirservers.

 Hmm, I wonder if a BUG() is the right thing to do here. It's probably ok
 in an alpha, but if a dirauth is out of sync, clients will log this as a
 BUG(), even though it's not their bug. (In most cases, if a dirauth is out
 of sync, that should self-correct, because it will be dropped from the
 consensus. Except for IPv6-only clients, which fetch mds from fallbacks
 and authorities so they can bootstrap.)

 In any case, this should be rare.

 > - Cleans up the outdated list if it grows above 30 elements.

 I think this is ok for the moment (it is no worse than the previous
 behaviour), but we should think about setting this limit low, and then
 trying an authority when we reach it (and then giving up on the md).
 That's a separate ticket - #23863.

 > A few notes:
 >
 > - I'm not checking if we have a recent consensus when we blacklist
 dirservers, as Nick suggested, which might actually be a problem. I think
 teor's suggestion of "check if our consensus is recent and try to get a
 newer one" is a whole project of its own that warrants its own ticket (or
 not?). What should we do here? Maybe we should not register outdated
 dirservers if we don't have a live consensus?

 Seems to make sense to me.

 > - teor, I'm not sure if I agree with your exponential backoff + list
 size argument, since IIUC the exponential backoff applies only when we
 fail to fetch the same md multiple times, whereas the outdated list can
 overgrow  just by failing many fetches for different mds. In any case, I
 opted for resetting the list after 30 arguments, which is a bit arbitrary
 but perhaps can save us from any surprising issues (?).

 I think there is a small risk of a client -> relay DDoS here, but it's no
 worse than the previous behaviour.

 > - I did not reset the list based on elapsed time because of teor's
 argument about clients fetching consensuses every 1 hour or so. Let me
 know if you don't like this.

 Seems 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] #24113 [Core Tor/Tor]: We stop trying to download an md after 8 failed tries

[Tor Bug Tracker & Wiki]

#24113: We stop trying to download an md after 8 failed tries
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 In the past, we have added a new option, like
 `TestingImportantMicrodescMaxDownloadTries`.

--
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] #23927 [Core Tor/Tor]: I can not get Tor to start on my ubuntu relay 16.04.3 LTS

[Tor Bug Tracker & Wiki]

#23927: I can not get Tor to start on my ubuntu relay 16.04.3 LTS
---+--
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by sdeziel):

 The "tor" service is not the real one (see "systemctl cat tor"). You
 likely want to start it with: "service tor@default start" instead.

--
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] #20412 [Metrics/Onionoo]: Skip bad archived descriptors rather than aborting the entire import

[Tor Bug Tracker & Wiki]

#20412: Skip bad archived descriptors rather than aborting the entire import
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:  #20548   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:9 karsten]:
 > Replying to [comment:8 iwakeh]:
 > > The fix looks ok and ready for merge.
 >
 > Will do! Thanks for checking!
 >
 > > (Was the initial implementation just chance or was there a reason for
 halting the import?)
 >
 > Hmm? Do you mean the initial ''import''? If so, I guess it worked out,
 because we only started including unparseable descriptors in CollecTor's
 output a few years ago.

 True.

 >
 > > I'm wondering, if the actual issue isn't in metrics-lib.
 > > Shouldn't there be a method `finishReading` that halts the reading
 process on client request?  Clients shouldn't be forced to read all
 available descriptors.  Afaik, the ISE is just due to calling the
 statistics methods before all was read.  New ticket for metrics-lib?
 >
 > Yes, that's another issue that we should fix. To be clear, this fix here
 is also a valid one: we shouldn't stop the import just because we ran into
 a single unparseable descriptor.

 Yes, my question above was an aside; not directed at the solution in this
 ticket.

 >
 > But what you point out is another issue: we shouldn't be forced to read
 all available descriptors. I'm not certain what the best fix is there.
 Maybe a `finishReading` or `abortReading` might work. But that's something
 that we can discuss on the new ticket. Can you open one? Thanks!

 See #24166.

--
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] #24166 [Metrics/Library]: Make descriptor reading stopable

[Tor Bug Tracker & Wiki]

#24166: Make descriptor reading stopable
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   |   Keywords:  metrics-2018
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 What would be the best way to not force reading of all descriptors?
 See #20412 comment:9 for background.

 Suggestion so far: create an `abortReading` method and after this method
 was called the reader's status is similar to a completed reading of
 descriptors, e.g., methods concerning stats don't throw ISEs anymore.

--
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] #24158 [Core Tor/Tor]: I get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relay

[Tor Bug Tracker & Wiki]

#24158: I get this error "Looks like our kernel doesn't have the support for 
KIST
anymore." on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  pastly
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sched  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dgoulet):

 Replying to [comment:11 pastly]:
 > dgoulet: can you clarify what message(s) you want to keep and which you
 want to get rid of?
 >
 > We have
 >
 > `Scheduler type %s has been enabled` every time the scheduler switches
 cleanly. I think we should keep this as notice.

 Yes we keep this one.

 >
 > `Looks like our kernel doesn't have the support for KIST` every time we
 try to use KIST but have to fallback to KISTLite. Should happen at most
 once unless you play games with your torrc and HUPing. I think we should
 keep this as notice (maybe even warn, but we don't want it to be too scary
 since it may not indicate a problem).

 Yes keep this one.

 >
 > `Scheduler type KIST has been disabled by the consensus or no kernel
 support` which gets called every time we call `select_scheduler()`, have
 KIST in `Schedulers`, but can't use it. I think this should be moved to
 info or removed.

 This one I propose we keep it notice but print _once_ and after that we do
 not. However, in the case of no kernel support, this is detected at
 runtime and we do log notice about it when detected so we don't need it.
 Thus the only way to transition out of KIST while having KIST enabled in
 Schedulers then is through the consensus. We should log notice that it
 happened but only once, not everytime we get a consensus. And if we ever
 transition back to KIST after a while, we'll get the "Scheduler type %s
 has been enabled" so we'll be back on track.

 >
 > I will gladly take care of this.

 Makes sense to 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] #24160 [Metrics/Atlas]: Wrong info about bridges?

[Tor Bug Tracker & Wiki]

#24160: Wrong info about bridges?
---+--
 Reporter:  eduperez   |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by eduperez):

 Ok, it all makes sense now; thanks for the info!

--
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] #22261 [Metrics/Onionoo]: Remove the $ from family fingerprints

[Tor Bug Tracker & Wiki]

#22261: Remove the $ from family fingerprints
-+
 Reporter:  teor |  Owner:  karsten
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 Why 2.0.0 and not 1.8.0? When we bumped the protocol version to 4.0 we
 only bumped the implementation version to 1.2.0, too. No need to pick a
 final version today, I'm just wondering why we would need a major
 (implementation) version change 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] #21637 [Metrics/Onionoo]: Include both declared and reachable IPv6 OR addresses

[Tor Bug Tracker & Wiki]

#21637: Include both declared and reachable IPv6 OR addresses
+
 Reporter:  teor|  Owner:  metrics-team
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Onionoo |Version:
 Severity:  Normal  | Resolution:
 Keywords:  metrics-2017, ipv6  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 Hmm, there are no tests for `DetailsDocumentWriter` yet. I guess we could
 create a test class. Do you have any preferences for such a test class, or
 should we just start with a minimal one that only tests this new field?

--
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] #20412 [Metrics/Onionoo]: Skip bad archived descriptors rather than aborting the entire import

[Tor Bug Tracker & Wiki]

#20412: Skip bad archived descriptors rather than aborting the entire import
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:  #20548   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:8 iwakeh]:
 > The fix looks ok and ready for merge.

 Will do! Thanks for checking!

 > (Was the initial implementation just chance or was there a reason for
 halting the import?)

 Hmm? Do you mean the initial ''import''? If so, I guess it worked out,
 because we only started including unparseable descriptors in CollecTor's
 output a few years ago.

 > I'm wondering, if the actual issue isn't in metrics-lib.
 > Shouldn't there be a method `finishReading` that halts the reading
 process on client request?  Clients shouldn't be forced to read all
 available descriptors.  Afaik, the ISE is just due to calling the
 statistics methods before all was read.  New ticket for metrics-lib?

 Yes, that's another issue that we should fix. To be clear, this fix here
 is also a valid one: we shouldn't stop the import just because we ran into
 a single unparseable descriptor.

 But what you point out is another issue: we shouldn't be forced to read
 all available descriptors. I'm not certain what the best fix is there.
 Maybe a `finishReading` or `abortReading` might work. But that's something
 that we can discuss on the new ticket. Can you open one? Thanks!

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

Re: [tor-bugs] #24158 [Core Tor/Tor]: I get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relay

[Tor Bug Tracker & Wiki]

#24158: I get this error "Looks like our kernel doesn't have the support for 
KIST
anymore." on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  pastly
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sched  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by pastly):

 dgoulet: can you clarify what message(s) you want to keep and which you
 want to get rid of?

 We have

 `Scheduler type %s has been enabled` every time the scheduler switches
 cleanly. I think we should keep this as notice.

 `Looks like our kernel doesn't have the support for KIST` every time we
 try to use KIST but have to fallback to KISTLite. Should happen at most
 once unless you play games with your torrc and HUPing. I think we should
 keep this as notice (maybe even warn, but we don't want it to be too scary
 since it may not indicate a problem).

 `Scheduler type KIST has been disabled by the consensus or no kernel
 support` which gets called every time we call `select_scheduler()`, have
 KIST in `Schedulers`, but can't use it. I think this should be moved to
 info or removed.

 I will gladly take care of this.

--
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] #24160 [Metrics/Atlas]: Wrong info about bridges?

[Tor Bug Tracker & Wiki]

#24160: Wrong info about bridges?
---+--
 Reporter:  eduperez   |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Replying to [ticket:24160 eduperez]:
 > I am currently running a bridge, and have tried to check it at
 atlas.torproject.org, but the info there seems to be wrong.
 >
 > I have copied the contents of the "hashed-fingerprint" file into the
 search box at ATLAS, and the info shown there seems to belong to my node:
 "nickname", "first seen", "last restarted", and "platform" all match my
 node. However, "OR address", and "advertised bandwidth" are off:
 >
 > * I have configured my node as "ORPort 9001", and effectively port 9001
 is open and listening; but ATLAS shows "IPv4:52563" at "OR address".

 The reason is that we're sanitizing TCP ports in order to make it harder
 to discover bridges with unusual ports. See https://metrics.torproject.org
 /bridge-descriptors.html#tcp-port

 I wonder if we should take out bridge OR address and ports from Atlas
 entirely. They were added before we started sanitizing TCP ports, and then
 they made some sense. But that may not be the case anymore.

 > * I have also configured "RelayBandwidthRate 512 KBytes" and
 "RelayBandwidthBurst 1024 KBytes", but ATLAS shows "55.09 KiB/s" at
 "advertised bandwith".

 The advertised bandwidth does not only depend on your configuration but
 also on what your relays reports. See
 https://metrics.torproject.org/glossary.html#advertised-bandwidth

 > Is this a known issue with ATLAS? Or perhaps I am misinterpreting the
 page? Many thanks!

 Not a code issue, but possibly a documentation issue. I'll leave it up to
 irl, the Atlas maintainer, to say whether there's something to fix in the
 documentation or presentation. Thanks for the report!

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

Re: [tor-bugs] #23816 [Core Tor/Tor]: Use exponential backoff with jitter and/or tune its parameters

[Tor Bug Tracker & Wiki]

#23816: Use exponential backoff with jitter and/or tune its parameters
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-24  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:  SponsorV
-+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Thanks!  The updated patches look good to me.  There are few minor nits
 with spacing around operators (e.g., `INT_MAX/3`, `base_delay+1`,
 `low_bound=0, high_bound=max_delay`) that you may wish to fix before
 merging, but they're probably not worth another round of review.

 I wrote some rough simulations in Python and they do show a significant
 improvement in terms of delays growing less quickly with the new
 algorithm.

--
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] #20699 [Core Tor/Tor]: prop224: Add control port events and commands

[Tor Bug Tracker & Wiki]

#20699: prop224: Add control port events and commands
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, needs-proposal,  |  Actual Points:
  prop224-extra, tor-control |
Parent ID:   | Points:  6
 Reviewer:   |Sponsor:
 |  SponsorR-must
-+-

Comment (by dgoulet):

 Spec: https://gitweb.torproject.org/torspec.git/tree/proposals/284-hsv3
 -control-port.txt

--
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] #24165 [Core Tor/Tor]: prop284: Changes needed on the proposal

[Tor Bug Tracker & Wiki]

#24165: prop284: Changes needed on the proposal
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs, tor-spec  |  Actual Points:
Parent ID:  #20699| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 it's your proposal; glad to merge!

--
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] #24165 [Core Tor/Tor]: prop284: Changes needed on the proposal

[Tor Bug Tracker & Wiki]

#24165: prop284: Changes needed on the proposal
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, tor-spec  |  Actual Points:
Parent ID:  #20699| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 See branch: `ticket24165_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] #24158 [Core Tor/Tor]: I get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relay

[Tor Bug Tracker & Wiki]

#24158: I get this error "Looks like our kernel doesn't have the support for 
KIST
anymore." on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  pastly
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sched  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

 * owner:  (none) => pastly
 * status:  needs_information => assigned


Comment:

 OK so only once.

 @pastly, I think we should go for only printing the log_notice from above,
 can you do it with your current branch that changes the man page? Else,
 I'll get to it, just assigned the ticket 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] #16678 [Applications/Tor Browser]: Enhance KeyboardEvent fingerprinting protection for unusual characters

[Tor Bug Tracker & Wiki]

#16678: Enhance KeyboardEvent fingerprinting protection for unusual characters
-+-
 Reporter:  arthuredelstein  |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201711R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  needs_review => needs_revision


Comment:

 Kathy and I reviewed the bug16678_2 changes. We have not tried to test the
 code yet, and we have not tried to determine if all of the mappings are
 optimal. That said, we have a few comments:

 1. Should we remove the "TODO needs more information" mappings? Or do we
 plan to do more research and include a mapping for them?

 2. Typo in a comment: Italisn

 3. Typo in a comment: FInnish

 4. Do we have automated tests for our key event fingerprinting changes?

--
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] #24165 [Core Tor/Tor]: prop284: Changes needed on the proposal

[Tor Bug Tracker & Wiki]

#24165: prop284: Changes needed on the proposal
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs, tor-spec
Actual Points:|  Parent ID:  #20699
   Points:|   Reviewer:
  Sponsor:|
--+
 Propopsal 284 is the HSv3 control port support (#20699) which was merged
 in tor-spec.git some days ago.

 A tor-dev@ discussion is ongoing and changes are needed:

 https://lists.torproject.org/pipermail/tor-dev/2017-November/012559.html

 This ticket is about to make a branch with the fixes from the discussion.

--
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] #24164 [Core Tor/Tor]: errors I get after I installed 0.3.2.3 on my relay

[Tor Bug Tracker & Wiki]

#24164: errors I get after I installed 0.3.2.3 on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * milestone:   => Tor: 0.3.2.x-final


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

Re: [tor-bugs] #24158 [Core Tor/Tor]: I get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relay

[Tor Bug Tracker & Wiki]

#24158: I get this error "Looks like our kernel doesn't have the support for 
KIST
anymore." on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sched  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:5 pastly]:

 > Thank you for running alpha Tor and reporting this.
 >
 >
 >
 >
 > > I keep getting this error.
 > > [notice]
 > >
 > >
 > >
 >
 > It's not an error. It's a friendly FYI.
 >
 > Dbryrtfbcbhgf: do you get these messages almost immediately when Tor
 starts or a few minutes/hours/++ later? My thinking is this: if it happens
 immediately, then that's a good argument for moving these messages into
 info as there may be plenty more relays that run on these rather old (but
 stable and bug fixed, right?) kernels. If it happens later, it isn't as
 good as an argument IMHO.
 >
 > Some open questions: is it important for people to know what scheduler
 they are using? What if they changed `Schedulers` in their torrc? What if
 their kernel suddenly stopped supporting a scheduler and they changed?
 >
 > In general I think it is important for people to be able to tell what
 scheduler their relay is using. Maybe these fallback messages are too
 error-looking though. And maybe if the user didn't set `Schedulers`, they
 really don't care and we shouldn't log anything. Do we tell users that
 they're using EWMA?
 >
 > **So my proposed solution** is to log this stuff at info by default, but
 if the user has set `Schedulers`, then to log it at notice.
 >
 > Sebastian: I'm making the manual a bit better. I think you're right: no
 one needs to know the acronym "AMAP".
 >
 > See my ticket24158 on gitweb.tpo for the manual language change.

  I get the log messages within a few minutes after I start Tor on the
 relay

--
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] #24164 [Core Tor/Tor]: errors I get after I installed 0.3.2.3 on my relay

[Tor Bug Tracker & Wiki]

#24164: errors I get after I installed 0.3.2.3 on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 I get the below errors when I install the latest alpha on my relay.
 14:45:28.000 [notice] Tor 0.3.2.3-alpha (git-d36fb2a6d1b7e75f) opening log
 file.

  14:45:28.316 [warn] OpenSSL version from headers does not match the
 version we're running with. If you get weird crashes, that might be why.
 (Compiled with 1000207f: OpenSSL 1.0.2g-fips  1 Mar 2016; running with
 1000207f: OpenSSL 1.0.2g  1 Mar 2016).

 14:45:28.316 [warn] Can't get entropy from getrandom().

--
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] #24135 [Core Tor/Tor]: fluxe4 (a fallback dir) has stable ipv6

[Tor Bug Tracker & Wiki]

#24135: fluxe4 (a fallback dir) has stable ipv6
--+
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * cc: teor (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] #23985 [Core Tor/Tor]: If less than 15 missing mds, Tor will delay md download for 10 mins

[Tor Bug Tracker & Wiki]

#23985: If less than 15 missing mds, Tor will delay md download for 10 mins
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | 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] #24118 [Core Tor/Tor]: spec: Update dir-spec.txt with HS v3 consensus param

[Tor Bug Tracker & Wiki]

#24118: spec: Update dir-spec.txt with HS v3 consensus param
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs, tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 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

[tor-bugs] #24163 [Webpages/Website]: Newsletter-master server down

[Tor Bug Tracker & Wiki]

#24163: Newsletter-master server down
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Unable to access and add a new newsletter (planned to send tomorrow) https
 ://newsletter-master.torproject.org/login

 Error message:

 Service Unavailable
 The server is temporarily unable to service your request due to
 maintenance downtime or capacity problems. Please try again later.
 Apache Server at newsletter-master.torproject.org Port 443

--
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] #7164 [Core Tor/Tor]: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1

[Tor Bug Tracker & Wiki]

#7164: microdesc.c:378: Bug: microdesc_free() called, but md was still 
referenced
1 node(s); held_by_nodes == 1
-+-
 Reporter:  jaj123   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.19
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, 025-backport, nickm- |  Actual Points:
  should-review, review-group-24 |
Parent ID:   | Points:  2
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


--
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] #23261 [Applications/Tor Launcher]: implement configuration portion of new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23261: implement configuration portion of new Tor Launcher UI
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, TorBrowserTeam201711R  |  Actual Points:
Parent ID:  #21951  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by mcs):

 * Attachment "bug23261-02-03-diff.txt" 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] #23261 [Applications/Tor Launcher]: implement configuration portion of new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23261: implement configuration portion of new Tor Launcher UI
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, TorBrowserTeam201711R  |  Actual Points:
Parent ID:  #21951  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by mcs):

 * keywords:  ux-team, TorBrowserTeam201711 => ux-team,
   TorBrowserTeam201711R
 * status:  needs_revision => needs_review


Comment:

 We fixed the issues that were mentioned in comment:36.
 We also fixed a problem that would sometimes cause the wizard buttons to
 have the wrong labels, etc. when an error occurred while the progress
 panel was in the process of opening. As before, there are three commits:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/log/?h=bug23261-03
 (there were no changes to the middle one in this round).

 I will also attach a diff that shows everything that was changed between
 our -02 and -03 branches.

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

Re: [tor-bugs] #24162 [Internal Services/Service - dist]: Torsocks tarballs should not be on my people.tpo

[Tor Bug Tracker & Wiki]

#24162: Torsocks tarballs should not be on my people.tpo
--+--
 Reporter:  dgoulet   |  Owner:  hiro
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - dist  |Version:
 Severity:  Normal| Resolution:
 Keywords:  torsocks  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by hiro):

 * status:  new => assigned
 * owner:  (none) => hiro


--
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] #24161 [Core Tor/Tor]: Recalculating voting schedule should be called first when setting a new consensus

[Tor Bug Tracker & Wiki]

#24161: Recalculating voting schedule should be called first when setting a new
consensus
---+
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-sr, tor-relay  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 Merged!

 (Assuming that this needs no changes file since it's a bugfix on a recent
 patch in 0.3.2. Please get me a changes file if not?)

--
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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 That change looks okay.  I'll wait to see if Teor says "no" and otherwise,
 I'll merge.

 Rationale: We should test this in 0.3.2, for possible backport.  If it
 breaks alpha, we put out another alpha fast.

--
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] #23985 [Core Tor/Tor]: If less than 15 missing mds, Tor will delay md download for 10 mins

[Tor Bug Tracker & Wiki]

#23985: If less than 15 missing mds, Tor will delay md download for 10 mins
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 > Hm. I meant to suggest we disable the
 TestingClientMaxIntervalWithoutRequest delay functionality if we are
 missing descs of primary guards. Aka not wait 10 mins before fetching the
 primary guard descriptors.

 Ah!  You mean something like
 {{{
 diff --git a/src/or/routerlist.c b/src/or/routerlist.c
 index f04e2ca160331b..f587bfadcef1a1 100644
 --- a/src/or/routerlist.c
 +++ b/src/or/routerlist.c
 @@ -5010,6 +5010,11 @@ launch_descriptor_downloads(int purpose,
log_debug(LD_DIR,
  "There are enough downloadable %ss to launch requests.",
  descname);
 +} else if (! router_have_minimum_dir_info()) {
 +  log_debug(LD_DIR,
 +"We are only missing %d %ss, but we'll fetch anyway,
 since "
 +"we don't yet have enough directory info.",
 +n_downloadable, descname);
  } else {

/* should delay */
 }}}

--
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] #24162 [Internal Services/Service - dist]: Torsocks tarballs should not be on my people.tpo

[Tor Bug Tracker & Wiki]

#24162: Torsocks tarballs should not be on my people.tpo
--+--
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - dist  |Version:
 Severity:  Normal|   Keywords:  torsocks
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 As it turns out, I release torsocks tarball using the people.tpo URL:

 https://people.torproject.org/~dgoulet/torsocks/

 This is kind of not good if the maintainership ever changes or even if
 someonelse does a release. The Debian package watches that URL for new
 release which is not ideal.

 I think we should move that location to `dist.torproject.org/torsocks` if
 possible?

--
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] #24161 [Core Tor/Tor]: Recalculating voting schedule should be called first when setting a new consensus

[Tor Bug Tracker & Wiki]

#24161: Recalculating voting schedule should be called first when setting a new
consensus
---+
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sr, tor-relay  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 See branch: `bug24161_032_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

[tor-bugs] #24161 [Core Tor/Tor]: Recalculating voting schedule should be called first when setting a new consensus

[Tor Bug Tracker & Wiki]

#24161: Recalculating voting schedule should be called first when setting a new
consensus
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-sr, tor-relay
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In `networkstatus_set_current_consensus()`, at some point the `if
 (is_usable_flavor)` does a series of action on the newly set consensus.

 One of those is `nodelist_set_consensus()` which among many things will
 compute the HSv3 HSDir index for every `node_t` in this new consensus.
 That step requires the voting schedule object to be defined too compute
 time periods that the HS subsystem needs requiring the voting schedule
 timings.

 So, the very first thing we should do when we get a new usable consensus
 is set its voting schedule timings. That is call
 `dirvote_recalculate_timing(options, now);` which is currently after the
 nodelist set.

 This has been observed by this Bug when tor starts with the latest change
 in #23623:

 {{{
 Nov 07 15:39:09.364 [notice] Bootstrapped 0%: Starting
 Nov 07 15:39:09.978 [warn] tor_timegm(): Bug: Out-of-range argument to
 tor_timegm (on Tor 0.3.3.0-alpha-dev c6c4a421fd7d8a0d)
 Nov 07 15:39:09.978 [warn] dirvote_get_start_of_next_interval(): Bug: Ran
 into an invalid time when trying to find midnight. (on Tor 0.3.3.0-alpha-
 dev c6c4a421fd7d8a0d)
 ...
 }}}

 The other thing I wondered is if we should add a safe guard to the public
 function `dirvote_get_next_valid_after_time()` to calculate the timings in
 case the voting schedule is zeroed because in this case, this is where the
 issue comes from, that function returns 0.

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

Re: [tor-bugs] #23985 [Core Tor/Tor]: If less than 15 missing mds, Tor will delay md download for 10 mins

[Tor Bug Tracker & Wiki]

#23985: If less than 15 missing mds, Tor will delay md download for 10 mins
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by asn):

 Replying to [comment:2 nickm]:
 > Replying to [comment:1 asn]:
 > > Perhaps the fix here is to disable this delay functionality if the
 missing descriptors are delaying bootstrap (e.g. if missing descs are
 primary guard descs)?
 >
 > Before we do that, let's consider the purpose of waiting here: we don't
 want anybody to be able to force us to use a secondary guard by denying us
 descriptors for any primary guards.

 Hm. I meant to suggest we disable the
 `TestingClientMaxIntervalWithoutRequest` delay functionality if we are
 missing descs of primary guards. Aka not wait 10 mins before fetching the
 primary guard descriptors.

 I think perhaps you understood that I suggested we disable the "waiting
 for primary guard descriptors" functionality, which was certainly not my
 intention. Sorry for the non-clear wording above.

--
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] #23816 [Core Tor/Tor]: Use exponential backoff with jitter and/or tune its parameters

[Tor Bug Tracker & Wiki]

#23816: Use exponential backoff with jitter and/or tune its parameters
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-24  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:  SponsorV
-+
Changes (by nickm):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #23816 [Core Tor/Tor]: Use exponential backoff with jitter and/or tune its parameters

[Tor Bug Tracker & Wiki]

#23816: Use exponential backoff with jitter and/or tune its parameters
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-24  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:  SponsorV
-+

Comment (by nickm):

 It seems that the test-network variant was added in
 38e3f91c6388bc676c0007b00948, for #20597.

 Based on the reasoning there, I think that it shouldn't be necessary to
 have that variant any more: previously, the maximum delay increase was 4x
 for production, 3x for test.  Now, it's 3x for everyone: so it shouldn't
 make testnets any worse.

 I've pushed an updated `bug23816_029`, with fixup commits to remove the
 "full jitter" algorithm.

--
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] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  asn
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * keywords:  regression backport? tor-hs => tor-hs
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 Way to much changes needed for v2 here. Deferring to 033.

--
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] #24118 [Core Tor/Tor]: spec: Update dir-spec.txt with HS v3 consensus param

[Tor Bug Tracker & Wiki]

#24118: spec: Update dir-spec.txt with HS v3 consensus param
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_revision => merge_ready


Comment:

 Replying to [comment:2 asn]:
 > Why change `hsdir-interval`? You mean change it from `hsdir-interval` to
 `hsdir_interval`? Or what?

 Yes, in the code we use `hsdir-interval` but it should be `hsdir_interval`
 if we want to be consistent with the naming which we should absolutely fix
 in 032.

 Patch in asn's `ticket24118_01` 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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:19 nickm]:
 > > Maybe we should not register outdated dirservers if we don't have a
 live consensus?
 >
 > I think that would be fine.

 I pushed a fixup for this. I also force-pushed because I had left a
 `log_warn()` accidentally.

--
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] #23561 [Applications/Tor Browser]: Fix nsis builds for Windows 64

[Tor Bug Tracker & Wiki]

#23561: Fix nsis builds for Windows 64
---+--
 Reporter:  boklm  |  Owner:  boklm
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201711  |  Actual Points:
Parent ID:  #20636 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by boklm):

 * status:  assigned => needs_review


Comment:

 The branch `bug_23561` in my git repo has a patch for review:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_23561&id=03a5abef9e76f9e7464e0110f068b9e65e9a841d

 With this patch we use a 32bit nsis for the 64bit bundle. This create a
 32bit installer to install the 64bit bundle.

--
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] #24096 [Community/Tor Support]: cURL error 7: Can't complete SOCKS5 connection to 0.0.0.0:0. (6)

[Tor Bug Tracker & Wiki]

#24096: cURL error 7: Can't complete SOCKS5 connection to 0.0.0.0:0. (6)
---+---
 Reporter:  ahmad.saeed|  Owner:  phoul
 Type:  defect | Status:  closed
 Priority:  Immediate  |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dgoulet):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 We'll need tor logs to be able to assist but right off the bat, seeing
 `0.0.0.0:0` should tell you that curl is trying to reach something not
 reachable.

 Error 7 should be "can't connect to proxy" but the address should be
 `127.0.0.1:9050` by default, the Tor SOCKS port.

--
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] #24124 [Core Tor/Tor]: [warn] Socks version -125 not recognized.

[Tor Bug Tracker & Wiki]

#24124: [warn] Socks version -125 not recognized.
--+
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_information => closed
 * resolution:   => invalid


Comment:

 This is an application bombing Tor with the wrong SOCKS version so those
 warnings should be there to inform the user that the application talking
 to it is not working properly. It is one of the main point of a tor client
 which is to provide a way in for an application to the tor network so if
 it is not working properly, I strongly think it should be loud to the
 user.

 I'm closing this for now because I don't see this as a bug. Reopen if
 someone can point at a bug?

--
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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 > Maybe we should not register outdated dirservers if we don't have a live
 consensus?

 I think that would be 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] #7164 [Core Tor/Tor]: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1

[Tor Bug Tracker & Wiki]

#7164: microdesc.c:378: Bug: microdesc_free() called, but md was still 
referenced
1 node(s); held_by_nodes == 1
-+-
 Reporter:  jaj123   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.19
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, 025-backport, nickm- |  Actual Points:
  should-review, review-group-24 |
Parent ID:   | Points:  2
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * cc: asn (added)
 * reviewer:   => asn


--
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] #23623 [Core Tor/Tor]: hs: Cache current time period number and SRV start time

[Tor Bug Tracker & Wiki]

#23623: hs: Cache current time period number and SRV start time
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  tor-hs, tor-sr, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+
Changes (by nickm):

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


Comment:

 Merged to 0.3.2 and forward!

--
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] #23985 [Core Tor/Tor]: If less than 15 missing mds, Tor will delay md download for 10 mins

[Tor Bug Tracker & Wiki]

#23985: If less than 15 missing mds, Tor will delay md download for 10 mins
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 Replying to [comment:1 asn]:
 > Perhaps the fix here is to disable this delay functionality if the
 missing descriptors are delaying bootstrap (e.g. if missing descs are
 primary guard descs)?

 Before we do that, let's consider the purpose of waiting here: we don't
 want anybody to be able to force us to use a secondary guard by denying us
 descriptors for any primary guards.

--
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] #24159 [Applications/Tor Browser]: The Torbutton version check does not deal properly with platform specific checks

[Tor Bug Tracker & Wiki]

#24159: The Torbutton version check does not deal properly with platform 
specific
checks
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-torbutton, TorBrowserTeam201711  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 We could use Services.appinfo.OS, but it returns strings like Darwin and
 WINNT.

--
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] #24158 [Core Tor/Tor]: I get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relay

[Tor Bug Tracker & Wiki]

#24158: I get this error "Looks like our kernel doesn't have the support for 
KIST
anymore." on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sched  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by pastly):

 Replying to [comment:6 dgoulet]:
 > I think that notice will be logged each time the conf changed or new
 consensus while having KIST disabled by no kernel support. We should
 probably log it once and only once.
 >{{{
 >log_notice(LD_SCHED, "Scheduler type KIST has been disabled by "
 > "the consensus or no kernel support.");
 >}}}

 I'm skimmed the code a bit and I think you're right. Every consensus we
 probably log the above message, but only on the first consensus after
 having to fall back do we log `Scheduler type KISTLite has been enabled.`

--
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] #24158 [Core Tor/Tor]: I get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relay

[Tor Bug Tracker & Wiki]

#24158: I get this error "Looks like our kernel doesn't have the support for 
KIST
anymore." on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sched  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by pastly):

 * status:  needs_revision => needs_information


Comment:

 Replying to [comment:6 dgoulet]:
 > @pastly: The man page change lgtm *except* that I wouldn't put `and
 doesn't prioritize very well`. It is good to be honest but then also it is
 kind of weird to document how shitty it is in the manual page but still
 offer the option :P.

 Pushed a fixup commit.

 I believe we are now waiting on information from Dbryrtfbcbhgf where in
 the logs he sees these messages.

 - Startup, or later?
 - One (per time you start Tor) or periodically?

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