Re: [tor-bugs] #16337 [Applications/Tor Browser]: Investigate whether Animations(Player) API provides new high resolution timestamp

[Tor Bug Tracker & Wiki]

#16337: Investigate whether Animations(Player) API provides new high resolution
timestamp
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting-time-   |  Actual Points:
  highres, tbb-7.0-must-alpha,   |
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by arthuredelstein):

 Replying to [comment:18 mcs]:
 > Replying to [comment:13 arthuredelstein]:
 > > Here's a patch for review:
 > > https://github.com/arthuredelstein/tor-browser/commit/16337
 >
 > This patch looks okay. Do we also need to patch
 `GetCurrentTimeAsDouble()` inside `dom/animation/AnimationTimeline.h`?
 Kathy and I are not sure how the Animation.timeline object relates to the
 other timing information.

 That's a good point. Animation.timeline and document.timeline aren't
 exposed in TBB/ESR52 because "dom.animations-api.core.enabled" is set to
 false. But I looked at it again and I found there is a simpler way to
 implement this patch that covers the *.timeline cases as well. So here's
 an updated patch. (The document.timeline.currentTime test doesn't run
 unless the "dom.animations-api.core.enabled" pref has been set to true by
 default, but I don't think this is a problem for TBB.)

 https://github.com/arthuredelstein/tor-browser/commit/16337+1

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

Re: [tor-bugs] #22177 [Core Tor/Tor]: Remove dead code in test_options_validate_impl()

[Tor Bug Tracker & Wiki]

#22177: Remove dead code in test_options_validate_impl()
--+
 Reporter:  ahf   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * status:  new => needs_review


Comment:

 Patch in https://gitlab.com/ahf/tor/merge_requests/9/commits

 Let's keep this ticket opened after landing this. Catalyst suggested
 adding a test for the error path in this code.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22177 [Core Tor/Tor]: Remove dead code in test_options_validate_impl()

[Tor Bug Tracker & Wiki]

#22177: Remove dead code in test_options_validate_impl()
--+
 Reporter:  ahf   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Coverity found some dead code in CID 1405875, which we should 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] #20270 [Core Tor/Tor]: "Descriptor is missing an ntor curve25519 onion key" message too noisy?

[Tor Bug Tracker & Wiki]

#20270: "Descriptor is missing an ntor curve25519 onion key" message too noisy?
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  accepted
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, triage-out-030-201612  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_information => accepted


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

Re: [tor-bugs] #20270 [Core Tor/Tor]: "Descriptor is missing an ntor curve25519 onion key" message too noisy?

[Tor Bug Tracker & Wiki]

#20270: "Descriptor is missing an ntor curve25519 onion key" message too noisy?
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, triage-out-030-201612  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Behavior I think I want: if the relay's version is obsolete, don't
 complain about the ntor key -- do whatever logs I would do for an obsolete
 relay. If the relay's version is not obsolete, *and* it's missing an ntor
 key, then tell me.

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

Re: [tor-bugs] #22101 [Core Tor/Tor]: Can't have relative DataDirectory with CookieAuthentication enabled

[Tor Bug Tracker & Wiki]

#22101: Can't have relative DataDirectory with CookieAuthentication enabled
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.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:

 What about the third case of the options_get_datadir_fname2_suffix(),
 where we just copy the entire DataDirectory into the fname output?

 On the whole, let me suggest an alternative fix to this problem:  There
 are over 30 places in the codebase where we refer to
 options->DataDirectory in one way or another. What if they were all
 replaced with a function like `get_data_directory()`, and
 options->DataDirectory were only used inside functions that cared what the
 user actually typed?  That one function could be the place that makes
 DataDirectory an absolute 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] #21978 [Core Tor/Tor]: hs: Decouple adding and validating a service

[Tor Bug Tracker & Wiki]

#21978: hs: Decouple adding and validating a service
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  0.2
 Reviewer:  asn  |Sponsor:  SponsorR-must
-+

Comment (by dgoulet):

 Replying to [comment:9 nickm]:
 > Sure; merged!
 >
 > Question -- how's coverage here?

 Very low... *but* the good news is that I'm almost at 100% with prop224
 for loading/configure service which uses heavily those functions.

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

Re: [tor-bugs] #21978 [Core Tor/Tor]: hs: Decouple adding and validating a service

[Tor Bug Tracker & Wiki]

#21978: hs: Decouple adding and validating a service
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  0.2
 Reviewer:  asn  |Sponsor:  SponsorR-must
-+
Changes (by nickm):

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


Comment:

 Sure; merged!

 Question -- how's coverage 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] #21886 [Applications/Tor Browser]: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on ESR52 with e10s off

[Tor Bug Tracker & Wiki]

#21886: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on
ESR52 with e10s off
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-7.0-must-alpha,   |  Actual Points:
  ff52-esr, TorBrowserTeam201705,|
  GeorgKoppen201705  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Just to give some small update as this is a surprisingly bit PITA: A
 crucial part of the issue plays NoScript: if one disables it the problem
 in this bug goes away. If one leaves it enabled then it is safe to say the
 problem got introduced between `FIREFOX_AURORA_52_BASE` and
 `FIREFOX_BETA_52_BASE`. The exact commit is not clear yet as I get hard to
 reproduce crashes in the area of interest which are related to the problem
 I think.

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

Re: [tor-bugs] #20409 [Core Tor/Chutney]: When some chutney tors die, clean up the rest

[Tor Bug Tracker & Wiki]

#20409: When some chutney tors die, clean up the rest
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 That branch looks plausible to me; I suggest a merge.

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

Re: [tor-bugs] #21903 [Core Tor/Chutney]: Disable DNS in chutney by default, and add an option to enable it

[Tor Bug Tracker & Wiki]

#21903: Disable DNS in chutney by default, and add an option to enable it
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #19573| Points:  0.5
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 That commit seems plausible, though I do wonder why we're making DNS
 broken-by-default.  Would it be better instead to have DNS work by default
 for chutney started from a command line, and have it disabled specifically
 when running tests that won't use it?  (I'll believe  either answer)

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

Re: [tor-bugs] #22158 [Applications/Tor Browser]: Tor browser core dump on Arch Linux

[Tor Bug Tracker & Wiki]

#22158: Tor browser core dump on Arch Linux
--+---
 Reporter:  jb.1234abcd   |  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 cypherpunks):

 Replying to [comment:8 gk]:
 Wrong. It's a GMP which doesn't expect that you give it nothing instead of
 response.

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

Re: [tor-bugs] #20761 [Applications/Tor Launcher]: Tor Browser 6.5a4 is ignoring additional SocksPorts

[Tor Bug Tracker & Wiki]

#20761: Tor Browser 6.5a4 is ignoring additional SocksPorts
---+--
 Reporter:  gk |  Owner:  mcs
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201705R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * keywords:  TorBrowserTeam201705 => TorBrowserTeam201705R
 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:41 gk]:
 > It is not guaranteed that you have at least one whitespace between key
 and value. Or are we optimizing for the `SAVECONF` case and there it is
 guaranteed?

 This was an oversight due to our incomplete understanding of tor's config
 file parser. Kathy and I made a fix and also addressed the other small
 issues you raised in comment:40. Here is our new patch:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug20761-05=5154173e0facfff26bede4c37d2c47669350d0ff

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

Re: [tor-bugs] #20761 [Applications/Tor Launcher]: Tor Browser 6.5a4 is ignoring additional SocksPorts

[Tor Bug Tracker & Wiki]

#20761: Tor Browser 6.5a4 is ignoring additional SocksPorts
---+
 Reporter:  gk |  Owner:  mcs
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201705   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by mcs):

 Replying to [comment:40 gk]:
 > What worries me more is how we would deploy the patch and related ones
 in the stable series. The thing is that probably a lot of users on macOS
 and Linux who are using e.g. TorBirdy have it configured to point to Tor
 Browser. And just switching to unix domain sockets in it is breaking
 things. I am actually not sure if doing that is worth it as we are not
 really enhancing security by ripping AF_INET related code out or enforcing
 it by sandboxing means in the stable series. Breaking a bunch of setups
 for no real enhancement seems not to be the way to go IMO.

 You make a good point that, given the lack of sandboxing in the stable
 series, it does not make sense to break things that previously worked
 (such as TorBirdy finding a SOCKS listener on TCP port 9150). Maybe we
 should ship our stable releases with
 `extensions.torlauncher.control_port_use_ipc = false` and
 `extensions.torlauncher.socks_port_use_ipc = false`.
 >

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

Re: [tor-bugs] #22158 [Applications/Tor Browser]: Tor browser core dump on Arch Linux

[Tor Bug Tracker & Wiki]

#22158: Tor browser core dump on Arch Linux
--+---
 Reporter:  jb.1234abcd   |  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:6 jb.1234abcd]:
 > Btw, in unrelated matter, I see an error msg on TB startup:
 > $ gdb
 > ...
 > (gdb) file Downloads/tor-browser_en-US/Browser/firefox
 > (gdb) run
 > ...
 > May 05 16:27:29.000 [notice] Bootstrapped 100%: Done
 > [New Thread 0x7fffd26ff700 (LWP 12887)]
 > [New Thread 0x7fffc06ff700 (LWP 12888)]
 > May 05 16:27:31.000 [notice] New control connection opened from
 127.0.0.1.
 > [New Thread 0x7fffbf9ff700 (LWP 12889)]
 > May 05 16:27:31.000 [notice] New control connection opened from
 127.0.0.1.
 > [New Thread 0x7fffbe9ff700 (LWP 12890)]
 > ...
 > [Thread 0x7fffbd1fc700 (LWP 12893) exited]
 > 1493994511800 addons.productaddonsERROR   Request failed certificate
 checks: [Exception... "SSL is required and URI scheme is not https."
 nsresult: "0x8000 (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
 resource://gre/modules/CertUtils.jsm :: checkCert :: line 145"  data: no]
 > ...
 >
 > The ERROR shows up every time, but it does not have impact on TB (from
 user point of view).

 That is a bit confusing but harmless. What happens is that Tor Browser
 checks for add-on updates but we prevent pinging Mozilla servers for
 Torbutton and Tor Launcher by setting the update url to
 `data:text/plain,`. The code is complaining then that cert validation
 fails as it expects an HTTPS URL and thus a certificate.

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

Re: [tor-bugs] #22158 [Applications/Tor Browser]: Tor browser core dump on Arch Linux

[Tor Bug Tracker & Wiki]

#22158: Tor browser core dump on Arch Linux
--+---
 Reporter:  jb.1234abcd   |  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:6 jb.1234abcd]:
 > Btw, in unrelated matter, I see an error msg on TB startup:
 > $ gdb
 > ...
 > (gdb) file Downloads/tor-browser_en-US/Browser/firefox
 > (gdb) run
 > ...
 > May 05 16:27:29.000 [notice] Bootstrapped 100%: Done
 > [New Thread 0x7fffd26ff700 (LWP 12887)]
 > [New Thread 0x7fffc06ff700 (LWP 12888)]
 > May 05 16:27:31.000 [notice] New control connection opened from
 127.0.0.1.
 > [New Thread 0x7fffbf9ff700 (LWP 12889)]
 > May 05 16:27:31.000 [notice] New control connection opened from
 127.0.0.1.
 > [New Thread 0x7fffbe9ff700 (LWP 12890)]
 > ...
 > [Thread 0x7fffbd1fc700 (LWP 12893) exited]
 > 1493994511800 addons.productaddonsERROR   Request failed certificate
 checks: [Exception... "SSL is required and URI scheme is not https."
 nsresult: "0x8000 (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
 resource://gre/modules/CertUtils.jsm :: checkCert :: line 145"  data: no]
 > ...
 >
 > The ERROR shows up every time, but it does not have impact on TB (from
 user point of view).

 That is a bit confusing but harmless. What happens is that Tor Browser
 checks for add-on updates but we prevent pinging Mozilla servers for
 Torbutton and Tor Launcher by setting the update url to
 `data:text/plain,`. The code is complaining then that cert validation
 failed as it expects an HTTPS URL and thus a certificate.

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

Re: [tor-bugs] #21625 [Applications/Tor Browser]: Review networking code for Firefox 52

[Tor Bug Tracker & Wiki]

#21625: Review networking code for Firefox 52
-+-
 Reporter:  gk   |  Owner:
 |  mikeperry
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:  fixed
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks, we are done here then, yay!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22176 [Applications/Tor Browser]: Review networking code for Firefox 59

[Tor Bug Tracker & Wiki]

#22176: Review networking code for Firefox 59
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff59-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We should review the networking code for Firefox 59 to make sure the are
 no Tor bypasses.

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

Re: [tor-bugs] #22175 [Metrics/Atlas]: link AS to compass.tpo

[Tor Bug Tracker & Wiki]

#22175: link AS to compass.tpo
---+-
 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 cypherpunks):

 alternatively you could link to atlas itself, since it can also search for
 ASes:
 https://atlas.torproject.org/#search/as:AS395978

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

Re: [tor-bugs] #22174 [Metrics/Consensus Health]: Choose what colors we should use for the consensus-health line graphs

[Tor Bug Tracker & Wiki]

#22174: Choose what colors we should use for the consensus-health line graphs
--+--
 Reporter:  tom   |  Owner:  linda
 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 linda):

 * cc: linda (added)


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

Re: [tor-bugs] #22174 [Metrics/Consensus Health]: Choose what colors we should use for the consensus-health line graphs

[Tor Bug Tracker & Wiki]

#22174: Choose what colors we should use for the consensus-health line graphs
--+--
 Reporter:  tom   |  Owner:  linda
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by linda):

 This is a complex question, but it depends what kind of data you are
 trying to represent. Data is commonly split into three categories:
 a) increasing values along a single dimension
 b) diverging values around the center of a scale
 c) discrete categories

 This will determine the kind of colors you would want to use. For a), it
 is typical to have few colors and use varying shades of darkness to
 display information
 [https://lisacharlotterost.github.io/pic/160423-colorpicker1.png example],
 whereas this is not true for b) and c). Since I don't know the type of
 information the health consensus data will look like, you will need to
 have a look at it before determining what coloring scheme to use.

 My initial instinct is that the data looks like either a) or b), because
 when I think of "health," I think of "mildly healthy to invincibly
 healthy"(a) or "really sick to really healthy"(b), but I could be wrong.

 So check this out as a starting place:
 * color schemes to use for increasing values in a single dimension
 ("mildly healthy to invincibly healthy," a), where you want 9-11 colors
 and to prefer them be colorblind safe:
 [http://colorbrewer2.org/#type=sequential=BuGn=9 9 color
 palettes, colorblind safe]
 * color schemes to use for in divergent values around the center of a
 scale ("really sick to really healthy," b) where you want 9-11 colors and
 to prefer them be colorblind safe:
 [http://colorbrewer2.org/#type=diverging=BrBG=11 11 color
 palettes, colorblind safe]

 Those above links are from a tool called ColorBrewer, where Cynthia Brewer
 did a bunch of research, wayyy more than me. Her research is incorporated
 into R's ggplot, and a whole bunch of things that are the standard for
 information visualization. So I defer to her expertise on this one. (I am
 not opposed to just telling you my most favorite 11 colors if it tickles
 your fancy, but I advise against this.)

 As you will see in the links above, the palette offer multiple coloring
 options. Take the
 [http://colorbrewer2.org/#type=sequential=BuGn=9 first link]---
 and look at the gradient of green vs the gradient of red. That can send a
 different type of message, due to psychological associations with color.
 Green looks like a calm map of the highlights while red seems like a
 doomsday map. So, all the colorblindness-proofing and color-distinciveness
 being equal, pick the message you want to send with the colors or pick the
 one that "feels" the best to you!

 I suggest using this tool above and picking one of those palettes, but if
 this is not satisfactory, or if you want to verify my claims, try poking
 around online with keywords such as "information visualization," "visually
 distinct colors," or "color perception." I hope this helps!

 ヽ(•◡•)ﾉ

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

Re: [tor-bugs] #22174 [Metrics/Consensus Health]: Choose what colors we should use for the consensus-health line graphs

[Tor Bug Tracker & Wiki]

#22174: Choose what colors we should use for the consensus-health line graphs
--+--
 Reporter:  tom   |  Owner:  linda
 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 tom):

 * owner:   => linda
 * status:  new => assigned


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22175 [Metrics/Atlas]: link AS to compass.tpo

[Tor Bug Tracker & Wiki]

#22175: link AS to compass.tpo
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Lets make the AS number on the atlas page more useful by linking it to
 compass.

 This would then give you all relays on that given AS.

 Example:
 https://atlas.torproject.org/#details/29C92C854E0F6652A77F3A8B231D6932993969E8
 would lik to:
 
https://compass.torproject.org/#/ases=AS395978?exit_filter=all_relays=cw_reverse==-1=AS395978

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

Re: [tor-bugs] #21883 [Metrics/Analysis]: One-off analysis for number of relays a bwauth decided the median for

[Tor Bug Tracker & Wiki]

#21883: One-off analysis for number of relays a bwauth decided the median for
--+---
 Reporter:  Sebastian |  Owner:  tom
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by tom):

 * status:  assigned => needs_information


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

Re: [tor-bugs] #22108 [Metrics/Consensus Health]: Bandwidth scanner page chooses yellow for moria1

[Tor Bug Tracker & Wiki]

#22108: Bandwidth scanner page chooses yellow for moria1
--+
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by tom):

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


Comment:

 yellow -> limegreen in
 
https://gitweb.torproject.org/depictor.git/commit/?id=1a9fc3ed6490777b3eed01bbca11d6cdcd2a609e

 Opened #22174 for the broader question.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22174 [Metrics/Consensus Health]: Choose what colors we should use for the consensus-health line graphs

[Tor Bug Tracker & Wiki]

#22174: Choose what colors we should use for the consensus-health line graphs
--+-
 Reporter:  tom   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 A more comprehensive bug than
 https://trac.torproject.org/projects/tor/ticket/22108

 https://consensus-health.torproject.org/graphs.html has two types of line
 graphs, the pure line graphs and the stacked area graphs.

 We should identify 11 colors for the line graph (we expect to use the
 first 9 but let's hedge a little) that are user friendly, distinct,
 accessible to color blind people, etc.

 And we should identify 5 colors for the stacked area graph. I had avoided
 using red because red implies 'bad' and technically none of the colors in
 the area graph is 'bad'. (Well, maybe Unmeasured could be considered
 'bad'...?)

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

Re: [tor-bugs] #21272 [Metrics]: Onionperf deployment

[Tor Bug Tracker & Wiki]

#21272: Onionperf deployment
-+--
 Reporter:  hiro |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by robgjansen):

 The new onion data on the metrics performance page looks great! What's the
 status of adding the archived data and the current data from
 https://phantomtrain.robgjansen.com? Once that is done, we should have
 historical data going back to April 2016 :)

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

Re: [tor-bugs] #22170 [Applications/Tor Browser]: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy safety on Android

[Tor Bug Tracker & Wiki]

#22170: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy 
safety
on Android
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr, tbb-mobile  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 See also https://bugzilla.mozilla.org/show_bug.cgi?id=1357997#c9 and
 hopefully subsequent comments.

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

Re: [tor-bugs] #22173 [Core Tor/Tor]: Support looking up node by ed25519 identity

[Tor Bug Tracker & Wiki]

#22173: Support looking up node by ed25519 identity
--+
 Reporter:  dgoulet   |  Owner:  nickm
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * cc: nickm (added)
 * priority:  Medium => High
 * points:   => 1


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22173 [Core Tor/Tor]: Support looking up node by ed25519 identity

[Tor Bug Tracker & Wiki]

#22173: Support looking up node by ed25519 identity
--+
 Reporter:  dgoulet   |  Owner:  nickm
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Currently we can only lookup a `node_t` object using the SHA1 identity
 digest (`node_get_by_id()` and friends).

 It would be good to have a map of `node_t` indexed by ed25519 identity so
 we can look them up that way.

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

Re: [tor-bugs] #21625 [Applications/Tor Browser]: Review networking code for Firefox 52

[Tor Bug Tracker & Wiki]

#21625: Review networking code for Firefox 52
-+-
 Reporter:  gk   |  Owner:
 |  mikeperry
 Type:  task | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:17 cypherpunks]:
 > Replying to [comment:16 mcs]:
 > > We do wonder why Mozilla is keeping APIs such as these (making them
 chrome-only) instead of simply removing them.
 > Compatibility: https://bugzilla.mozilla.org/show_bug.cgi?id=1247628

 Thanks. I would characterize the situation more as "Mozilla may reuse the
 TCPSocket/UDPSocket code to provide similar capabilities to WebExtensions
 add-ons" (which, if you compare what can be done in an XPCOM extension
 with WebExtensions could be viewed as a compatibility 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] #21668 [Core Tor/Tor]: Prop278: Update cached_dir_t and related types to no longer assume single compresison method

[Tor Bug Tracker & Wiki]

#21668: Prop278: Update cached_dir_t and related types to no longer assume 
single
compresison method
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by nickm):

 actual_points += .2

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

Re: [tor-bugs] #21668 [Core Tor/Tor]: Prop278: Update cached_dir_t and related types to no longer assume single compresison method

[Tor Bug Tracker & Wiki]

#21668: Prop278: Update cached_dir_t and related types to no longer assume 
single
compresison method
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by nickm):

 ahf, have a look at `compress_consensus_more_ways`.  It needs tests, and
 it doesn't do all of this ticket, but it seems to work for me and at least
 it doesn't keep the old tests from passing. :)

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

Re: [tor-bugs] #22115 [Applications/Tor Browser]: Use i386 containers for building Tor Browser on linux32 and win32

[Tor Bug Tracker & Wiki]

#22115: Use i386 containers for building Tor Browser on linux32 and win32
--+---
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201705  |  Actual Points:
Parent ID:  #17379| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 After switching to i386 containers, we are affected by #20635, with
 sometime (but not always) a segmentation fault while building go.

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

Re: [tor-bugs] #21625 [Applications/Tor Browser]: Review networking code for Firefox 52

[Tor Bug Tracker & Wiki]

#21625: Review networking code for Firefox 52
-+-
 Reporter:  gk   |  Owner:
 |  mikeperry
 Type:  task | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:16 mcs]:
 > We do wonder why Mozilla is keeping APIs such as these (making them
 chrome-only) instead of simply removing them.
 Compatibility: https://bugzilla.mozilla.org/show_bug.cgi?id=1247628

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

Re: [tor-bugs] #21824 [Applications/Tor Browser]: Investigate using runc instead of docker

[Tor Bug Tracker & Wiki]

#21824: Investigate using runc instead of docker
--+
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201705  |  Actual Points:
Parent ID:  #17379| Points:
 Reviewer:|Sponsor:
--+
Changes (by boklm):

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


Comment:

 This is done in commit 2d98c063010fc5b0f8da3e386587a501e27507b9.

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

Re: [tor-bugs] #22158 [Applications/Tor Browser]: Tor browser core dump on Arch Linux

[Tor Bug Tracker & Wiki]

#22158: Tor browser core dump on Arch Linux
--+---
 Reporter:  jb.1234abcd   |  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 cypherpunks):

 Try to open a lot of pages and close them step by step, e10s is very
 crashy in such cases.

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

Re: [tor-bugs] #16337 [Applications/Tor Browser]: Investigate whether Animations(Player) API provides new high resolution timestamp

[Tor Bug Tracker & Wiki]

#16337: Investigate whether Animations(Player) API provides new high resolution
timestamp
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting-time-   |  Actual Points:
  highres, tbb-7.0-must-alpha,   |
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 Replying to [comment:13 arthuredelstein]:
 > Here's a patch for review:
 > https://github.com/arthuredelstein/tor-browser/commit/16337

 This patch looks okay. Do we also need to patch `GetCurrentTimeAsDouble()`
 inside `dom/animation/AnimationTimeline.h`? Kathy and I are not sure how
 the Animation.timeline object relates to the other timing 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] #21625 [Applications/Tor Browser]: Review networking code for Firefox 52

[Tor Bug Tracker & Wiki]

#21625: Review networking code for Firefox 52
-+-
 Reporter:  gk   |  Owner:
 |  mikeperry
 Type:  task | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:13 gk]:
 > mcs/brade: I'd like to hear your opinion about the TCPSocket stuff (see
 below) as you had concerns about that the last time which resulted into
 filing #18866. (All the other pieces replied to in this comment are even
 less problematic I think.)

 Kathy and I agree with your analysis.
 We do wonder why Mozilla is keeping APIs such as these (making them
 chrome-only) instead of simply removing 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] #22158 [Applications/Tor Browser]: Tor browser core dump on Arch Linux

[Tor Bug Tracker & Wiki]

#22158: Tor browser core dump on Arch Linux
--+---
 Reporter:  jb.1234abcd   |  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 jb.1234abcd):

 Thanks.
 I ran TB with coredump and debug files a few times, but I get clean
 sessions (TB does not die).

 I e-mailed a link to the coredump file as requested.

 Btw, in unrelated matter, I see an error msg on TB startup:
 $ gdb
 ...
 (gdb) file Downloads/tor-browser_en-US/Browser/firefox
 (gdb) run
 ...
 May 05 16:27:29.000 [notice] Bootstrapped 100%: Done
 [New Thread 0x7fffd26ff700 (LWP 12887)]
 [New Thread 0x7fffc06ff700 (LWP 12888)]
 May 05 16:27:31.000 [notice] New control connection opened from 127.0.0.1.
 [New Thread 0x7fffbf9ff700 (LWP 12889)]
 May 05 16:27:31.000 [notice] New control connection opened from 127.0.0.1.
 [New Thread 0x7fffbe9ff700 (LWP 12890)]
 ...
 [Thread 0x7fffbd1fc700 (LWP 12893) exited]
 1493994511800   addons.productaddonsERROR   Request failed certificate
 checks: [Exception... "SSL is required and URI scheme is not https."
 nsresult: "0x8000 (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
 resource://gre/modules/CertUtils.jsm :: checkCert :: line 145"  data: no]
 ...

 The ERROR shows up every time, but it does not have impact on TB (from
 user point of view).

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

Re: [tor-bugs] #21882 [Metrics/Consensus Health]: Graph for number of relays that bwauths decided the median for

[Tor Bug Tracker & Wiki]

#21882: Graph for number of relays that bwauths decided the median for
--+
 Reporter:  Sebastian |  Owner:  tom
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by tom):

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


Comment:

 This is rebased and 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] #22148 [Core Tor/Tor]: prop140: conformance to proposal, unhandled corner cases

[Tor Bug Tracker & Wiki]

#22148: prop140: conformance to proposal, unhandled corner cases
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .5
Parent ID:  #13339| Points:  .5
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by nickm):

 * actualpoints:   => .5


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

Re: [tor-bugs] #22148 [Core Tor/Tor]: prop140: conformance to proposal, unhandled corner cases

[Tor Bug Tracker & Wiki]

#22148: prop140: conformance to proposal, unhandled corner cases
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #13339| Points:  .5
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 Replying to [ticket:22148 nickm]:
 > There are some remaining issues in my prop140_complete branch.
 >
 > We should [allocate] a protover for directories that support these new
 requests.

 Done in `prop140_aftermath_url`, which now I've tested. :)

 > Right now, we treat failures to apply a consensus diff as if the
 consensus download had failed.  Is this what we should be doing?

 Still remains. I've made this into #22172 since it will take more
 thinking.

 > The proposal specifies a method for downloading diffs without using the
 X-Or-Diff-From-Consensus syntax.  We should implement that on the server
 side.

 Done in `prop140_aftermath_url`.

 > Our proposal specifies networkstatus parameters, but the code doesn't
 implement them.

 Done in `prop140_aftermath_cfg`.

 > The proposal says that sha3 digests may be truncated in requests: I
 propose we do not implement that, and revise the proposal to match.

 Done in torspec in 28816242f9eaa5509dc400a48ade1e7c4a591717 and
 522d75dd3969a4e220a113d38cf2c4497d264ab4.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22172 [Core Tor/Tor]: prop140: What to do when a diff fails to apply?

[Tor Bug Tracker & Wiki]

#22172: prop140: What to do when a diff fails to apply?
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #13339
   Points:|   Reviewer:
  Sponsor:  Sponsor4  |
--+
 Right now, we treat failures to apply a consensus diff as if the consensus
 download had failed.  Is this what we should be doing?

 (Formerly part of #22148)

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

Re: [tor-bugs] #21625 [Applications/Tor Browser]: Review networking code for Firefox 52

[Tor Bug Tracker & Wiki]

#21625: Review networking code for Firefox 52
-+-
 Reporter:  gk   |  Owner:
 |  mikeperry
 Type:  task | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:7 mikeperry]:
 > Components that could probably use another review (Part 3/3):
 >  * The NetworkInfoService (./netwerk/base/NetworkInfoServiceCocoa.cpp
 and ./netwerk/base/NetworkInfoServiceLinux.cpp) both collect a list of
 local IP addresses for use in
 nsNetworkInfoService::ListNetworkAddresses(). This is used by mDNS and the
 Presentation API. Did I miss any uses? Maybe we want to patch this out
 just in case?

 Sounds like a good idea to me. This is: #22165.

 >  * media/mtransport/nr_socket_prsock.cpp is an alternate non-SOCKS
 socket API. It should be disabled by WebRTC, but if Mozilla removed the
 compile-time WebRTC option, this definitely needs a double-check that it
 is not used.

 Marked for `ff59-esr` (#22166).

 >  * netwerk/base/ThrottleQueue.cpp uses what appear to be local sockets
 for timer notification. Could use a double-check.

 This looks actually okay to me. It got implemented in
 https://bugzilla.mozilla.org/show_bug.cgi?id=1244227, for dev tools as an
 option to simulate crappy networks.

 >  * On Android, the uses of ch.boye.httpclientandroidlib.impl.client.*
 should be verified again.

 #22170

 >  * The full git diff from esr45 to esr52 of ./android/ should probably
 be reviewed by someone with more Android development experience than me,
 for additional networking calls.

 #22171

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22171 [Applications/Tor Browser]: Review networking calls in esr45-esr52 diff of ./android/* closer

[Tor Bug Tracker & Wiki]

#22171: Review networking calls in esr45-esr52 diff of ./android/* closer
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff52-esr, tbb-
  |  mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Mike writes in #21625:
 {{{
 The full git diff from esr45 to esr52 of ./android/ should probably be
 reviewed by someone with more Android development experience than me, for
 additional networking calls.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22170 [Applications/Tor Browser]: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy safety on Android

[Tor Bug Tracker & Wiki]

#22170: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy 
safety
on Android
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff52-esr, tbb-
  |  mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We should check ch.boye.httpclientandroidlib.impl.client.* for proxy
 compliance. If we don't get to it earlier then it is a blocker for our Tor
 Browser on mobile.

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

Re: [tor-bugs] #22169 [Metrics/Onionoo]: Two typos in the documentation

[Tor Bug Tracker & Wiki]

#22169: Two typos in the documentation
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Good catches.  Applied and pushed to master, though it might take a while
 until these are updated on the server.  Closing.  Thanks!

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

Re: [tor-bugs] #22167 [Metrics/Onionoo]: Remove the protocol page

[Tor Bug Tracker & Wiki]

#22167: Remove the protocol page
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  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:

 Good catch.  Removed in master, though it might take a while until it's
 updated on the server.  Closing.  Thanks!

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

Re: [tor-bugs] #20961 [Core Tor/Tor]: prop224: Implement consensus params to adjust portion of the protocol

[Tor Bug Tracker & Wiki]

#20961: prop224: Implement consensus params to adjust portion of the protocol
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  assigned
 Priority:  Very High|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #12424   | Points:  0.5
 Reviewer:   |Sponsor:  SponsorR-must
-+

Comment (by dgoulet):

 New possible one would be: Number of extra intro points we use when
 picking a new set (`NUM_INTRO_POINTS_EXTRA`). It's coming from proposal
 155, section 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] #22164 [Core Tor/Tor]: Fix memory leak in parse_or_diff_from_header()

[Tor Bug Tracker & Wiki]

#22164: Fix memory leak in parse_or_diff_from_header()
--+
 Reporter:  ahf   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged!

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

Re: [tor-bugs] #22168 [Metrics/Onionoo]: Do not return empty objects

[Tor Bug Tracker & Wiki]

#22168: Do not return empty objects
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 I admit that empty objects are not terribly useful.  But they're empty
 objects in an array, and even an empty object in a given position can be
 considered as information.  We cannot remove them without possibly
 breaking clients, even though that's probably an edge case.  But the saved
 bandwidth is likely not worth the effort of putting out a new major
 version.  I'm closing this as wontfix, but thanks for the suggestion
 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] #21943 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall getpid)

[Tor Bug Tracker & Wiki]

#21943: (Sandbox) Caught a bad syscall attempt (syscall getpid)
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.10
 Severity:  Normal   | Resolution:
 Keywords:  sandbox seccomp2 getpid  |  Actual Points:  .1
  029-backport 030-backport AffectsTails |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 anonym: Can you confirm that this patch fixes it 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] #22164 [Core Tor/Tor]: Fix memory leak in parse_or_diff_from_header()

[Tor Bug Tracker & Wiki]

#22164: Fix memory leak in parse_or_diff_from_header()
--+
 Reporter:  ahf   |  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 lgtm;

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

Re: [tor-bugs] #22158 [Applications/Tor Browser]: Tor browser core dump on Arch Linux

[Tor Bug Tracker & Wiki]

#22158: Tor browser core dump on Arch Linux
--+---
 Reporter:  jb.1234abcd   |  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):

 If i need debug symbols I usually create a `.debug` directory in `tor-
 browser_en-US/Browser` and copy the contents of `Debug/Browser` into that
 one. See: https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-
 Files.html.

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

Re: [tor-bugs] #22163 [User Experience/Website]: Make it more obvious how to report security related bugs

[Tor Bug Tracker & Wiki]

#22163: Make it more obvious how to report security related bugs
-+--
 Reporter:  gk   |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by mcs):

 * cc: mcs (added)


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

Re: [tor-bugs] #22169 [Metrics/Onionoo]: Two typos in the documentation

[Tor Bug Tracker & Wiki]

#22169: Two typos in the documentation
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cypherpunks):

 * status:  new => 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

[tor-bugs] #22169 [Metrics/Onionoo]: Two typos in the documentation

[Tor Bug Tracker & Wiki]

#22169: Two typos in the documentation
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Patch is coming once i get 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

[tor-bugs] #22168 [Metrics/Onionoo]: Do not return empty objects

[Tor Bug Tracker & Wiki]

#22168: Do not return empty objects
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 In some instances Onionoo returns relay and bridge arrays with empty
 objects. This seems like a waste of bandwidth. Next are some URLs that
 return arrays with empty objects.

 https://onionoo.torproject.org/details?fields=a (non-existing fields makes
 both arrays consist of only empty objects)
 https://onionoo.torproject.org/details?fields=fingerprint (using a field
 that only exists for relays makes the bridge array consist of only empty
 objects)

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

Re: [tor-bugs] #22158 [Applications/Tor Browser]: Tor browser core dump on Arch Linux

[Tor Bug Tracker & Wiki]

#22158: Tor browser core dump on Arch Linux
--+---
 Reporter:  jb.1234abcd   |  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 jb.1234abcd):

 I set it up as follows.

 My regular (production) tor browser is in dir
 /home/jb/Downloads/tor-browser_en-US/Browser/firefox
 I unzipped debug symbols file in dir:
 /home/jb/Downloads/Debug/Browser/
 $ ls -al /home/jb/Downloads/Debug/Browser/
 drwx-- 4 jb jb  4096 Jan  1  2000 .
 drwx-- 3 jb jb  4096 Jan  1  2000 ..
 drwx-- 3 jb jb  4096 Jan  1  2000 browser
 drwx-- 2 jb jb  4096 Jan  1  2000 components
 -rwx-- 1 jb jb943767 Jan  1  2000 firefox
 -rwx-- 1 jb jb   1562241 Jan  1  2000 libfreebl3.so
 -rwx-- 1 jb jb332084 Jan  1  2000 liblgpllibs.so
 -rwx-- 1 jb jb   2315707 Jan  1  2000 libmozsqlite3.so
 -rwx-- 1 jb jb916364 Jan  1  2000 libnspr4.so
 -rwx-- 1 jb jb   5169835 Jan  1  2000 libnss3.so
 -rwx-- 1 jb jb624131 Jan  1  2000 libnssckbi.so
 -rwx-- 1 jb jb878445 Jan  1  2000 libnssdbm3.so
 -rwx-- 1 jb jb466443 Jan  1  2000 libnssutil3.so
 -rwx-- 1 jb jb 59055 Jan  1  2000 libplc4.so
 -rwx-- 1 jb jb 37104 Jan  1  2000 libplds4.so
 -rwx-- 1 jb jb961197 Jan  1  2000 libsmime3.so
 -rwx-- 1 jb jb   1136843 Jan  1  2000 libsoftokn3.so
 -rwx-- 1 jb jb   1105266 Jan  1  2000 libssl3.so
 -rwx-- 1 jb jb 766254529 Jan  1  2000 libxul.so
 -rwx-- 1 jb jb   4020862 Jan  1  2000 plugin-container
 -rwx-- 1 jb jb522787 Jan  1  2000 updater
 -rwx-- 1 jb jb   1128839 Jan  1  2000 webapprt-stub

 I overwrote original files with unzipped debug files:
 $ cp -pr /home/jb/Downloads/Debug/Browser/* /home/jb/Downloads/tor-
 browser_en-US/Browser/

 $ coredumpctl gdb 2186
 ...
 Executable: /home/jb/Downloads/tor-browser_en-US/Browser/firefox
 ...
 Reading symbols from /home/jb/Downloads/tor-browser_en-
 US/Browser/firefox...done.
 ...
 Program terminated with signal SIGSEGV, Segmentation fault.
 ...
 (gdb)
 (gdb) br main
 (gdb) run
 Starting program: /home/jb/Downloads/tor-browser_en-US/Browser/firefox
 /bin/bash: /home/jb/Downloads/tor-browser_en-US/Browser/firefox: cannot
 execute binary file: Exec format error
 /bin/bash: /home/jb/Downloads/tor-browser_en-US/Browser/firefox: Success
 During startup program exited with code 126.
 (gdb)

 It does not seem to work ...
 Can you give me instructions how to set it up properly ?
 Then I can re-run the debugging session and capture whatever data you need
 to figure out what caused the dump.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22167 [Metrics/Onionoo]: Remove the protocol page

[Tor Bug Tracker & Wiki]

#22167: Remove the protocol page
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 According to https://onionoo.torproject.org/protocol.html the page will be
 removed after March 31, 2017 but it's still there.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22166 [Applications/Tor Browser]: Make sure media/mtransport/nr_socket_prsock.cpp is disabled in Tor Browser

[Tor Bug Tracker & Wiki]

#22166: Make sure media/mtransport/nr_socket_prsock.cpp is disabled in Tor 
Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff59-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Currently we don't compile media/mtransport/nr_socket_prsock.cpp in as we
 use `--disable-webrtc`. There is the idea to move to a preference-based
 approach for disabling webrtc, though
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1314443). If that is done we
 need to be sure that media/mtransport/nr_socket_prsock.cpp stays
 unavailable, though.

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

Re: [tor-bugs] #22165 [Applications/Tor Browser]: Rip out the option to collect local IP addresses

[Tor Bug Tracker & Wiki]

#22165: Rip out the option to collect local IP addresses
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr, tbb-7.0-must|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Actually, there is a Windows version, NetworkInfoServiceWindows.cpp, as
 well. We should probably return early in all three `DoListAddresses()`
 methods with `NS_ERROR_FAILURE`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22165 [Applications/Tor Browser]: Rip out the option to collect local IP addresses

[Tor Bug Tracker & Wiki]

#22165: Rip out the option to collect local IP addresses
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff52-esr,
  |  tbb-7.0-must
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The NetworkInfoService (./netwerk/base/NetworkInfoServiceCocoa.cpp and
 ./netwerk/base/NetworkInfoServiceLinux.cpp) both collect a list of local
 IP addresses for use in nsNetworkInfoService::ListNetworkAddresses(). This
 is used by mDNS and the Presentation API. We should rip out the relevant
 part as a defense in depth

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

Re: [tor-bugs] #21625 [Applications/Tor Browser]: Review networking code for Firefox 52

[Tor Bug Tracker & Wiki]

#21625: Review networking code for Firefox 52
-+-
 Reporter:  gk   |  Owner:
 |  mikeperry
 Type:  task | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 2c: now Firefox uses 3 loopback connections (the child process too).
 What about DNS-RPC calls?
 (Also what protection might be added against extraction of MAC address as
 in recent exploit? Maybe, some interception of such system calls?)

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

Re: [tor-bugs] #8387 [Core Tor/Tor]: Unbuilt one-hop circuits sometimes hang around forever

[Tor Bug Tracker & Wiki]

#8387: Unbuilt one-hop circuits sometimes hang around forever
-+-
 Reporter:  mikeperry|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, 025-triaged, |  Actual Points:
  027-triaged-1-out, 2016-bug-retrospective, |
  tor-03-unspecified-201612  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 I found this in my logs :

 {{{
 May 04 16:08:02.000 [notice] Diagnostic for issue 8387: Found 1 one-hop
 circuits more than 1800 seconds old! Logging 1...
 May 04 16:08:02.000 [notice]   #0 created at 2017-05-04 15:26:07. open,
 General-purpose client. Not marked for close. Package window: 1000. usable
 for new conns. Dirty since 2017-05-04 15:58:06 (596 seconds vs 600-second
 cutoff).
 May 04 16:08:02.000 [notice] It has been 23 seconds since I last called
 circuit_expire_old_circuits_clientside().
 }}}

 on Tor 0.3.1.0-alpha-dev (git-b8f7488e94f2cb83) ; tor client only on
 debian unstable 32bit.

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

Re: [tor-bugs] #22164 [Core Tor/Tor]: Fix memory leak in parse_or_diff_from_header()

[Tor Bug Tracker & Wiki]

#22164: Fix memory leak in parse_or_diff_from_header()
--+
 Reporter:  ahf   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * status:  new => needs_review


Comment:

 Added patch in https://gitlab.com/ahf/tor/merge_requests/8/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

[tor-bugs] #22164 [Core Tor/Tor]: Fix memory leak in parse_or_diff_from_header()

[Tor Bug Tracker & Wiki]

#22164: Fix memory leak in parse_or_diff_from_header()
--+
 Reporter:  ahf   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We should fix the memory leak found in parse_or_diff_from_header(). This
 was found via Coverity under CID 1405876.

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

Re: [tor-bugs] #22158 [Applications/Tor Browser]: Tor browser core dump on Arch Linux

[Tor Bug Tracker & Wiki]

#22158: Tor browser core dump on Arch Linux
--+---
 Reporter:  jb.1234abcd   |  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):

 I wonder if you could get gdb to read the debug symbols we provide in
 separate files (see the tor-browser-linux*debug.zip ones in
 https://dist.torproject.org/torbrowser/6.5.2/) to get better stack traces.

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

Re: [tor-bugs] #21943 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall getpid)

[Tor Bug Tracker & Wiki]

#21943: (Sandbox) Caught a bad syscall attempt (syscall getpid)
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.10
 Severity:  Normal   | Resolution:
 Keywords:  sandbox seccomp2 getpid  |  Actual Points:  .1
  029-backport 030-backport AffectsTails |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-
Changes (by anonym):

 * keywords:  sandbox seccomp2 getpid 029-backport 030-backport => sandbox
 seccomp2 getpid 029-backport 030-backport AffectsTails


Comment:

 This affects Tails: in our automated test suite setup, this prevents all
 Chutney nodes from starting (unless we disable sandboxing in
 `torrc_templates/common.i`). A backport to 3.x would be appreciated!

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

Re: [tor-bugs] #20114 [Applications/Tor Check]: check.torproject.org false-negatives "not connected through tor"

[Tor Bug Tracker & Wiki]

#20114: check.torproject.org false-negatives  "not connected through tor"
+-
 Reporter:  6h72Q484AddGha8H|  Owner:  arlolra
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by cypherpunks):

 #22161 closed as 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] #21625 [Applications/Tor Browser]: Review networking code for Firefox 52

[Tor Bug Tracker & Wiki]

#21625: Review networking code for Firefox 52
-+-
 Reporter:  gk   |  Owner:
 |  mikeperry
 Type:  task | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 mcs/brade: I'd like to hear your opinion about the TCPSocket stuff (see
 below) as you had concerns about that the last time which resulted into
 filing #18866. (All the other pieces replied to in this comment are even
 less problematic I think.)

 Replying to [comment:6 mikeperry]:
 > Stuff to verify is still patched or disabled (part 2/3)
 >  * The DNS service was changed a bit for e10s. See
 ./netwerk/dns/ChildDNSService.cpp. Verify our DNS patch still actually
 disables non-SOCKS DNS with e10s.

 ChildDNSService.cpp has no own resolver capabilities. Sync resolve is not
 supported at all;  `AsyncResolveExtended` creates a DNSChildRequest and
 starts that request. It gets sent to the parent process
 (SendPDNSReqeustContstructor()). The corresponding
 `RecvPDNSRequestConstructor` method calls `DoAsyncResolve` provided by
 `DNSRequestParent` which calls `AsyncResolveExtended` which we have
 patched in nsDNSService2.cpp.

 >  * Make sure RTSP is still disabled for desktop and Android
 (netwerk/protocol/rtsp/*)

 RTSP is gone with

 https://bugzilla.mozilla.org/show_bug.cgi?id=1295885
 https://bugzilla.mozilla.org/show_bug.cgi?id=1291629

 . The hint in the `moz.build` file is just a leftover.


 >  * Make sure disabling WebRTC still disables all of the
 ./media/mtransport/* stuff.

 We have
 {{{
 if CONFIG['MOZ_WEBRTC']:
 DIRS += [
 '/media/webrtc',
 '/media/mtransport',
 ]
 }}}
 in `toolkit.mozbuild` and we don't set `MOZ_WEBRTC` as we don't compile it
 in with the configure switch.

 >  * Verify our defense-in-depth patches to NSS/OCSP still apply (ditto
 for other proxy patches)

 They do and other patches still applied as well (see #20680 for what we
 did and for review comments).

 >  * Verify that the TCPSocket and UDPSocket DOM APIs are still disabled
 by pref (esp if the moz prefix goes away).

 There is no pref anymore for `TCPSocket`, rather it is bound to
 `ShouldTCPSocketExist`:
 {{{
 -  [NewObject, Pref="dom.mozTCPSocket.enabled", CheckAnyPermissions="tcp-
 socket"]
 +  [NewObject, Func="mozilla::dom::TCPSocket::ShouldTCPSocketExist"]
 }}}
 which does
 {{{
 return
 nsContentUtils::IsSystemPrincipal(nsContentUtils::ObjectPrincipal(global));
 }}}
 . Thus only chrome code can use it. I think we are not worse off than we
 were with the pref in ESR45.

 There are no changes regarding the UDPSocket DOM API, so we are still
 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] #22089 [Applications/Tor Browser]: Add Decentraleyes to stop tracking by large CDNs (resulting in slightly less traffic for exits) in the Tor Browser (was: Adding Decentraleyes to stop

[Tor Bug Tracker & Wiki]

#22089: Add Decentraleyes to stop tracking by large CDNs (resulting in slightly
less traffic for exits) in the Tor Browser
--+--
 Reporter:  imageverif|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  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] #22161 [Applications/Tor Check]: check.torproject.org false report

[Tor Bug Tracker & Wiki]

#22161: check.torproject.org false report
+---
 Reporter:  desci   |  Owner:  arlolra
 Type:  defect  | Status:  closed
 Priority:  Very Low|  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  check   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by cypherpunks):

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


Comment:

 duplicate of #20114

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

Re: [tor-bugs] #20114 [Applications/Tor Check]: check.torproject.org false-negatives "not connected through tor" (was: Tor Browser v6.0.4 on Linux reported that exiting via node 162.243.117.41 was "no

[Tor Bug Tracker & Wiki]

#20114: check.torproject.org false-negatives  "not connected through tor"
+-
 Reporter:  6h72Q484AddGha8H|  Owner:  arlolra
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |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] #22161 [Applications/Tor Check]: check.torproject.org false report

[Tor Bug Tracker & Wiki]

#22161: check.torproject.org false report
+-
 Reporter:  desci   |  Owner:  arlolra
 Type:  defect  | Status:  new
 Priority:  Very Low|  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  check   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by blockflare):

 See this answer by @arlolra https://tor.stackexchange.com/a/873

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

Re: [tor-bugs] #22158 [Applications/Tor Browser]: Tor browser core dump on Arch Linux

[Tor Bug Tracker & Wiki]

#22158: Tor browser core dump on Arch Linux
--+---
 Reporter:  jb.1234abcd   |  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 jb.1234abcd):

 Tor Browser 6.5.2

 Not reproducible.

 Additional info:
 $ coredumpctl gdb 2186
 ...
 Reading symbols from /home/jb/Downloads/tor-browser_en-
 US/Browser/firefox...(no debugging symbols found)...done.
 [New LWP 5626]
 [New LWP 2198]
 [New LWP 2186]
 [New LWP 2214]
 [New LWP 2189]
 [New LWP 2190]
 [New LWP 2235]
 [New LWP 2193]
 [New LWP 2194]
 [New LWP 2195]
 [New LWP 2196]
 [New LWP 2197]
 [New LWP 2199]
 [New LWP 2200]
 [New LWP 2202]
 [New LWP 2206]
 [New LWP 2219]
 [New LWP 2224]
 [New LWP 2275]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library "/usr/lib/libthread_db.so.1".
 Core was generated by `./firefox --class Tor Browser -profile
 TorBrowser/Data/Browser/profile.default'.
 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  0x7f8418598ea0 in raise () from /usr/lib/libpthread.so.0
 [Current thread is 1 (Thread 0x7f83bd8ff700 (LWP 5626))]
 (gdb)
 (gdb) info reg
 rax0x0  0
 rbx0xb  11
 rcx0x7f8418598ea0   140205320933024
 rdx0x0  0
 rsi0x7f83bd8fe820   140203797768224
 rdi0x2  2
 rbp0x7f83bd8fe950   0x7f83bd8fe950
 rsp0x7f83bd8fe820   0x7f83bd8fe820
 r8 0x0  0
 r9 0x7f83bd8fe820   140203797768224
 r100x8  8
 r110x246582
 r120x7f83bd8ff670   140203797771888
 r130x15fa   5626
 r140x7f83bd8ff700   140203797772032
 r150x7f83bd8fea80   140203797768832
 rip0x7f8418598ea0   0x7f8418598ea0 
 eflags 0x246[ PF ZF IF ]
 cs 0x33 51
 ss 0x2b 43
 ds 0x0  0
 es 0x0  0
 fs 0x0  0
 gs 0x0  0

 (gdb) bt
 #0  0x7f8418598ea0 in raise () at /usr/lib/libpthread.so.0
 #1  0x7f84141a319c in  () at /home/jb/Downloads/tor-browser_en-
 US/Browser/libxul.so
 #2  0x7f8414c78c36 in  () at /home/jb/Downloads/tor-browser_en-
 US/Browser/libxul.so
 #3  0x7f8418598fe0 in  () at
 /usr/lib/libpthread.so.0
 #4  0x7f841419f0b7 in  () at /home/jb/Downloads/tor-browser_en-
 US/Browser/libxul.so
 #5  0x7f8418989568 in  () at /home/jb/Downloads/tor-browser_en-
 US/Browser/libnspr4.so
 #6  0x7f841858e2e7 in start_thread () at /usr/lib/libpthread.so.0
 #7  0x7f841760a54f in clone () at /usr/lib/libc.so.6
 (gdb) info threads
   Id   Target Id Frame
   1Thread 0x7f83bd8ff700 (LWP 5626) 0x7f8418598ea0 in raise ()
 from /usr/lib/libpthread.so.0
   2Thread 0x7f84042fa700 (LWP 2198) 0x7f8418594756 in
 pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
   3Thread 0x7f84189a5740 (LWP 2186) 0x7f8418594756 in
 pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
   4Thread 0x7f83f48f8700 (LWP 2214) 0x7f8418594756 in
 pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
   5Thread 0x7f8408dff700 (LWP 2189) 0x7f8417605889 in syscall ()
 from /usr/lib/libc.so.6
   6Thread 0x7f8405eff700 (LWP 2190) 0x7f841760067d in poll () from
 /usr/lib/libc.so.6
   7Thread 0x7f83d57ff700 (LWP 2235) 0x7f841760067d in poll () from
 /usr/lib/libc.so.6
   8Thread 0x7f8404cff700 (LWP 2193) 0x7f8418594756 in
 pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
   9Thread 0x7f8404afe700 (LWP 2194) 0x7f8418594756 in
 pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
   10   Thread 0x7f84048fd700 (LWP 2195) 0x7f8418594756 in
 pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
   11   Thread 0x7f84046fc700 (LWP 2196) 0x7f8418594756 in
 pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
   12   Thread 0x7f84044fb700 (LWP 2197) 0x7f8418594756 in
 pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
   13   Thread 0x7f8402fff700 (LWP 2199) 0x7f8418594756 in
 pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
   14   Thread 0x7f8402279700 (LWP 2200) 0x7f8418594756 in
 pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
   15   Thread 0x7f84004ff700 (LWP 2202) 0x7f8418594ca6 in
 pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
   16 

Re: [tor-bugs] #16337 [Applications/Tor Browser]: Investigate whether Animations(Player) API provides new high resolution timestamp

[Tor Bug Tracker & Wiki]

#16337: Investigate whether Animations(Player) API provides new high resolution
timestamp
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting-time-   |  Actual Points:
  highres, tbb-7.0-must-alpha,   |
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by arthuredelstein):

 Replying to [comment:15 gk]:
 > Replying to [comment:13 arthuredelstein]:
 > > Here's a patch for review:
 > > https://github.com/arthuredelstein/tor-browser/commit/16337
 >
 > We don't want to have a `ResistFingerprinting`-check here? What makes
 that feature different from, say, the one in #10286 where you explicitly
 added one? Or maybe that's just because the other timestamp clamping code
 does not have such a check either?

 Yes, I left it out to be consistent with the other clamping code we
 currently have in Tor Browser. Once it gets uplifted to Mozilla, we can
 put it behind a pref. Jonathan has already created infrastructure for that
 in https://bugzilla.mozilla.org/show_bug.cgi?id=1217238

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

Re: [tor-bugs] #16337 [Applications/Tor Browser]: Investigate whether Animations(Player) API provides new high resolution timestamp

[Tor Bug Tracker & Wiki]

#16337: Investigate whether Animations(Player) API provides new high resolution
timestamp
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting-time-   |  Actual Points:
  highres, tbb-7.0-must-alpha,   |
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by arthuredelstein):

 Replying to [comment:14 tom]:
 > Does this need to get added to the in-progress Mozilla patch?

 Yes, I'll add it tomorrow.

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

Re: [tor-bugs] #16337 [Applications/Tor Browser]: Investigate whether Animations(Player) API provides new high resolution timestamp

[Tor Bug Tracker & Wiki]

#16337: Investigate whether Animations(Player) API provides new high resolution
timestamp
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting-time-   |  Actual Points:
  highres, tbb-7.0-must-alpha,   |
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Replying to [comment:13 arthuredelstein]:
 > Here's a patch for review:
 > https://github.com/arthuredelstein/tor-browser/commit/16337

 We don't want to have a `ResistFingerprinting`-check here? What makes that
 feature different from, say, the one in #10286 where you explicitly added
 one? Or maybe that's just because the other timestamp clamping code does
 not have such a check either?

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

Re: [tor-bugs] #22162 [Applications/Tor Browser]: Review speculative connections

[Tor Bug Tracker & Wiki]

#22162: Review speculative connections
---+--
 Reporter:  tom|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ff59-esr, tbb-linkability  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * keywords:   => ff59-esr, tbb-linkability


Comment:

 We might want to add that to our test in #21657.

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

Re: [tor-bugs] #22158 [Applications/Tor Browser]: Tor browser core dump on Arch Linux

[Tor Bug Tracker & Wiki]

#22158: Tor browser core dump on Arch Linux
--+---
 Reporter:  jb.1234abcd   |  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:
--+---
Changes (by gk):

 * keywords:   => tbb-crash
 * status:  new => needs_information


Comment:

 Is that reproducible? Which Tor Browser version have you been using?

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

Re: [tor-bugs] #22161 [Applications/Tor Check]: check.torproject.org false report

[Tor Bug Tracker & Wiki]

#22161: check.torproject.org false report
+-
 Reporter:  desci   |  Owner:  arlolra
 Type:  defect  | Status:  new
 Priority:  Very Low|  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  check   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by gk):

 * owner:   => arlolra
 * component:  - Select a component => Applications/Tor Check


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

Re: [tor-bugs] #22163 [User Experience/Website]: Make it more obvious how to report security related bugs

[Tor Bug Tracker & Wiki]

#22163: Make it more obvious how to report security related bugs
-+--
 Reporter:  gk   |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gk):

 * cc: linda (added)


Comment:

 Might be something for our website redesign to take into account, adding
 Linda.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22163 [User Experience/Website]: Make it more obvious how to report security related bugs

[Tor Bug Tracker & Wiki]

#22163: Make it more obvious how to report security related bugs
-+--
 Reporter:  gk   |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 We had a report about a bug reporter getting different (and partly)
 conflicting advice on how to report security sensitive bugs. The canonical
 way of doing so is mailing to tor-secur...@lists.torproject.org. However,
 that seems to be not found easily. We should change that on our website.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22162 [Applications/Tor Browser]: Review speculative connections

[Tor Bug Tracker & Wiki]

#22162: Review speculative connections
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Mozilla just landed https://bugzilla.mozilla.org/show_bug.cgi?id=1348278
 (will be in ESR 59 but not 52) to speculatively connect to a link when the
 user mousedowns (but before they release.)

 There is no pref for this.

 The bug also mentions speculative connections on hover on http pages.

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

Re: [tor-bugs] #16337 [Applications/Tor Browser]: Investigate whether Animations(Player) API provides new high resolution timestamp

[Tor Bug Tracker & Wiki]

#16337: Investigate whether Animations(Player) API provides new high resolution
timestamp
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting-time-   |  Actual Points:
  highres, tbb-7.0-must-alpha,   |
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by tom):

 Does this need to get added to the in-progress Mozilla 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