[tor-bugs] #22701 [Core Tor/Tor]: Missing makefile dependencies make parallel builds fail

[Tor Bug Tracker & Wiki]

#22701: Missing makefile dependencies make parallel builds fail
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.8
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 I think we're missing some dependencies in the src/ext/ed25519/ref10
 makefile on Tor 0.3.0.8. I bet it still exists in 0.3.1.

 I repeated the same make command, and it worked fine, because the files
 were there.

 I'm hoping someone else knows how to fix it:
 {{{
 $ make -j8 all check
 make  all-am
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_0.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_1.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_add.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_cmov.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_copy.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_frombytes.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_invert.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_isnegative.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_isnonzero.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_mul.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_neg.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_pow22523.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_sq.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_sq2.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_sub.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_tobytes.o
 make[1]: Entering directory '/home/privcount/tor-privcount'
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_mul.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_add.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_double_scalarmult.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_frombytes.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_madd.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_msub.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p1p1_to_p2.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p1p1_to_p3.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p2_0.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 fe_pow22523.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_double_scalarmult.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p2_dbl.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p3_0.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p1p1_to_p2.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p2_0.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p3_dbl.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p2_dbl.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p3_to_cached.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p3_to_p2.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p3_tobytes.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p3_0.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p3_dbl.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_precomp_0.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_scalarmult_base.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_sub.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_tobytes.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_p3_to_cached.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_scalarmult_base.o
   CC   src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-
 ge_sub.o
   CC   

Re: [tor-bugs] #22653 [Core Tor/Tor]: upgrading Tor-0.2.9.10 to Tor-0.3.0.8 or Tor-0.3.1.3_alpha fails to build circuits

[Tor Bug Tracker & Wiki]

#22653: upgrading Tor-0.2.9.10 to Tor-0.3.0.8 or Tor-0.3.1.3_alpha fails to 
build
circuits
-+-
 Reporter:  t0r  |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.8
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard tor-bridge obfs4proxy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by t0r):

 Any help?

 Maybe we are too busy to handle this issue. I will first downgraded to
 Tor-0.2.9.10

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

Re: [tor-bugs] #22515 [Obfuscation/meek]: Check meek TLS fingerprint on ESR 52

[Tor Bug Tracker & Wiki]

#22515: Check meek TLS fingerprint on ESR 52
--+
 Reporter:  dcf   |  Owner:  dcf
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

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


Comment:

 I checked and the fingerprint looks good. I tried Firefox 52.2.0esr and
 Tor Browser 7.0.1 on Windows 7 and Debian 9, and the fingerprint was the
 same in all four cases.

  *
 
[[doc/meek/SampleClientHellos#TorBrowser7.0.1basedonFirefox52.2.0esronWindows72017-06-22]]
  * [[doc/meek/SampleClientHellos#Firefox52.2.0esronWindows72017-06-22]]
  *
 
[[doc/meek/SampleClientHellos#TorBrowser7.0.1basedonFirefox52.2.0esronDebianstretch2017-06-22]]
  *
 [[doc/meek/SampleClientHellos#Firefox52.2.0esronDebianstretch2017-06-22]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22700 [Core Tor/Tor]: Stop relays using the Client*IPv6* options

[Tor Bug Tracker & Wiki]

#22700: Stop relays using the Client*IPv6* options
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy, tor-options, tor-relay
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+--
 Some operators add all the IPv6 options to their torrcs.
 We should warn when they add client options on relays.

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

Re: [tor-bugs] #18082 [Core Tor/Tor]: Log separate HS extra-info stats for Single Onion Services

[Tor Bug Tracker & Wiki]

#18082: Log separate HS extra-info stats for Single Onion Services
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, sos, tor-hs statistics |  Actual Points:
  privcount-maybe|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I'm tracking this in these PrivCount tickets:
 Intro Service: https://github.com/privcount/privcount/issues/342
 Intro Client: https://github.com/privcount/privcount/issues/343
 Rend: https://github.com/privcount/privcount/issues/344

 Note that any Tor2web stats on relays would be biased by
 Tor2webRendezvousPoints.

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

Re: [tor-bugs] #18082 [Core Tor/Tor]: Log separate HS extra-info stats for Single Onion Services

[Tor Bug Tracker & Wiki]

#18082: Log separate HS extra-info stats for Single Onion Services
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, sos, tor-hs statistics |  Actual Points:
  privcount-maybe|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 If we were going to do this, we should measure the client side as well, so
 we can track Tor2web usage.

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

Re: [tor-bugs] #18082 [Core Tor/Tor]: Log separate HS extra-info stats for Single Onion Services (was: Log separate HS extra-info stats for RSOS (and SOS))

[Tor Bug Tracker & Wiki]

#18082: Log separate HS extra-info stats for Single Onion Services
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, sos, tor-hs statistics |  Actual Points:
  privcount-maybe|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 PrivCount only runs on relays.
 A relay could guess it was connected to a single onion service by working
 out it was an intro or rend point directly connected to a client.

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

Re: [tor-bugs] #17808 [Core Tor/Tor]: Tor doesn't produce a backtrace on gcc x86_64 on macOS (was: Tor 0.2.7.6 doesn't produce a backtrace on gcc 4.9.3 on OS X 10.11.2)

[Tor Bug Tracker & Wiki]

#17808: Tor doesn't produce a backtrace on gcc x86_64 on macOS
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.6
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-relay backtrace   |  Actual Points:
  needs-analysis |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  tor-client tor-relay backtrace needs-analysis old-system =>
 tor-client tor-relay backtrace needs-analysis


Comment:

 Tor Browser is now using clang to build for macOS, so maybe we could
 document this for other packagers, and then leave this as a nice-to-do.

 And this is a current issue, not just an old 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] #22699 [Applications/Tor Browser]: Use browser pref for javascript at High Security Level

[Tor Bug Tracker & Wiki]

#22699: Use browser pref for javascript at High Security Level
+--
 Reporter:  mikeperry   |  Owner:  tbb-team
 Type:  enhancement | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201706  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  tbb-security => tbb-security, TorBrowserTeam201706


Comment:

 Good idea.

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

Re: [tor-bugs] #22698 [Applications/Tor Browser]: High CPU on facebook.com (Tor Browser 7.0.1)

[Tor Bug Tracker & Wiki]

#22698: High CPU on facebook.com (Tor Browser 7.0.1)
--+---
 Reporter:  Pant  |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

 * status:  new => needs_information
 * cc: tbb-team (added)
 * component:  - Select a component => Applications/Tor Browser


Comment:

 Thank you for filing this ticket. Please help us to understand and
 reproduce this problem by answering the following questions:
 - Are you viewing the main Facebook news feed?
 - What OS / platform are you on?
 - What is your Tor Browser security slider setting (low/medium/high)?
 - Do you have any extra add-ons installed in Tor Browser?

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

Re: [tor-bugs] #22699 [Applications/Tor Browser]: Use browser pref for javascript at High Security Level

[Tor Bug Tracker & Wiki]

#22699: Use browser pref for javascript at High Security Level
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 And get "Temporarily allow all this page" broken?

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

Re: [tor-bugs] #22450 [Core Tor/Tor]: Tor works in compatibility mode on Windows 7 and later

[Tor Bug Tracker & Wiki]

#22450: Tor works in compatibility mode on Windows 7 and later
-+--
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:  Tor: unspecified
 Severity:  Minor| Resolution:
 Keywords:  tor-client, windows  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 Nice joke, teor. But this ticket is about current behavior. Tor is not
 compatible with Windows 7 and later, thus OS runs it in compatibility mode
 and with Virtualized UAC.

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

Re: [tor-bugs] #22698 [- Select a component]: High CPU on facebook.com (Tor Browser 7.0.1) (was: High CPU on facebook.com (Tor Browser))

[Tor Bug Tracker & Wiki]

#22698: High CPU on facebook.com (Tor Browser 7.0.1)
--+-
 Reporter:  Pant  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

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

[tor-bugs] #22699 [Applications/Tor Browser]: Use browser pref for javascript at High Security Level

[Tor Bug Tracker & Wiki]

#22699: Use browser pref for javascript at High Security Level
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-security
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 It would be wise to set javascript.enabled to false in about:config at the
 high security level, in addition to having NoScript disable scripting for
 us. This should be an easy change, and there is no reason to exclusively
 depend on NoScript. NoScript could miss something, especially if the e10s
 transition caused a lot of upheaval.

 (Similarly, Firefox could miss something, since javascript.enabled is no
 longer a UI-exposed pref, so we should do both, for defense in depth.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22698 [- Select a component]: High CPU on facebook.com (Tor Browser)

[Tor Bug Tracker & Wiki]

#22698: High CPU on facebook.com (Tor Browser)
--+-
 Reporter:  Pant  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 While on facebook.com (logged in) all CPU cores rises high around 80%.

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

Re: [tor-bugs] #22697 [Core Tor/Tor]: Tor should mandatory require brackets around ipv6 address

[Tor Bug Tracker & Wiki]

#22697: Tor should mandatory require brackets around ipv6 address
--+
 Reporter:  toralf|  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Just a little more context...

 10:18 < atagar> toralf: If this is in a descriptor then yes, the square
 brackets are mandatory (https://gitweb.torproject.org/torspec.git/tree
 /dir-spec.txt#n1244). If it's in the torrc then it's unspecified. Tor
 lacks a spec for what it'll accept but all its examples have square
 brackets (https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy).

 10:21 < atagar> I'd very much favor saying tor should require square
 brackets as it does with the spec. Otherwise your example (reject6
 2a00:1450:4001:0058::7/16:443) is a pita to parse since the '/16' is
 optional, so that means I'd also need to make sense of
 '2a00:1450:4001:0058::7:443'.

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

Re: [tor-bugs] #13703 [Core Tor/Tor]: Adding doc/HARDENING

[Tor Bug Tracker & Wiki]

#13703: Adding doc/HARDENING
-+-
 Reporter:  mmcc |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  hardening, security, opsec, docs,|  Actual Points:
  lorax, tor-relay, tor-doc  |
Parent ID:   | Points:
 Reviewer:  isis |Sponsor:
-+-
Changes (by isis):

 * keywords:
 hardening, security, opsec, docs, lorax, tor-relay, tor-doc, review-
 group-18
 => hardening, security, opsec, docs, lorax, tor-relay, tor-doc


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

Re: [tor-bugs] #13703 [Core Tor/Tor]: Adding doc/HARDENING

[Tor Bug Tracker & Wiki]

#13703: Adding doc/HARDENING
-+-
 Reporter:  mmcc |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  hardening, security, opsec, docs,|  Actual Points:
  lorax, tor-relay, tor-doc, review-group-18 |
Parent ID:   | Points:
 Reviewer:  isis |Sponsor:
-+-
Changes (by isis):

 * status:  needs_review => new
 * reviewer:   => isis
 * milestone:  Tor: 0.3.2.x-final => Tor: unspecified


Comment:

 It seems like that gist that mmcc linked to above has disappeared
 (https://gist.github.com/plsql/49e642d5bce835df2946). The account for that
 github user has also either disappeared or been renamed. Setting to "new"
 and moving out of 0.3.2.x-final because there's no patch/document to
 review.

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

[tor-bugs] #22697 [Core Tor/Tor]: Tor should mandatory require brackets around ipv6 address

[Tor Bug Tracker & Wiki]

#22697: Tor should mandatory require brackets around ipv6 address
--+
 Reporter:  toralf|  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Stem and Tor do differ about validating an ipv6 address :
 {{{
 ValueError: '2a00:1450:4001:0058::7/16' isn't a wildcard, IPv4, or IPv6
 address: reject6 2a00:1450:4001:0058::7/16:443
 }}}
 The same term is accepted by Tor (within torrc).

 maybe Tor should be more strict too ?

 A short talk with atagar on IRC yielded into this bug report.

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

Re: [tor-bugs] #18114 [Core Tor/Tor]: Warn when ReachableAddresses restricts connections to relays chosen by others

[Tor Bug Tracker & Wiki]

#18114: Warn when ReachableAddresses restricts connections to relays chosen by
others
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor2web, warning, log, |  Actual Points:
  reachableaddresses |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  rsos, tor2web => rsos, tor2web, warning, log,
   reachableaddresses


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

Re: [tor-bugs] #18106 [Core Tor/Tor]: Rename fascist_firewall_* functions to reachable_address_*

[Tor Bug Tracker & Wiki]

#18106: Rename fascist_firewall_* functions to reachable_address_*
+--
 Reporter:  teor|  Owner:
 Type:  enhancement | Status:  new
 Priority:  Low |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Trivial | Resolution:
 Keywords:  easy, minor, rename, tor-relay  |  Actual Points:
Parent ID:  | Points:  small
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:  easy => easy, minor, rename, tor-relay
 * severity:  Normal => Trivial


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

Re: [tor-bugs] #18105 [Core Tor/Tor]: Replace getsockname with tor_getsockname

[Tor Bug Tracker & Wiki]

#18105: Replace getsockname with tor_getsockname
-+-
 Reporter:  teor |  Owner:
 |  eewayhsu
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, api, code-  |  Actual Points:
  simplification |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  easy, intro => easy, intro, api, code-simplification


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

Re: [tor-bugs] #18084 [Core Tor/Tor]: Use the same fallback directory mirror to bootstrap

[Tor Bug Tracker & Wiki]

#18084: Use the same fallback directory mirror to bootstrap
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard post-prop271 fallback  |  Actual Points:
  enumeration-resistence | Points:
Parent ID:  #7798|  medium/large
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-guard post-prop271 fallback enumeration-resistence


Comment:

 It wouldn't be so hard to make our existing code handle this, I think.

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

Re: [tor-bugs] #18082 [Core Tor/Tor]: Log separate HS extra-info stats for RSOS (and SOS)

[Tor Bug Tracker & Wiki]

#18082: Log separate HS extra-info stats for RSOS (and SOS)
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, sos, tor-hs statistics |  Actual Points:
  privcount-maybe|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  rsos, sos, tor-hs => rsos, sos, tor-hs statistics privcount-
 maybe


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

Re: [tor-bugs] #18037 [Core Tor/Tor]: Should the user be allowed to specify FQDNs for HS TARGETs?

[Tor Bug Tracker & Wiki]

#18037: Should the user be allowed to specify FQDNs for HS TARGETs?
-+-
 Reporter:  yawning  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Minor| Resolution:
 Keywords:  tor-hs, dns, maybe-bad-idea  |  Actual Points:
  security-risk rsos |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-hs, dns => tor-hs, dns, maybe-bad-idea security-risk rsos


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

Re: [tor-bugs] #18117 [Core Tor/Tor]: When stem calls controller.close_circuit(circuit_id), circuits don't really close

[Tor Bug Tracker & Wiki]

#18117: When stem calls controller.close_circuit(circuit_id), circuits don't 
really
close
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-control needs-analysis mystery   |  Actual Points:
  circuit-lifetime   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-control needs-analysis mystery circuit-lifetime


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

Re: [tor-bugs] #18124 [Core Tor/Tor]: We never use interface names on Windows, avoid retrieving them

[Tor Bug Tracker & Wiki]

#18124: We never use interface names on Windows, avoid retrieving them
---+---
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Very Low   |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-client win32 easy windows api  |  Actual Points:
Parent ID: | Points:  small
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:  easy, performance => tor-client win32 easy windows api


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

Re: [tor-bugs] #17049 [Core Tor/Tor]: This platform is missing getrlimit(). Increase the number of connections in Windows

[Tor Bug Tracker & Wiki]

#17049: This platform is missing getrlimit(). Increase the number of 
connections in
Windows
+--
 Reporter:  TORques |  Owner:  lunar
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  invalid
 Keywords:  tor-relay windows tor-docs logging  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by cypherpunks):

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


Comment:

 Tor shouldn't modify Windows.
 The same registry tweaks as a recommendation are in #17172.

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

Re: [tor-bugs] #18140 [Core Tor/Tor]: Update dir-spec for "reasonably live" consensuses

[Tor Bug Tracker & Wiki]

#18140: Update dir-spec for "reasonably live" consensuses
---+
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Low|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-spec, doc  |  Actual Points:
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted
 * milestone:  Tor: unspecified => Tor: 0.3.2.x-final


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

Re: [tor-bugs] #18134 [Core Tor/Tor]: tor issues missleading permission warning when torrc overrides User config directive of default torrc

[Tor Bug Tracker & Wiki]

#18134: tor issues missleading permission warning when torrc overrides User 
config
directive of default torrc
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, warning, setuid, permissions,  |  Actual Points:
  logs, tor-relay, usability |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  easy, warning => easy, warning, setuid, permissions, logs,
 tor-relay, usability


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

Re: [tor-bugs] #17991 [Core Tor/Tor]: Handle non-127.0.0.1 IPv4 loopback addresses

[Tor Bug Tracker & Wiki]

#17991: Handle non-127.0.0.1 IPv4 loopback addresses
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-client loopback weird-   |  Actual Points:
  configuration ipv4 address | Points:
Parent ID:   |  small/medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-client loopback weird-configuration ipv4 address


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

Re: [tor-bugs] #17990 [Core Tor/Tor]: torrc default config ORPort should be changed to 443 from 9001

[Tor Bug Tracker & Wiki]

#17990: torrc default config ORPort should be changed to 443 from 9001
-+-
 Reporter:  tomnux   |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-design tor-relay maybe-bad-|  Actual Points:
  idea   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => needs-design tor-relay maybe-bad-idea


Comment:

 If we did this by default without some fallback mechanism, Tor wouldn't
 start as an unprivileged user on unixes.  So, we'd need some design to
 make it practical.

 We could have the default port be "auto" if we did anything to make "auto"
 ports more persistent.

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

Re: [tor-bugs] #17971 [Core Tor/Tor]: Unrecognized relay in exit address '[scrubbed].exit'. Refusing.

[Tor Bug Tracker & Wiki]

#17971: Unrecognized relay in exit address '[scrubbed].exit'. Refusing.
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Normal   | Resolution:
 Keywords:  log, docs, exit tor-client   |  Actual Points:
  misleading-logs usability  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  log, doc, exit => log, docs, exit tor-client misleading-logs
 usability


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

Re: [tor-bugs] #17957 [Core Tor/Tor]: Detect stolen onion service key

[Tor Bug Tracker & Wiki]

#17957: Detect stolen onion service key
-+-
 Reporter:  ess2 |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  key-observatory, tor-hs, needs-  |  Actual Points:
  proposal, key-theft, intro |
Parent ID:   | Points:  6
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  key-observatory, tor-hs, needs-proposal => key-observatory,
 tor-hs, needs-proposal, key-theft, intro


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

Re: [tor-bugs] #17956 [Core Tor/Tor]: Let tor handle disconnects better

[Tor Bug Tracker & Wiki]

#17956: Let tor handle disconnects better
-+-
 Reporter:  dns2utf8 |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.5
 Severity:  Normal   | Resolution:
 Keywords:  network reliability client   |  Actual Points:
  sponsor8-maybe needs-testing needs-design  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  network => network reliability client sponsor8-maybe needs-
 testing needs-design


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

Re: [tor-bugs] #17952 [Core Tor/Tor]: Make address family search via ioctl more accurate on obscure platforms

[Tor Bug Tracker & Wiki]

#17952: Make address family search via ioctl more accurate on obscure platforms
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, easy, lorax tor-relay  |  Actual Points:
  address-detection  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  ipv6, easy, lorax => ipv6, easy, lorax tor-relay address-
 detection


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

Re: [tor-bugs] #17953 [Core Tor/Tor]: Fallback to resolving localhost when interface searches fail

[Tor Bug Tracker & Wiki]

#17953: Fallback to resolving localhost when interface searches fail
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client address-detection |  Actual Points:
  localhost  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-client address-detection localhost


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

Re: [tor-bugs] #17949 [Core Tor/Tor]: Make loopback address search more accurate

[Tor Bug Tracker & Wiki]

#17949: Make loopback address search more accurate
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy tor-client tor-relay loopback   |  Actual Points:
  weird-configuration|
Parent ID:  #17991   | Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  easy => easy tor-client tor-relay loopback weird-configuration


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

Re: [tor-bugs] #17948 [Core Tor/Tor]: HiddenServicePort should connect to localhost by default

[Tor Bug Tracker & Wiki]

#17948: HiddenServicePort should connect to localhost by default
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  reopened
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, easy, maybe-bad-idea-or-   |  Actual Points:
  maybe-not tor-hs   |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  ipv6, easy => ipv6, easy, maybe-bad-idea-or-maybe-not tor-hs


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

Re: [tor-bugs] #6741 [Archived/Vidalia]: Vidalia not-responding after minute of working

[Tor Bug Tracker & Wiki]

#6741: Vidalia not-responding after minute of working
--+--
 Reporter:  HavingError12 |  Owner:  chiiph
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Archived/Vidalia  |Version:  Vidalia: 0.2.20
 Severity:  Normal| Resolution:  user disappeared
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:  Vidalia 0.2.15 0.2.19 0.2.20 Tor 0.2.2.35 0.2.2.37 0.2.2.38
 Windows =>
 * status:  needs_information => closed
 * resolution:   => user disappeared
 * severity:   => Normal


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

Re: [tor-bugs] #17928 [Core Tor/Tor]: Warnings in syslog for wrong permissions on hidden service dir are misleading

[Tor Bug Tracker & Wiki]

#17928: Warnings in syslog for wrong permissions on hidden service dir are
misleading
-+-
 Reporter:  throwaway232344  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.5
 Severity:  Trivial  | Resolution:
 Keywords:  tor-hs permissions chmod logging |  Actual Points:
  usability  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-hs => tor-hs permissions chmod logging usability


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

Re: [tor-bugs] #17928 [Core Tor/Tor]: Warnings in syslog for wrong permissions on hidden service dir are misleading

[Tor Bug Tracker & Wiki]

#17928: Warnings in syslog for wrong permissions on hidden service dir are
misleading
-+-
 Reporter:  throwaway232344  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.5
 Severity:  Trivial  | Resolution:
 Keywords:  tor-hs permissions chmod logging |  Actual Points:
  easy? usability|
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-hs permissions chmod logging usability => tor-hs
 permissions chmod logging easy? usability


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

Re: [tor-bugs] #17873 [Core Tor/Tor]: replacing 0.0.0.0 listeners at runtime fails

[Tor Bug Tracker & Wiki]

#17873: replacing 0.0.0.0 listeners at runtime fails
+--
 Reporter:  cypherpunks |  Owner:
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-client port bind switching  |  Actual Points:
Parent ID:  | Points:  medium
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:  easy => tor-client port bind switching


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

Re: [tor-bugs] #19280 [Applications/Tor Browser]: Replace or fork NoScript in the Tor Browser

[Tor Bug Tracker & Wiki]

#19280: Replace or fork NoScript in the Tor Browser
--+--
 Reporter:  herbst|  Owner:  tbb-team
 Type:  project   | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #22684 [Core Tor/Tor]: Expose we_fetch_{micro, router_}descriptors on control port

[Tor Bug Tracker & Wiki]

#22684: Expose we_fetch_{micro,router_}descriptors on control port
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-control   |  Actual Points:  .1
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Thanks Nick! Both changes look 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] #22675 [Applications/Tor Browser]: Tor Browser 7.0.1 opens at 1000x500 resolution

[Tor Bug Tracker & Wiki]

#22675: Tor Browser 7.0.1 opens at 1000x500 resolution
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


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

Re: [tor-bugs] #17867 [Core Tor/Tor]: Remove addresses and ports from dir_server_t and just use the ones in fake_status

[Tor Bug Tracker & Wiki]

#17867: Remove addresses and ports from dir_server_t and just use the ones in
fake_status
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  easy, refactor, tor-client   |  Actual Points:
  SponsorS-deferred  |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  easy, refactor, SponsorS-deferred => easy, refactor, tor-
 client SponsorS-deferred


Comment:

 I'm not 100% sure this is a great idea, but _some kind_ of refactoring on
 these types sounds like a good idea.

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

Re: [tor-bugs] #22659 [Applications/Tor Browser]: Changes to `intl.accept.languages` get overwritten after restart

[Tor Bug Tracker & Wiki]

#22659: Changes to `intl.accept.languages` get overwritten after restart
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  TorBrowserTeam201706, GeorgKoppen201706|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Nothing seems related in it. Does that happen in non-e10s mode?

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

Re: [tor-bugs] #17862 [Core Tor/Tor]: Stop distributing rebuildable files

[Tor Bug Tracker & Wiki]

#17862: Stop distributing rebuildable files
--+--
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.4.26
 Severity:  Minor | Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

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


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

Re: [tor-bugs] #17845 [Core Tor/Tor]: Add unit tests for IPv6 relay descriptors

[Tor Bug Tracker & Wiki]

#17845: Add unit tests for IPv6 relay descriptors
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-tests-coverage, tor-   |  Actual Points:
  tests-unit, tor-relay  |
Parent ID:  #17811   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

 * keywords:  ipv6, tor-tests-coverage, tor-tests-unit => ipv6, tor-tests-
 coverage, tor-tests-unit, tor-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] #17881 [Core Tor/Tor]: Use return codes from test programs to simplify test scripts

[Tor Bug Tracker & Wiki]

#17881: Use return codes from test programs to simplify test scripts
+--
 Reporter:  cypherpunks |  Owner:
 Type:  enhancement | Status:  new
 Priority:  Low |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Minor   | Resolution:
 Keywords:  tor-testing simplification  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:   => tor-testing simplification


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

Re: [tor-bugs] #17882 [Core Tor/Tor]: Remove needless *_support_ntor()

[Tor Bug Tracker & Wiki]

#17882: Remove needless *_support_ntor()
-+-
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  easy tor-client code-removal |  Actual Points:
  technical-debt |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  easy => easy tor-client code-removal technical-debt


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

Re: [tor-bugs] #17901 [Core Tor/Tor]: Tor would bind ControlPort to public ip address if it has no localhost interface

[Tor Bug Tracker & Wiki]

#17901: Tor would bind ControlPort to public ip address if it has no localhost
interface
-+-
 Reporter:  s7r  |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Major| Resolution:
 Keywords:  tor-control misconfiguration |  Actual Points:
  security easy  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-control misconfiguration security easy


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

Re: [tor-bugs] #19280 [Applications/Tor Browser]: Replace or fork NoScript in the Tor Browser

[Tor Bug Tracker & Wiki]

#19280: Replace or fork NoScript in the Tor Browser
--+--
 Reporter:  herbst|  Owner:  tbb-team
 Type:  project   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 https://hackademix.net/2009/05/04/dear-adblock-plus-and-noscript-users-
 dear-mozilla-community/

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

Re: [tor-bugs] #17909 [Core Tor/Tor]: 'GETINFO config-text' always includes HiddenServiceStatistics

[Tor Bug Tracker & Wiki]

#17909: 'GETINFO config-text' always includes HiddenServiceStatistics
--+--
 Reporter:  atagar|  Owner:
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

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


Comment:

 #21150 got fixed, and so this is fixed too.

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

Re: [tor-bugs] #17911 [Core Tor/Tor]: check Tor for local clock leaks

[Tor Bug Tracker & Wiki]

#17911: check Tor for local clock leaks
---+---
 Reporter:  proper |  Owner:
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  analysis tor-client term-project?  |  Actual Points:
Parent ID: | Points:  3
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:   => analysis tor-client term-project?


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

Re: [tor-bugs] #17927 [Core Tor/Tor]: Use SRWLock for non-recursive locks on vista and later

[Tor Bug Tracker & Wiki]

#17927: Use SRWLock for non-recursive locks on vista and later
-+-
 Reporter:  nickm|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay windows win32 api locking  |  Actual Points:
  easy   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-relay windows win32 api locking easy


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

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[Tor Bug Tracker & Wiki]

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  asn|Sponsor:
---+---
Changes (by nickm):

 * status:  merge_ready => accepted


Comment:

 Thank you, asn! Merging to 0.3.0 and forward.

 I'm putting this back in "accept" since I believe Roger has more to add.

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

Re: [tor-bugs] #22154 [Metrics/metrics-lib]: Remove code that was deprecated in the 1.x series

[Tor Bug Tracker & Wiki]

#22154: Remove code that was deprecated in the 1.x series
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * owner:  metrics-team => iwakeh
 * status:  new => accepted


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

Re: [tor-bugs] #22695 [Metrics/metrics-lib]: descriptor file processing

[Tor Bug Tracker & Wiki]

#22695: descriptor file processing
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 I don't have a good answer yet, but my hope is that we can get rid of
 `fileName` in the medium term. See also #22207. Maybe there are more
 descriptors that we'd have to change for this, but I really hope that all
 descriptors will be self-describing without relying on file names in the
 future.

 Regarding `descriptorFile`, I think we'll have to permit `null` there,
 because it's not a strict requirements that descriptors come from a
 descriptor file. For example, an application might want to store
 descriptors in a database and parse them at a later time, and then it
 won't necessarily have the file name anymore.

 I'll think more about this and maybe come up with a better answer later.

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

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[Tor Bug Tracker & Wiki]

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:
   |  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  asn|Sponsor:
---+---
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:16 nickm]:
 > I think we do need both checks; without a live consensus, we don't want
 to expand the list _or_ change its members' status.
 >
 > The checks are slightly different; for expand it was "reasonably live"
 and for change status it's "live". I think that maybe they should both
 become "live"; let's try that.
 >
 > What do you think of the commit I just added to the branch?

 Makes sense. I like it more this way and less code dup.

 I tested it with an old consensus from collector, and tor correctly
 declined to add any guards to the sampled set before fetching a new
 consensus.

 Marking this branch as `merge_ready`.

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

Re: [tor-bugs] #17837 [Core Tor/Tor]: Move SOCKSPort open proxy warning to a more sensible location

[Tor Bug Tracker & Wiki]

#17837: Move SOCKSPort open proxy warning to a more sensible location
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.2.7.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  fixed
 Keywords:  doc, easy |  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.2.7.x-final


Comment:

 Actually, it appears ln5 fixed this in
 5be36a46cab7626c52e0c50e55ca73703698e399, which was merged in
 0.2.7.2-alpha.

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

Re: [tor-bugs] #17640 [Core Tor/Tor]: Handle CREATE/CREATED cell processing gracefully under load.

[Tor Bug Tracker & Wiki]

#17640: Handle CREATE/CREATED cell processing gracefully under load.
-+-
 Reporter:  yawning  |  Owner:  yawning
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, scaling, tor-dos, tor-relay  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorU-can
-+-

Comment (by nickm):

 Also see #17806.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22696 [Metrics/metrics-lib]: create a test collection for the entire metrics-lib API

[Tor Bug Tracker & Wiki]

#22696: create a test collection for the entire metrics-lib API
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Separate API and implementation tests.

 This task might need to be broken down into useful sub-units.
 The goal is to create tests for each part of the API which only access the
 API and not the underlying implementation.

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

Re: [tor-bugs] #17837 [Core Tor/Tor]: Move SOCKSPort open proxy warning to a more sensible location

[Tor Bug Tracker & Wiki]

#17837: Move SOCKSPort open proxy warning to a more sensible location
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  doc, easy |  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted
 * milestone:  Tor: unspecified => Tor: 0.3.2.x-final


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

Re: [tor-bugs] #17806 [Core Tor/Tor]: Make onion queues rational, combine with workqueue logic.

[Tor Bug Tracker & Wiki]

#17806: Make onion queues rational, combine with workqueue logic.
-+-
 Reporter:  nickm|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  intro, term-project-ideas, tor-dos,  |  Actual Points:
  cpuworker multithreading multicore needs-cs|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Also see #17640.

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

Re: [tor-bugs] #17835 [Core Tor/Tor]: Make ClientPreferIPv6ORPort/DirPort smarter

[Tor Bug Tracker & Wiki]

#17835: Make ClientPreferIPv6ORPort/DirPort smarter
-+--
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client ipv6  |  Actual Points:
Parent ID:  #17811   | Points:  medium/large
 Reviewer:   |Sponsor:
-+--
Changes (by nickm):

 * keywords:   => tor-client 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] #17811 [Core Tor/Tor]: Tor Clients on IPv6

[Tor Bug Tracker & Wiki]

#17811: Tor Clients on IPv6
---+---
 Reporter:  teor   |  Owner:
 Type:  task   | Status:  new
 Priority:  High   |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6 tor-client master-ticket  |  Actual Points:
Parent ID: | Points:  (parent)
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:  ipv6 => ipv6 tor-client master-ticket


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

Re: [tor-bugs] #17808 [Core Tor/Tor]: Tor 0.2.7.6 doesn't produce a backtrace on gcc 4.9.3 on OS X 10.11.2

[Tor Bug Tracker & Wiki]

#17808: Tor 0.2.7.6 doesn't produce a backtrace on gcc 4.9.3 on OS X 10.11.2
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.6
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-relay backtrace   |  Actual Points:
  needs-analysis old-system  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-client tor-relay backtrace needs-analysis old-system
 * points:  ?large? =>


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

Re: [tor-bugs] #17806 [Core Tor/Tor]: Make onion queues rational, combine with workqueue logic.

[Tor Bug Tracker & Wiki]

#17806: Make onion queues rational, combine with workqueue logic.
-+-
 Reporter:  nickm|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  intro, term-project-ideas, tor-dos,  |  Actual Points:
  cpuworker multithreading multicore needs-cs|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  intro, term-project-ideas, tor-dos =>
 intro, term-project-ideas, tor-dos, cpuworker multithreading multicore
 needs-cs


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

Re: [tor-bugs] #17807 [Core Tor/Tor]: Use OpenSSL 1.1.0 ASYNC engine support

[Tor Bug Tracker & Wiki]

#17807: Use OpenSSL 1.1.0 ASYNC engine support
-+-
 Reporter:  nickm|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  term-project-ideas tor-relay needs-  |  Actual Points:
  design multiprocessing |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  term-project-ideas => term-project-ideas tor-relay needs-
 design multiprocessing


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

Re: [tor-bugs] #22695 [Metrics/metrics-lib]: descriptor file processing

[Tor Bug Tracker & Wiki]

#22695: descriptor file processing
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Description changed by iwakeh:

Old description:

> In 1.9.0 a new method `getDescrptorFile` was introduced.  This actually
> can cause various problems and has some open design questions that should
> be answered in this ticket.
> (I'll attach a branch with a test demonstration part of the problem.)
>
> `DescriptorParser` has the new method (since 1.9.0):
>
> {{{
> public Iterable parseDescriptors(byte[] rawDescriptorBytes,
> File descriptorFile, String fileName);
> }}}
>
> In addition to the problem demonstrated in the (to be attached) test this
> raises some questions:
>
> 1) What should be done, if `descriptorFile.getName() != fileName`?
> 2) What should be done, if `descriptorFile != null && (null == fileName
> || fileName.isEmpty())`?
> 3) What should be done, if `descriptorFile == null && null != fileName`?
> 4a) What should be done, if `descriptorFile == null && null != fileName
> && fileName.isEmpty()`?
> 4b) What should be done, if `descriptorFile == null && null == fileName`?

New description:

 In 1.9.0 a new method `getDescrptorFile` was introduced.  This actually
 can cause various problems and has some open design questions that should
 be answered in this ticket.
 (I'll attach a branch with a test demonstrating part of the problem.)

 `DescriptorParser` has the new method (since 1.9.0):

 {{{
 public Iterable parseDescriptors(byte[] rawDescriptorBytes,
 File descriptorFile, String fileName);
 }}}

 In addition to the problem demonstrated in the (to be attached) test this
 raises some questions:

 1) What should be done, if `descriptorFile.getName() != fileName`?
 2) What should be done, if `descriptorFile != null && (null == fileName ||
 fileName.isEmpty())`?
 3) What should be done, if `descriptorFile == null && null != fileName`?
 4a) What should be done, if `descriptorFile == null && null != fileName &&
 fileName.isEmpty()`?
 4b) What should be done, if `descriptorFile == null && null == fileName`?

 The implementation of the solution should also have tests for each of the
 possible cases.

--

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

Re: [tor-bugs] #17800 [Core Tor/Tor]: Tor Unit Tests should TT_FORK before initialising global PRNG state

[Tor Bug Tracker & Wiki]

#17800: Tor Unit Tests should TT_FORK before initialising global PRNG state
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  easy tor-tests prng init mostly- |  Actual Points:
  harmless   |
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  easy => easy tor-tests prng init mostly-harmless


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

Re: [tor-bugs] #17799 [Core Tor/Tor]: Use a better PRNG unless OpenSSL starts using a better one on their own. (was: Hash All PRNG output before use)

[Tor Bug Tracker & Wiki]

#17799: Use a better PRNG unless OpenSSL starts using a better one on their own.
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-relay tor-client prng crypto  |  Actual Points:  5
Parent ID:| Points:  5
 Reviewer:  asn   |Sponsor:
--+
Changes (by nickm):

 * keywords:   => tor-relay tor-client prng crypto


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

Re: [tor-bugs] #17782 [Core Tor/Tor]: Relays may publish descriptors with incorrect IP address

[Tor Bug Tracker & Wiki]

#17782: Relays may publish descriptors with incorrect IP address
---+---
 Reporter:  fk |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Major  | Resolution:
 Keywords:  intro tor-relay address-detection  |  Actual Points:
Parent ID:  #17811 | Points:  medium
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:  intro => intro tor-relay address-detection


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

Re: [tor-bugs] #17773 [Core Tor/Tor]: Should clients avoid using guards that lost the Guard flag?

[Tor Bug Tracker & Wiki]

#17773: Should clients avoid using guards that lost the Guard flag?
---+--
 Reporter:  arma   |  Owner:  arma
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-client guards  |  Actual Points:
Parent ID: | Points:  medium?
 Reviewer: |Sponsor:
---+--
Changes (by nickm):

 * keywords:   => tor-client guards


Comment:

 Note that prop271 has substantially changed the original behavior here.

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

Re: [tor-bugs] #17765 [Core Tor/Tor]: If tor gets different addresses via different methods, it flips between them

[Tor Bug Tracker & Wiki]

#17765: If tor gets different addresses via different methods, it flips between
them
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay address-detection  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-relay address-detection


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

Re: [tor-bugs] #17768 [Core Tor/Tor]: Measure Hidden Service Rendezvous Path Lengths

[Tor Bug Tracker & Wiki]

#17768: Measure Hidden Service Rendezvous Path Lengths
---+---
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs measurement needs-analysis  |  Actual Points:
Parent ID: | Points:  medium
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:   => tor-hs measurement needs-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] #17754 [Core Tor/Tor]: 0.2.7.5 cannot work inside lxc container

[Tor Bug Tracker & Wiki]

#17754: 0.2.7.5 cannot work inside lxc container
-+-
 Reporter:  kibba|  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.5
 Severity:  Normal   | Resolution:
 Keywords:  lxc tor-client compatibility |  Actual Points:
  apparmor needs-diagnosis container |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  lxc => lxc tor-client compatibility apparmor needs-diagnosis
 container


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

Re: [tor-bugs] #17728 [Core Tor/Tor]: Use NETINFO handshake rather than date header to check time with authorities

[Tor Bug Tracker & Wiki]

#17728: Use NETINFO handshake rather than date header to check time with
authorities
---+---
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-client easy time boostrap  |  Actual Points:
Parent ID:  #9675  | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:   => tor-client easy time boostrap


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

Re: [tor-bugs] #22295 [Metrics/Metrics website]: update metrics-lib tutorials for major version release

[Tor Bug Tracker & Wiki]

#22295: update metrics-lib tutorials for major version release
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * milestone:  metrics-lib 2.0.0 =>


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

Re: [tor-bugs] #17692 [Core Tor/Tor]: Review every use of onehop_tunnel for assumptions that it's a directory connection

[Tor Bug Tracker & Wiki]

#17692: Review every use of onehop_tunnel for assumptions that it's a directory
connection
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  rsos correctness technical-debt  |  Actual Points:
  tor-hs tor-client  | Points:
Parent ID:   |  small/medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  rsos => rsos correctness technical-debt tor-hs tor-client


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

Re: [tor-bugs] #17793 [Core Tor/Tor]: Inconsistent function comment cache_failure_intro_lookup

[Tor Bug Tracker & Wiki]

#17793: Inconsistent function comment cache_failure_intro_lookup
---+--
 Reporter:  cypherpunks|  Owner:
 Type:  defect | Status:  new
 Priority:  Very Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Trivial| Resolution:
 Keywords:  easy tor-docs comment  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by nickm):

 * keywords:   => easy tor-docs comment


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

Re: [tor-bugs] #17787 [Core Tor/Tor]: Improve address detection on multihomed relays

[Tor Bug Tracker & Wiki]

#17787: Improve address detection on multihomed relays
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-relay ipv6 multihome address-|  Actual Points:
  detection  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-relay ipv6 multihome address-detection


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

Re: [tor-bugs] #22295 [Metrics/Metrics website]: update metrics-lib tutorials for major version release

[Tor Bug Tracker & Wiki]

#22295: update metrics-lib tutorials for major version release
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  new => needs_review
 * component:  Metrics/metrics-lib => Metrics/Metrics website


Comment:

 Moving to metrics-web where it really belongs, even though it's tightly
 related to the metrics-lib 2.0.0 release.

 Please review [https://gitweb.torproject.org/karsten/metrics-
 web.git/log/?h=task-22295 my branch task-22295].

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

Re: [tor-bugs] #22695 [Metrics/metrics-lib]: descriptor file processing

[Tor Bug Tracker & Wiki]

#22695: descriptor file processing
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 First thoughts about possible answers:

 1) Several answers:
i) some form of exception?
ii) warning and use the descriptorFile given?
 2) Set `fileName = descriptorFile.getName()`.
 3) More tricky:
i) use `descriptorFile = new File(fileName)` is potentially problematic
 b/c there is no such file.
ii) leave `descriptorFile = null` and forget about the given filename?
iii) add getDescriptorFilename() to the Descriptor interface?
iv) some form of exception?
 4) some form of exception?

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

Re: [tor-bugs] #22652 [Metrics/CollecTor]: Adapt CollecTor to metrics-lib 1.9.0

[Tor Bug Tracker & Wiki]

#22652: Adapt CollecTor to metrics-lib 1.9.0
---+--
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

 * status:  needs_revision => needs_review


Comment:

 Please review
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-22652
 this commit]. The final fix depends on #22695.

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

Re: [tor-bugs] #22695 [Metrics/metrics-lib]: descriptor file processing

[Tor Bug Tracker & Wiki]

#22695: descriptor file processing
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 The failing assertion is `assertNotNull(desc.getDescriptorFile());` in
 [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-22695=2c3d324c263eefd8a1d27bd8c83a92ca26753279
 this branch].

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22695 [Metrics/metrics-lib]: descriptor file processing

[Tor Bug Tracker & Wiki]

#22695: descriptor file processing
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 In 1.9.0 a new method `getDescrptorFile` was introduced.  This actually
 can cause various problems and has some open design questions that should
 be answered in this ticket.
 (I'll attach a branch with a test demonstration part of the problem.)

 `DescriptorParser` has the new method (since 1.9.0):

 {{{
 public Iterable parseDescriptors(byte[] rawDescriptorBytes,
 File descriptorFile, String fileName);
 }}}

 In addition to the problem demonstrated in the (to be attached) test this
 raises some questions:

 1) What should be done, if `descriptorFile.getName() != fileName`?
 2) What should be done, if `descriptorFile != null && (null == fileName ||
 fileName.isEmpty())`?
 3) What should be done, if `descriptorFile == null && null != fileName`?
 4a) What should be done, if `descriptorFile == null && null != fileName &&
 fileName.isEmpty()`?
 4b) What should be done, if `descriptorFile == null && null == 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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[Tor Bug Tracker & Wiki]

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  asn|Sponsor:
---+---

Comment (by nickm):

 I think we do need both checks; without a live consensus, we don't want to
 expand the list _or_ change its members' status.

 The checks are slightly different; for expand it was "reasonably live" and
 for change status it's "live". I think that maybe they should both become
 "live"; let's try that.

 What do you think of the commit I just added to the branch?

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

Re: [tor-bugs] #22688 [Core Tor/Tor]: Make sure HSDir3s never know service, client, or bridge IP addresses

[Tor Bug Tracker & Wiki]

#22688: Make sure HSDir3s never know service, client, or bridge IP addresses
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  prop224, relay-safety,   |  Actual Points:  0.3
  031-backport, maybe-030-backport-with-21406|
Parent ID:  #17945   | Points:  0.3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 See #21406 for the recent changes to channel_is_client().

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

Re: [tor-bugs] #22688 [Core Tor/Tor]: Make sure HSDir3s never know service, client, or bridge IP addresses

[Tor Bug Tracker & Wiki]

#22688: Make sure HSDir3s never know service, client, or bridge IP addresses
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  prop224, relay-safety,   |  Actual Points:  0.3
  031-backport, maybe-030-backport-with-21406|
Parent ID:  #17945   | Points:  0.3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:5 dgoulet]:
 > Some comments:
 >
 > * We should break this assert() in two different ones else if triggered,
 we won't know which condition triggered it:
 >
 > {{{
 > +  /* A clever compiler might complain this is always true */
 > +  tor_assert(TO_CONN(conn) && TO_CONN(conn)->linked);
 > }}}

 Agreed.

 > * How do we know that this is a `one-hop` circuit with this condition?
 >
 > {{{
 > +  /* Well, we won't be sending anything back on that, will we?
 > +   * (Avoid giving the wrong answer because state has been reset.) */
 > +  if (TO_CONN(conn)->linked_conn_is_closed ||
 > +  !l_conn || l_conn->marked_for_close) {
 > +log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
 > +   "Refusing %s one-hop encrypted directory connection.",
 > +   TO_CONN(conn)->linked_conn_is_closed ? "closed linked" :
 > +   !l_conn ? "NULL linked" : "marked for closed linked");
 > +return 0;
 > +  }
 > }}}
 >
 >  Same goes with these condition later:
 >
 > {{{
 > +  if (BUG(!exitconn) || !exitconn->on_circuit) {
 > [...]
 > +  if (BUG(!orcirc) || !orcirc->p_chan) {
 > }}}

 We don't.

 > * Would using `CIRCUIT_IS_ORCIRC()` me more appropriate here?
 >
 > {{{
 > +  /* We should always be using an OR circuit */
 > +  if (BUG(exitconn->on_circuit->purpose != CIRCUIT_PURPOSE_OR)) {
 > +return 0;
 > +  }
 > }}}

 Agreed: I couldn't find it when I was writing the patch.

 > * I'm unclear on where this is checked? Maybe it's done through some
 indirect checks that I haven't spotted but is there a way you can know
 that with an `or_circuit_t` ?
 >
 > {{{
 > + * For client circuits via relays, this is true for 2-hop or greater
 paths,
 > + * for client circuits via bridges, this is true for 3-hop or greater
 paths.
 > }}}

 This is checked at the end of the function using
 `!channel_is_client(p_chan)`.

 `channel_is_client()` is true if the channel is connected to a non-
 authenticated peer (something without a fingerprint). This can either be a
 client or a bridge.

 So to pass the `!channel_is_client(p_chan)` check:
 * a client can't connect directly, so a client has to have a 2-hop path
 through a relay,
 * a bridge can't connect directly, so a client has to have a 3-hop path
 through a bridge.

 Does that make sense?

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

Re: [tor-bugs] #21932 [Metrics/metrics-lib]: Stop relying on the platform's default charset

[Tor Bug Tracker & Wiki]

#21932: Stop relying on the platform's default charset
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  assigned => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/log/?h=task-21932-4 my branch task-21932-4].

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

Re: [tor-bugs] #22688 [Core Tor/Tor]: Make sure HSDir3s never know service, client, or bridge IP addresses

[Tor Bug Tracker & Wiki]

#22688: Make sure HSDir3s never know service, client, or bridge IP addresses
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  prop224, relay-safety,   |  Actual Points:  0.3
  031-backport, maybe-030-backport-with-21406|
Parent ID:  #17945   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Some comments:

 * We should break this assert() in two different ones else if triggered,
 we won't know which condition triggered it:

 {{{
 +  /* A clever compiler might complain this is always true */
 +  tor_assert(TO_CONN(conn) && TO_CONN(conn)->linked);
 }}}

 * How do we know that this is a `one-hop` circuit with this condition?

 {{{
 +  /* Well, we won't be sending anything back on that, will we?
 +   * (Avoid giving the wrong answer because state has been reset.) */
 +  if (TO_CONN(conn)->linked_conn_is_closed ||
 +  !l_conn || l_conn->marked_for_close) {
 +log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
 +   "Refusing %s one-hop encrypted directory connection.",
 +   TO_CONN(conn)->linked_conn_is_closed ? "closed linked" :
 +   !l_conn ? "NULL linked" : "marked for closed linked");
 +return 0;
 +  }
 }}}

  Same goes with these condition later:

 {{{
 +  if (BUG(!exitconn) || !exitconn->on_circuit) {
 [...]
 +  if (BUG(!orcirc) || !orcirc->p_chan) {
 }}}

 * Would using `CIRCUIT_IS_ORCIRC()` me more appropriate here?

 {{{
 +  /* We should always be using an OR circuit */
 +  if (BUG(exitconn->on_circuit->purpose != CIRCUIT_PURPOSE_OR)) {
 +return 0;
 +  }
 }}}

 * I'm unclear on where this is checked? Maybe it's done through some
 indirect checks that I haven't spotted but is there a way you can know
 that with an `or_circuit_t` ?

 {{{
 + * For client circuits via relays, this is true for 2-hop or greater
 paths,
 + * for client circuits via bridges, this is true for 3-hop or greater
 paths.
 }}}

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

Re: [tor-bugs] #22690 [Core Tor/Tor]: SR: Authorities can add a reveal to their own vote, but expect a commit in all votes

[Tor Bug Tracker & Wiki]

#22690: SR: Authorities can add a reveal to their own vote, but expect a commit 
in
all votes
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sr|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:3 teor]:
 > Replying to [comment:2 dgoulet]:
 > > This is possible with a bad clock on the authority side which makes
 the relay thinks that it's in the REVEAL phase but it is in fact in the
 COMMIT phase.
 > >
 > > A bit weird though that you get that on chutney because all relays
 have the same clock! The logs here will definitely help out.
 >
 > chutney does some weird things with TestingV3AuthVotingStartOffset that
 might cause this issue. Occasionally one authority starts before the
 offset, and another starts after it, and their consensuses get out of
 sync.
 >
 > But this is really weird: it is an authority rejecting its own vote, so
 it has to have the same clock, right?

 I don't think so. The warning simply says that it received the
 `234887728412ECD247629DD9888735F1A7AA` commit value with a reveal
 which was seen in the `234887728412ECD247629DD9888735F1A7AA` vote.

 That log warning should *not* have been emitted by
 `234887728412ECD247629DD9888735F1A7AA` else we have another problem!

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

Re: [tor-bugs] #22690 [Core Tor/Tor]: SR: Authorities can add a reveal to their own vote, but expect a commit in all votes

[Tor Bug Tracker & Wiki]

#22690: SR: Authorities can add a reveal to their own vote, but expect a commit 
in
all votes
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sr|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:2 dgoulet]:
 > This is possible with a bad clock on the authority side which makes the
 relay thinks that it's in the REVEAL phase but it is in fact in the COMMIT
 phase.
 >
 > A bit weird though that you get that on chutney because all relays have
 the same clock! The logs here will definitely help out.

 chutney does some weird things with TestingV3AuthVotingStartOffset that
 might cause this issue. Occasionally one authority starts before the
 offset, and another starts after it, and their consensuses get out of
 sync.

 But this is really weird: it is an authority rejecting its own vote, so it
 has to have the same clock, right?

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

Re: [tor-bugs] #22476 [Metrics/metrics-lib]: Replace ImplementationNotAccessibleException with RuntimeException

[Tor Bug Tracker & Wiki]

#22476: Replace ImplementationNotAccessibleException with RuntimeException
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Meh. `ProviderNotFoundException` doesn't have a constructor that accepts a
 `Throwable`. Maybe we shouldn't pick unrelated runtime exceptions and
 simply use `RuntimeException`. After all, we don't want people to catch
 them and distinguish them by type anyway, and the message will be
 sufficient to track down the issue.

 I also took out the log message change and linked the discussion here in
 #20430. Let's tackle that together with other logging changes.

 Please review [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/log/?h=task-22476 my branch task-22476] for 2.0.0.

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

Re: [tor-bugs] #22690 [Core Tor/Tor]: SR: Authorities can add a reveal to their own vote, but expect a commit in all votes

[Tor Bug Tracker & Wiki]

#22690: SR: Authorities can add a reveal to their own vote, but expect a commit 
in
all votes
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sr|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_information
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 This is possible with a bad clock on the authority side which makes the
 relay thinks that it's in the REVEAL phase but it is in fact in the COMMIT
 phase.

 A bit weird though that you get that on chutney because all relays have
 the same clock! The logs here will definitely help 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] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop Tor2Web connecting to (Rendezvous) Single Onion Services
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, sos, tor2web, tor-hs,  |  Actual Points:
  029-proposed, 029-teor-no, needs-design,   |
  needs-proposal-maybe   |
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #20430 [Metrics/metrics-lib]: log-level definition for metrics-lib

[Tor Bug Tracker & Wiki]

#20430: log-level definition for metrics-lib
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #20540   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 When we get back to this ticket, let's consider turning log messsage
 `"Serving implementation {} for {}."` into a debug message. See also the
 [https://trac.torproject.org/projects/tor/ticket/22476#comment:5 related
 discussion on #22476].

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