[tor-bugs] #23609 [Obfuscation/BridgeDB]: bridges.tp.o responds "Processing Failed" to bridge fetch attempts

[Tor Bug Tracker & Wiki]

#23609: bridges.tp.o responds "Processing Failed" to bridge fetch attempts
--+--
 Reporter:  arma  |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Go to
 https://bridges.torproject.org/
 click 'bridges' in step 2
 Now you're on
 https://bridges.torproject.org/options
 Click "Just give me bridges"
 and it brings me to a page called
 https://bridges.torproject.org/bridges
 and the content of this page is simply "Processing Failed".

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

Re: [tor-bugs] #23607 [Core Tor/Tor]: control_event_bootstrap_problem() should ignore "early" problems instead of asserting

[Tor Bug Tracker & Wiki]

#23607: control_event_bootstrap_problem() should ignore "early" problems 
instead of
asserting
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * status:  assigned => needs_review


Comment:

 Proposed fix in https://oniongit.eu/catalyst/tor/merge_requests/5
 Note this also includes the patch for #23606.  Thanks to arma for
 suggesting this approach.

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

Re: [tor-bugs] #23606 [Core Tor/Tor]: incorrect clock skew sign convention in or_state_load()

[Tor Bug Tracker & Wiki]

#23606: incorrect clock skew sign convention in or_state_load()
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  clock-skew|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * status:  assigned => needs_review


Comment:

 Proposed fix in https://oniongit.eu/catalyst/tor/merge_requests/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] #22110 [Core Tor/Tor]: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec

[Tor Bug Tracker & Wiki]

#22110: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  easy, tor-spec, spec  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:5 nickm]:
 > I've tried doing a simple change here, to ratify the existing behavior,
 in torspec branch bug22110. What do you think?

 This looks good to me. Let's get it merged, to document the behaviour up
 to at least 0.3.2.

 Replying to [comment:6 nickm]:
 > another option here might be to remove TOR_BUILD_TAG. Does anyone use
 it?

 I have no 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] #23608 [Core Tor/Tor]: Some channelpadidng tests still use unmocked time

[Tor Bug Tracker & Wiki]

#23608: Some channelpadidng tests still use unmocked time
--+--
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mikeperry):

 * status:  assigned => needs_review


Comment:

 Ok. The patch is in mikeperry/bug23608
 (d7e9f7b6633cd1d1975d252063c095478da909f1). I mock time for all the tests
 now, even the ones that don't use timers. Just in case.

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

[tor-bugs] #23608 [Core Tor/Tor]: Some channelpadidng tests still use unmocked time

[Tor Bug Tracker & Wiki]

#23608: Some channelpadidng tests still use unmocked time
--+---
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 I missed a couple tests in my rush to get the patch done for the merge
 window. Embarrassing. Patch to follow shortly.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23607 [Core Tor/Tor]: control_event_bootstrap_problem() should ignore "early" problems instead of asserting

[Tor Bug Tracker & Wiki]

#23607: control_event_bootstrap_problem() should ignore "early" problems 
instead of
asserting
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The `clock_skew_warning()` refactoring can allow calls to
 `control_event_bootstrap_problem()` prior to bootstrap phase 0, causing an
 assertion failure.  (Clock skew in a state file is one possibility.)
 Instead of asserting, ignore such calls, because they seem to always have
 another logging path.

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

Re: [tor-bugs] #15508 [Metrics/Atlas]: Make uptime sorting numeric and take the actual unit into account

[Tor Bug Tracker & Wiki]

#15508: Make uptime sorting numeric and take the actual unit into account
---+-
 Reporter:  cypherpunks|  Owner:  phw
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by teor):

 No

 > Update: Bandwidth and IP address sorting are now fixed, but uptime
 sorting
 still needs addressing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23606 [Core Tor/Tor]: incorrect clock skew sign convention in or_state_load()

[Tor Bug Tracker & Wiki]

#23606: incorrect clock skew sign convention in or_state_load()
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  clock-skew
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 `or_state_load()` uses an incorrect sign convention for clock skew, which
 causes the log message from `clock_skew_warning()` to be worded
 incorrectly we have warped backward in time since we last wrote our state
 file.  The correct convention is skew is negative if our clock is behind
 (in the past relative to) the reference.

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

Re: [tor-bugs] #23384 [Applications/Tor Browser]: Configure VM for Tor Browser builds

[Tor Bug Tracker & Wiki]

#23384: Configure VM for Tor Browser builds
--+--
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201709  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * cc: pospeselr (added)


Comment:

 pospeselr: you also send me your ssh key if you want to get access to this
 VM for doing some Tor Browser builds.

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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by cypherpunks):

 Replying to [comment:58 gk]:
 > Replying to [comment:57 cypherpunks]:
 > > Replying to [comment:54 gk]:
 > > > `bug_16010_v4` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=bug_16010_v4) has the `tor-browser` patches for review.
 https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_16010_v4=03833cf4c2a833f6e5420e92368ac2dae1b99c70
 has the additional code changes I needed to apply.
 > > This makes NPAPI and GMP to fail silently. Gaining a sandbox for
 plugins seems to be worth fixing the problem with underscores.
 >
 > Actually not NPAPI which would not be much of a problem.
 Some mozillians may think NPAPI was removed, and Flash is working through
 some magic. But that's not the case, and sandbox for it is really needed.
 > So, currently this would only affect GMPs but that's a thing we don't
 support out-of-the-box either. We don't want to have DRM GMPs and the
 OpenH264 one is not useful as we are disabling WebRTC.
 WebRTC is needed too (but without holes).
 > That said Mozilla wants to get away from `SANDBOX_EXPORTS` as well, so
 this seems not a bad direction to move in and allows us to use our scarce
 resources somewhere else.
 Do they want to rename all their processes to firefox.exe? (Previous
 attempt failed.)
 > If anybody wants to investigate the underscores issue, please do. I'd
 like to know what's up with that one.
 It seemed Jacek liked such issues :) If so, ni him again.
 But, doesn't it work without underscores with patching
 https://dxr.mozilla.org/mozilla-
 esr52/source/security/sandbox/chromium/sandbox/win/src/interception.h#238?

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

Re: [tor-bugs] #23303 [Core Tor/Tor]: hs: Explain why we reset the directory connection timestamp client side

[Tor Bug Tracker & Wiki]

#23303: hs: Explain why we reset the directory connection timestamp client side
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #23300   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by mikeperry):

 The comment and the associated code were Roger's and Nick's from 2005 and
 2011, respectively.. But the effect of the lines is that this circuit is
 now considered fresh by the various timeout things that care. Since this
 is on an entry conn (and not a circuit), I'm guessing that the applicable
 timeouts would be stream and general connection timeouts. I've not worked
 on those. I've only worked on circuit and orconn timeouts.

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

Re: [tor-bugs] #17689 [Metrics/Consensus Health]: Use extra-info fields for download times

[Tor Bug Tracker & Wiki]

#17689: Use extra-info fields for download times
--+--
 Reporter:  tom   |  Owner:  tom
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * owner:  Tom => tom
 * status:  new => assigned


Comment:

 Reassigning to the lower-case tom person.

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

Re: [tor-bugs] #17738 [Metrics/Compass]: Remove obsolete Advertised Bandwidth column (was: Compass doesn't aggreagte advertised bandwidth by country)

[Tor Bug Tracker & Wiki]

#17738: Remove obsolete Advertised Bandwidth column
-+--
 Reporter:  teor |  Owner:  metrics-team
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 You're right, the advertised bandwidth percentages are all 0. But that's
 not an issue of aggregation, it's because Onionoo doesn't provide these
 values anymore. Let me change this ticket to one for removing this
 obsolete column.

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

Re: [tor-bugs] #23590 [Applications/Tor Browser]: Tor Browser needs write access to /dev/shm

[Tor Bug Tracker & Wiki]

#23590: Tor Browser needs write access to /dev/shm
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Replying to [comment:2 gk]:
 > Looking around I am actually not convinced this is a Tor Browser bug.
 Chrome has even an own error message for that pointing to chmod 1777:
 > {{{
 > [4856:4856:0820/085005:ERROR:shared_memory_posix.cc(258)] Unable to
 access(W_OK|X_OK) /dev/shm: Permission denied
 > [4856:4856:0820/085005:FATAL:shared_memory_posix.cc(260)] This is
 frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod
 1777 /dev/shm' to fix.
 > }}}

 Yeah it's not.  Normal users should be able to (among other things) create
 POSIX shared memory objects via `shm_open()`, and it is reasonable to
 expect that this will succeed.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #6450, #6619, #6639, #6648, ...

[Tor Bug Tracker & Wiki]

Batch modification to #6450, #6619, #6639, #6648, #6713, #7568, #7640, #7744, 
#7834, #7879, #8054, #8461, #8498, #9350, #9993, #10001, #10859, #11434, #17738 
by karsten:


Action: reassign

Comment:
I believe that gsathya has stopped working on any of these tickets quite a 
while ago. Reassigning to the friendly metrics-team user. (gsathya, thanks for 
having worked on all these tickets back when you did!)

--
Tickets URL: 

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

Re: [tor-bugs] #18048 [Metrics/Atlas]: Update Atlas's jQuery

[Tor Bug Tracker & Wiki]

#18048: Update Atlas's jQuery
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  assigned
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * owner:  RaBe => irl
 * status:  new => assigned


Comment:

 I believe that RaBe is not actively working on this ticket anymore. irl,
 it's all yours. :)

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

Re: [tor-bugs] #23536 [Internal Services/Service - trac]: Traceback thrown at my face when trying to connect to Trac

[Tor Bug Tracker & Wiki]

#23536: Traceback thrown at my face when trying to connect to Trac
--+-
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 Got this instead of logging in. And this in console:
 {{{
 20:18:36.215 NS_BINDING_ABORTED: Component returned failure code:
 0x804b0002 (NS_BINDING_ABORTED) [nsIStreamListener.onDataAvailable] 1
 WebRequest.jsm:355
 }}}

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

Re: [tor-bugs] #23522 [Metrics/Atlas]: Improve tooltip on DNS name field (and maybe title) (was: tooltip on dns name field (and maybe title) could need improvement)

[Tor Bug Tracker & Wiki]

#23522: Improve tooltip on DNS name field (and maybe title)
---+-
 Reporter:  irl|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Tweak summary.

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

Re: [tor-bugs] #22346 [Metrics/Statistics]: Investigate drop in Tor Browser update pings in early 2017, possibly caused by update URL change (was: tor browser update URL change and the update ping met

[Tor Bug Tracker & Wiki]

#22346: Investigate drop in Tor Browser update pings in early 2017, possibly 
caused
by update URL change
+--
 Reporter:  cypherpunks |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 Tweak summary.

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

Re: [tor-bugs] #23544 [Metrics/Onionoo]: Add recommended_version parameter (was: add recommended_version parameter)

[Tor Bug Tracker & Wiki]

#23544: Add recommended_version parameter
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Capitalize summary.

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

Re: [tor-bugs] #23509 [Metrics/Atlas]: Implement family-level pages showing aggregated graphs (was: implement family-level pages showing aggregated graphs)

[Tor Bug Tracker & Wiki]

#23509: Implement family-level pages showing aggregated graphs
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Capitalize summary.

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

Re: [tor-bugs] #22423 [Metrics/Website]: Refactor plot_networksize() to use modern R packages and methods (was: plot_networksize() refactor)

[Tor Bug Tracker & Wiki]

#22423: Refactor plot_networksize() to use modern R packages and methods
+--
 Reporter:  johnbwilliams   |  Owner:  metrics-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Website |Version:
 Severity:  Minor   | Resolution:
 Keywords:  plot_networksize()  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 Tweak summary.

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

Re: [tor-bugs] #22193 [Metrics/Onionoo]: Add HTML IDs to Onionoo's protocol page for direct referencing (was: add html IDs to the onionoo website for direct referencing)

[Tor Bug Tracker & Wiki]

#22193: Add HTML IDs to Onionoo's protocol page for direct referencing
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Tweak summary.

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

Re: [tor-bugs] #21389 [Metrics/Onionoo]: Support searches for effective family (strict and non strict maching) (was: allow to search for effective family (strict and non strict maching))

[Tor Bug Tracker & Wiki]

#21389: Support searches for effective family (strict and non strict maching)
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Tweak summary.

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

Re: [tor-bugs] #21230 [Metrics/Atlas]: Work with a restrictive CSP policy (was: Atlas should work with a restrictive CSP policy)

[Tor Bug Tracker & Wiki]

#21230: Work with a restrictive CSP policy
-+
 Reporter:  cypherpunks  |  Owner:  cypherpunks
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics/Atlas|Version:
 Severity:  Normal   | Resolution:
 Keywords:  security,css,javascript,csp  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 Simplify summary.

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

Re: [tor-bugs] #23602 [Core Tor/Tor]: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)

[Tor Bug Tracker & Wiki]

#23602: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)
--+
 Reporter:  hellais   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Branch `ticket23602_029` in my public repository has an example of what
 I'm thinking of here. It's based on maint-0.2.9, but should merge cleanly
 to master.  It works for me on OSX with homebrew.  Does it work for you?

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

Re: [tor-bugs] #21087 [Metrics/CollecTor]: Separate truncated descriptor(s) from next complete descriptor (was: What is @source?)

[Tor Bug Tracker & Wiki]

#21087: Separate truncated descriptor(s) from next complete descriptor
---+--
 Reporter:  atagar |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-help   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Change the summary to reflect what a possible solution could be 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] #23590 [Applications/Tor Browser]: Tor Browser needs write access to /dev/shm

[Tor Bug Tracker & Wiki]

#23590: Tor Browser needs write access to /dev/shm
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Looking around I am actually not convinced this is a Tor Browser bug.
 Chrome has even an own error message for that pointing to chmod 1777:
 {{{
 [4856:4856:0820/085005:ERROR:shared_memory_posix.cc(258)] Unable to
 access(W_OK|X_OK) /dev/shm: Permission denied
 [4856:4856:0820/085005:FATAL:shared_memory_posix.cc(260)] This is
 frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod
 1777 /dev/shm' to fix.
 }}}

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pospeselr):

 Is there a firefox #define for the major version already in use to place
 these changes behind?

 Replying to [comment:26 gk]:
 > Replying to [comment:25 pospeselr]:
 > > So is the consensus here that we should just #ifdef out the offending
 code and instead return empty-string for the requested data, and undo the
 user-setting change entirely?
 >
 > I think so, yes, given the power of XPCOM-based extensions which are the
 main targets of this patch.

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

Re: [tor-bugs] #20550 [Metrics/CollecTor]: Implement SanitizedBridgeExtraInfoDescriptor class that encapsulates the sanitizing logic for bridge extra-info descriptors (was: implement SanitizedBridgeEx

[Tor Bug Tracker & Wiki]

#20550: Implement SanitizedBridgeExtraInfoDescriptor class that encapsulates the
sanitizing logic for bridge extra-info descriptors
---+
 Reporter:  iwakeh |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #20542 | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Try to make the summary slightly more useful.

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

Re: [tor-bugs] #20549 [Metrics/CollecTor]: Implement SanitizedBridgeServerDescriptor class that encapsulates the sanitizing logic for bridge server descriptors (was: implement SanitizedBridgeServerDes

[Tor Bug Tracker & Wiki]

#20549: Implement SanitizedBridgeServerDescriptor class that encapsulates the
sanitizing logic for bridge server descriptors
---+
 Reporter:  iwakeh |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #20542 | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Try to make the summary slightly more useful.

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

Re: [tor-bugs] #20546 [Metrics/CollecTor]: Implement CleanUtils class for common file system operations (was: implement CleanUtils)

[Tor Bug Tracker & Wiki]

#20546: Implement CleanUtils class for common file system operations
---+--
 Reporter:  iwakeh |  Owner:  Samdney
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-help   |  Actual Points:
Parent ID:  #20518 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Let the summary reveal a bit more what this ticket is about.

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

Re: [tor-bugs] #23603 [Core Tor/Tor]: hs: Cleanup race between circuit close and free with the HS circuitmap

[Tor Bug Tracker & Wiki]

#23603: hs: Cleanup race between circuit close and free with the HS circuitmap
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 #23604 was merged some hours ago so running master now should help us get
 more information if this bug comes again.

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

Re: [tor-bugs] #20518 [Metrics/CollecTor]: Make various architecture improvements and modernizations (was: CollecTor: architecture improvements and modernization)

[Tor Bug Tracker & Wiki]

#20518: Make various architecture improvements and modernizations
---+
 Reporter:  iwakeh |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Tweak summary.

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

Re: [tor-bugs] #20489 [Metrics/CollecTor]: Add various tests for recently fixed issues (was: add tests for CollecTor)

[Tor Bug Tracker & Wiki]

#20489: Add various tests for recently fixed issues
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-help   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Make an attempt to tweak the summary a bit.

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

Re: [tor-bugs] #20430 [Metrics/Library]: Define common log levels (was: log-level definition for metrics-lib)

[Tor Bug Tracker & Wiki]

#20430: Define common log levels
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #20540   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Tweak summary.

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

Re: [tor-bugs] #23602 [Core Tor/Tor]: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)

[Tor Bug Tracker & Wiki]

#23602: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)
--+
 Reporter:  hellais   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Replying to [comment:5 nickm]:
 >Now that we require OpenSSL 1.0.1, we should look for a function that was
 introduced in OpenSSL 1.0.1.  We should probably make sure that it's
 something that libressl also has, if possible.


 TLSv1_1_method() seems like a good candidate.

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

Re: [tor-bugs] #23602 [Core Tor/Tor]: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS) (was: Fix compilation on macOS)

[Tor Bug Tracker & Wiki]

#23602: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)
--+
 Reporter:  hellais   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  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

Re: [tor-bugs] #20287 [Metrics/Website]: Perform another review of CollecTor's file protocol and fix any remaining differences to the code (was: digest computation for names of vote files in CollecTor

[Tor Bug Tracker & Wiki]

#20287: Perform another review of CollecTor's file protocol and fix any 
remaining
differences to the code
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  defect   | Status:  accepted
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #20234   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Make the summary more generic, as there seems to be more than just one
 remaining issue with this document.

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

Re: [tor-bugs] #23603 [Core Tor/Tor]: hs: Cleanup race between circuit close and free with the HS circuitmap

[Tor Bug Tracker & Wiki]

#23603: hs: Cleanup race between circuit close and free with the HS circuitmap
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 So, here's a patch I came up with when I sorta believed the above theory:
 http://paste.debian.net/987018/

 But I found a problem with the theory above:  when we call
 `hs_circuitmap_remove_circuit()` in step 4, shouldn't we _either_ hit the
 "Could not find circuit" warning, or fail the "tmp == circ"  assertion?

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

Re: [tor-bugs] #20234 [Metrics/Website]: Add CollecTor's file-structure protocol (was: add CollecTor's file-structure protocol to Metrics-web)

[Tor Bug Tracker & Wiki]

#20234: Add CollecTor's file-structure protocol
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_information
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Capitalize and simplify summary.

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

Re: [tor-bugs] #19754 [Metrics/Statistics]: Restructure metrics-web backend (was: restructure metrics-web backend)

[Tor Bug Tracker & Wiki]

#19754: Restructure metrics-web backend
+
 Reporter:  iwakeh  |  Owner:  iwakeh
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by karsten):

 Capitalize summary.

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

Re: [tor-bugs] #19650 [Metrics/Onionoo]: Keep non-printable characters out of details documents (was: do not include non-printable strings in details documents)

[Tor Bug Tracker & Wiki]

#19650: Keep non-printable characters out of details documents
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Old description:

> Future Tor will not publish non-ASCII descriptors and dir auths will
> reject them at some point.
>
> Since this is quite far in the future, what do you think about removing
> such strings in onionoo (before it reaches tor)?
> I'm not suggesting to ignore the entire descriptor in such a case but
> just replace such chars with "?" ?
> "??B`?
" -> "??B`??"
>
> https://atlas.torproject.org/#details/21E84B294794821E2898E8ED18402E45E4FC351E
>
> Note: I used "non-printable" (vs. non-ASCII) since onionoo data includes
> printable but non-ASCII chars.
>
> https://lists.torproject.org/pipermail/tor-relays/2016-July/009667.html
>
> related:
> [1] https://trac.torproject.org/projects/tor/ticket/19647
> [2] https://trac.torproject.org/projects/tor/ticket/18938

New description:

 Future Tor will not publish non-ASCII descriptors and dir auths will
 reject them at some point.

 Since this is quite far in the future, what do you think about removing
 such strings in onionoo (before it reaches tor)?
 I'm not suggesting to ignore the entire descriptor in such a case but just
 replace such chars with "?" ?
 "??B`?" -> "??B`??"

 https://atlas.torproject.org/#details/21E84B294794821E2898E8ED18402E45E4FC351E

 Note: I used "non-printable" (vs. non-ASCII) since onionoo data includes
 printable but non-ASCII chars.

 https://lists.torproject.org/pipermail/tor-relays/2016-July/009667.html

 related:
 [1] https://trac.torproject.org/projects/tor/ticket/19647
 [2] https://trac.torproject.org/projects/tor/ticket/18938

--

Comment (by karsten):

 Tweak summary.

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

Re: [tor-bugs] #19611 [Metrics]: Make all Metrics Java projects confirm to guidelines (was: Metrics java projects should confirm to guidelines)

[Tor Bug Tracker & Wiki]

#19611: Make all Metrics Java projects confirm to guidelines
-+
 Reporter:  iwakeh   |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 Tweak summary.

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

Re: [tor-bugs] #11434 [Metrics/Compass]: Make various UI improvements (was: select only non-exit relays, related items)

[Tor Bug Tracker & Wiki]

#11434: Make various UI improvements
-+-
 Reporter:  grarpamp |  Owner:  gsathya
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * severity:   => Normal


Comment:

 Reflect in the summary that this ticket is about a little bit of
 everything. And it's probably moot anyway, because Compass is even less
 maintained now than 3 years ago. But let's keep it open for now. Maybe
 some of the ideas here can survive and be carried over to Atlas, who
 knows.

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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Replying to [comment:57 cypherpunks]:
 > Replying to [comment:54 gk]:
 > > `bug_16010_v4` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=bug_16010_v4) has the `tor-browser` patches for review.
 https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_16010_v4=03833cf4c2a833f6e5420e92368ac2dae1b99c70
 has the additional code changes I needed to apply.
 > This makes NPAPI and GMP to fail silently. Gaining a sandbox for plugins
 seems to be worth fixing the problem with underscores.

 Actually not NPAPI which would not be much of a problem. So, currently
 this would only affect GMPs but that's a thing we don't support out-of-
 the-box either. We don't want to have DRM GMPs and the OpenH264 one is not
 useful as we are disabling WebRTC.

 That said Mozilla wants to get away from `SANDBOX_EXPORTS` as well, so
 this seems not a bad direction to move in and allows us to use our scarce
 resources somewhere else.

 If anybody wants to investigate the underscores issue, please do. I'd like
 to know what's up with that one.

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

Re: [tor-bugs] #10859 [Metrics/Compass]: Make URL reusable even without explicitly specifying the number of results (was: compass url not reusable if you don't specify number of results)

[Tor Bug Tracker & Wiki]

#10859: Make URL reusable even without explicitly specifying the number of 
results
-+-
 Reporter:  arma |  Owner:  gsathya
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * severity:   => Normal


Comment:

 Tweak summary.

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

Re: [tor-bugs] #19368 [Metrics]: Metrics Team FAQ

[Tor Bug Tracker & Wiki]

#19368: Metrics Team FAQ
-+
 Reporter:  iwakeh   |  Owner:  (none)
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

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


Comment:

 I don't think that we need to keep this ticket open. We can always edit
 the wiki to make the team FAQ there more accurate. And the "Funding"
 section already says that it "probably belongs into a Tor Project's FAQ".
 Closing.

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

Re: [tor-bugs] #19169 [Metrics/CollecTor]: Verify, correct, and extend runtime statistics (was: verify, correct and extend runtime statistics)

[Tor Bug Tracker & Wiki]

#19169: Verify, correct, and extend runtime statistics
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Tweak summary a bit.

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

Re: [tor-bugs] #18354 [Metrics/Onionoo]: flush cached host_name on IP change

[Tor Bug Tracker & Wiki]

#18354: flush cached host_name on IP change
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

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


Comment:

 I just checked again and couldn't find a single relay with an IP address
 in the `"host_name"` field that did not match an entry in
 `"onion_addresses"`. Maybe the examples given in comment 3 above came from
 non-running relays. Closing as fixed.

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 Replying to [comment:25 pospeselr]:
 > So is the consensus here that we should just #ifdef out the offending
 code and instead return empty-string for the requested data, and undo the
 user-setting change entirely?

 I think so, yes, given the power of XPCOM-based extensions which are the
 main targets of this patch.

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

Re: [tor-bugs] #18342 [Metrics/Onionoo]: Provide more accurate reverse DNS results (was: onionoo has poor reverse DNS results)

[Tor Bug Tracker & Wiki]

#18342: Provide more accurate reverse DNS results
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 Make an summary more accurate (at least).

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

Re: [tor-bugs] #13562 [Metrics/Onionoo]: Add more detailed logging to backend and frontend components (was: additional logging for backend and frontend components)

[Tor Bug Tracker & Wiki]

#13562: Add more detailed logging to backend and frontend components
-+
 Reporter:  iwakeh   |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #20540   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 Tweak the summary a bit.

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

Re: [tor-bugs] #9929 [Metrics/Compass]: compass doesn't display more than 10 relays in a given AS

[Tor Bug Tracker & Wiki]

#9929: compass doesn't display more than 10 relays in a given AS
-+
 Reporter:  cypherpunks  |  Owner:  gsathya
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:  worksforme
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

 * status:  new => closed
 * resolution:   => worksforme
 * severity:   => Normal


Comment:

 I can't reproduce this. Maybe this was fixed at some point in the last 4
 years without updating this ticket. Closing.

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

Re: [tor-bugs] #8857 [Metrics/Compass]: Unknown/null AS not searchable

[Tor Bug Tracker & Wiki]

#8857: Unknown/null AS not searchable
-+-
 Reporter:  jn   |  Owner:  gsathya
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * status:  new => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 Sounds like there exists a workaround for this rather atypical use case.
 Closing.

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

Re: [tor-bugs] #8505 [Metrics/Compass]: ExitCompass: statistics about Fast Exits

[Tor Bug Tracker & Wiki]

#8505: ExitCompass: statistics about Fast Exits
-+-
 Reporter:  mo   |  Owner:  gsathya
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * status:  new => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 I believe that either the "Exit Reimbursement Program" has ended long ago,
 or that whoever is in charge for that has found an alternative solution.
 Closing.

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

Re: [tor-bugs] #8328 [Metrics/Compass]: compass lists first 10 but says it defaults to all

[Tor Bug Tracker & Wiki]

#8328: compass lists first 10 but says it defaults to all
-+-
 Reporter:  arma |  Owner:  gsathya
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 I believe this is fixed. Either that, or I don't understand the issue.
 Closing as fixed.

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

Re: [tor-bugs] #6703 [Metrics/Compass]: Replace Exit and Guard flag checkboxes with radio buttons (off, yes, no) (was: replace exit & guard flag checkboxes with radio buttons (off, yes, no))

[Tor Bug Tracker & Wiki]

#6703: Replace Exit and Guard flag checkboxes with radio buttons (off, yes, no)
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

 * severity:   => Normal


Comment:

 Tweak summary a bit.

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

Re: [tor-bugs] #6701 [Metrics/Compass]: .onion domains for onionoo.tpo, atlas.tpo & compass.tpo

[Tor Bug Tracker & Wiki]

#6701: .onion domains for onionoo.tpo, atlas.tpo & compass.tpo
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

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


Comment:

 Done. See https://onion.torproject.org/. Closing.

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

Re: [tor-bugs] #6696 [Metrics/Compass]: add Byte/s to Advertised Bandwidth column

[Tor Bug Tracker & Wiki]

#6696: add Byte/s to Advertised Bandwidth column
-+-
 Reporter:  cypherpunks  |  Owner:  gsathya
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * status:  needs_review => closed
 * resolution:   => invalid
 * severity:   => Normal


Comment:

 Oh, this ticket has become invalid over the years. Onionoo's protocol
 version 2.1 ''"Removed optional "advertised_bandwidth_fraction" field from
 details documents and optional "advertised_bandwidth" and
 "advertised_bandwidth_fraction" fields from weights documents on November
 16, 2014."'' Closing as, hmm, 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] #23536 [Internal Services/Service - trac]: Traceback thrown at my face when trying to connect to Trac

[Tor Bug Tracker & Wiki]

#23536: Traceback thrown at my face when trying to connect to Trac
--+-
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by hiro):

 We had it reported a second time already:

 !https://share.riseup.net/#D4m1msk857NknWZT-qNdcg

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

Re: [tor-bugs] #6730 [Metrics/Compass]: Display newly added or recently disappeared relays or bridges (was: A way to see changes in datasets over time)

[Tor Bug Tracker & Wiki]

#6730: Display newly added or recently disappeared relays or bridges
-+
 Reporter:  mo   |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

 * severity:   => Normal


Comment:

 Try to make the summary more accurate/useful.

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

Re: [tor-bugs] #6856 [Metrics/Website]: Add graph on bandwidth by major Tor version and bandwidth by recommended flag (was: new graph: bandwidth by major Tor version and bandwidth by recommended flag)

[Tor Bug Tracker & Wiki]

#6856: Add graph on bandwidth by major Tor version and bandwidth by recommended
flag
-+--
 Reporter:  cypherpunkx  |  Owner:  metrics-team
 Type:  enhancement  | Status:  assigned
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * severity:   => Normal


Comment:

 Tweak summary a bit.

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

Re: [tor-bugs] #22733 [Metrics/Library]: Use parameterized tests instead of repeated methods (was: use parameterized tests instead of repeated methods)

[Tor Bug Tracker & Wiki]

#22733: Use parameterized tests instead of repeated methods
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Capitalize summary.

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

Re: [tor-bugs] #22583 [Metrics/Library]: Replace code where we iterate over a directory using a Stack with FileVisitor (was: use FileVisitor)

[Tor Bug Tracker & Wiki]

#22583: Replace code where we iterate over a directory using a Stack with
FileVisitor
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Make an attempt to make the summary a bit clearer.

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

Re: [tor-bugs] #22696 [Metrics/Library]: Create a test collection for the entire API (was: create a test collection for the entire metrics-lib API)

[Tor Bug Tracker & Wiki]

#22696: Create a test collection for the entire API
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Tweak summary a bit.

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

Re: [tor-bugs] #22185 [Metrics/Atlas]: Add red unmeasured icon to properties (was: add red unmeasured icon to properties)

[Tor Bug Tracker & Wiki]

#22185: Add red unmeasured icon to properties
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Capitalize summary.

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

Re: [tor-bugs] #22147 [Metrics/Atlas]: Add Onionoo's exit_addresses field (was: add exit_addresses onionoo field)

[Tor Bug Tracker & Wiki]

#22147: Add Onionoo's exit_addresses field
---+
 Reporter:  cypherpunks|  Owner:  cypherpunks
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Use more capital letters in summary.

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

Re: [tor-bugs] #21959 [Metrics/Atlas]: Expose relays_published on search/results and relays page (was: expose relays_published on search/results and relays page)

[Tor Bug Tracker & Wiki]

#21959: Expose relays_published on search/results and relays page
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Capitalize summary.

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

Re: [tor-bugs] #22297 [Metrics/Atlas]: Show graphs in "table" format (was: show graphs in "table" format)

[Tor Bug Tracker & Wiki]

#22297: Show graphs in "table" format
---+-
 Reporter:  Hello71|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Capitalize summary, though it remains a bit cryptic to me what a "table"
 format is.

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

Re: [tor-bugs] #21368 [Metrics/Atlas]: Add number of effective family members to search output page (was: add number of effective family members to search output page)

[Tor Bug Tracker & Wiki]

#21368: Add number of effective family members to search output page
---+
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Capitalize summary.

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

Re: [tor-bugs] #22428 [Metrics/CollecTor]: Add webstats module (was: add webstats module to collector)

[Tor Bug Tracker & Wiki]

#22428: Add webstats module
---+---
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_information
 Priority:  High   |  Milestone:  CollecTor 1.4.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by karsten):

 Tweak the summary (start with capital letter, remove redundant component
 name).

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

Re: [tor-bugs] #20983 [Metrics/CollecTor]: Stop sanitizing contact information from bridge descriptors (was: bridge ContactInfo information (less sanitization))

[Tor Bug Tracker & Wiki]

#20983: Stop sanitizing contact information from bridge descriptors
---+--
 Reporter:  cypherpunks|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Tweak the summary a bit.

 FWIW, there's now a [https://metrics.torproject.org/bridge-
 descriptors.html specification for sanitized bridge descriptors].

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

Re: [tor-bugs] #19654 [Metrics/Atlas]: Handle situations more gracefully when SVG is disabled (like in Tor Browser's High Security mode) (was: Atlas doesn't work with TBB high security)

[Tor Bug Tracker & Wiki]

#19654: Handle situations more gracefully when SVG is disabled (like in Tor
Browser's High Security mode)
---+-
 Reporter:  cypherpunks|  Owner:  phw
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Try to make the summary more useful.

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

Re: [tor-bugs] #18797 [Metrics/Library]: Create a DescriptorGenerator for testing and maybe other purposes (was: create a DescriptorGenerator?)

[Tor Bug Tracker & Wiki]

#18797: Create a DescriptorGenerator for testing and maybe other purposes
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  assigned
 Priority:  Low  |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Tweak the summary a bit.

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

Re: [tor-bugs] #23376 [Webpages/Webtools]: Build survey form for Onion Browser branding research

[Tor Bug Tracker & Wiki]

#23376: Build survey form for Onion Browser branding research
---+--
 Reporter:  isabela|  Owner:  hiro
 Type:  project| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages/Webtools  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by sjmurdoch):

 I've used [https://www.limesurvey.org/ LimeSurvey] which meets criteria 1,
 4, 6, probably 5, and potentially could be modified to meet the others. It
 might be worth a look.

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

Re: [tor-bugs] #23604 [Core Tor/Tor]: Improve circuit logging

[Tor Bug Tracker & Wiki]

#23604: Improve circuit logging
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  tor-log, tor-circuit, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 sure; merged!

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

Re: [tor-bugs] #22110 [Core Tor/Tor]: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec

[Tor Bug Tracker & Wiki]

#22110: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  easy, tor-spec, spec  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #22110 [Core Tor/Tor]: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec

[Tor Bug Tracker & Wiki]

#22110: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  easy, tor-spec, spec  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => assigned
 * owner:  (none) => nickm


Comment:

 setting owner

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

Re: [tor-bugs] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

[Tor Bug Tracker & Wiki]

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

[Tor Bug Tracker & Wiki]

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => assigned
 * owner:  (none) => dgoulet


Comment:

 setting owner

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

Re: [tor-bugs] #23420 [Core Tor/Tor]: prop224: Pad RENDEZVOUS1 cell to match legacy cell length

[Tor Bug Tracker & Wiki]

#23420: prop224: Pad RENDEZVOUS1 cell to match legacy cell length
+--
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, prop224-extra, tor-hs  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 Don't use crypto_strongest_rand() unless you need an extra hash.

 Personally, I believe that the "don't expose PRNG bytes to the world"
 wisdom is bad, but if you want to avoid it, pass 32 bytes of crypto_rand()
 output through SHAKE?

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

Re: [tor-bugs] #22276 [Core Tor/Tor]: Merge prop220/prop244 to tor-spec/dir-spec

[Tor Bug Tracker & Wiki]

#22276: Merge prop220/prop244 to tor-spec/dir-spec
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Done in 85e4033f9c4640998e8edbfc1502e092515934e5 and related commits.

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

Re: [tor-bugs] #22861 [Core Tor/Tor]: Update tor-spec for ed25519 link authentication keys

[Tor Bug Tracker & Wiki]

#22861: Update tor-spec for ed25519 link authentication keys
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal| Resolution:  implemented
 Keywords:  spec  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Done in 85e4033f9c4640998e8edbfc1502e092515934e5

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pospeselr):

 So is the consensus here that we should just #ifdef out the offending code
 and instead return empty-string for the requested data, and undo the user-
 setting change entirely?

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

Re: [tor-bugs] #23603 [Core Tor/Tor]: hs: Cleanup race between circuit close and free with the HS circuitmap

[Tor Bug Tracker & Wiki]

#23603: hs: Cleanup race between circuit close and free with the HS circuitmap
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by dgoulet:

Old description:

> Here is the scenario that has been encountered by asn. The following is
> in chronological order:
>
> 1. [02:21:27] An intro point (IP) is picked and circuit A is launched.
>
> 2. [02:23:47] Circuit A never completes and thus is '''marked for
> close''' which is NOT free thus still in our HS circuitmap.
>
> 2. [02:23:48] A second later, the HS housekeeping kicks in (every 1 sec)
> and we notice that we are missing a circuit for this IP so we launch a
> new circuit B. What happens then is this new circuit B takes the place of
> circuit A in the HS circuitmap with the *same* hs_token (the token in
> this case is the IP authentication public key).
>
> At this point, we have circuit A marked for close and we have circuit B
> that was launched and replaced circuit A with the same hs_token which
> identify the IP. So far so good.
>
> 3. [02:23:48] At the same second, we get a `circuit_build_failed()` which
> is only called from
> `circuit_about_to_free()`->`circuit_close_all_marked()` which means it is
> freeing circuit '''A''' leading to a `hs_circuitmap_remove_circuit()`
> which will use its `hs_token` to remove circuit B because it is the same
> token.
>
> We end up with no circuit for the intro point IP in our circuitmap.
>
> 4. [02:23:49] A second after our circuit build failed which removed
> circuit B from the circuitmap, we cleanup the IP from our list through
> the house keeping and we launch a new circuit to a new intro point. The
> reason why we removed the IP is either because it has expire, no `node_t`
> could be found or we retried too many times on that circuit which the
> allowed number of retries is 3 right now. When we do remove an IP from
> our service list, we also try to close the circuit but because circuit B
> got removed from the circuitmap, we can't find it thus it is not closed.
>
> 5. [02:24:54] Circuit B completes but we are unable to find the IP in our
> service list. And boom we get the warning:
>
> In summary, we end up with an intro circuit being established but not in
> our circuitmap leading to the failed lookup when we remove that IP from
> our service list for whatever reason.
>
> Seems like one thing we could do is actually remove a circuit from the HS
> circuitmap when we mark for close because at that point, the circuit is
> good as dead. We avoid this race between mark for close and actually
> being freed where in between a new circuit to the same destination with
> the same hs_token can be launched.

New description:

 Here is the scenario that has been encountered by asn. The following is in
 chronological order:

 1. [02:21:27] An intro point (IP) is picked and circuit A is launched.

 2. [02:23:47] Circuit A never completes and thus is '''marked for close'''
 which is NOT free thus still in our HS circuitmap.

 3. [02:23:48] A second later, the HS housekeeping kicks in (every 1 sec)
 and we notice that we are missing a circuit for this IP so we launch a new
 circuit B. What happens then is this new circuit B takes the place of
 circuit A in the HS circuitmap with the *same* hs_token (the token in this
 case is the IP authentication public key).

 At this point, we have circuit A marked for close and we have circuit B
 that was launched and replaced circuit A with the same hs_token which
 identify the IP. So far so good.

 4. [02:23:48] At the same second, we get a `circuit_build_failed()` which
 is only called from
 `circuit_about_to_free()`->`circuit_close_all_marked()` which means it is
 freeing circuit '''A''' leading to a `hs_circuitmap_remove_circuit()`
 which will use its `hs_token` to remove circuit B because it is the same
 token.

 We end up with no circuit for the intro point IP in our circuitmap.

 5. [02:23:49] A second after our circuit build failed which removed
 circuit B from the circuitmap, we cleanup the IP from our list through the
 house keeping and we launch a new circuit to a new intro point. The reason
 why we removed the IP is either because it has expire, no `node_t` could
 be found or we retried too many times on that circuit which the allowed
 number of retries is 3 right now. When we do remove an IP from our service
 list, we also try to close the circuit but because circuit B got removed
 from the circuitmap, we can't find it thus it is not closed.

 6. [02:24:54] Circuit B completes but we are unable to 

Re: [tor-bugs] #23603 [Core Tor/Tor]: hs: Cleanup race between circuit close and free with the HS circuitmap

[Tor Bug Tracker & Wiki]

#23603: hs: Cleanup race between circuit close and free with the HS circuitmap
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [ticket:23603 dgoulet]:
 > Here is the scenario that has been encountered by asn. The following is
 in chronological order:
 >
 > 1. [02:21:27] An intro point (IP) is picked and circuit A is launched.
 >
 > 2. [02:23:47] Circuit A never completes and thus is '''marked for
 close''' which is NOT free thus still in our HS circuitmap.
 >
 > 3. [02:23:48] A second later, the HS housekeeping kicks in (every 1 sec)
 and we notice that we are missing a circuit for this IP so we launch a new
 circuit B. What happens then is this new circuit B takes the place of
 circuit A in the HS circuitmap with the *same* hs_token (the token in this
 case is the IP authentication public key).
 >
 > At this point, we have circuit A marked for close and we have circuit B
 that was launched and replaced circuit A with the same hs_token which
 identify the IP. So far so good.
 >
 > 4. [02:23:48] At the same second, we get a `circuit_build_failed()`
 which is only called from
 `circuit_about_to_free()`->`circuit_close_all_marked()` which means it is
 freeing circuit '''A''' leading to a `hs_circuitmap_remove_circuit()`
 which will use its `hs_token` to remove circuit B because it is the same
 token.
 >
 > We end up with no circuit for the intro point IP in our circuitmap.
 >
 > 5. [02:23:49] A second after our circuit build failed which removed
 circuit B from the circuitmap, we cleanup the IP from our list through the
 house keeping and we launch a new circuit to a new intro point. The reason
 why we removed the IP is either because it has expire, no `node_t` could
 be found or we retried too many times on that circuit which the allowed
 number of retries is 3 right now. When we do remove an IP from our service
 list, we also try to close the circuit but because circuit B got removed
 from the circuitmap, we can't find it thus it is not closed.
 >
 > 6. [02:24:54] Circuit B completes but we are unable to find the IP in
 our service list. And boom we get the warning:
 >
 > In summary, we end up with an intro circuit being established but not in
 our circuitmap leading to the failed lookup when we remove that IP from
 our service list for whatever reason.
 >
 > Seems like one thing we could do is actually remove a circuit from the
 HS circuitmap when we mark for close because at that point, the circuit is
 good as dead. We avoid this race between mark for close and actually being
 freed where in between a new circuit to the same destination with the same
 hs_token can be launched.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23605 [Core Tor/Tor]: BOOTSTRAP PROGRESS=80 is a lie

[Tor Bug Tracker & Wiki]

#23605: BOOTSTRAP PROGRESS=80 is a lie
-+-
 Reporter:   |  Owner:  (none)
  catalyst   |
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  bootstrap clock-skew tor-guard
 Severity:  Normal   |  usability ux
Actual Points:   |  Parent ID:  #22266
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Tor can report `BOOTSTRAP_STATUS_CONN_OR` (PROGRESS=80, "Connecting to the
 Tor network") when it actually can do no such thing.  In some situations
 (e.g., clock skew) this causes progress to get stuck at 80% indefinitely,
 resulting in very poor user experience.

 Right now `update_router_have_minimum_dir_info()` reports the
 `BOOTSTRAP_STATUS_CONN_OR` event if there's a "reasonably live" consensus
 and enough descriptors downloaded.  A client with a clock skewed several
 hours into the future can get stalled here indefinitely due to inability
 to select a guard: if the client's clock is skewed, it will never have a
 live consensus.  (Guard selection seems to require a non-expired
 consensus, rather than a reasonably live consensus at least during
 bootstrap.)

 We should either relax the guard selection consensus liveness requirement,
 or avoid reporting `BOOTSTRAP_STATUS_CONN_OR` when we have no reasonable
 chance of actually connecting to a guard for building application
 circuits.

 Arguably we shouldn't start downloading descriptors until we have a non-
 expired consensus either, because that gets represented as a considerable
 chunk of the progress bar (40%->80%) in a way that could be misleading to
 a user.  Making that change without additional work would cause bootstrap
 to get stuck at 40% instead of 80%, which might be an improvement.  This
 can already happen if the client's clock is skewed several hours in the
 past.

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

Re: [tor-bugs] #23420 [Core Tor/Tor]: prop224: Pad RENDEZVOUS1 cell to match legacy cell length

[Tor Bug Tracker & Wiki]

#23420: prop224: Pad RENDEZVOUS1 cell to match legacy cell length
+--
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, prop224-extra, tor-hs  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by dgoulet):

 The padding is very cheap to do although I think the current code takes
 the raw bytes from our PRNG so we might not want to expose that to the RP
 directly? The `crypto_strongest_rand()` is the one hashing the bytes but
 could be heavier?

 Considering the padding will in most cases pass the test, seems a win-win
 to just do it.

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

Re: [tor-bugs] #23104 [Applications/Tor Browser]: CSS line-height reveals the platform Tor Browser is running on

[Tor Bug Tracker & Wiki]

#23104: CSS line-height reveals the platform Tor Browser is running on
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-os,   |  Actual Points:
  TorBrowserTeam201709R  |
Parent ID:   | Points:
 Reviewer:  gk   |Sponsor:
-+-

Comment (by igt0):

 Great question, the css2 specification[1] says that the line height factor
 should be between 1.0 and 1.2. Mozilla uses 1.2 for some time[2] and only
 if the ascending and descending values are 0. Chrome has its own thing[3].

 That said, for the short and medium term, I think the current test makes
 sense because if the line factor changes, the test will break. I tried to
 think about a ref test instead of JS test. However the 1.2 value would be
 hardcoded on it anyway.

 [1] https://www.w3.org/TR/CSS2/visudet.html
 [2] https://developer.mozilla.org/en-US/docs/Web/CSS/line-height
 [3] https://bugs.chromium.org/p/chromium/issues/detail?id=455754

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

Re: [tor-bugs] #23604 [Core Tor/Tor]: Improve circuit logging

[Tor Bug Tracker & Wiki]

#23604: Improve circuit logging
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-log, tor-circuit, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  assigned => needs_review
 * keywords:  tor-log, tor-circuit => tor-log, tor-circuit, tor-hs


Comment:

 See branch: `ticket23604_032_01`

 There is a second commit about adding a log in the HS subsystem. I cheated
 ;). That new code path is tested with `hs_service/service_event`.

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

Re: [tor-bugs] #18101 [Applications/Tor Browser]: IP leak from Windows UI dialog with URI

[Tor Bug Tracker & Wiki]

#18101: IP leak from Windows UI dialog with URI
-+-
 Reporter:  uileak   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-disk-leak, tbb-proxy-bypass, |  Actual Points:
  TorBrowserTeam201709R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-disk-leak, tbb-proxy-bypass, TorBrowserTeam201709 => tbb-
 disk-leak, tbb-proxy-bypass, TorBrowserTeam201709R
 * status:  needs_revision => needs_review


Comment:

 Thanks for the review, gk. Here's a patch for the Linux fix only in case
 we want to put that into the alpha. I'll be testing Mac next by Georg's
 method and then go back to Windows.

 https://github.com/arthuredelstein/tor-browser/commit/18101_linux

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

Re: [tor-bugs] #23602 [Core Tor/Tor]: Fix compilation on macOS

[Tor Bug Tracker & Wiki]

#23602: Fix compilation on macOS
--+
 Reporter:  hellais   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Your questions are the answers to each other! :)

 If we make it so that only OpenSSL >= 1.0.1 passes the test, then the
 system libraries will get skipped.

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

Re: [tor-bugs] #23602 [Core Tor/Tor]: Fix compilation on macOS

[Tor Bug Tracker & Wiki]

#23602: Fix compilation on macOS
--+
 Reporter:  hellais   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by hellais):

 > The first problem is that we are detecting OpenSSL by looking for
 RAND_add(). That was once okay, but now that we require OpenSSL 1.0.1, we
 should look for a function that was introduced in OpenSSL 1.0.1. We should
 probably make sure that it's something that libressl also has, if
 possible.

 Correct me if I am wrong, but isn't this a separate issue unrelated to
 making the build system work on macOS with homebrew?

 Even if it were to pass in this case, users will in almost every case want
 to use the homebrew version of libraries if they have it installed.

 > The second problem is that our search path doesn't include
 /usr/local/opt/ and /usr/local/opt/openssl/. But we could fix that just by
 adding them.

 That is actually how I originally implemented the fix for this, but that
 will actually not work since the order in which libraries are searched for
 needs to change in macOS. The lookup order there is made to first look for
 system libraries (in this case the crummy macOS default ones) and only
 after the ones in the special prefixes. On macOS the order should be
 inverted.

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

Re: [tor-bugs] #23602 [Core Tor/Tor]: Fix compilation on macOS

[Tor Bug Tracker & Wiki]

#23602: Fix compilation on macOS
--+
 Reporter:  hellais   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 I think we need a different fix here.  Look at how we're calling
 TOR_SEARCH_LIBRARY: there are two problems.

 The first problem is that we are detecting OpenSSL by looking for
 RAND_add().  That was once okay, but now that we require OpenSSL 1.0.1, we
 should look for a function that was introduced in OpenSSL 1.0.1.  We
 should probably make sure that it's something that libressl also has, if
 possible.

 (We could probably get away with looking for a function that was
 introduced in 1.0.0, since we're trying to avoid 0.9.8 in particular.)

 The second problem is that our search path doesn't include /usr/local/opt/
 and /usr/local/opt/openssl/.  But we could fix that just by adding them.

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

Re: [tor-bugs] #23080 [Core Tor/Tor]: connection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the format of ExtORPort USERADDR

[Tor Bug Tracker & Wiki]

#23080: connection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the
format of ExtORPort USERADDR
-+-
 Reporter:  dcf  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-spec, pt-spec, needs-spec-   |  Actual Points:
  change, spec   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Thanks, dcf!  Merging now.

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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by cypherpunks):

 Replying to [comment:54 gk]:
 > `bug_16010_v4` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=bug_16010_v4) has the `tor-browser` patches for review.
 https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_16010_v4=03833cf4c2a833f6e5420e92368ac2dae1b99c70
 has the additional code changes I needed to apply.
 This makes NPAPI and GMP to fail silently. Gaining a sandbox for plugins
 seems to be worth fixing the problem with underscores.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23604 [Core Tor/Tor]: Improve circuit logging

[Tor Bug Tracker & Wiki]

#23604: Improve circuit logging
--+--
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-log, tor-circuit
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 While debugging #23603, I realized that we mix `n_circ_id` and
 `globale_identifier` in the logs which makes things difficult to match a
 circuit and sometimes it is just impossible.

 We also have no logs when we free a circuit that is going from marked as
 closed to free. The marked for close log was added recently so at least
 its that but it prints the `n_circ_id` which is not always set and thus no
 way to link it to the global identifier.

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

Re: [tor-bugs] #23602 [Core Tor/Tor]: Fix compilation on macOS

[Tor Bug Tracker & Wiki]

#23602: Fix compilation on macOS
--+
 Reporter:  hellais   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pastly):

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


Comment:

 Works for me on 10.11.6 with homebrew 1.3.2 and homebrew openssl 1.0.2l.

 Still compiles on Linux 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