Re: [tor-bugs] #28835 [Applications/Tor Browser]: Tor Shortcut not moved/removed as McAfee quarantined firefox.exe

[Tor Bug Tracker & Wiki]

#28835: Tor Shortcut not moved/removed as McAfee quarantined firefox.exe
--+--
 Reporter:  Mummydogg |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: Newbiedoo (added)


Comment:

 #28854 is a duplicate.

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

Re: [tor-bugs] #28854 [Applications/Tor Browser]: Tor file keeps getting quarantined

[Tor Bug Tracker & Wiki]

#28854: Tor file keeps getting quarantined
--+---
 Reporter:  Newbiedoo |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * owner:  (none) => tbb-team
 * status:  new => closed
 * component:  Core Tor => Applications/Tor Browser
 * resolution:   => duplicate


Comment:

 The problem is because McAfee thinks your firefox.exe is infected by some
 malware. But the more likely explanation is that McAfee is plainly wrong
 here. Please contact McAfee so they can fix that on their side and/or,
 probably even better, get rid of it. This is a duplicate of #28835.

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

Re: [tor-bugs] #28858 [Applications/Tor Browser]: I cannot enter in tor

[Tor Bug Tracker & Wiki]

#28858: I cannot enter in tor
--+---
 Reporter:  juliomolito   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * owner:  (none) => tbb-team
 * component:  - Select a component => Applications/Tor Browser
 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Please follow-up in #28834 you already opened, thanks. Duplicate of
 #28834.

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

Re: [tor-bugs] #28855 [Applications/Tor Browser]: Blank item in Help menu

[Tor Bug Tracker & Wiki]

#28855: Blank item in Help menu
--+---
 Reporter:  sparklingfart |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duplicate of #22942.

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

Re: [tor-bugs] #22942 [Applications/Tor Browser]: Empty menuitem below "About Tor Browser"

[Tor Bug Tracker & Wiki]

#22942: Empty menuitem below "About Tor Browser"
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: sparklingfart (added)


Comment:

 #28855 is a duplicate.

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

Re: [tor-bugs] #20746 [Applications/Tor Browser]: TBB - What are /tmp/0123.mlf files (where 0123 is PID of Firefox)

[Tor Bug Tracker & Wiki]

#20746: TBB - What are /tmp/0123.mlf files (where 0123 is PID of Firefox)
--+--
 Reporter:  ronvandaal_   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:  #23073| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * parent:   => #23073


Comment:

 Those files are Selfrando's memory layout files. See:
 https://lists.torproject.org/pipermail/tbb-dev/2017-May/000537.html ff.
 for further information.

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

Re: [tor-bugs] #28868 [Core Tor/sbws]: best_priority() can starve the worker threads of good relays

[Tor Bug Tracker & Wiki]

#28868: best_priority() can starve the worker threads of good relays
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 Replying to [ticket:28868 teor]:
 > `best_priority()` tries to measure unmeasured and failing relays first.
 >
 > But if `fraction_relays` or `min_relays` always fail, those relays will
 always end up first in the priority queue. (More precisely, those relays
 will end up first in the priority queue, until the results of the good
 relays ~~time out~~ are discarded for being too old.)
 >
 > Thinking about starvation is complicated, because of the
 `freshness_reduction_factor` on some errors.
 >
 > Here's a very simple algorithm that avoids starving good relays for
 failed relays:
 > 1. Count the number of times that sbws has attempted to get a result
 from each relay.

 This is already done when writing the results: ResultError and
 ResultSuccess keep that.

 > 2. Test the relays with the lowest number of attempts first. (Don't
 check if the attempt succeeded or failed.)

 This's what i was proposing by commenting the part where it prioritizes
 ResultError measurements.
 >
 > For this priority rule to work, every time a relay is queued, it must
 get a result. Here's how we can make that happen"
 > * Modify `result_putter_error()` to store an error result to the queue.

 result_putter already writes ResultError.

 Here there're two other bugs, result_putter_error, only happens when:
 1. The relay being measured, doesn't have a descriptor (#28870)
 2. The operator hits KeyboardInterrupt (#28869)

 AFAIK, there're no other cases where the error callback is called.
 > * Make sure timeouts store an error result to the queue.
 > * Add a unit test and integration test that makes sure every queued
 relay has a result.

 Testing this is hard, but i'll see.

 > Here's an alternative that might be simpler to implement:
 > * before a relay is queued using `pool.apply_async()` in
 `run_speedtest()`, store a `ResultAttempt` to the queue
 > * only count `ResultAttempt`s when prioritising relays

 I don't see this easier. I'll evaluate after other changes has been made
 in #28663

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28870 [Core Tor/sbws]: Stop asserting when there's not a descriptor for a relay being measured

[Tor Bug Tracker & Wiki]

#28870: Stop asserting when there's not a descriptor for a relay being measured
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #28663
   Points: |   Reviewer:
  Sponsor: |
---+---
 When sbws doesn't have a descriptor for a relay that is being measured
 (but it has a network status document, and possibly the other way around),
 it raises and exception via this assert
 
(https://github.com/torproject/sbws/blob/ee64d76df54ceb3a3c9e1e2a797fd70d68bb0035/sbws/lib/relaylist.py#L45),
 which causes the error callback in the thread pool in scanner.
 Instead, it should just return None (what can also be done by getattr and
 removes redundant code), and all the logic that depends on it will just
 work fine, it just won't be choose as an exit, since there's no
 information about the exit flags, but will get measured.

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

Re: [tor-bugs] #28869 [Core Tor/sbws]: KeyboardInterrupt will cause a callback error and does not close the thread pool cleanly

[Tor Bug Tracker & Wiki]

#28869: KeyboardInterrupt will cause a callback error and does not close the 
thread
pool cleanly
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * component:  - Select a component => Core Tor/sbws


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

[tor-bugs] #28869 [- Select a component]: KeyboardInterrupt will cause a callback error and does not close the thread pool cleanly

[Tor Bug Tracker & Wiki]

#28869: KeyboardInterrupt will cause a callback error and does not close the 
thread
pool cleanly
--+---
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  sbws: 1.0.x-final
Component:  - Select a component  |Version:  sbws: 1.0.2
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #28663
   Points:|   Reviewer:
  Sponsor:|
--+---
 KeyboardInterrupt is being catched in main
 
(https://github.com/torproject/sbws/blob/ee64d76df54ceb3a3c9e1e2a797fd70d68bb0035/sbws/core/scanner.py#L394),
 it's not possible from there to call pool.close() so that the pool
 terminates the threads.
 What is more, it'll result in a callback error to the pool.
 When the operator wants to cancel sbws, it should close all the threads,
 don't call callback error, and don't show all the exceptions that the
 threads hit not being able to finish.

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

Re: [tor-bugs] #28803 [Applications/Tor Browser]: Integrate building pluggable transports for Android into tor-browser-build

[Tor Bug Tracker & Wiki]

#28803: Integrate building pluggable transports for Android into 
tor-browser-build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, TBA-a3, |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 I think starting with Pluto 2 if there are no blockers for that is the
 right thing to do. Re the sepaate project/go-android-toolchain: I am not
 sure why we would need that separate project for the compiler as we build
 Go for all the other platforms in projects/go. Why can't we add the
 necessary bits for Android there as well?

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

Re: [tor-bugs] #28823 [Applications/Tor Browser]: Every web page crashes on Windows 7 with Tor Browser 8

[Tor Bug Tracker & Wiki]

#28823: Every web page crashes on Windows 7 with Tor Browser 8
--+---
 Reporter:  testcy|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 One other thing I wondered: Do the crashes go away if you adjust your
 security slider to, say, "safer" or "safest"? (You can do so by clicking
 on the onion icon on the toolbar and selecting Security Settings...

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

Re: [tor-bugs] #28752 [Applications/Tor Browser]: Gradle sometimes downloads tor-android-binary resources during build (or the build is failing)

[Tor Bug Tracker & Wiki]

#28752: Gradle sometimes downloads tor-android-binary resources during build (or
the build is failing)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam201812, TBA-a3   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 Replying to [comment:7 sisbell]:
 > I've got the fix ready but the current build is giving me an error in
 the firefox-locale-bundle. It looks like a perl module isn't installed.
 >
 > {{{
 > Can't locate JSON.pm in @INC (you may need to install the JSON module)
 > 
 > BEGIN failed--compilation aborted at /home/shane/github/tor-
 browser-4/projects/firefox-locale-bundle/get_hg_hash line 4.
 > }}}

 Yes, you need to install that perl module on your build machine, see the
 README and the commit message of commit
 56ce89fe1a99c304b7292a7087ae8d0ad2412273.

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

Re: [tor-bugs] #28866 [Core Tor/sbws]: ResultDump.queue.put() can hang if the queue is full

[Tor Bug Tracker & Wiki]

#28866: ResultDump.queue.put() can hang if the queue is full
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 Replying to [ticket:28866 teor]:
 > sbws calls `ResultDump.queue.put()` in blocking mode:
 >
 
https://github.com/torproject/sbws/blob/ee64d76df54ceb3a3c9e1e2a797fd70d68bb0035/sbws/core/scanner.py#L303
 >
 > But multiprocessing callbacks need to return immediately:
 >
 
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.apply_async
 >
 > So sbws should call put() without blocking, or with a (very small)
 timeout:
 > https://docs.python.org/3/library/queue.html#queue.Queue.put

 I'm not sure we can make this callback not blocking, since it'll be
 accessing the same part of memory and needs to write to disk. Not sure
 either about the small timeout.
 I'll try, but dunno how i can test all of this.

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

Re: [tor-bugs] #28864 [Core Tor/sbws]: sbws AsyncResults have no timeout

[Tor Bug Tracker & Wiki]

#28864: sbws AsyncResults have no timeout
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 Replying to [ticket:28864 teor]:
 > After sbws queues an `AsyncResult`, it will wait forever for the result
 to be ready:
 >
 
https://github.com/torproject/sbws/blob/ee64d76df54ceb3a3c9e1e2a797fd70d68bb0035/sbws/core/scanner.py#L359-L364
 >
 > If at least one result hangs, then sbws will hang, because
 `AsyncResult.ready()` does not have a timeout.

 In theory this won't happen, since both circuits and requests have a
 timeout. Also the sleep happen in the main thread, not the thread that is
 getting the results

 > Instead, sbws should call `AsyncResult.wait([timeout])` on each result,
 after calling `pool.apply_async()` on a large number of results.
 >
 > See
 
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.AsyncResult.wait

 I'll try this anyway

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

Re: [tor-bugs] #28663 [Core Tor/sbws]: sbws stops accumulating, silently

[Tor Bug Tracker & Wiki]

#28663: sbws stops accumulating, silently
---+---
 Reporter:  stefani|  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28639 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 Replying to [comment:14 teor]:

 > > The point where sbws is stalled is in this loop:
 
https://github.com/torproject/sbws/blob/ee64d76df54ceb3a3c9e1e2a797fd70d68bb0035/sbws/core/scanner.py#L362,
 which was added in #28061 in order to stop measuring the same relay by two
 threads when a new loop starts.
 >
 > This code can block forever ~~at a few point~~ for a few different
 reasons. I will open a new child ticket for every location that can block.
 >
 > > Turned out that there's 1 thread that is not measuring relays, it's
 the one storing the results, so that could be solved just changing "> 0"
 to "> 1", i'll try that.
 >
 > pending_results is a list of AsyncResults, not threads:
 >
 
https://docs.python.org/2/library/multiprocessing.html#multiprocessing.pool.AsyncResult
 >
 > So this change doesn't do what you say it does.

 That's the logic thing to think, but i couldn't find enough documentation.
 Firstable, Pool manages tasks, jobs and results
 
(https://github.com/python/cpython/blob/master/Lib/multiprocessing/pool.py#L186),
 and have at least 3 queues _inqueue, _outqueue, _taskqueue.
 I left sbws running extra logging the "jobs" and the queues, and the
 moment it was stalled, pending_results was 1, so was the difference
 between _inqueue and _outqueue, and the "job" i could see, was thread 1,
 resultdump waiting for more results to get.
 So while i'd agree with you, it's still not clear to me that that's the
 case.

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

Re: [tor-bugs] #28752 [Applications/Tor Browser]: Gradle sometimes downloads tor-android-binary resources during build (or the build is failing)

[Tor Bug Tracker & Wiki]

#28752: Gradle sometimes downloads tor-android-binary resources during build (or
the build is failing)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam201812, TBA-a3   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sisbell):

 I've got the fix ready but the current build is giving me an error in the
 firefox-locale-bundle. It looks like a perl module isn't installed.

 {{{
 Can't locate JSON.pm in @INC (you may need to install the JSON module)
 
 BEGIN failed--compilation aborted at /home/shane/github/tor-
 browser-4/projects/firefox-locale-bundle/get_hg_hash line 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] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library

[Tor Bug Tracker & Wiki]

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

Comment (by sisbell):

 Replying to [comment:18 sysrqb]:

 > Replying to [comment:15 sisbell]:
 >
 >
 >
 > > Evaluation:
 > >
 > > 1. Tor Installation: Tor Onion Proxy library is using tor-android-
 binary - Who is going to install the tor binary? Orbot or Tor Onion Proxy
 Libray. If orbot installs, we will need to configure the onion proxy to
 use those locations for tor files/libraries.
 > >
 > >
 > >
 >
 > We'd use this instead of Orbot. This library would completely replace
 our Orbot implementation.
 >
 >
 >
 >
 > > 1. Settings Screen: there is no settings screen: configure ports,
 delete/add onion addresses [these features need to be defined]
 > >
 > >
 > >
 >
 > Right. We'll need to create our own UI for Orbot and TOPL, so I don't
 consider this a blocker.
 >
 >
 >
 >
 > > 1. Starting Proxy: This is a simple operation to start but we need to
 display the startup logs to the user. We also need to define UI to handle
 things like restart or shutdown.
 > > 1. Stability: Its workable for an alpha, but we should cleanup up the
 threading and socket connections
 > >
 > >
 > >
 > >
 >
 > This is what I'm primarily worried about. Is the code quality where we
 need it. Is it tested? Is the code safe (for some value of safe)? With
 Orbot, we weren't exposing our users to new code (because Orbot was
 previously a dependency). If we use TOPL then we should be confident this
 won't be worse.
 I tested it back in February of this year and it works. While working on
 the code, I didn't see anything jumping out as unsafe. It's straight-
 forward.

 >
 >
 >
 >
 > > In summary: this is not a simply a drop-in. It will need a UI defined
 and built but core functionality is all there. Suggest cleanup of
 threading before a production release.
 > >
 > >
 > >
 >
 > Can you estimate how much time this will require? Would we need to re-
 write much of the code and redesign it?

 Its no more than one week to cleanup threading and the other async
 handling. So not much of the code would need to be re-written. I'm seeing
 TOPL library as more of a replacement for orbotservice.

 So far I see we need to bring in Orbot app features (not complete list)

  1. Build our pluggable transports (this is currently handled as part of
 orbot dependency)
  1. Transport lifecycle (start/stop)
  1. Onboarding flow
  1. Cookie management
  1. Hidden services management
  1. Additional permissions handling
  1. UI for bootstrap
  1. Tor, transports and other binary installations (some of this is
 already included in TOPL)
  1. Tor lifecycle/bootstrap (already there but needs some modification)

 We can break this into service components and front-end UI components.

 its hard to give exact estimate without going through full list of
 features first. Here is an initial estimate

  * Bring TOPL inline with orbotservice - 1 week
  * Pluggable transport build - ??? needs more investigation
  * Re-write of Orbot UI and providers - 3 weeks

 So best case would be about one-man-month. If we wanted to be keep Orbot
 but just integrate TOPL and remove orbotservice, we would be looking at
 more like 2 weeks.

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

Re: [tor-bugs] #28863 [Core Tor/Fallback Scripts]: updateFallbackDirs.py thinks it is python 3 compatible but it is not

[Tor Bug Tracker & Wiki]

#28863: updateFallbackDirs.py thinks it is python 3 compatible but it is not
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.0.x-final
Component:  Core Tor/Fallback Scripts  |Version:  Tor:
   |  0.3.5.5-alpha
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  new => needs_revision


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

Re: [tor-bugs] #28863 [Core Tor/Fallback Scripts]: updateFallbackDirs.py thinks it is python 3 compatible but it is not

[Tor Bug Tracker & Wiki]

#28863: updateFallbackDirs.py thinks it is python 3 compatible but it is not
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.0.x-final
Component:  Core Tor/Fallback Scripts  |Version:  Tor:
   |  0.3.5.5-alpha
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * parent:   => #28793
 * milestone:   => Tor: 0.4.0.x-final


Comment:

 Thanks for this patch.

 We don't have CI for this script yet, so we can easily make changes that
 break some platforms. (I might wait to merge this patch until we have CI
 for python 2 and 3.)

 Replying to [comment:1 starlight]:
 > The TLS certificate validation problem could be the result of running
 with torsocks.  Two years+ ago updateFallbackDirs.py ran fine this way,
 but much code has been added and changed since.  Did not try running over
 direct connection.

 Running the script over Tor was never supported, because the script is
 designed to measure  direct consensus download speeds. We documented this
 requirement in April 2016:
 {{{
 # This script should be run from a stable, reliable network connection,
 # with no other network activity (and not over tor).
 # If this is not possible, please disable:
 # PERFORM_IPV4_DIRPORT_CHECKS and PERFORM_IPV6_DIRPORT_CHECKS
 }}}

 I am not sure about the https change, the only https URL I can see is:
 {{{
 ONIONOO = 'https://onionoo.torproject.org/'
 }}}

 This URL validates fine in my (Tor) browser.

 I also see this note in the Python 2 urllib2 documentation:
 {{{
 Note The urllib2 module has been split across several modules in Python 3
 named urllib.request and urllib.error. The 2to3 tool will automatically
 adapt imports when converting your sources to Python 3.
 }}}
 https://docs.python.org/2/library/urllib2.html

 Is your patch missing the imports for python 3?

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

Re: [tor-bugs] #28797 [Core Tor/Fallback Scripts]: Set up CI on the fallback script with a small number of relays

[Tor Bug Tracker & Wiki]

#28797: Set up CI on the fallback script with a small number of relays
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * type:  defect => enhancement


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

Re: [tor-bugs] #28795 [Core Tor/Tor]: Generate a new fallback list in 2019 and backport it to all supported Tor versions

[Tor Bug Tracker & Wiki]

#28795: Generate a new fallback list in 2019 and backport it to all supported 
Tor
versions
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fallback, 029-backport,  |  Actual Points:
  034-backport, 035-backport, 040-backport   |
Parent ID:  #28793   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * type:  defect => task


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

Re: [tor-bugs] #28794 [Core Tor/Fallback Scripts]: Run an opt-in process for relay operators to become fallbacks in 2019

[Tor Bug Tracker & Wiki]

#28794: Run an opt-in process for relay operators to become fallbacks in 2019
---+--
 Reporter:  teor   |  Owner:  phoul
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * type:  defect => task


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

Re: [tor-bugs] #28525 [Core Tor/Tor]: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large Scale NAT) IPv4 Ranges

[Tor Bug Tracker & Wiki]

#28525: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large
Scale NAT) IPv4 Ranges
--+
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by teor):

 Replying to [comment:11 nickm]:
 > This patch does what it is supposed to do.  It would be good to have a
 test.
 >
 > One problem here is that I'm not sure that this changed behavior is
 correct.  If you have an address inside a carrier NAT, you have the worst
 of both worlds: it is an address that the public internet cannot reach,
 but it is an address that other random people on your internet provider
 can still connect to.  In other words, these addresses are not useful
 enough to call them public, but not safe enough to call them private. So
 we need to treat these addresses as internal for the purpose of "can this
 address go onto the public tor network", but we need to treat them as non-
 internal for the purpose of "is it safe to have a socksport/extorport/etc
 here."
 >
 > The main purpose of the rest of my review here is to see what else we
 would need to change to make sure this change is safe.  I'm going to do
 this by looking at all the users of tor_addr_is_internal in the codebase.
 >
 >* In warn_nonlocal_client_ports(), we will stop warning about binding
 a socksport to one of these addresses.  Is this a problem?  I need more
 guidance from others.

 We should not let random people at your ISP connect to your SOCKSPorts.

 >* In warn_nonlocal_ext_orports(), we will stop warning about binding
 an extorport to one of these addresses.  (same note as above)

 We should not let random people at your ISP connect to your ExtORPorts.

 >* In connection_is_rate_limited(), we no longer count connections to
 or from one of these addresses as having any rate limits.

 If these addresses aren't allowed to be ORPorts on the public network,
 then rate limits probably aren't needed. There might be the rare case of a
 private bridge that we need to think about.

 >* In channeltls.c [which calls tor_addr_is_internal via
 is_local_addr()], we count any OR connections to these addresses as
 "local", which seems unwise.

 I don't know what local OR connections mean. I'd need to look at the code
 and check.

 > But all the other cases that I could find seemed like an improvement.
 >
 > Maybe what we need here is to replace the `for_listening` argument with
 a more general set of bitflags?

 Seems sensible.

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

Re: [tor-bugs] #28868 [Core Tor/sbws]: best_priority() can starve the worker threads of good relays

[Tor Bug Tracker & Wiki]

#28868: best_priority() can starve the worker threads of good relays
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 There's one problem with this scheme: if many new relays join the network
 every hour, then they will starve older relays. But that's a problem for
 the bad relays people, not sbws.

 To avoid this problem, we could have two queues/pools: one for unmeasured
 relays, and one for measured relays. (Torflow does something like this, by
 having ~8 measured partitions, and an unmeasured partition.)

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

Re: [tor-bugs] #28868 [Core Tor/sbws]: best_priority() can starve the worker threads of good relays

[Tor Bug Tracker & Wiki]

#28868: best_priority() can starve the worker threads of good relays
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---
Description changed by teor:

Old description:

> `best_priority()` tries to measure unmeasured and failing relays first.
>
> But if `fraction_relays` or `min_relays` always fail, those relays will
> always end up first in the priority queue. (More precisely, those relays
> will end up first in the priority queue, until the results of the good
> relays time out.)
>
> Thinking about starvation is complicated, because of the
> `freshness_reduction_factor` on some errors.
>
> Here's a very simple algorithm that avoids starving good relays for
> failed relays:
> 1. Count the number of times that sbws has attempted to get a result from
> each relay.
> 2. Test the relays with the lowest number of attempts first. (Don't check
> if the attempt succeeded or failed.)
>
> For this priority rule to work, every time a relay is queued, it must get
> a result. Here's how we can make that happen"
> * Modify `result_putter_error()` to store an error result to the queue.
> * Make sure timeouts store an error result to the queue.
> * Add a unit test and integration test that makes sure every queued relay
> has a result.
>
> Here's an alternative that might be simpler to implement:
> * before a relay is queued using `pool.apply_async()` in
> `run_speedtest()`, store a `ResultAttempt` to the queue
> * only count `ResultAttempt`s when prioritising relays

New description:

 `best_priority()` tries to measure unmeasured and failing relays first.

 But if `fraction_relays` or `min_relays` always fail, those relays will
 always end up first in the priority queue. (More precisely, those relays
 will end up first in the priority queue, until the results of the good
 relays ~~time out~~ are discarded for being too old.)

 Thinking about starvation is complicated, because of the
 `freshness_reduction_factor` on some errors.

 Here's a very simple algorithm that avoids starving good relays for failed
 relays:
 1. Count the number of times that sbws has attempted to get a result from
 each relay.
 2. Test the relays with the lowest number of attempts first. (Don't check
 if the attempt succeeded or failed.)

 For this priority rule to work, every time a relay is queued, it must get
 a result. Here's how we can make that happen"
 * Modify `result_putter_error()` to store an error result to the queue.
 * Make sure timeouts store an error result to the queue.
 * Add a unit test and integration test that makes sure every queued relay
 has a result.

 Here's an alternative that might be simpler to implement:
 * before a relay is queued using `pool.apply_async()` in
 `run_speedtest()`, store a `ResultAttempt` to the queue
 * only count `ResultAttempt`s when prioritising relays

--

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

[tor-bugs] #28868 [Core Tor/sbws]: best_priority() can starve the worker threads of good relays

[Tor Bug Tracker & Wiki]

#28868: best_priority() can starve the worker threads of good relays
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #28663
   Points: |   Reviewer:
  Sponsor: |
---+---
 `best_priority()` tries to measure unmeasured and failing relays first.

 But if `fraction_relays` or `min_relays` always fail, those relays will
 always end up first in the priority queue. (More precisely, those relays
 will end up first in the priority queue, until the results of the good
 relays time out.)

 Thinking about starvation is complicated, because of the
 `freshness_reduction_factor` on some errors.

 Here's a very simple algorithm that avoids starving good relays for failed
 relays:
 1. Count the number of times that sbws has attempted to get a result from
 each relay.
 2. Test the relays with the lowest number of attempts first. (Don't check
 if the attempt succeeded or failed.)

 For this priority rule to work, every time a relay is queued, it must get
 a result. Here's how we can make that happen"
 * Modify `result_putter_error()` to store an error result to the queue.
 * Make sure timeouts store an error result to the queue.
 * Add a unit test and integration test that makes sure every queued relay
 has a result.

 Here's an alternative that might be simpler to implement:
 * before a relay is queued using `pool.apply_async()` in
 `run_speedtest()`, store a `ResultAttempt` to the queue
 * only count `ResultAttempt`s when prioritising relays

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

[tor-bugs] #28867 [Internal Services/Service - trac]: Need to improve ./delete-user script for deleting spam comments

[Tor Bug Tracker & Wiki]

#28867: Need to improve ./delete-user script for deleting spam comments
--+-
 Reporter:  arma  |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 We have a delete-user script, which is supposed to remove session tokens
 from the trac repo, delete the user, and delete the tickets and comments
 that they have made.

 But it doesn't actually delete their comments. See #19407 for a bunch of
 spam comments that aren't deleted by running the script.

 Thanks!

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

[tor-bugs] #28866 [Core Tor/sbws]: ResultDump.queue.put() can hang if the queue is full

[Tor Bug Tracker & Wiki]

#28866: ResultDump.queue.put() can hang if the queue is full
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #28663
   Points: |   Reviewer:
  Sponsor: |
---+---
 sbws calls `ResultDump.queue.put()` in blocking mode:
 
https://github.com/torproject/sbws/blob/ee64d76df54ceb3a3c9e1e2a797fd70d68bb0035/sbws/core/scanner.py#L303

 But multiprocessing callbacks need to return immediately:
 
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.apply_async

 So sbws should call put() without blocking, or with a (very small)
 timeout:
 https://docs.python.org/3/library/queue.html#queue.Queue.put

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28865 [Core Tor/sbws]: sbws keeps the number of AsyncResults less than the number of threads

[Tor Bug Tracker & Wiki]

#28865: sbws keeps the number of AsyncResults less than the number of threads
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #28663
   Points: |   Reviewer:
  Sponsor: |
---+---
 This ticket is a follow-up to #28864.

 `multiprocessing.Pool` can accept any number of queued `AsyncResult`s:
 
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool

 But sbws waits for 5 seconds when there are `max_pending_results` queued
 `AsyncResult`s:
 
https://github.com/torproject/sbws/blob/ee64d76df54ceb3a3c9e1e2a797fd70d68bb0035/sbws/core/scanner.py#L359-L361

 This sbws code is unnecessary, because `Pool` manages its own queue of
 `AsyncResult`s.

 There are two different ways that this code blocks execution:
 * when a result finishes, the `time.sleep(5)` call blocks the thread from
 getting a new `AsyncResult` for up to 5 seconds
 * if `max_pending_results` `AsyncResult`s ever block, the process hangs

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

Re: [tor-bugs] #28864 [Core Tor/sbws]: sbws AsyncResults have no timeout

[Tor Bug Tracker & Wiki]

#28864: sbws AsyncResults have no timeout
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 This ticket probably needs to be done at the same time as #28865.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28864 [Core Tor/sbws]: sbws AsyncResults have no timeout

[Tor Bug Tracker & Wiki]

#28864: sbws AsyncResults have no timeout
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #28663
   Points: |   Reviewer:
  Sponsor: |
---+---
 After sbws queues an `AsyncResult`, it will wait forever for the result to
 be ready:
 
https://github.com/torproject/sbws/blob/ee64d76df54ceb3a3c9e1e2a797fd70d68bb0035/sbws/core/scanner.py#L359-L364

 If at least one result hangs, then sbws will hang, because
 `AsyncResult.ready()` does not have a timeout.

 Instead, sbws should call `AsyncResult.wait([timeout])` on each result,
 after calling `pool.apply_async()` on a large number of results.

 See
 
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.AsyncResult.wait

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

Re: [tor-bugs] #28863 [Core Tor/Fallback Scripts]: updateFallbackDirs.py thinks it is python 3 compatible but it is not

[Tor Bug Tracker & Wiki]

#28863: updateFallbackDirs.py thinks it is python 3 compatible but it is not
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:  Tor:
   |  0.3.5.5-alpha
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by starlight):

 The TLS certificate validation problem could be the result of running with
 torsocks.  Two years+ ago updateFallbackDirs.py ran fine this way, but
 much code has been added and changed since.  Did not try running over
 direct connection.

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

Re: [tor-bugs] #20746 [Applications/Tor Browser]: TBB - What are /tmp/0123.mlf files (where 0123 is PID of Firefox)

[Tor Bug Tracker & Wiki]

#20746: TBB - What are /tmp/0123.mlf files (where 0123 is PID of Firefox)
--+--
 Reporter:  ronvandaal_   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Yes, I see these files too. I am running Tor Browser 8.5a6. What is
 causing 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] #28663 [Core Tor/sbws]: sbws stops accumulating, silently

[Tor Bug Tracker & Wiki]

#28663: sbws stops accumulating, silently
---+---
 Reporter:  stefani|  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28639 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:13 juga]:
 > The instantiated locks without acquire and release use the context
 manager, so that might not be a failure.
 > The point where sbws is stalled is in this loop:
 
https://github.com/torproject/sbws/blob/ee64d76df54ceb3a3c9e1e2a797fd70d68bb0035/sbws/core/scanner.py#L362,
 which was added in #28061 in order to stop measuring the same relay by two
 threads when a new loop starts.

 This code can block forever at a few point. I will open a new child ticket
 for every location that can block.

 > Turned out that there's 1 thread that is not measuring relays, it's the
 one storing the results, so that could be solved just changing "> 0" to ">
 1", i'll try that.

 pending_results is a list of AsyncResults, not threads:
 
https://docs.python.org/2/library/multiprocessing.html#multiprocessing.pool.AsyncResult

 So this change doesn't do what you say it does.

 > However, there's still the mistery about why commenting the lines in
 relaprioritizer solves the problem too.

 It might solve the problem by changing where the code blocks.

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

Re: [tor-bugs] #28853 [Core Tor/Tor]: parse_short_policy() could be faster

[Tor Bug Tracker & Wiki]

#28853: parse_short_policy() could be faster
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.4.9
 Severity:  Normal   | Resolution:
 Keywords:  startup performance  |  Actual Points:
Parent ID:  #28481   | Points:
 Reviewer:   |Sponsor:  Sponsor8-can
-+
Changes (by teor):

 * 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] #23764 [Core Tor/Tor]: hs-v3: No live consensus on client with a bridge

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 A few weeks ago, asn suggested I look at these commits for this ticket:
 {{{
 <+asn> teor: perhaps a useful commit to see while you are checking out
 code/spec is 2520ee34c6d1b5eb83a6c3ffdaf1e8b3013b619f
 <+asn> teor: wrt hsv3 and live consensus
 <+asn> teor: also 9e900d1db7c8c9e164b5b14d5cdd4099c1ce45f0
 <+asn> teor: and b89d2fa1db2379bffd2e2b4c851c3facc57b6ed8
 }}}

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Replying to [comment:43 juga]:
 > Replying to [comment:42 teor]:
 > > It looks like you're setting the compression state, then adding the
 data uncompressed.
 > >
 > > You didn't open a pull request, so I commented on the commit:
 > >
 
https://github.com/torproject/tor/commit/b03091842bc4590e11e3ac026daae8ed6d8f7554#r31629291
 > >
 
https://github.com/torproject/tor/commit/b03091842bc4590e11e3ac026daae8ed6d8f7554#r31629096
 >
 > I didn't create a PR, cause i knew that code fails, but wanted to ask
 about it.

 Please open pull requests for code questions and CI, even if the code
 doesn't work yet.

 When you open a pull request:
 * comments are easier to make and easier to find
 * new commits get handled better
 * the CI is done on a merge with master, so any bugs fixed in master are
 fixed in the CI

 If you don't want a pull request merged, put the ticket in needs_review,
 and say that the code doesn't work.

 Some people also put "WIP" or "work in progress" in the pull request
 title:
 https://stackoverflow.com/a/39741877

 > i've left new comments after setting the compression state.

 I'm not sure how to find the new code, or the CI for that code.

 I tried looking at your branches, but they haven't changed:
 https://github.com/juga0/tor/branches

 When you ask questions, please open a pull request.
 (Or link to a branch, or a commit. But a pull request is better.)

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

Re: [tor-bugs] #28815 [Core Tor/Tor]: Refactor similar compression buffer code in dircache.c

[Tor Bug Tracker & Wiki]

#28815: Refactor similar compression buffer code in dircache.c
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, tor-dir, tor-bwauth  |  Actual Points:
Parent ID:  #21377   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #21377


Comment:

 Let's think about fixing this technical debt before merging #21377.

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

Re: [tor-bugs] #28816 [Core Tor/Tor]: Log a bug for uncompressed data on a compressed connection

[Tor Bug Tracker & Wiki]

#28816: Log a bug for uncompressed data on a compressed connection
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, tor-dir, tor-bwauth  |  Actual Points:
Parent ID:  #21377   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #21377


Comment:

 Let's think about fixing this technical debt before merging #21377.

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

Re: [tor-bugs] #28863 [Core Tor/Fallback Scripts]: updateFallbackDirs.py thinks it is python 3 compatible but it is not

[Tor Bug Tracker & Wiki]

#28863: updateFallbackDirs.py thinks it is python 3 compatible but it is not
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:  Tor:
   |  0.3.5.5-alpha
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by starlight):

 * Attachment "updateFallbackDirs.py-python3.patch" added.

 touch up to apply after 2to3.7

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28863 [Core Tor/Fallback Scripts]: updateFallbackDirs.py thinks it is python 3 compatible but it is not

[Tor Bug Tracker & Wiki]

#28863: updateFallbackDirs.py thinks it is python 3 compatible but it is not
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Core Tor/Fallback Scripts
  Version:  Tor:   |   Severity:  Normal
  0.3.5.5-alpha|
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
 This comment would lead one to believe the script will run with python 3
 but problems remain:

 {{{
 # Optionally uses ipaddress (python 3 builtin) or py2-ipaddress (package)
 # for netblock analysis.
 }}}

 After running `2to3-3.7` on commit 6BC5C06D additional manual revisions
 were required per the attached patch.  A subtle certificate validation
 problem exists, not enough time to fix so disabled it.  Have good CA files
 in both system and Python directories and `openssl s_client` has no
 problem.

 {{{
 OUTPUT_CANDIDATES = True
 }}}

 is broken, wasn't prepared to spend the time hacking 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] #28803 [Applications/Tor Browser]: Integrate building pluggable transports for Android into tor-browser-build

[Tor Bug Tracker & Wiki]

#28803: Integrate building pluggable transports for Android into 
tor-browser-build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, TBA-a3, |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Skipping FTEProxy makes a lot of sense at this point -- there are only a
 handful of bridges, and we expect FTEProxy to go away once Marionette
 replaces it.

 For the future, so you are aware of what comes next, the three next PTs we
 plan to investigate, and hopefully will want to put onto Tor Browser
 Android too, are:

 * Snowflake: https://snowflake.torproject.org/ (I think Hans is messing
 with that one now)

 * httpsproxy: https://gitweb.torproject.org/pluggable-
 transports/httpsproxy.git/tree/

 * Marionette: #26920

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

Re: [tor-bugs] #28803 [Applications/Tor Browser]: Integrate building pluggable transports for Android into tor-browser-build

[Tor Bug Tracker & Wiki]

#28803: Integrate building pluggable transports for Android into 
tor-browser-build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, TBA-a3, |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 It looks like the candidate PTs are

  1. obfs4 (implemented in orbot)
  1. meek (implemeted in orbot - uses meek_lite)
  1. fteproxy[wiki:FteProxy -]has no plans for support on Android:
 https://github.com/kpdyer/fteproxy/issues/187

 '''Configuration:'''

 The obfs binary used by orbot supports: obfs3, obfs4. meek lite binary
 also is available. So we can support (1) and (2). All of these are
 configured and written to a custom torrc file:

   '''!ClientTransportPlugin''' ''transport'' exec ''path-to-binary''
 [options]::
 The bridge list is read from a text file in the res/raw  folder. The
 bridges are then written to the custom torrc file.

 '''Building the libraries:'''

 Orbot uses Pluto to build the transports for Android:
 https://github.com/guardianproject/pluto . However, there is an updated
 Pluto 2 library available:
 https://github.com/guardianproject/AndroidPluggableTransports

 So first question is do we want to use Pluto 1 (which is what orbot is
 currently using) or Pluto 2 which is the current recommended version?

 To build the transport (for Pluto 1), we will need:

  1. Build go toolchain for android (this could be a separate project/go-
 android-toolchain)
  1. Build (with go)  github.com/n8fr8/meek/meek-client
  1. Build (with go) git.torproject.org/pluggable-
 transports/obfs4.git/obfs4proxy

 Pluto has a script which sets the correct parameters go compile params and
 flags. We can modify this script for use in tor-browser-build

 The files in Pluto are then packaged into an Android library with the
 binaries in the res/raw folder. For our purposes, we could put these into
 the assets folder instead since we want to add this in the last phase of
 the tor-browser build. We will need to just make sure to create an
 installer class that will pull from the assets folder into the private
 data section of the app so we can execute the binaries during runtime.

 For Pluto 2 the build is different: It uses the following git repo for
 building the transports: [https://gitlab.com/eighthave/goptbundle
 https://gitlab.com/eighthave/goptbundle .]We can then follow a similar
 process for installing as outlined above.

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

Re: [tor-bugs] #28795 [Core Tor/Tor]: Generate a new fallback list in 2019 and backport it to all supported Tor versions

[Tor Bug Tracker & Wiki]

#28795: Generate a new fallback list in 2019 and backport it to all supported 
Tor
versions
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fallback, 029-backport,  |  Actual Points:
  034-backport, 035-backport, 040-backport   |
Parent ID:  #28793   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by starlight):

 * cc: starlight@… (added)


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

[tor-bugs] #28862 [Webpages]: cant log in to tor

[Tor Bug Tracker & Wiki]

#28862: cant log in to tor
---+--
 Reporter:  Fx2345 |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Component:  Webpages
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 cant log in to tor

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

Re: [tor-bugs] #28857 [Core Tor/Stem]: A commit has broken creation of v3 onion services with Stem 1.7

[Tor Bug Tracker & Wiki]

#28857: A commit has broken creation of v3 onion services with Stem 1.7
---+
 Reporter:  maqp   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  regression hs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by maqp):

 nickm: Thank you! I'm not sure to what bug you are referring to. Is there
 a ticket number?

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

Re: [tor-bugs] #28857 [Core Tor/Stem]: A commit has broken creation of v3 onion services with Stem 1.7

[Tor Bug Tracker & Wiki]

#28857: A commit has broken creation of v3 onion services with Stem 1.7
---+
 Reporter:  maqp   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  regression hs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * cc: atagar (added)
 * owner:  (none) => atagar
 * component:  Core Tor/Tor => Core Tor/Stem
 * milestone:  Tor: 0.3.5.x-final =>


Comment:

 Oh,  I get it!  This is the stem bug related to the changed log messages.
 It should be fixed in stem soon.

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

Re: [tor-bugs] #28857 [Core Tor/Tor]: A commit has broken creation of v3 onion services with Stem 1.7

[Tor Bug Tracker & Wiki]

#28857: A commit has broken creation of v3 onion services with Stem 1.7
---+
 Reporter:  maqp   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  regression hs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * milestone:  Tor: 0.4.0.x-final => Tor: 0.3.5.x-final


Comment:

 Oh; I hadn't seen that this bug is in 0.3.5.

 I don't see how it can be caused by the commit that you mention, though:
 that commit only changes log messages.

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

Re: [tor-bugs] #28823 [Applications/Tor Browser]: Every web page crashes on Windows 7 with Tor Browser 8

[Tor Bug Tracker & Wiki]

#28823: Every web page crashes on Windows 7 with Tor Browser 8
--+---
 Reporter:  testcy|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by testcy):

 I have been using Tor for a few years and up to version 7.5.6 it worked
 fine. Since version 8 came out this problem appeared. I did not install
 recently a new software that should be causing a conflict. I have been
 using Comodo for years without any major issues. I don't use Trusteer
 products.

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

Re: [tor-bugs] #28857 [Core Tor/Tor]: A commit has broken creation of v3 onion services with Stem 1.7

[Tor Bug Tracker & Wiki]

#28857: A commit has broken creation of v3 onion services with Stem 1.7
---+
 Reporter:  maqp   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  regression hs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by maqp):

 This bug affects both [https://onionshare.org/ OnionShare] and
 [https://github.com/maqp/tfc TFC] that are no longer able to use v3 Onion
 Services. For TFC it makes releasing the next version quite impossible as
 it will be v3 only.

 Does `Tor 0.4.0.x-final` milestone mean the projects will have to wait
 until April? Everything has been working great for five months: ever since
 [https://trac.torproject.org/projects/tor/ticket/25552 #25552] (that was
 considered to be 0.3.5 must) was fixed.

 I understand you're busy but if it's at all possible, could you please
 take a look what's going on.

 Atagar: can you please check if this is something Stem could 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] #28750 [Applications/Tor Browser]: TBB freezes with Script: chrome://global/content/bindings/notification.xml:74

[Tor Bug Tracker & Wiki]

#28750: TBB freezes with Script:
chrome://global/content/bindings/notification.xml:74
--+---
 Reporter:  bo0od |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by bo0od):

 > What do you mean with "with allowing HTML5 + some JS"?

 like when the website ask me:

 "will you allow x.com to use your HTML5 canvas image data? This may be
 used to uniquely identify your computer"

 i will allow it.

 and i have put the security of TBB to Safer, so it will allow JS by
 default when there is SSL/TLS.

 I will give back any further method/report if i see any handy stuff to
 help identify the issue.

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

Re: [tor-bugs] #28857 [Core Tor/Tor]: A commit has broken creation of v3 onion services with Stem 1.7

[Tor Bug Tracker & Wiki]

#28857: A commit has broken creation of v3 onion services with Stem 1.7
---+
 Reporter:  maqp   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  regression hs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * keywords:   => regression hs
 * component:  - Select a component => Core Tor/Tor
 * milestone:   => Tor: 0.4.0.x-final


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

[tor-bugs] #28861 [Core Tor/Torsocks]: torsocks: Unsupported syscall number 217

[Tor Bug Tracker & Wiki]

#28861: torsocks: Unsupported syscall number 217
+---
 Reporter:  ilf |  Owner:  dgoulet
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Component:  Core Tor/Torsocks
  Version:  Tor: 0.3.4.9|   Severity:  Normal
 Keywords:  torsocks, syscall, 217  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
 % torsocks --version
 Torsocks 2.3.0

 % torsocks mutt
 
 1544962729 WARNING torsocks[21365]: [syscall] Unsupported syscall number
 217. Denying the call (in tsocks_syscall() at syscall.c:568)
 1544962729 WARNING torsocks[21367]: [syscall] Unsupported syscall number
 217. Denying the call (in tsocks_syscall() at syscall.c:568)
 1544962729 WARNING torsocks[21369]: [syscall] Unsupported syscall number
 217. Denying the call (in tsocks_syscall() at syscall.c:568)
 1544962729 WARNING torsocks[21371]: [syscall] Unsupported syscall number
 217. Denying the call (in tsocks_syscall() at syscall.c:568)
 1544962729 WARNING torsocks[21373]: [syscall] Unsupported syscall number
 217. Denying the call (in tsocks_syscall() at syscall.c:568)

 https://gitweb.torproject.org/torsocks.git/tree/src/lib/syscall.c#n567

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

Re: [tor-bugs] #28823 [Applications/Tor Browser]: Every web page crashes on Windows 7 with Tor Browser 8

[Tor Bug Tracker & Wiki]

#28823: Every web page crashes on Windows 7 with Tor Browser 8
--+---
 Reporter:  testcy|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:14 testcy]:
 > I thought uninstalling Comodo was just to make sure that it was not
 related and that I could install it again since the problem did not stop.
 The number of pages that crash I think is smaller now, compared with Tor
 8. Some seem to be more consistent, but not always crashing with the
 latest alpha, for example https://www.skypub.com was always crashing
 yesterday and today seems to be working.

 Hm, then I wonder what makes it stop crashing. You are the only one that
 reported these kind of issues since 8.0 came out which, as I said, makes
 me wonder what could be different on your machine than on all the other
 hundreds of thousands Windows machines that work fine with Tor Browser. Do
 you have some Trusteer product on your computer as well?

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

[tor-bugs] #28860 [Core Tor/Tor]: Increased DNS failure rate when using ServerDNSResolvConfFile with tor 0.3.4.9 (as opposed to 0.3.3.x)

[Tor Bug Tracker & Wiki]

#28860: Increased DNS failure rate when using ServerDNSResolvConfFile with tor
0.3.4.9 (as opposed to 0.3.3.x)
+--
 Reporter:  nusenu  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Core Tor/Tor
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 A major tor exit relay operator reports that
 after upgrading from 0.3.3.x to 0.3.4.9 his DNS failure rate significantly
 increased.

 He also reported that he is observing DNS issues only when using
 ServerDNSResolvConfFile and no problems when not using that config option.
 Using that option worked fine on tor 0.3.3.x



 With ServerDNSResolvConfFile option on 0.3.4.9:
 {{{
 Dec 13 02:39:52.000 [notice] eventdns: Nameserver 8.8.8.8:53 is back up
 Dec 13 02:39:53.000 [warn] eventdns: All nameservers have 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

[tor-bugs] #28859 [Metrics/ExoneraTor]: Use Java 8 date-time functionality in ExoneraTor

[Tor Bug Tracker & Wiki]

#28859: Use Java 8 date-time functionality in ExoneraTor
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:  #23752
   Points:  |   Reviewer:
  Sponsor:  |
+--
 We had plans to use Java 8 date-time functionality in all our code bases
 for quite a while now. I finally picked this up by reading a few
 tutorials, mostly to figure out which of the three types we're going to
 use: `Instant`, `LocalDateTime`, or `ZonedDateTime`. I picked ExoneraTor
 for this discussion/review, because nothing else depends on it and we're
 currently not working on this code base in other tickets.

 So, I think I have a plan now, and I'm presenting it here using snippets
 from my ExoneraTor patch:

 {{{
 @@ -131,10 +132,11 @@ public class ExoneraTorDatabaseImporter {
  try {
if (lockFile.exists()) {
  BufferedReader br = new BufferedReader(new FileReader(lockFile));
 -long runStarted = Long.parseLong(br.readLine());
 +Instant runStarted = Instant.ofEpochMilli(Long.parseLong(
 +br.readLine()));
  br.close();
 -if (System.currentTimeMillis() - runStarted
 -< 6L * 60L * 60L * 1000L) {
 +if (runStarted.plus(Duration.ofHours(6L))
 +.compareTo(Instant.now()) >= 0) {
logger.warn("File 'exonerator-lock' is less than 6 "
+ "hours old.  Exiting.");
System.exit(1);
 }}}

 This code is used to write the current system time to a local lock file to
 determine when we need to obey that or can safely delete it. Let's ignore
 the design and just look at the date-time part for now.

 So, I think that we can replace code where we used
 `System.currentTimeMillis()` in the past with `Instant`. The concept is
 close enough to the "machine time" concept rather than "human time" that
 `Instant` will work for us. We care about hours here, not things like
 calendar months.

 {{{
 @@ -223,7 +225,8 @@ public class ExoneraTorDatabaseImporter {

/* Parse a consensus. */
private static void parseConsensus(RelayNetworkStatusConsensus
 consensus) {
 -long validAfterMillis = consensus.getValidAfterMillis();
 +LocalDateTime validAfter =
 LocalDateTime.ofInstant(Instant.ofEpochMilli(
 +consensus.getValidAfterMillis()), ZoneOffset.UTC);
  for (NetworkStatusEntry entry :
 consensus.getStatusEntries().values()) {
if (entry.getFlags().contains("Running")) {
  String fingerprintBase64 = null;
 }}}

 Things are a bit different here. The valid-after time in a consensus is
 not just a point on the timeline. It's an actual date and time that has a
 meaning for humans. That somewhat rules out the `Instant`.

 Now, why use `LocalDateTime` here und not `ZonedDateTime`, as suggested
 before? Well, I could imagine doing either, as long as we're consistent
 across our codebases.

 However, one reason that made me pick `LocalDateTime` in the end was the
 comparison with PostgreSQL's `TIMESTAMP [WITHOUT TIMEZONE]` vs. `TIMESTAMP
 WITH TIMEZONE` types. We're importing lots of timestamps into PostgreSQL,
 but we're always using `TIMESTAMP [WITHOUT TIMEZONE]`. Because we know
 that timestamps in Tor are always UTC and we simply don't need timezone
 information. The [https://jdbc.postgresql.org/documentation/head/8-date-
 time.html corresponding types] for `TIMESTAMP [WITHOUT TIMEZONE]` and
 `TIMESTAMP WITH TIMEZONE` are `LocalDateTime` and `OffsetDateTime`, by the
 way.

 The only use case I see where `LocalDateTime` could be problematic is when
 somebody wants to convert our timestamps to their local timezone. But
 that's not a common use case for us, and we're primarily building our
 tools for ourselves and the services we provide.

 {{{
 @@ -248,26 +251,21 @@ public class ExoneraTorDatabaseImporter {
 [...]
  try {
for (String orAddress : orAddresses) {
  insertStatusentryStatement.clearParameters();
 -insertStatusentryStatement.setTimestamp(1,
 -new Timestamp(validAfterMillis), calendarUTC);
 +insertStatusentryStatement.setObject(1, validAfter);
  insertStatusentryStatement.setString(2, fingerprintBase64);
  if (!orAddress.contains(":")) {
insertStatusentryStatement.setString(3, orAddress);
 }}}

 This is what it looks like when we're passing a `LocalDateTime` to the
 database.

 {{{
 @@ -47,7 +50,9 @@ public class QueryServlet extends HttpServlet {

private DataSource ds;

 [...]
 +  private static final DateTimeFormatter validAfterTimeFormatter
 +  = DateTimeFormatter.ofPattern("-MM-dd 

Re: [tor-bugs] #28859 [Metrics/ExoneraTor]: Use Java 8 date-time functionality in ExoneraTor

[Tor Bug Tracker & Wiki]

#28859: Use Java 8 date-time functionality in ExoneraTor
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #23752  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * status:  assigned => needs_review


Comment:

 Please review
 
[https://gitweb.torproject.org/user/karsten/exonerator.git/commit/?h=task-28859=714862c3ecde23b44076c7dca42f8366714f8c11
 commit 714862c in my task-28859 branch].

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

Re: [tor-bugs] #7790 [HTTPS Everywhere/EFF-HTTPS Everywhere]: problem with Google Translate and https-everywhere

[Tor Bug Tracker & Wiki]

#7790: problem with Google Translate and https-everywhere
-+-
 Reporter:  kargig   |  Owner:  pde
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:  HTTPS-E
  Everywhere |  4.0dev3
 Severity:  Normal   | Resolution:
 Keywords:  httpse-ruleset-bug   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Jameswood):

 i was using Google translate and the site [http://www.cheetahtraffic.com/]
 kept on crashing, i had to finally translate it back to english for good.

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

Re: [tor-bugs] #27325 [Core Tor/Tor]: Rework NETINFO cell parsing and generation with trunnel

[Tor Bug Tracker & Wiki]

#27325: Rework NETINFO cell parsing and generation with trunnel
-+-
 Reporter:  rl1987   |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  trunnel wireformat heartbleed-   |  Actual Points:
  safety security parsing|
Parent ID:  #27143   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by rl1987):

 Pushed two more commits to address that.

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