Re: [tor-bugs] #27974 [Applications/Tor Browser]: Make SEARX the Default Search Engine

[Tor Bug Tracker & Wiki]

#27974: Make SEARX the Default Search Engine
--+--
 Reporter:  nicwow|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 I think we should add it first and test it out if at all, before making a
 new search engine the default one. Thus, this is a parent of #19208.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19208 [Applications/Tor Browser]: add searx search engine

[Tor Bug Tracker & Wiki]

#19208: add searx search engine
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  reopened
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:  searx |  Actual Points:
Parent ID:  #27974| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * parent:   => #27974


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13433 [Applications/Tor Browser]: "Update failed" from 4.0-alpha-3 on 32-bit when I have a large file in my browser tree

[Tor Bug Tracker & Wiki]

#13433: "Update failed" from 4.0-alpha-3 on 32-bit when I have a large file in 
my
browser tree
--+---
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Actually, this bug might have been resolved by not doing the staged
 updating anymore (see rstrong's
 https://bugzilla.mozilla.org/show_bug.cgi?id=1108985#c6).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13433 [Applications/Tor Browser]: "Update failed" from 4.0-alpha-3 on 32-bit when I have a large file in my browser tree

[Tor Bug Tracker & Wiki]

#13433: "Update failed" from 4.0-alpha-3 on 32-bit when I have a large file in 
my
browser tree
--+---
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Sounds good, done.

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

Re: [tor-bugs] #18186 [Applications/Tor Browser]: tor browser updater handles full disk poorly

[Tor Bug Tracker & Wiki]

#18186: tor browser updater handles full disk poorly
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: arma (added)


Comment:

 #13433 is a duplicate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #11506 [Applications/Tor Browser]: Users are confused by the 2000-01-01 00:00 UTC timestamp

[Tor Bug Tracker & Wiki]

#11506: Users are confused by the 2000-01-01 00:00 UTC timestamp
-+-
 Reporter:  lunar|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-helpdesk-frequent,   |  Actual Points:
  TorBrowserTeam201601, GeorgKoppen201601, tbb-  |
  rbm|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 #23559 covers the "Extensions Last Updated" part of this issue. Duping
 that one over to this 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] #23559 [Applications/Tor Browser]: Extensions Last Updated date January 1, 2000

[Tor Bug Tracker & Wiki]

#23559: Extensions Last Updated date January 1, 2000
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 I think we should try to get this solved as an enhancement. But we can do
 so while working on #11506. So, duping this over to that 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

[tor-bugs] #28319 [Core Tor/Tor]: accept a reasonably live consensus for path selection

[Tor Bug Tracker & Wiki]

#28319: accept a reasonably live consensus for path selection
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.6.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  bootstrap, clock-skew, tor-guard,
 Severity:  Normal   |  usability, ux, s8-errors, 035-roadmap-subtask,
 |  035-triaged-in-20180711, s8-bootstrap
Actual Points:   |  Parent ID:  #23605
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 When I fixed guard selection in #24661, tor said:
 {{{
 Nov 05 15:29:55.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no recent usable consensus.
 }}}

 Maybe this is a logging issue, maybe it's another constraint we need to
 fix.

 See the full log in:
 https://trac.torproject.org/projects/tor/ticket/24661#comment:13

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28290 [Applications/Tor Browser]: Stop lying that "reporting real OS in navigator.userAgent is not a bug"

[Tor Bug Tracker & Wiki]

#28290: Stop lying that "reporting real OS in navigator.userAgent is not a bug"
--+--
 Reporter:  indigotime|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting-os |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * priority:  Very High => Medium
 * keywords:   => tbb-fingerprinting-os


Comment:

 I am fine logging this as a bug in our system to remind us of the fact
 that this is an OS fingerprinting vector we actually like to get solved
 (together with the other OS fingerprinting ones).

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

Re: [tor-bugs] #28255 [Core Tor/Tor]: verify guard selection consensus expiry constraints

[Tor Bug Tracker & Wiki]

#28255: verify guard selection consensus expiry constraints
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew, tor-guard,|  Actual Points:
  usability, ux, s8-errors, 035-roadmap- |
  subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #23605   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by teor):

 Path selection also appears to fail, see:
 https://trac.torproject.org/projects/tor/ticket/24661#comment:13

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24661 [Core Tor/Tor]: accept a reasonably live consensus for guard selection

[Tor Bug Tracker & Wiki]

#24661: accept a reasonably live consensus for guard selection
-+-
 Reporter:  catalyst |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew,   |  Actual Points:
  s8-bootstrap, s8-errors, ux,   |
  033-triage-20180320, 034-roadmap-proposed, |
  034-triage-20180328, 034-included-20180328,|
  034-deferred-20180602, 035-removed-20180711|
Parent ID:  #23605   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by teor):

 * owner:  catalyst => teor
 * version:   => Tor: 0.3.0.1-alpha
 * milestone:  Tor: unspecified => Tor: 0.3.6.x-final


Comment:

 I have a draft branch for this bug.

 I still need to fix the entry nodes unit tests.

 There also seem to be other parts of tor's codebase that require a recent
 consensus:
 {{{
 Nov 05 15:29:04.000 [notice] Bootstrapped 25%: Loading networkstatus
 consensus
 Nov 05 15:29:51.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no usable consensus.
 Nov 05 15:29:52.000 [notice] Bootstrapped 40%: Loading authority key certs
 Nov 05 15:29:55.000 [warn] Our clock is 30 minutes, 6 seconds behind the
 time published in the consensus network status document (2018-11-05
 06:00:00 UTC).  Tor needs an accurate clock to work correctly. Please
 check your time and date settings!
 Nov 05 15:29:55.000 [warn] Received microdesc flavor consensus with skewed
 time (CONSENSUS): It seems that our clock is behind by 30 minutes, 6
 seconds, or that theirs is ahead. Tor requires an accurate clock to work:
 please check your time, timezone, and date settings.
 Nov 05 15:29:55.000 [warn] Problem bootstrapping. Stuck at 40%: Loading
 authority key certs. (Clock skew -1806 in microdesc flavor consensus from
 CONSENSUS; CLOCK_SKEW; count 1; recommendation warn; host ? at ?)
 Nov 05 15:29:55.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no recent usable consensus.
 Nov 05 15:29:55.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no recent usable consensus.
 Nov 05 17:27:43.000 [notice] Your system clock just jumped 7056 seconds
 forward; assuming established circuits no longer work.
 }}}

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

Re: [tor-bugs] #28187 [Applications/Tor Browser]: Change Tor Circuit display icon to an onion

[Tor Bug Tracker & Wiki]

#28187: Change Tor Circuit display icon to an onion
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, ux-team,  |  Actual Points:
  TorBrowserTeam201811R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => needs_review
 * keywords:  tbb-usability, ux-team => tbb-usability, ux-team,
 TorBrowserTeam201811R


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24465 [Applications/Tor Browser]: Snowflake broken if no libatomic on host

[Tor Bug Tracker & Wiki]

#24465: Snowflake broken if no libatomic on host
-+-
 Reporter:  isabela  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, tbb-rbm,  |  Actual Points:
  TorBrowserTeam201811R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  snowflake, tbb-rbm, TorBrowserTeam201809 => snowflake, tbb-
 rbm, TorBrowserTeam201811R


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27299 [Core Tor/Tor]: hsv3: Clarify timing sources around hsv3 code

[Tor Bug Tracker & Wiki]

#27299: hsv3: Clarify timing sources around hsv3 code
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs hsv3 refactoring easy  |  Actual Points:
Parent ID:  #23605| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by teor):

 * sponsor:   => Sponsor8-can
 * parent:   => #23605


Comment:

 I think we should use approx_time() consistently, because it saves CPU on
 some platforms.

 Tentatively assigning to Sponsor 8.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23764 [Core Tor/Tor]: hs-v3: No live consensus on client with a bridge

[Tor Bug Tracker & Wiki]

#23764: hs-v3: No live consensus on client with a bridge
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #23605   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by teor):

 * sponsor:   => Sponsor8-can
 * parent:   => #23605


Comment:

 When we merge #24661, the HS subsystem will be the only remaining client
 code that requires a live consensus. I think we could do this ticket in
 Sponsor 8, if you want.

 (Otherwise, clients will bootstrap with clock skew, but they won't be able
 to use v3 onion services.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25885 [Core Tor/Tor]: count_acceptable_nodes() would be more accurate using node_has_preferred_descriptor()

[Tor Bug Tracker & Wiki]

#25885: count_acceptable_nodes() would be more accurate using
node_has_preferred_descriptor()
--+
 Reporter:  nickm |  Owner:  neel
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by teor):

 Oh, I missed this ticket. Sorry!

 I think you're right. I think we want to fail if we can't find enough
 entry nodes, or if we can't find enough non-entry nodes.

 Also, it would be useful for the log message to say how many of each type
 of node we want.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27284 [Core Tor/Tor]: Check IPv6 exit policies on microdescs

[Tor Bug Tracker & Wiki]

#27284: Check IPv6 exit policies on microdescs
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  034-backport-maybe, ipv6 => ipv6


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27366 [Core Tor/Tor]: Ask Travis CI to reduce the number of erroring builds

[Tor Bug Tracker & Wiki]

#27366: Ask Travis CI to reduce the number of erroring builds
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-ci|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 It seems that Travis has solved their issues for the moment.

 For future reference:

 It often takes Travis a week to respond to emails.

 {{{
 For the next time, here the information you can include in every e-mail
 you send us:

 - GitHub account
 - Repository name
 - Explanation of the issue
 - Copy of the error message (if any)
 - Link to a specific build showing the issue
 }}}

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

Re: [tor-bugs] #27366 [Core Tor/Tor]: Ask Travis CI to reduce the number of erroring builds

[Tor Bug Tracker & Wiki]

#27366: Ask Travis CI to reduce the number of erroring builds
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-ci|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  assigned => 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] #27296 [Core Tor/Tor]: macOS x86_64 fails test-timers

[Tor Bug Tracker & Wiki]

#27296: macOS x86_64 fails test-timers
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.6-rc
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 I think we might have fixed this error with our other timer fixes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27530 [Core Tor/Tor]: Configure: Use AC_TRY_RUN() to check that --enable-gcc-hardening works

[Tor Bug Tracker & Wiki]

#27530: Configure: Use AC_TRY_RUN() to check that --enable-gcc-hardening works
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  fast-fix  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * owner:  teor => (none)


Comment:

 Anyone can do this patch.

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

Re: [tor-bugs] #27736 [Core Tor/Tor]: Make sure that Tor doesn't build an IPv4 and an IPv6 connection to the same relay

[Tor Bug Tracker & Wiki]

#27736: Make sure that Tor doesn't build an IPv4 and an IPv6 connection to the 
same
relay
-+--
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client ipv6  |  Actual Points:
Parent ID:  #17835   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by teor):

 * owner:  teor => (none)


Comment:

 We should write tests to make sure that we don't make multiple connections
 to the same 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

Re: [tor-bugs] #27778 [Core Tor/Tor]: Travis: add link-time optimisation to detect function signature mismatches

[Tor Bug Tracker & Wiki]

#27778: Travis: add link-time optimisation to detect function signature 
mismatches
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorV-can
--+--
Changes (by teor):

 * sponsor:   => SponsorV-can


Comment:

 We could do this ticket to check our PrivCount bindings.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28318 [Core Tor/Tor]: Appveyor: build on Windows Server 2012 R2 and Windows Server 2016

[Tor Bug Tracker & Wiki]

#28318: Appveyor: build on Windows Server 2012 R2 and Windows Server 2016
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:
  |  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fast-fix, test, appveyor, tor-ci  |  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 See my branch ticket28318-035 or
 https://github.com/torproject/tor/pull/476

 This change doubles our appveyor build time. If that's a problem, we can
 just build x86-64 on Windows Server 2016.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28318 [Core Tor/Tor]: Appveyor: build on Windows Server 2012 R2 and Windows Server 2016

[Tor Bug Tracker & Wiki]

#28318: Appveyor: build on Windows Server 2012 R2 and Windows Server 2016
+--
 Reporter:  teor|  Owner:  teor
 Type:  | Status:  assigned
  enhancement   |
 Priority:  Medium  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core|Version:
  Tor/Tor   |
 Severity:  Normal  |   Keywords:  fast-fix, test, appveyor, tor-ci
Actual Points:  0.1 |  Parent ID:
   Points:  0.1 |   Reviewer:
  Sponsor:  |
+--
 Appveyor provides build images with Windows Server 2012 R2 (the default)
 and Windows Server 2016. These images are called:
 * Visual Studio 2015
 * Visual Studio 2017

 https://www.appveyor.com/docs/windows-images-software/#operating-system

 Our builds work on these images:
 https://ci.appveyor.com/project/teor2345/tor/builds/20046114

 So we should probably build on both of 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] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  029-backport, review-group-22, |
  034-triage-20180328, 034-removed-20180328, |
  031-unreached-backport, 035-roadmap-subtask,   |
  035-triaged-in-20180711|
Parent ID:  #26637   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * cc: mikeperry (added)


Comment:

 If Mike wants to modify crypto_rand_double(), I could do the review.

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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 hs_get_extend_info_from_lspecs() already has good coverage:
 
https://coveralls.io/builds/19903451/source?filename=src/feature/hs/hs_common.c#L1677

 But the direct_conn line needs to be tested, because it changed in this
 branch:
 
https://coveralls.io/builds/19903451/source?filename=src/feature/hs/hs_common.c#L1740

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 The tests for fascist_firewall_choose_address_ls() look good to me.

 It looks like we still need tests for hs_get_extend_info_from_lspecs(),
 then we're done.

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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

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

 * status:  needs_revision => needs_review


Comment:

 I have added the requested changes and have pushed them. Same PR.

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

Re: [tor-bugs] #28096 [Core Tor/Tor]: Windows 8.1 and 10 relays claim to be Windows 8

[Tor Bug Tracker & Wiki]

#28096: Windows 8.1 and 10 relays claim to be Windows 8
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.34
 Severity:  Normal   | Resolution:
 Keywords:  windows, fast-fix, 029-backport, |  Actual Points:  0.2
  033-backport, 034-backport, 035-backport   |
Parent ID:   | Points:  0.2
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 Here's what I am stuck with:
 1. I want to test get_uname().
 2. I think we can test get_uname() by making the unit tests print the Tor,
 OS, and library versions when they start. (And that's a nice feature.)
 3. But I only want the Windows tests to print this log in the parent test
 process.
 4. The parent/child flag is in tinytest.c, but the tor-specific code is in
 testing_common.c. How do I get access to the parent/child flag in
 testing_common.c ?

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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 Thanks!

 I think this is good test code, but we can make the link specifier code a
 bit more reliable by using memcpy(), and setting and getting lengths. See
 the pull request comments for details.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28193 [Core Tor/Tor]: Compile-time assertion

[Tor Bug Tracker & Wiki]

#28193: Compile-time assertion
--+--
 Reporter:  riastradh |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+--

Comment (by riastradh):

 Elaborating on the unused attribute: the warning -Wunused-local-typedefs
 fires specifically for typedefs within a function body.  If you're not
 comfortable relying on typedefs within a function body to work (which may
 be an extension to C99, don't remember offhand), then you can proscribe
 the use of CTASSERT inside function bodies and omit ATTR_UNUSED.  If you
 are comfortable relying on typedefs within a function body to work, then
 you may want to keep the ATTR_UNUSED.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28113 [Core Tor/Tor]: notify systemd if shutdown will be longer than 30 seconds

[Tor Bug Tracker & Wiki]

#28113: notify systemd if shutdown will be longer than 30 seconds
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-systemd, 029-backport-maybe, |  Actual Points:
  033-backport-maybe, 034-backport-maybe, 035|
  -backport-maybe|
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => merge_ready


Comment:

 I pushed three small commits to your pull request to fix these issues:

 1. If tor's systemd TimeoutStopSec is less than the ShutdownWaitLength,
 plus the time it takes tor to shut down after its ShutdownWaitLength has
 expired, then systemd may terminate Tor abnormally. Let's explain that
 better in the changes file.

 2. Tor's systemd file in dist/ has a TimeoutSec of 30, which is too low:
 https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in
 Debian has a TimeoutStopSec of 60, which seems like a good change to
 upstream:
 
https://gitweb.torproject.org/debian/tor.git/tree/debian/systemd/tor@default.service

 3. This is a bugfix, so it should get a bugfix changes file

 See my branch ticket28113-029 for the squash and cherry-pick to 0.2.9:
 https://github.com/torproject/tor/pull/474

 This branch merges cleanly all the way to master:
 https://github.com/torproject/tor/pull/475
 (GitHub's pull requests can't do this merge, but git can.)

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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

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

 * status:  needs_revision => needs_review


Comment:

 I have added a test. The same PR
 (https://github.com/torproject/tor/pull/256) is used here.

 On my system (FreeBSD 11.2 on HP EliteBook 1040 G3), the test passes.
 There is a merge as the last commit, but this is because of a merge
 conflict in the `#include`s of `src/test/test_policy.c` and CI would not
 build without it.

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  029-backport, review-group-22, |
  034-triage-20180328, 034-removed-20180328, |
  031-unreached-backport, 035-roadmap-subtask,   |
  035-triaged-in-20180711|
Parent ID:  #26637   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * status:  assigned => needs_revision


Comment:

 Thanks for this code, I'll integrate it into crypto_rand_double(), and
 make the necessary replacements in its callers.

 This might not happen for a little while, because I have some rust code to
 write first.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28317 [Metrics/Relay Search]: Relay Search flags are vertical on Tor Browser 8.0.2 on macOS

[Tor Bug Tracker & Wiki]

#28317: Relay Search flags are vertical on Tor Browser 8.0.2 on macOS
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * Attachment "RelaySearchTorBrowser.png" added.

 Relay Search screenshot Tor Browser 8.0.2 on macOS 10.13

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28317 [Metrics/Relay Search]: Relay Search flags are vertical on Tor Browser 8.0.2 on macOS

[Tor Bug Tracker & Wiki]

#28317: Relay Search flags are vertical on Tor Browser 8.0.2 on macOS
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When I open Relay Search in Tor Browser 8.0.2 on macOS 10.13, almost all
 the relay search flags for a relay are in a narrow, vertical column.

 See the attached screenshot.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28305 [Metrics/Statistics]: Include client numbers even if we think we got reports from more than 100% of all relays

[Tor Bug Tracker & Wiki]

#28305: Include client numbers even if we think we got reports from more than 
100%
of all relays
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  SponsorV-can
+--
Changes (by teor):

 * sponsor:   => SponsorV-can


Comment:

 Replying to [comment:2 karsten]:
 > You'll find a description/specification how frac is calculate here:
 https://metrics.torproject.org/reproducible-metrics.html#relay-users
 >
 > Maybe rounding error was not the right term. In fact, I believe it might
 be a situation like the one you're describing. I can extract the variable
 values going into the frac formula; maybe one of them is responsible for
 getting us above the 100%.

 I wonder if changing the bandwidth interval to 24 hours revealed this
 issue?

 For servers which report 24 hour intervals, I think that:
 {{{
 h(R^H) is usually equal to h(H)
 n(H) is usually 24
 n(R\H) is usually 0
 n(N) can be slightly less than 24, if a relay was unreachable or
 misconfigured, but didn't go down
 Therefore, frac can be slightly more than 1.
 }}}

 > However, we should carefully consider whether we want to change that
 formula or rather not touch it until we have PrivCount as replacement. If
 we think the frac value isn't going to grow much beyond 100%, we could
 just accept that inaccuracy and live with it. If we think it's going to
 grow towards, say, 150%, I agree that we'll have to do something.

 I think a similar analysis applies to PrivCount: if a relay is up for the
 whole day, then it will report statistics using PrivCount. But if that
 relay is dropped from some consensuses due to reachability, then our idea
 of the average number of running relays will be too low.

 We won't see this bug until almost all relays are running PrivCount. But
 let's avoid re-implementing this bug in PrivCount if we can.

 What can PrivCount do to avoid introducing a similar 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] #28229 [Core Tor/Tor]: Possible race condition opening SOCKS Port in test_rebind.py

[Tor Bug Tracker & Wiki]

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

 * status:  accepted => needs_review


Comment:

 We should review and merge this patch, then leave the ticket open for
 further analysis.

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  029-backport, review-group-22, |
  034-triage-20180328, 034-removed-20180328, |
  031-unreached-backport, 035-roadmap-subtask,   |
  035-triaged-in-20180711|
Parent ID:  #26637   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-

Comment (by riastradh):

 I should add about `sample_uniform_01` vs `sample_uniform_01_open` that,
 generally, the only reason you should use `sample_uniform_01_open` is as a
 drop-in replacement for the current `crypto_rand_double` to avoid breaking
 downstream code that assumes it can't get the floating-point number 1.

 If you want to take the log of the sample without getting -infinity, for
 instance to generate an exponential sample, you want a floating-point
 number in (0, 1], not a floating-point number in [0, 1).  (Even better,
 for an exponential sample, you can use -log(p/2) if a fair coin toss turns
 up heads, and -log1p(-p/2) if it turns up tails -- then the sampler
 supports high precision negative and positive outputs; flip another coin
 to pick the sign, for a Laplace sampler.)  If for some reason you are
 tempted to compute log1p(-p) or 1/(1 - p) downstream where p is uniform in
 [0, 1), better to change what happens downstream to compute log(p) or 1/p
 where p is in (0, 1] -- log1p and 1/(1 - p) are ill-conditioned near 1, so
 it's always better to avoid relying on computations involving such
 intermediate quantities.

 The Mironov paper analyzes the use of (a) a correct uniform distribution
 like I provided (actually, sometimes he vacillates between (0,1) and (0,1]
 but I don't think it matters for the proof except maybe requiring a small
 adjustment to Eq. (7)), together with (b) a correctly rounded natural
 logarithm, and proves a differential privacy result, Theorem 1, under
 those assumptions.

 The system's libm is unlikely to have a correctly rounded log, with
 maximum 0.5ulp error, corresponding to 2^-53^ relative error, but it is
 likely to have something very close to that -- almost certainly much
 better than 1ulp or 2^-52^ relative error.  As a rough approximation, I
 think you can just take eta in Sec. 5.2 of the paper to be 2^-52^ instead
 of 2^-53^, and instead of the (1/lambda + 2^-49^B/lambda)-differential
 privacy asserted in Theorem 1, you get (1/lambda +
 2^-48^B/lambda)-differential privacy.

 P.S.  If in your Laplace sampler you use the exponential sampler I
 described above -- toss a fair coin to decide whether to use -log(p/2) or
 -log1p(-p/2), instead of the standard unconditional -log(p) -- I bet
 you'll get a slightly better differential privacy bound.  But it would
 take a bit of work to identify the better bound and prove it, and really,
 most of this is just to get confidence that the bound doesn't explode and
 is reasonably small in concrete parameters, not to prove the bestest most
 tightest bound 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] #28315 [Applications/Tor Browser]: "New Identity for this Site"

[Tor Bug Tracker & Wiki]

#28315: "New Identity for this Site"
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by arthuredelstein:

Old description:

> We have "New Circuit for this Site", but the cache and other supercookies
> for that first party are not wiped. Only the stream is changed.
>
> It should be possible to implement "New Identity for this Site", for
> example by incrementing the container ID. (Note however that containers
> are not as strict as first-party isolation, so it might be better to
> introduce a new counting mechanism into origin attributes that shares the
> same strict policy as FPI.) In that case, all supercookies would be wiped
> and a fresh circuit used.

New description:

 We have "New Circuit for this Site", but the cache and other supercookies
 for that first party are not wiped. Only the stream is changed.

 It should be possible to implement "New Identity for this Site", for
 example by incrementing the container ID. (Note however that containers
 are not as strict as first-party isolation, so it might be better to
 introduce a new counting mechanism into origin attributes that shares the
 same strict policy as FPI.) In that case, all supercookies would be wiped
 and a fresh circuit used.

 See also #28316.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28316 [Applications/Tor Browser]: New Identity per search

[Tor Bug Tracker & Wiki]

#28316: New Identity per search
--+--
 Reporter:  arthuredelstein   |  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:|
--+--
 If we are able to implemented #28315, "New Identity for this Site", it
 should also be possible to create a "new identity" for every search
 generated by the address bar (aka the "Awesome Bar"). That would help to
 reduce linking multiple searches from the same user.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28261 [Community/Translations]: Please provide the english language strings for Torbutton under "en-US" and not "en" as it is now

[Tor Bug Tracker & Wiki]

#28261: Please provide the english language strings for Torbutton under "en-US" 
and
not "en" as it is now
+--
 Reporter:  gk  |  Owner:  emmapeel
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by igt0):

 So we need to rename the  following locales:

 en -> en_US
 zh-CN -> zh_CN
 zh-HK -> zh_HK
 zh-TW -> zh_TW
 pt-BR -> pt_BR

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28116 [Metrics/Statistics]: Split up legacy module into more maintainable parts

[Tor Bug Tracker & Wiki]

#28116: Split up legacy module into more maintainable parts
+-
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by irl):

 This plan sounds good.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27867 [Applications/Tor Browser]: Gesturify 2.x does not work with Tor Browser 8

[Tor Bug Tracker & Wiki]

#27867: Gesturify 2.x does not work with Tor Browser 8
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by Thorin):

 might be dom.w3c_pointer_events.enabled=false (sorry, I don't have a TBB8*
 handy to check the default value) - see
 https://github.com/Robbendebiene/Gesturefy/issues/271#issuecomment-376139960

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28193 [Core Tor/Tor]: Compile-time assertion

[Tor Bug Tracker & Wiki]

#28193: Compile-time assertion
--+--
 Reporter:  riastradh |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+--

Comment (by riastradh):

 1. I don't think there's any situation in which you need to pass arguments
 through to another macro with extra parentheses around them unless the
 downstream macro fails to parenthesize some expression itself.  x can't
 have commas except within balanced parentheses in CTASSERT, so it can't be
 confused for two macro arguments when expanding into CTASSERT_EXPN.
 CTASSERT_EXPN, in turn, via CTASSERT_DECL, will parenthesize x in the end.

It won't hurt, so if you want to be paranoid (which is understandable
 among the sharp edges of the C preprocessor) you can add the parentheses,
 but there's no need.

 2. GCC 4.8 enabled -Wunused-local-typedefs in -Wall by default.  If you
 don't subscribe to this warning option, then ATTR_UNUSED is not necessary.
 Even if it turned out to be necessary in some scenario, the only adverse
 effects of failing to have it will be that the compiler yells at you, so
 if you want to remove it, be my guest.

 3. I put the copying notice on so there would be no questions about
 whether it is available under a licence acceptable for Tor without having
 to go through the rigmarole of signing a CLA to hand it over to the Tor
 Project, Inc., in case you happen to have such a process.

You are welcome to use this code under the standard Tor 3-clause BSD
 licence.  Can also just substitute 'The NetBSD Foundation, Inc.' for my
 name if that would be less complicated, since you already have the same
 licence text and same copyright holder in the top-level LICENSE file.  I
 don't have a preference -- I just want to minimize hassle for everyone
 around.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28315 [Applications/Tor Browser]: "New Identity for this Site"

[Tor Bug Tracker & Wiki]

#28315: "New Identity for this Site"
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 If it's possible to build this, I think we should consider (from a ux
 perspective) getting rid of the 'new circuit for this site' option and
 just offering the 'new identity for this site' option. But there sure is a
 lot of per-site state to discard -- but being able to isolate it enough
 that we can discard it per-site would be awesome!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28315 [Applications/Tor Browser]: "New Identity for this Site"

[Tor Bug Tracker & Wiki]

#28315: "New Identity for this Site"
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by arthuredelstein:

Old description:

> We have "New Circuit for this Site", but the cache and other supercookies
> for that first party are not wiped. One the stream is changed.
>
> It should be possible to implement "New Identity for this Site", for
> example by incrementing the container ID. (Note however that containers
> are not as strict as first-party isolation, so it might be better to
> introduce a new counting mechanism into origin attributes that shares the
> same strict policy as FPI.) In that case, all supercookie would be wiped
> and a fresh circuit used.
>
> (Sorry if this is a duplicate. I thought there might be a ticket already
> but I couldn't find one.)

New description:

 We have "New Circuit for this Site", but the cache and other supercookies
 for that first party are not wiped. Only the stream is changed.

 It should be possible to implement "New Identity for this Site", for
 example by incrementing the container ID. (Note however that containers
 are not as strict as first-party isolation, so it might be better to
 introduce a new counting mechanism into origin attributes that shares the
 same strict policy as FPI.) In that case, all supercookie would be wiped
 and a fresh circuit used.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28315 [Applications/Tor Browser]: "New Identity for this Site"

[Tor Bug Tracker & Wiki]

#28315: "New Identity for this Site"
--+--
 Reporter:  arthuredelstein   |  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:|
--+--
 We have "New Circuit for this Site", but the cache and other supercookies
 for that first party are not wiped. One the stream is changed.

 It should be possible to implement "New Identity for this Site", for
 example by incrementing the container ID. (Note however that containers
 are not as strict as first-party isolation, so it might be better to
 introduce a new counting mechanism into origin attributes that shares the
 same strict policy as FPI.) In that case, all supercookie would be wiped
 and a fresh circuit used.

 (Sorry if this is a duplicate. I thought there might be a ticket already
 but I couldn't find one.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28315 [Applications/Tor Browser]: "New Identity for this Site"

[Tor Bug Tracker & Wiki]

#28315: "New Identity for this Site"
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by arthuredelstein:

Old description:

> We have "New Circuit for this Site", but the cache and other supercookies
> for that first party are not wiped. Only the stream is changed.
>
> It should be possible to implement "New Identity for this Site", for
> example by incrementing the container ID. (Note however that containers
> are not as strict as first-party isolation, so it might be better to
> introduce a new counting mechanism into origin attributes that shares the
> same strict policy as FPI.) In that case, all supercookie would be wiped
> and a fresh circuit used.

New description:

 We have "New Circuit for this Site", but the cache and other supercookies
 for that first party are not wiped. Only the stream is changed.

 It should be possible to implement "New Identity for this Site", for
 example by incrementing the container ID. (Note however that containers
 are not as strict as first-party isolation, so it might be better to
 introduce a new counting mechanism into origin attributes that shares the
 same strict policy as FPI.) In that case, all supercookies would be wiped
 and a fresh circuit used.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28291 [Obfuscation/Obfsproxy]: Please remove two offline bridges

[Tor Bug Tracker & Wiki]

#28291: Please remove two offline bridges
---+---
 Reporter:  traumschule|  Owner:  asn
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by arma):

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


Comment:

 I asked traumschule where these bridges came from, and I think they came
 from moat. That is, they don't seem to be built-in bridges (i.e. the ones
 you can see in about:config).

 So I don't think there's anything to be done here. I'm going to close the
 ticket. In theory the bridge auth should decide that they're not Running,
 and stop telling bridgedb that they're Running, and bridgedb will stop
 giving them out. If we can discover any evidence that that chain was
 broken here, we should file a new ticket and fix that, but in the mean
 time it is not weird that bridgedb is sometimes giving out bridges that
 turn out to be down by the time the user gets 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] #28305 [Metrics/Statistics]: Include client numbers even if we think we got reports from more than 100% of all relays

[Tor Bug Tracker & Wiki]

#28305: Include client numbers even if we think we got reports from more than 
100%
of all relays
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 You'll find a description/specification how frac is calculate here:
 https://metrics.torproject.org/reproducible-metrics.html#relay-users

 Maybe rounding error was not the right term. In fact, I believe it might
 be a situation like the one you're describing. I can extract the variable
 values going into the frac formula; maybe one of them is responsible for
 getting us above the 100%.

 However, we should carefully consider whether we want to change that
 formula or rather not touch it until we have PrivCount as replacement. If
 we think the frac value isn't going to grow much beyond 100%, we could
 just accept that inaccuracy and live with it. If we think it's going to
 grow towards, say, 150%, I agree that we'll have to do something.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28116 [Metrics/Statistics]: Split up legacy module into more maintainable parts

[Tor Bug Tracker & Wiki]

#28116: Split up legacy module into more maintainable parts
+-
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by karsten):

 Replying to [comment:2 irl]:
 > This looks good to me.

 Awesome! I'll start deploying changes over the next days. That will take a
 while, though.

 > We might want to consider renaming the not-very-IPv6-specific-anymore
 module.

 Agreed. I'd like to rename it to just servers. But we still have a servers
 module which is just another name for the legacy module. Confusing, right?

 My plan is to:
  1. merge/deploy these changes,
  2. remove then unused code from the legacy module,
  3. rename the legacy module to bandwidth, because it's only remaining
 purpose will be to produce our bandwidth history statistics, and
  4. rename the ipv6servers module to servers.

 Anyway, doing step 1 first. Keeping this ticket open until that's the
 case, and then creating tickets for the next steps.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28254 [Metrics/Onionoo]: Update to GeoLite2 ASN database format

[Tor Bug Tracker & Wiki]

#28254: Update to GeoLite2 ASN database format
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 Great. Thanks for looking! We should talk about putting out a new release
 soon. Adding to my list. Closing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28254 [Metrics/Onionoo]: Update to GeoLite2 ASN database format

[Tor Bug Tracker & Wiki]

#28254: Update to GeoLite2 ASN database format
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 This looks good to me.

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

Re: [tor-bugs] #28116 [Metrics/Statistics]: Split up legacy module into more maintainable parts

[Tor Bug Tracker & Wiki]

#28116: Split up legacy module into more maintainable parts
+-
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 This looks good to me.

 We might want to consider renaming the not-very-IPv6-specific-anymore
 module.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28314 [Metrics/Relay Search]: Alleged Family Members never disappear

[Tor Bug Tracker & Wiki]

#28314: Alleged Family Members never disappear
--+--
 Reporter:  Quake |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Quake):

 Double checked to confirm that I have nothing set on MyFamily. The poster
 on tor-relays says the same.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28314 [Metrics/Relay Search]: Alleged Family Members never disappear

[Tor Bug Tracker & Wiki]

#28314: Alleged Family Members never disappear
+--
 Reporter:  Quake   |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Metrics/Relay Search
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 I've noticed that Alleged Family Members on metrics seemingly never
 disappear.

 Reported on Tor-relays: https://lists.torproject.org/pipermail/tor-
 relays/2018-November/016558.html

 I also have the same issue:
 
https://metrics.torproject.org/rs.html#details/490FB3FAAF8837407D94CA7E1DEF025DEF0F3516

 My other relay has been offline for months (since July 2018) and it still
 displays as a family member.

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

Re: [tor-bugs] #28229 [Core Tor/Tor]: Possible race condition opening SOCKS Port in test_rebind.py

[Tor Bug Tracker & Wiki]

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

Comment (by rl1987):

 Patch for diagnostics: https://github.com/torproject/tor/pull/473

 This should help with digging up the root cause of the failure, if it
 happens again.

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

Re: [tor-bugs] #28303 [Core Tor/Tor]: Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build

[Tor Bug Tracker & Wiki]

#28303: Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build
--+--
 Reporter:  kjak  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  openbsd   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by kjak):

 * status:  new => needs_review


Comment:

 I'm updating the status of this ticket to `needs_review` since there is a
 PR to fix the problem.  (Please correct me if I'm wrong 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

[tor-bugs] #28313 [- Select a component]: Trouble Connecting to Tor browser

[Tor Bug Tracker & Wiki]

#28313: Trouble Connecting to Tor browser
--+--
 Reporter:  coolnoob  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  - Select a component
  Version:|   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Hello, I'm having trouble Connecting to Tor browser. I thought it was a
 bit size promblem but was not. I downloaded 32 bit size nothing happened.
 Also 64 bit size and nothing happened. My computer is by the way 64 bit. I
 haven't downloaded Tor bundle but it might not be the promblem. I tried
 all this at night so times of clock might be wrong idk. The error is:
 failed to establish a connection. (Failed to connect host) and some
 numbers but I forgot what they were.



 Please Help

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28096 [Core Tor/Tor]: Windows 8.1 and 10 relays claim to be Windows 8

[Tor Bug Tracker & Wiki]

#28096: Windows 8.1 and 10 relays claim to be Windows 8
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.34
 Severity:  Normal   | Resolution:
 Keywords:  windows, fast-fix, 029-backport, |  Actual Points:  0.2
  033-backport, 034-backport, 035-backport   |
Parent ID:   | Points:  0.2
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 I added the missing Windows server versions, made the "or later" text
 automatic, and deleted some unreachable code.

 The patch is bigger than I'd like to backport, but we can't report the
 correct Windows version without it. If you'd like, I can reduce the size
 of the patch by adding the unreachable pre-Windows 2000 code back in.

 Here are the branches and pull requests:

 My bug28096-029 merges cleanly from maint-0.2.9 to maint-0.3.4.
 https://github.com/torproject/tor/pull/429

 My bug28096-035 merges cleanly from maint-0.3.5 to master.
 https://github.com/torproject/tor/pull/430

 I implemented #28308 in bug28096-ticket28308-035:
 https://github.com/torproject/tor/pull/472

 Since it just has test changes and refactoring, we can merge
 bug28096-ticket28308-035 to 0.3.5 or master.

 There's still one TODO: I don't know how to just log in the main Windows
 test process. I'm going to ask nickm how to do that.

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

Re: [tor-bugs] #28312 [Core Tor/Tor]: Tor exits when configuring a PidFile containing ~

[Tor Bug Tracker & Wiki]

#28312: Tor exits when configuring a PidFile containing ~
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * status:  reopened => closed
 * resolution:   => duplicate
 * parent:  #28298 =>


Comment:

 Replying to [comment:5 teor]:
 > Let's deal with these issues, then.

 I'm going to re-close this ticket as a duplicate of #27708, and we can do
 the above "use expand_filename more consistently" work in #28311.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28298 [Core Tor/Tor]: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory

[Tor Bug Tracker & Wiki]

#28298: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative
DataDirectory
--+--
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:6 teor]:
 > "~" expansion is a missing feature, not a bug. Your shell does it, many
 other contexts do not. See #28311.

 It is true that we don't call expand_filename() consistently on other
 config options. #28311 is a great ticket for tracking that (orthogonal)
 issue.

 > But you've found another bug in Tor's config handling. On my machine, it
 results in a crash and a spurious call to free(). See #28312.

 Turns out that ticket is a duplicate of #27708.

 So I think we resume being good to review/merge this fix. And we could
 still want somebody to add unit tests if they want.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28311 [Core Tor/Tor]: Call expand_filename (e.g. for ~ expansion) on all FILENAME config options (was: Do ~ expansion on tor's configured paths)

[Tor Bug Tracker & Wiki]

#28311: Call expand_filename (e.g. for ~ expansion) on all FILENAME config 
options
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * parent:  #28298 =>


Comment:

 (removing #28298 as a parent, since this ticket is about a further
 improvement, and that ticket is about a regression)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28312 [Core Tor/Tor]: Tor exits when configuring a PidFile containing ~ (was: Crash when configuring a PidFile containing ~)

[Tor Bug Tracker & Wiki]

#28312: Tor exits when configuring a PidFile containing ~
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #28298| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  closed => reopened
 * priority:  High => Medium
 * milestone:  Tor: 0.3.5.x-final => Tor: unspecified
 * keywords:  memory-safety, regression, security-low =>
 * resolution:  duplicate =>


Old description:

> The patch in #28298 may avoids the "~" bug in DataDirectory, but adding ~
> to many other configured path crashes tor:
> {{{
> tor DisableNetwork 1 PidFile "~/.torpid"
> }}}
> with this error:
> {{{
> Nov 04 15:35:10.740 [notice] Tor 0.3.4.8 (git-da95b91355248ad8) running
> on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11,
> Liblzma N/A, and Libzstd N/A.
> ...
> Nov 04 15:35:10.744 [warn] Path for PidFile (~/.torpid) is relative and
> will resolve to /Users/base/~/.torpid. Is this what you wanted?
> ...
> Nov 04 15:35:10.000 [warn] Unable to open "~/.torpid" for writing: No
> such file or directory
> Nov 04 15:35:10.000 [err] Unable to write PIDFile "~/.torpid"
> Nov 04 15:35:10.000 [err] set_options: Bug: Acting on config options left
> us in a broken state. Dying. (on Tor 0.3.4.8 da95b91355248ad8)
> Nov 04 15:35:10.000 [err] Reading config failed--see warnings above.
> tor(79983,0x7fffa9c06380) malloc: *** error for object 0x7: pointer being
> freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> Abort trap: 6
> Exit 134
> }}}

New description:

 The patch in #28298 may avoids the "~" bug in DataDirectory, but adding ~
 to many other configured path makes tor exit:
 {{{
 tor DisableNetwork 1 PidFile "~/.torpid"
 }}}
 with this error:
 {{{
 Nov 05 00:07:29.465 [notice] Tor 0.3.4.9 (git-4ac3ccf2863b86e7) running on
 Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11, Liblzma
 5.2.4, and Libzstd 1.3.7.
 Nov 05 00:07:29.466 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Nov 05 00:07:29.467 [notice] Configuration file "/usr/local/etc/tor/torrc"
 not present, using reasonable defaults.
 Nov 05 00:07:29.473 [warn] Path for PidFile (~/.torpid) is relative and
 will resolve to /Users/base/tor-034/build-c/~/.torpid. Is this what you
 wanted?
 Nov 05 00:07:29.475 [notice] Scheduler type KISTLite has been enabled.
 Nov 05 00:07:29.475 [notice] Opening Socks listener on 127.0.0.1:9050
 Nov 05 00:07:29.000 [warn] Unable to open "~/.torpid" for writing: No such
 file or directory
 Nov 05 00:07:29.000 [err] Unable to write PIDFile "~/.torpid"
 Nov 05 00:07:29.000 [err] set_options: Bug: Acting on config options left
 us in a broken state. Dying. (on Tor 0.3.4.9 4ac3ccf2863b86e7)
 Nov 05 00:07:29.000 [err] Reading config failed--see warnings above.
 }}}

--

Comment:

 Replying to [comment:1 arma]:
 > First issue is that our PidFile handling never calls expand_filename().
 If we want it to, we could fix that. We probably should.
 >
 > Also, this might be a good time to wonder if there is a better way to
 call expand_filename more uniformly on config options that should expect
 it. Maybe want a new config type FILENAME, rather than the current
 ambiguous choice STRING ? Oh wait, we *have* one of those already, e.g.
 DirPortFrontPage is one. So the bug here is that PidFile is a STRING not a
 FILENAME? And the second bug is that we don't uniformly run
 expand_filename() on config options of type FILENAME?

 Let's deal with these issues, 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] #28312 [Core Tor/Tor]: Crash when configuring a PidFile containing ~

[Tor Bug Tracker & Wiki]

#28312: Crash when configuring a PidFile containing ~
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  memory-safety, regression,   |  duplicate
  security-low   |  Actual Points:
Parent ID:  #28298   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 Ah, that's #27708.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28312 [Core Tor/Tor]: Crash when configuring a PidFile containing ~

[Tor Bug Tracker & Wiki]

#28312: Crash when configuring a PidFile containing ~
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  memory-safety, regression,   |  Actual Points:
  security-low   |
Parent ID:  #28298   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 It is reproducible, here's the AddressSanitizer output:
 {{{
 Nov 05 00:02:49.018 [notice] Tor 0.3.4.8 (git-da95b91355248ad8) running on
 Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11, Liblzma
 5.2.4, and Libzstd 1.3.7.
 ...
 =
 ==3252==ERROR: AddressSanitizer: heap-use-after-free on address
 0x61d03d48 at pc 0x00010cfc9888 bp 0x7ffee2d27350 sp 0x7ffee2d27348
 READ of size 8 at 0x61d03d48 thread T0
 #0 0x10cfc9887 in or_options_free_ config.c:968
 #1 0x10cfc9ac7 in config_free_all config.c:997
 #2 0x10d1f9195 in tor_free_all main.c:3677
 #3 0x10d1f9a54 in tor_run_main main.c:4258
 #4 0x10d3c5e20 in tor_main tor_api.c:84
 #5 0x10ced8efa in main tor_main.c:32
 #6 0x7fff710f6014 in start (libdyld.dylib:x86_64+0x1014)

 0x61d03d48 is located 200 bytes inside of 2256-byte region
 [0x61d03c80,0x61d04550)
 freed by thread T0 here:
 #0 0x10e27410d in wrap_free
 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5710d)
 #1 0x10cfe7a16 in options_init_from_string config.c:5534
 #2 0x10cfe5b83 in options_init_from_torrc config.c:5280
 #3 0x10d1f88ff in tor_init main.c:3524
 #4 0x10d1f9a45 in tor_run_main main.c:4256
 #5 0x10d3c5e20 in tor_main tor_api.c:84
 #6 0x10ced8efa in main tor_main.c:32
 #7 0x7fff710f6014 in start (libdyld.dylib:x86_64+0x1014)

 previously allocated by thread T0 here:
 #0 0x10e273f53 in wrap_malloc
 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x56f53)
 #1 0x10d46b469 in tor_malloc_ util.c:150
 #2 0x10d46b520 in tor_malloc_zero_ util.c:178
 #3 0x10cfe6c8e in options_init_from_string config.c:5383
 #4 0x10cfe5b83 in options_init_from_torrc config.c:5280
 #5 0x10d1f88ff in tor_init main.c:3524
 #6 0x10d1f9a45 in tor_run_main main.c:4256
 #7 0x10d3c5e20 in tor_main tor_api.c:84
 #8 0x10ced8efa in main tor_main.c:32
 #9 0x7fff710f6014 in start (libdyld.dylib:x86_64+0x1014)

 SUMMARY: AddressSanitizer: heap-use-after-free config.c:968 in
 or_options_free_
 Shadow bytes around the buggy address:
   0x1c3a0750: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
   0x1c3a0760: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
   0x1c3a0770: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
   0x1c3a0780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
   0x1c3a0790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
 =>0x1c3a07a0: fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd
   0x1c3a07b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
   0x1c3a07c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
   0x1c3a07d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
   0x1c3a07e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
   0x1c3a07f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
 Shadow byte legend (one shadow byte represents 8 application bytes):
   Addressable:   00
   Partially addressable: 01 02 03 04 05 06 07
   Heap left redzone:   fa
   Freed heap region:   fd
   Stack left redzone:  f1
   Stack mid redzone:   f2
   Stack right redzone: f3
   Stack after return:  f5
   Stack use after scope:   f8
   Global redzone:  f9
   Global init order:   f6
   Poisoned by user:f7
   Container overflow:  fc
   Array cookie:ac
   Intra object redzone:bb
   ASan internal:   fe
   Left alloca redzone: ca
   Right alloca redzone:cb
 ==3252==ABORTING
 Abort trap: 6
 Exit 134
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28312 [Core Tor/Tor]: Crash when configuring a PidFile containing ~

[Tor Bug Tracker & Wiki]

#28312: Crash when configuring a PidFile containing ~
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  memory-safety, regression,   |  Actual Points:
  security-low   |
Parent ID:  #28298   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [ticket:28312 teor]:
 {{{
 > tor(79983,0x7fffa9c06380) malloc: *** error for object 0x7: pointer
 being freed was not allocated
 > *** set a breakpoint in malloc_error_break to debug
 > Abort trap: 6
 > Exit 134
 }}}

 I can't reproduce this part. Are you sure you did a clean build? Is there
 something wrong with your osx? (Also, you're on 0.3.4.8, when there's an
 0.3.4.9 out.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28311 [Core Tor/Tor]: Do ~ expansion on tor's configured paths

[Tor Bug Tracker & Wiki]

#28311: Do ~ expansion on tor's configured paths
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #28298| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 I think we need to:

 (A) as you say, document in the two *path* functions that they expect
 expand_filename has already been called as needed.

 (B) actually call expand_filename on all config options of type FILENAME,
 at the appropriate time (and figure out what that is)

 (C) change some things from STRING to FILENAME so they will benefit from
 step b. PidFile is one such thing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28312 [Core Tor/Tor]: Crash when configuring a PidFile containing ~

[Tor Bug Tracker & Wiki]

#28312: Crash when configuring a PidFile containing ~
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  memory-safety, regression,   |  Actual Points:
  security-low   |
Parent ID:  #28298   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 First issue is that our PidFile handling never calls expand_filename(). If
 we want it to, we could fix that. We probably should.

 Also, this might be a good time to wonder if there is a better way to call
 expand_filename more uniformly on config options that should expect it.
 Maybe want a new config type FILENAME, rather than the current ambiguous
 choice STRING ? Oh wait, we *have* one of those already, e.g.
 DirPortFrontPage is one. So the bug here is that PidFile is a STRING not a
 FILENAME? And the second bug is that we don't uniformly run
 expand_filename() on config options of type FILENAME?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28311 [Core Tor/Tor]: Do ~ expansion on tor's configured paths

[Tor Bug Tracker & Wiki]

#28311: Do ~ expansion on tor's configured paths
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #28298| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 But `PidFile ~/.torpid` does not work, see #28311.

 And path_is_relative() or make_path_absolute() don't handle "~".

 At the very least, these functions should document their expectation that
 expand_filename() has been run on the path before they see 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] #28311 [Core Tor/Tor]: Do ~ expansion on tor's configured paths

[Tor Bug Tracker & Wiki]

#28311: Do ~ expansion on tor's configured paths
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #28298| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 For example, set a torrc file with
 {{{
 RunAsDaemon 1
 DataDirectory ~/.test
 }}}
 and it should work as expected (even with the #28298 fix).

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

Re: [tor-bugs] #28311 [Core Tor/Tor]: Do ~ expansion on tor's configured paths

[Tor Bug Tracker & Wiki]

#28311: Do ~ expansion on tor's configured paths
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #28298| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 No, ~ is supposed to be supported. See expand_filename() -- it handles
 both ~/ and ~arma/.

 So I think this ticket is already done.

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

Re: [tor-bugs] #21377 [Core Tor/Tor]: DirAuths should expose bwauth bandwidth files

[Tor Bug Tracker & Wiki]

#21377: DirAuths should expose bwauth bandwidth files
-+-
 Reporter:  tom  |  Owner:  juga
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, metrics, tor-bwauth,|  Actual Points:
  035-removed-20180711, 036-roadmap-proposed |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 All the CI on this branch failed.

 juga, I'm not sure if you get emails from appveyor or travis when builds
 fail? Or if you're in the #tor-ci channel?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28298 [Core Tor/Tor]: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory

[Tor Bug Tracker & Wiki]

#28298: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative
DataDirectory
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_revision


Comment:

 Replying to [comment:4 arma]:
 > Ok, that above fix is bad, because it will complain when you set
 DataDirectory to e.g. {{{~/.test}}} -- which is actually an absolute path,
 even if it doesn't start with {{{/}}}.

 "~" expansion is a missing feature, not a bug. Your shell does it, many
 other contexts do not. See #28311.

 But you've found another bug in Tor's config handling. On my machine, it
 results in a crash and a spurious call to free(). See #28312.

 Replying to [comment:5 arma]:
 > My {{{bug28298}}} branch has this better fix.
 >
 > But it still lacks unit test improvements. Maybe somebody wants to add
 those?

 Maybe if we fixed #28312, your original solution would work?

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

Re: [tor-bugs] #28298 [Core Tor/Tor]: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory

[Tor Bug Tracker & Wiki]

#28298: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative
DataDirectory
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 (We don't have a status for "needs more code and more investigation".
 Maybe "needs_information"?)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28312 [Core Tor/Tor]: Crash when configuring a PidFile containing ~

[Tor Bug Tracker & Wiki]

#28312: Crash when configuring a PidFile containing ~
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:  Tor: 0.3.2.1-alpha
  Tor/Tor|   Keywords:  memory-safety, regression,
 Severity:  Normal   |  security-low
Actual Points:   |  Parent ID:  #28298
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The patch in #28298 may avoids the "~" bug in DataDirectory, but adding ~
 to many other configured path crashes tor:
 {{{
 tor DisableNetwork 1 PidFile "~/.torpid"
 }}}
 with this error:
 {{{
 Nov 04 15:35:10.740 [notice] Tor 0.3.4.8 (git-da95b91355248ad8) running on
 Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11, Liblzma
 N/A, and Libzstd N/A.
 ...
 Nov 04 15:35:10.744 [warn] Path for PidFile (~/.torpid) is relative and
 will resolve to /Users/base/~/.torpid. Is this what you wanted?
 ...
 Nov 04 15:35:10.000 [warn] Unable to open "~/.torpid" for writing: No such
 file or directory
 Nov 04 15:35:10.000 [err] Unable to write PIDFile "~/.torpid"
 Nov 04 15:35:10.000 [err] set_options: Bug: Acting on config options left
 us in a broken state. Dying. (on Tor 0.3.4.8 da95b91355248ad8)
 Nov 04 15:35:10.000 [err] Reading config failed--see warnings above.
 tor(79983,0x7fffa9c06380) malloc: *** error for object 0x7: pointer being
 freed was not allocated
 *** set a breakpoint in malloc_error_break to debug
 Abort trap: 6
 Exit 134
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28311 [Core Tor/Tor]: Do ~ expansion on tor's configured paths

[Tor Bug Tracker & Wiki]

#28311: Do ~ expansion on tor's configured paths
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #28298
   Points:|   Reviewer:
  Sponsor:|
--+--
 Split off #28298:

 Replying to [comment:4 arma]:
 > Ok, that above fix is bad, because it will complain when you set
 DataDirectory to e.g. {{{~/.test}}} -- which is actually an absolute path,
 even if it doesn't start with {{{/}}}.

 "~" expansion is not universal: it only works in some shells, some
 languages, and some applications.

 In particular, "~" expansion is not a documented feature of
 path_is_relative() or make_path_absolute(). We can add it as a feature if
 you want.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28298 [Core Tor/Tor]: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory

[Tor Bug Tracker & Wiki]

#28298: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative
DataDirectory
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 My {{{bug28298}}} branch has this better fix.

 But it still lacks unit test improvements. Maybe somebody wants to add
 those?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28298 [Core Tor/Tor]: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory

[Tor Bug Tracker & Wiki]

#28298: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative
DataDirectory
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Ok, that above fix is bad, because it will complain when you set
 DataDirectory to e.g. {{{~/.test}}} -- which is actually an absolute path,
 even if it doesn't start with {{{/}}}.

 So I now think the "validate_data_directories() earlier" option is the
 best plan.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28096 [Core Tor/Tor]: Windows 8.1 and 10 relays claim to be Windows 8

[Tor Bug Tracker & Wiki]

#28096: Windows 8.1 and 10 relays claim to be Windows 8
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.34
 Severity:  Normal   | Resolution:
 Keywords:  windows, fast-fix, 029-backport, |  Actual Points:  0.2
  033-backport, 034-backport, 035-backport   |
Parent ID:   | Points:  0.2
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 With this code, Appveyor is reporting "Windows 8.1 or later":
 
https://ci.appveyor.com/project/teor2345/tor/builds/20035097/job/6ih2pqwfrf10mtk8#L2741

 But the actual version is "Windows Server 2012 R2":
 https://www.appveyor.com/docs/windows-images-software/#operating-system

 Also, the log message is shown every time the unit tests "fork" on
 Windows.

 Looks like I'll need to revise this patch.

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

Re: [tor-bugs] #28310 [Applications/Tor Browser]: Nightly builds of obfs4 are failing

[Tor Bug Tracker & Wiki]

#28310: Nightly builds of obfs4 are failing
---+--
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201811, tbb-rbm  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by yawning):

 Either update the deterministic build system to leverage Go 1.11's module
 versioning support, or delete the `go.mod` and `go.sum` files at build
 time.

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

[tor-bugs] #28310 [Applications/Tor Browser]: Nightly builds of obfs4 are failing

[Tor Bug Tracker & Wiki]

#28310: Nightly builds of obfs4 are failing
-+-
 Reporter:  boklm|  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  TorBrowserTeam201811,
 Severity:  Normal   |  tbb-rbm
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Nightly builds of obfs4 fail with the following error:
 {{{
 Starting build: Sun Nov  4 02:09:59 2018
 go: missing Git command. See https://golang.org/s/gogetcmd
 go: missing Git command. See https://golang.org/s/gogetcmd
 go: missing Git command. See https://golang.org/s/gogetcmd
 go: git.torproject.org/pluggable-
 transports/goptlib.git@v0.0.0-20180321061416-7d56ec4f381e: git init --bare
 in
 
/var/tmp/dist/gopath/pkg/mod/cache/vcs/a1643565e160bd0cf0e6283c6f3360d36ea15fa020f44619773cc82b775dfd2f:
 exec: "git": executable file not found in $PATH
 go: github.com/agl/ed25519@v0.0.0-20170116200512-5312a6153412: git init
 --bare in
 
/var/tmp/dist/gopath/pkg/mod/cache/vcs/0b82478dc41eb662b31914d0f711acabb12bf913cb746feb99c21463b792f537:
 exec: "git": executable file not found in $PATH
 go: github.com/dchest/siphash@v1.2.0: git init --bare in
 
/var/tmp/dist/gopath/pkg/mod/cache/vcs/7839629564df366d975b0413e853645690a1d25430b2a0077d2615a05e23ad7d:
 exec: "git": executable file not found in $PATH
 go: golang.org/x/net@v0.0.0-20181011144130-49bb7cea24b1: unrecognized
 import path "golang.org/x/net" (https fetch: Get https://golang.org/x/net
 ?go-get=1: x509: certificate signed by unknown authority)
 go: golang.org/x/crypto@v0.0.0-20181015023909-0c41d7ab0a0e: unrecognized
 import path "golang.org/x/crypto" (https fetch: Get
 https://golang.org/x/crypto?go-get=1: x509: certificate signed by unknown
 authority)
 go: error loading module requirements
 }}}

 This seems related to obfs4 commit
 `08f4d470188e9dad8658f2d2107880d8fdf326be`:
 https://gitweb.torproject.org/pluggable-
 transports/obfs4.git/commit/?id=08f4d470188e9dad8658f2d2107880d8fdf326be

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