Re: [tor-bugs] #21308 [Applications/Tor Browser]: Fix modernizr breakage for TBB/ESR52

[Tor Bug Tracker & Wiki]

#21308: Fix modernizr breakage for TBB/ESR52
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201702R  |  Actual Points:
Parent ID:  #20680   | Points:
 Reviewer:   |Sponsor:  Sponsor4
-+-

Comment (by arthuredelstein):

 Replying to [comment:6 mcs]:
 > r=brade, r=mcs
 > This looks good to us. Nice work!
 > We tested with the Modernizr script (using our own little test page) and
 the right thing seemed to happen.

 Thanks for reviewing this! I added a small mochitest to make sure it's
 working correctly.
 https://github.com/arthuredelstein/tor-browser/commit/21308+2
 I will this add patch to the latest #20680 branch.

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

Re: [tor-bugs] #21425 [Core Tor/Tor]: entry_list_is_constrained() should look at the guard_selection_t object

[Tor Bug Tracker & Wiki]

#21425: entry_list_is_constrained() should look at the guard_selection_t object
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  guards|  Actual Points:
Parent ID:  #20822| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [ticket:21425 nickm]:
 > to find out if our list of entry points is highly limited

 At least originally, the definition of constrained was more like 'fixed'.
 The question is whether the entry list is growable using the default
 algorithm of "go to the consensus and pick a new one". So it isn't about
 whether it's limited to a few or a lot, it's about whether it's growable.

 (I haven't looked at the code changes lately to see how much we've gotten
 away from that definition, but I'd posit that wherever we have, it's a
 potential bug. :)

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

Re: [tor-bugs] #21205 [Core Tor/Tor]: Instrument clients to measure directory usage

[Tor Bug Tracker & Wiki]

#21205: Instrument clients to measure directory usage
--+
 Reporter:  nickm |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sponsor4  |  Actual Points:
Parent ID:| Points:  parent
 Reviewer:|Sponsor:  Sponsor4
--+

Comment (by teor):

 One relevant value of N is the consensus expiry time (0-3 hours), another
 is the reasonably live time (24 hours after expiry, so 24-27 hours),
 another is the relay descriptor mandatory refresh time (I think this is 18
 hours, but you should check this), and another is the microdescriptor
 expiry time (which I think is a week, but you should check this). A week
 is also the time that every descriptor must change in, as onion keys are
 rotated every week.

 Also, we might want to do a scenario where the client is on but the
 network is disconnected.

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

Re: [tor-bugs] #21205 [Core Tor/Tor]: Instrument clients to measure directory usage

[Tor Bug Tracker & Wiki]

#21205: Instrument clients to measure directory usage
--+
 Reporter:  nickm |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sponsor4  |  Actual Points:
Parent ID:| Points:  parent
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by isabela):

 * sponsor:   => Sponsor4


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

Re: [tor-bugs] #21367 [Metrics/Atlas]: mark platform string red (or in some other obvious way) if recommended_version field is not true

[Tor Bug Tracker & Wiki]

#21367: mark platform string red (or in some other obvious way) if
recommended_version field is not true
---+-
 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):

 Please flag not recommended relays in the search results able as red
 entries + tooltip  text.

 Use case:
 "show me my outdated relays"

 https://lists.torproject.org/pipermail/tor-
 relays/2017-February/011921.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

[tor-bugs] #21427 [Metrics/Onionoo]: allow to filter for tor_version

[Tor Bug Tracker & Wiki]

#21427: allow to filter for tor_version
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 use case:
 "show me all relays with contact X and tor version Z"

 ideally it would be possible to search for
 - multiple versions
 - version ranges (older than, newer than)

 https://lists.torproject.org/pipermail/tor-
 relays/2017-February/011921.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] #20894 [Core Tor/Tor]: Resolve read-off-end-of-buffer on atoi in fetch_from_buf_http (TROVE-2016-10-001) (was: Fix known instance of TROVE-2016-10-001)

[Tor Bug Tracker & Wiki]

#20894: Resolve read-off-end-of-buffer on atoi in fetch_from_buf_http
(TROVE-2016-10-001)
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  tor-03-unspecified-201612  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 The problem was the atoi() in fetch_from_buf_http: it's entirely too happy
 to read off the end of a buf if there is no subsequent '\n' in the same
 chunk as the "content-length".

 We fixed this with the patch for #20384, where we made sure that every buf
 chunk was NUL-terminated, but we really ought to fix the underlying issue
 too.

 I have an overcomplicated patch in bug20894_024.  Probably it should use
 tor_parse_uint64 instead of atoi.  But the part that I really dislike is
 the hunt-for-the-newline-and-copy-the-header part -- it's overcomplicated
 and more than a little bit zany.

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

Re: [tor-bugs] #18113 [Applications/Tor Launcher]: Dynamically allocate clients to default Tor Browser bridges of a certain type

[Tor Bug Tracker & Wiki]

#18113: Dynamically allocate clients to default Tor Browser bridges of a certain
type
---+
 Reporter:  isis   |  Owner:  brade
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-bridges|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by brade):

 * keywords:  tbb-bridges, TorBrowserTeam201604 => tbb-bridges


Comment:

 removing outdated keyword

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

Re: [tor-bugs] #21308 [Applications/Tor Browser]: Fix modernizr breakage for TBB/ESR52

[Tor Bug Tracker & Wiki]

#21308: Fix modernizr breakage for TBB/ESR52
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201702R  |  Actual Points:
Parent ID:  #20680   | Points:
 Reviewer:   |Sponsor:  Sponsor4
-+-

Comment (by mcs):

 r=brade, r=mcs
 This looks good to us. Nice work!
 We tested with the Modernizr script (using our own little test page) and
 the right thing seemed to happen.

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

Re: [tor-bugs] #18757 [Core Tor/Tor]: Memunit config defaults say "KB" rather than "KBytes"

[Tor Bug Tracker & Wiki]

#18757: Memunit config defaults say "KB" rather than "KBytes"
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by neerajbattan):

 I have added the removed extra line from src/config/torrc.sample.in,
 created a different patch for updateFallbackDirs.py and changed "We just
 generated an extra-info descriptors that" to "We just generated an extra-
 info descriptor that". Please let me know if still some changes are
 needed.

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

Re: [tor-bugs] #21201 [Applications/Tor Browser]: Adapt torbutton to TBB/FF52ESR

[Tor Bug Tracker & Wiki]

#21201: Adapt torbutton to TBB/FF52ESR
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton,ff52-esr,  |  Actual Points:
  TorBrowserTeam201702   |
Parent ID:  #20680   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 Replying to [comment:7 mcs]:
 > Here is an additional small fix (needed for e10s compatibility):
 >
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug21201-01&id=b5b4dd067aaea6f9eee79eca249d56b6bd636a08

 I should have mentioned that the reason it is okay to remove the "No
 initial browser content window?" code is because it is leftover from the
 pre-#19459 era; Kathy and I do not see a need for it any longer.

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

Re: [tor-bugs] #21369 [Core Tor/Tor]: Tor crashes with tor_assertion_failed_() [Assertion buf->datalen < INT_MAX failed in write_to_buf at ../src/or/buffers.c:832]

[Tor Bug Tracker & Wiki]

#21369: Tor crashes with tor_assertion_failed_() [Assertion buf->datalen < 
INT_MAX
failed in write_to_buf at ../src/or/buffers.c:832]
--+
 Reporter:  svengo|  Owner:
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.9
 Severity:  Critical  | Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 How is this Tor configured?  Is it a relay, a hidden service, a client?
 Can you paste the torrc (or as much of it as is not private)?

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

Re: [tor-bugs] #2106 [Core Tor/Tor]: Controller can't unset httpsproxy if it doesn't resolve

[Tor Bug Tracker & Wiki]

#2106: Controller can't unset httpsproxy if it doesn't resolve
-+-
 Reporter:  arma |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, easy,|  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by neerajbattan):

 arma: I would like to work on this bug, where are the values for
 HTTPProxy, HTTPSProxy,Socks4Proxy,Socks5Proxy stored and what value should
 I change to when tor unable to connect to this proxy set?

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

Re: [tor-bugs] #21369 [Core Tor/Tor]: Tor crashes with tor_assertion_failed_() [Assertion buf->datalen < INT_MAX failed in write_to_buf at ../src/or/buffers.c:832]

[Tor Bug Tracker & Wiki]

#21369: Tor crashes with tor_assertion_failed_() [Assertion buf->datalen < 
INT_MAX
failed in write_to_buf at ../src/or/buffers.c:832]
--+
 Reporter:  svengo|  Owner:
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.9
 Severity:  Critical  | Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Also, I sure wish I knew what this function was:
 {{{
  Feb  1 16:54:26 arnor Tor-eriador[24009]: Bug:
 /usr/bin/tor(+0x1081e6) [0x55744380f1e6
 }}}

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

Re: [tor-bugs] #21369 [Core Tor/Tor]: Tor crashes with tor_assertion_failed_() [Assertion buf->datalen < INT_MAX failed in write_to_buf at ../src/or/buffers.c:832]

[Tor Bug Tracker & Wiki]

#21369: Tor crashes with tor_assertion_failed_() [Assertion buf->datalen < 
INT_MAX
failed in write_to_buf at ../src/or/buffers.c:832]
--+
 Reporter:  svengo|  Owner:
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.9
 Severity:  Critical  | Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 So, I can only think of two possibilities here:

 1. There was somehow an underflow in buf->datalen, and we subtracted more
 from it than we should have, thus taking it to a large positive value.

 2. There were really 2 gigabytes of data allocated in a single buffer.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #21278, #20894, #21415

[Tor Bug Tracker & Wiki]

Batch modification to #21278, #20894, #21415 by nickm:


Action: reassign

--
Tickets URL: 

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

Re: [tor-bugs] #21211 [Core Tor/Tor]: Write and analyze proposals for compressing consensus (diff)s with better algorithms

[Tor Bug Tracker & Wiki]

#21211: Write and analyze proposals for compressing consensus (diff)s with 
better
algorithms
--+
 Reporter:  nickm |  Owner:  ahf
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sponsor4  |  Actual Points:
Parent ID:  #21209| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * owner:   => ahf
 * 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

Re: [tor-bugs] #21267 [Applications/Tor Browser]: e10s compatibility for Torbutton's content sizer

[Tor Bug Tracker & Wiki]

#21267: e10s compatibility for Torbutton's content sizer
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton,ff52-esr,  |  Actual Points:
  TorBrowserTeam201702   |
Parent ID:  #21201   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by mcs):

 * cc: arthuredelstein (added)


Comment:

 Kathy and I spent some time looking at what it would take to make the
 content-sizer.js code work in an e10s environment. Unfortunately, it does
 not look like it will be a simple task and the existing code is
 complicated enough that it makes sense for Arthur to own this task.

 Most of the problems are inside the updateDimensions() function. All
 places where the code accesses gBrowser.contentWindow must be modified to
 get information using an alternative method, or we need to use a content
 script combined with Firefox's message manager from the chrome side to
 request the info we need (full screen state, zoom factor, content window
 dimensions). The necessary changes will be a little tricky because simple
 variable access must be replaced with asynchronous message exchanges.
 Kathy and I do not understand the existing content-sizer code well enough
 to be confident that we will account for everything correctly when we
 rearchitect the code in this 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] #21201 [Applications/Tor Browser]: Adapt torbutton to TBB/FF52ESR

[Tor Bug Tracker & Wiki]

#21201: Adapt torbutton to TBB/FF52ESR
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton,ff52-esr,  |  Actual Points:
  TorBrowserTeam201702   |
Parent ID:  #20680   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 Here is an additional small fix (needed for e10s compatibility):
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug21201-01&id=b5b4dd067aaea6f9eee79eca249d56b6bd636a08

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21426 [Applications/Tor Browser]: Make sure keyup events don't leak underlying keyboard layout

[Tor Bug Tracker & Wiki]

#21426: Make sure keyup events don't leak underlying keyboard layout
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-fingerprinting
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Sometimes if one is not paying attention to lift the key pressed earlier
 than the modifier key first it happens that the `keyup` event is leaking
 the key that would have been pressed without the modifier in the first
 place. See the `ß` in #21390. We should make sure that the `keyup` event
 is delivering the same key as in the `keypress` event.

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

Re: [tor-bugs] #21417 [Applications/Tor Browser]: cannot use search engine

[Tor Bug Tracker & Wiki]

#21417: cannot use search engine
--+---
 Reporter:  suriela   |  Owner:  suriela
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Could you give a bit more information about your setup? Like what Tor
 Browser version you use? What operating system etc.? In short: how can we
 reproduce your problem?

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

Re: [tor-bugs] #21390 [Applications/Tor Browser]: keypress events are not getting spoofed

[Tor Bug Tracker & Wiki]

#21390: keypress events are not getting spoofed
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  not a bug
 Keywords:  tbb-fingerprinting|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Okay, this is not a bug. It turns out I mixed up `charCode` and `keyCode`
 values. While we spoof the latter the former are merely ASCII values of
 the key that got pressed. By coincidence both give back `63` for `?` on a
 with a german layout without spoofing. Our patch fixes that for the
 `keyCode` case leacing the `charCode` case untouched as it does not vary
 with a different keyboard layout.

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

Re: [tor-bugs] #20718 [Core Tor/Tor]: Prop271 -- Resolve all 'XXXX prop271' items

[Tor Bug Tracker & Wiki]

#20718: Prop271 -- Resolve all ' prop271' items
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  TorCoreTeam201612  |  Actual Points:
Parent ID:  #20822 | Points:  1
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 Okay.  None are critical for 0.3.0 still.  I opened tickets for the ones
 that should get fixed later.

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

Re: [tor-bugs] #21425 [Core Tor/Tor]: entry_list_is_constrained() should look at the guard_selection_t object

[Tor Bug Tracker & Wiki]

#21425: entry_list_is_constrained() should look at the guard_selection_t object
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  guards|  Actual Points:
Parent ID:  #20822| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * parent:   => #20822


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

Re: [tor-bugs] #21424 [Core Tor/Tor]: Treat directory guard success only as a partial success for the guard?

[Tor Bug Tracker & Wiki]

#21424: Treat directory guard success only as a partial success for the guard?
---+--
 Reporter:  nickm  |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  needs-proposal guards  |  Actual Points:
Parent ID:  #20822 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by nickm):

 * parent:   => #20822


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

Re: [tor-bugs] #21423 [Core Tor/Tor]: Refactor choose_good_entry_server based on different usecases

[Tor Bug Tracker & Wiki]

#21423: Refactor choose_good_entry_server based on different usecases
-+
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guards refactor  |  Actual Points:
Parent ID:  #20822   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * parent:   => #20822


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

Re: [tor-bugs] #21422 [Core Tor/Tor]: Possibly, learn more network data from GUARD_USABLE_NEVER circuits?

[Tor Bug Tracker & Wiki]

#21422: Possibly, learn more network data from GUARD_USABLE_NEVER circuits?
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  cbt guards|  Actual Points:
Parent ID:  #20822| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * parent:   => #20822


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

Re: [tor-bugs] #21421 [Core Tor/Tor]: Maybe check for GUARD_WAIT circuit readiness whenever a guard fails

[Tor Bug Tracker & Wiki]

#21421: Maybe check for GUARD_WAIT circuit readiness whenever a guard fails
+--
 Reporter:  nickm   |  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  guards performance  |  Actual Points:
Parent ID:  #20822  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * parent:   => #20822


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21425 [Core Tor/Tor]: entry_list_is_constrained() should look at the guard_selection_t object

[Tor Bug Tracker & Wiki]

#21425: entry_list_is_constrained() should look at the guard_selection_t object
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  guards
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We use entry_list_is_constrained() in a few places to find out if our list
 of entry points is highly limited (e.g., to a few bridges or a few
 EntryNodes).  But it doesn't do that very well:  instead, it looks to see
 if EntryNodes is set or UseBridges is set.

 We have better ways: we should be looking at the size of the guard sample,
 or something.

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

[tor-bugs] #21424 [Core Tor/Tor]: Treat directory guard success only as a partial success for the guard?

[Tor Bug Tracker & Wiki]

#21424: Treat directory guard success only as a partial success for the guard?
--+---
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  needs-proposal guards
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Right now, we treat having received data from a directory guard as that
 guard having succeeded.  But this could be trouble: it doesn't actually
 mean that the guard will make circuits nicely.  We could use a notion of
 'partial success' for guards, possibly?  Or a separate directory/circuit
 success track?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21423 [Core Tor/Tor]: Refactor choose_good_entry_server based on different usecases

[Tor Bug Tracker & Wiki]

#21423: Refactor choose_good_entry_server based on different usecases
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  guards refactor
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The choose_good_entry_server function was used in four ways: picking out
 guards for the old (pre-prop271) guard algorithm; picking out guards for
 circuits; picking out guards for testing circuits on non-bridgees; picking
 out entries when entry guards are disabled.  These options should be
 disentangled.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21422 [Core Tor/Tor]: Possibly, learn more network data from GUARD_USABLE_NEVER circuits?

[Tor Bug Tracker & Wiki]

#21422: Possibly, learn more network data from GUARD_USABLE_NEVER circuits?
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  cbt guards
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In `cirucit_send_next_onion_skin()`, when the circuit is built but we
 decide not to use it at all because of the guard state, we don't continue
 on to the rest of the function, where we count statistics about circuit
 build times and so on.  This could be a mistake; we should revisit it.

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

[tor-bugs] #21421 [Core Tor/Tor]: Maybe check for GUARD_WAIT circuit readiness whenever a guard fails

[Tor Bug Tracker & Wiki]

#21421: Maybe check for GUARD_WAIT circuit readiness whenever a guard fails
--+
 Reporter:  nickm |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  guards performance
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Right now we check whether any `GUARD_WAIT` circuits can become usable
 (`OPEN`) once a second or so, in
 `circuit_upgrade_circuits_from_guard_wait()`.  But maybe we should do so
 more often -- possibly, whenever a guard is marked as down?

 This would make some streams attach up to one second faster -- but only in
 the cases when primary guards are down but we expected them to be up.

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

Re: [tor-bugs] #17903 [Core Tor/Tor]: router_pick_trusteddirserver_impl should distinguish between fallbacks and authorities

[Tor Bug Tracker & Wiki]

#17903: router_pick_trusteddirserver_impl should distinguish between fallbacks 
and
authorities
---+---
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Very Low   |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  tor-03-unspecified-201612  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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


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

Re: [tor-bugs] #13790 [Core Tor/Tor]: Refactor and add comments to new_route_len()

[Tor Bug Tracker & Wiki]

#13790: Refactor and add comments to new_route_len()
-+-
 Reporter:  dgoulet  |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  026-deferrable,  |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #5462 [Core Tor/Tor]: Clients should alert the user if many guards are unreachable

[Tor Bug Tracker & Wiki]

#5462: Clients should alert the user if many guards are unreachable
-+-
 Reporter:  mikeperry|  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-client, large-feature, path- |  Actual Points:
  bias, 026-triaged-1, 027-triaged-1-in, |
  028-triaged, prop259, tor-guard, tor-guards-   |
  revamp, tor-03-unspecified-201612  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorU-can
-+-
Changes (by nickm):

 * status:  needs_information => closed
 * resolution:   => fixed
 * milestone:  Tor: unspecified => Tor: 0.3.0.x-final


Comment:

 Indeed so!

 s/217/271/

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

Re: [tor-bugs] #21420 [Core Tor/Tor]: Link certificate start date in the future

[Tor Bug Tracker & Wiki]

#21420: Link certificate start date in the future
--+
 Reporter:  mmcloughlin   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #21270 [Applications/Tor Browser]: TBB noscript settings break WebExtensions addons

[Tor Bug Tracker & Wiki]

#21270: TBB noscript settings break WebExtensions addons
+--
 Reporter:  replaythesong   |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-usability, tbb-security-slider  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by replaythesong):

 In TBB 6.5, security slider has 3 settings instead of 4. Bug occurs in
 medium or high, but not in low.

 So, in steps to reproduce, replace 'medium-low' with 'low' and replace
 'medium-high' with 'medium'.

 An aside: in 6.5, when moz-extension: is added so that the script does
 finally run in medium (or high), it is now accompanied by an error in
 noscript/DOM.js:
 {{{
 NS_NOINTERFACE: Component returned failure code: 0x80004002
 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface]
 }}}
 This error does not appear to prevent the script running. It does not
 appear at all in 'low' security mode.

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

Re: [tor-bugs] #21334 [Core Tor/Tor]: prop224: Update prop224 HS desriptor generation code to produce the latest descriptor format

[Tor Bug Tracker & Wiki]

#21334: prop224: Update prop224 HS desriptor generation code to produce the 
latest
descriptor format
-+
 Reporter:  asn  |  Owner:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+

Comment (by asn):

 And here is a gitlab merge request for this branch:
 https://gitlab.com/asn/tor/merge_requests/10

 (I also force pushed to my `bug21334_v1` to fix some check-spaces
 artifacts)

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

Re: [tor-bugs] #21396 [Applications/Tor Browser]: Torbutton breaks Session Manager addon

[Tor Bug Tracker & Wiki]

#21396: Torbutton breaks Session Manager addon
-+-
 Reporter:  HolD |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-6.5-regression,  |  Actual Points:
  TorBrowserTeam201702, GeorgKoppen201702|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: lnl (added)


Comment:

 Replying to [comment:7 yawning]:
 > Replying to [comment:6 gk]:
 > > Session Manager does not like it that
 `chrome://sessionmanager/locale/sessionmanager.dtd` and
 `chrome://sessionmanager/locale/options.dtd` are blocked by our fix for
 #8725. Things like `&toolbar.tooltip` need to be available for content
 after the first installation. HolD: does adding the toolbar buttons
 manually to the toolbar work for you?
 >
 > What's the origin URI when the requests make it to the content policy?
 If this is one of the cases where `aRequestOrigin` can basically be
 anything, the only way to solve this would be to whitelist the relevant
 URIs.  Note that, doing so will make it trivial for sites to fingerprint
 if the addon is present or not (then again, people installing extra
 addons/plugins void the non-existent warranty in the first place).

 `moz-nullprincipal:{1f22744b-c4db-41b6-8d6e-3d06c176578e}`. Looking at the
 docs it seems like checking for that one would be okay. But this is not a
 solution that scales well. I wonder if we should just add a preference
 `extensions.torbutton_resource_and_chrome_uri_fingerprinting` and set that
 to `false` by default allowing users to override it and to disable the
 content policy hack. Maybe UX folks have an idea.

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