Re: [tor-bugs] #10534 [Applications/Tor Browser]: Let's not advertise help desk emails directly

[Tor Bug Tracker & Wiki]

#10534: Let's not advertise help desk emails directly
-+-
 Reporter:  lunar|  Owner:
 Type:  defect   |  mikeperry
 Priority:  High | Status:  closed
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  tbb-usability, tbb-easy, SponsorO,   | Resolution:  fixed
  TorBrowserTeam201604R  |  Actual Points:
Parent ID:  #10974   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by phoul):

 Strings should be picked up by Transifex every few hours. The changed en
 values should be present in the strings until they are properly translated
 at that time.

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

Re: [tor-bugs] #18365 [Core Tor/Tor]: Fined-grain timer implementation to support per-connection or per-circuit timers

[Tor Bug Tracker & Wiki]

#18365: Fined-grain timer implementation to support per-connection or 
per-circuit
timers
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  performance, backend,|Version:
  TorCoreTeam201604  | Resolution:
Parent ID:   |  Actual Points:  medium
 Reviewer:   | Points:  medium
 |Sponsor:
-+-
Changes (by andrea):

 * status:  needs_review => needs_revision


Comment:

 Begin code review for nickm's timeouts_v2 branch:

 32e80ea3d32d5fd8207d16f9e5b26defa0d98a7c:

  - No detailed review of this commit as this is an import of external code

  - One potential concern: we need to be pretty clear whether the times
we use here are meant to be monotonic times or real-time clock times;
it doesn't look like timeout.c makes any direct time syscalls itself,
just lets the caller supply the current time as a uint64_t, which gives
us flexibility there, but it will be necessary to be consistent within
any given struct timeouts.  Possibly some admonitory documentation is
in order somewhere.

- Okay, in d0638fe760363f9c040256ac2884234ddad1d384 it looks like we're
  committing to monotonic time in libevent_timer_reschedule().
 Consider
  this concern resolved.

 05499b6ded25b5cbc8b16916fa9c0a39407ab10f:

  - Straightforward makefile changes; this looks fine

 9d6c530015e4eefd7b333885eaeca1f9fcbc6578:

  - Stop compiler warnings for timeout.c; looks okay, but are we sure we
got everything for every possible case we end up building?

  - Same for cbf47612b737a6ad31f17084ef5c36f5ebe33a76; some nervousness
about all these bitmasks and casts.

 c77cf8825a33d902c5827f0b4f0a71cec97a3a85:

  - This looks pretty straightforward and unobjectionable.

 d0638fe760363f9c040256ac2884234ddad1d384:

  - Is using a single pool of timeouts for both absolute and relative
values with tor_gettimeofday_cached_monotonic() entirely wise?

- From the comment for that function:

 {{{
  * In future versions of Tor, this may return a time does not have its
  * origin at the Unix epoch.
 }}}

  This, of course, is intended to allow for a future change to
  clock_gettime(CLOCK_MONOTONIC, ...), which will provide smoother
  behavior in the case the clock actually does run backwards than
  the current remember-and-compare implementation, but is not
 guaranteed
  to have any particular origin.  Using that where available is clearly
  the most reliable way to handle relative timeouts, but wrong for
 absolute
  ones, and the function we're using is defined to allow us room to
 make
  that change in the future.

  - Do we actually have any examples of needing to fire a particular
 callback
exactly once at or after a particular wall clock time as these absolute
timeouts provide?

  - If we do need absolute timeouts, we should think about splitting things
up into two timeouts objects rather than just a unified
 global_timeouts;
if relative timeouts are monotonic and absolute timeouts are based on
clock time, then resetting time potentially changes the order of future
timeouts without any timeout having occurred.  Then we're free to use
the appropriate definition of time separately for each.

 f7a6f142c67a3d256d522d1cfa66e525d16d6ab7:

  - These tests look just fine.

 cbf47612b737a6ad31f17084ef5c36f5ebe33a76:

  - See comments for 9d6c530015e4eefd7b333885eaeca1f9fcbc6578

  - This particular cast in timeouts_del(), for example, will break
on a machine with 64-bit pointers and 32-bit ints if WHEEL_LEN
is very large.

- timeout.c does document size constraints on these parameters
  such that this should work on any platform with integer sizes
  consistent with ISO C, though.

 b9e0f7c91623e5ebde774bab61030f04b808c024:

  - More tests; looks okay.

 d3a2b9e836cfed39f64963b171be152a7ae8ff4b:

  - Changes file looks fine

 In conclusion, this needs more thought about relative vs. absolute
 timeouts
 I think.  Should I review the imported timeout.c code itself separately,
 or is this something solid and widely used enough we aren't overly worried
 about it?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list

Re: [tor-bugs] #18741 [Applications/Tor Browser]: OCSP and favicon isolation is only partly working in ESR 45

[Tor Bug Tracker & Wiki]

#18741: OCSP and favicon isolation is only partly working in ESR 45
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  High | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Major|  Milestone:
 Keywords:  ff45-esr, tbb-6.0a5, |Version:
  TorBrowserTeam201604R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by arthuredelstein):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:9 mcs]:

 Thanks for the review. Here's a new version with 4 patches:
 https://github.com/arthuredelstein/tor-browser/commits/16326+4.
 Hash: 164431b40788b18b28502804224b54cc5760083b

 > Can you explain why the above patch is needed? Why aren't we passing the
 correct aNode in all cases? I am worried that we will poke around in the
 ancestor elements looking for a "firstparty" attribute in a lot more cases
 now, and I am not sure what the implications are (but I have not run the
 code yet).

 I agree that seems dangerous. So now I'm proposing a change to the
 `ThirdPartyUtil.cpp` code so that it only looks at the immediate node, and
 does not traverse the ancestors.
 Hash: 3553684ab8fa75ac55b930916b7ee06c862c644e

 To compensate for this change, I used a XUL attribute inheritance trick
 that allows the "firstparty" attribute on the `tab` element to propagate
 down to its icon `xul:image`:
 Hash: e4854b02006d5b156c8e40d482b869b904eb1034

 These changes together give the same behavior of favicons, but hopefully
 this arrangement is much less likely to affect other objects in the DOM.

 > > * 8317e098f0b880eded1301fe40e3e9fd1b813fc3 adds network isolation
 testing to our cache isolation regression test patch
 >
 > It would have helped me if there was a comment inside the
 observeChannels() callback that explained how the check worked, e.g.,
 > {{{
 > // All "thirdPartyChild" resources are loaded from example.net, so we
 expect
 > // the first party host to be .com or .org.
 > }}}

 Sorry that wasn't clear. I have added a comment like that in the new
 version.

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

Re: [tor-bugs] #17895 [Applications/Tor Browser]: Tor Browser Bundle installer subject to DLL hijacking

[Tor Bug Tracker & Wiki]

#17895: Tor Browser Bundle installer subject to DLL hijacking
-+-
 Reporter:  ericlaw  |  Owner:  boklm
 Type:  defect   | Status:
 Priority:  High |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Major|Version:
 Keywords:  tbb-gitian, tbb-security,| Resolution:
  TorBrowserTeam201604R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * status:  assigned => needs_review
 * keywords:  tbb-gitian, tbb-security, TorBrowserTeam201604 => tbb-gitian,
 tbb-security, TorBrowserTeam201604R


Comment:

 Replying to [comment:18 gk]:

 >
 > What we need here is:
 > 1) Cross-compiling NSIS

 The branch bug_17895 in my user repo is doing that:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 bundle.git/commit/?h=bug_17895=ed474700d85d135fa1e1bf6ae358a9c781d8dac6

 To fix the build issues, we are using the patches from the Debian package.

 > 2) Making sure the resulting .exe files are still bit-by-bit
 reproducible

 I checked that re-bundling results in the same .exe file. I did not check
 yet that it is also the case after a `make clean-utils`, I will try it
 tomorrow.

 > 3) Making sure that these files are still working on all supported
 Windows versions (XP - 10)
 > 4) Making sure stripping the authenticode signature is still
 reproducible

 I did not check that yet.

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

Re: [tor-bugs] #18867 [Applications/Tor Browser]: Ship auto-updates for Tor Browser nightly channel

[Tor Bug Tracker & Wiki]

#18867: Ship auto-updates for Tor Browser nightly channel
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 I think the main sub tasks are:
 * generating new certificates to sign the nightly mars, and adding them in
 tor-browser in `toolkit/mozapps/update/updater/Makefile.in` (for the
 public part), and on the nightly build machine
 * changing the version number (currently set to 'tbb-nightly') to an
 increasing version number (maybe the date ?), so that the updater can see
 it as a new version
 * updating the nightly build scripts to sign the mar files, generate the
 xml update responses and upload them somewhere

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18868 [- Select a component]: add packages for Ubuntu 16.04 LTS (Xenial Xerus) to deb.torproject.org

[Tor Bug Tracker & Wiki]

#18868: add packages for Ubuntu 16.04 LTS (Xenial Xerus) to deb.torproject.org
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Ubuntu 16.04 LTS has been released.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18867 [Applications/Tor Browser]: Ship auto-updates for Tor Browser nightly channel

[Tor Bug Tracker & Wiki]

#18867: Ship auto-updates for Tor Browser nightly channel
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We want to get more users to test our nightly builds. The main hurdle
 currently is the missing auto-update. This is the parent ticket that
 tracks this task.

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

Re: [tor-bugs] #18863 [Applications/Tor Browser]: Disable MozTCPSocket for sure

[Tor Bug Tracker & Wiki]

#18863: Disable MozTCPSocket for sure
-+-
 Reporter:  gk   |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff45-esr, tbb-6.0a5, |  Actual Points:
  TorBrowserTeam201604R  | Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by gk):

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


Comment:

 Commit c659c00756a77d0ca923aa21ca4e429deec3b3c5 on tor-
 browser-45.0.2esr-6.x-1 has the fix. Yes, we could rip that part fully out
 which is #18866.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18866 [Applications/Tor Browser]: Rip mozTCPSocket out of Tor Browser

[Tor Bug Tracker & Wiki]

#18866: Rip mozTCPSocket out of Tor Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In #18863 we disabled the usage of mozTCPSocket per preference. We might
 want to rip out that code 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] #18800 [Applications/Tor Browser]: Remove localhost DNS lookup in nsProfileLock.cpp

[Tor Bug Tracker & Wiki]

#18800: Remove localhost DNS lookup in nsProfileLock.cpp
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff45-esr, tbb-6.0a5, |  Actual Points:
  TorBrowserTeam201604R  | Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by gk):

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


Comment:

 Applied as commit 1afada0068a11265f291b8c836854391f532e754 on tor-
 browser-45.0.2esr-6.x-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] #18821 [Applications/Tor Browser]: Make sure libmdns is Android only and disabled for Orfox

[Tor Bug Tracker & Wiki]

#18821: Make sure libmdns is Android only and disabled for Orfox
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:  fixed
 Keywords:  ff45-esr, tbb-6.0a5, |  Actual Points:
  TorBrowserTeam201604R GeorgKoppen201604| Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by gk):

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


Comment:

 Oops. Fixed in commit 7ce38290aaac3b6351061f9ecc5cd6751d10edb4 on tor-
 browser-45.0.2esr-6.x-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] #18859 [Core Tor]: A new SOCKS connection should use a pre-built circuit for its first stream

[Tor Bug Tracker & Wiki]

#18859: A new SOCKS connection should use a pre-built circuit for its first 
stream
-+-
 Reporter:  arthuredelstein  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:3 arma]:
 > Arthur: can you attach an event log (setevents circ stream) here to show
 the problem?

 Here's an example session:

 {{{
 setevents circ stream
 250 OK
 getinfo circuit-status
 250+circuit-status=
 1 BUILT $F1A7CE1B1D558DC24E39B6B30FF217ECCEECF141~Kings
 BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:03.769809
 2 BUILT
 
$F1A7CE1B1D558DC24E39B6B30FF217ECCEECF141~Kings,$A47CF4F0B9AFD005C0A5B67A503158923202BE90~dragon1993,$EC116BCB80565A408CE67F8EC3FE3B0B02C3A065~orion
 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:04.809515 SOCKS_USERNAME="--unknown--"
 SOCKS_PASSWORD="0"
 3 BUILT
 
$F1A7CE1B1D558DC24E39B6B30FF217ECCEECF141~Kings,$EF29F69F49FF1C17CBDCFF8E11E10CD9F6B9DF95~raincat,$6207FC9DDE4EC78F45BB24C53C2EEE63DCC2E2B6~PrivacyRepublic
 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:05.790793
 4 BUILT
 
$F1A7CE1B1D558DC24E39B6B30FF217ECCEECF141~Kings,$385FE4D32D51C03766F3FBD24B108D6FB82C9E36~CDR,$2CF5110C8F31F45737F807F080ABA90A7AE50781~dragon1993
 BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:06.789676
 5 BUILT
 
$F1A7CE1B1D558DC24E39B6B30FF217ECCEECF141~Kings,$F60E3B747FE017346005243058FFFE72AA7D59A2~torpoc666,$5937800DEB5B3FDF68BD3392F2AE3A084254FE5F~tor6kryptonit
 BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:07.790465
 .
 250 OK
 }}}
 Now I opened a new tab and entered "https://arthuredelstein.github.io; in
 the URL bar domain:
 {{{
 650 STREAM 14 NEW 0 arthuredelstein.github.io:443
 SOURCE_ADDR=127.0.0.1:52129 PURPOSE=USER
 650 STREAM 14 SENTCONNECT 3 arthuredelstein.github.io:443
 650 STREAM 14 REMAP 3 23.235.43.133:443 SOURCE=EXIT
 650 STREAM 14 SUCCEEDED 3 23.235.43.133:443
 }}}
 Then I waited a few seconds, and opened a new tab and entered
 "example.com":
 {{{
 650 STREAM 15 NEW 0 example.com:80 SOURCE_ADDR=127.0.0.1:52130
 PURPOSE=USER
 650 CIRC 6 LAUNCHED BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:55.108644
 650 CIRC 6 EXTENDED $F1A7CE1B1D558DC24E39B6B30FF217ECCEECF141~Kings
 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:55.108644 SOCKS_USERNAME="example.com"
 SOCKS_PASSWORD="0"
 650 CIRC 6 EXTENDED
 
$F1A7CE1B1D558DC24E39B6B30FF217ECCEECF141~Kings,$408807EE2ED6C87F921139ABE0C07E84203A8621~MysticOrb
 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:55.108644 SOCKS_USERNAME="example.com"
 SOCKS_PASSWORD="0"
 650 CIRC 6 EXTENDED
 
$F1A7CE1B1D558DC24E39B6B30FF217ECCEECF141~Kings,$408807EE2ED6C87F921139ABE0C07E84203A8621~MysticOrb,$B0964415A5380080570845E7CBFCADF87FDCCE5A~Necto7
 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:55.108644 SOCKS_USERNAME="example.com"
 SOCKS_PASSWORD="0"
 650 CIRC 6 BUILT
 
$F1A7CE1B1D558DC24E39B6B30FF217ECCEECF141~Kings,$408807EE2ED6C87F921139ABE0C07E84203A8621~MysticOrb,$B0964415A5380080570845E7CBFCADF87FDCCE5A~Necto7
 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:55.108644 SOCKS_USERNAME="example.com"
 SOCKS_PASSWORD="0"
 650 STREAM 15 SENTCONNECT 6 example.com:80
 650 STREAM 15 REMAP 6 93.184.216.34:80 SOURCE=EXIT
 650 STREAM 15 SUCCEEDED 6 93.184.216.34:80
 [snipped more circuit and stream events]
 }}}
 Finally I inspected the list of open circuits again.
 {{{
 getinfo circuit-status
 250+circuit-status=
 1 BUILT $F1A7CE1B1D558DC24E39B6B30FF217ECCEECF141~Kings
 BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:03.769809
 2 BUILT
 
$F1A7CE1B1D558DC24E39B6B30FF217ECCEECF141~Kings,$A47CF4F0B9AFD005C0A5B67A503158923202BE90~dragon1993,$EC116BCB80565A408CE67F8EC3FE3B0B02C3A065~orion
 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:04.809515 SOCKS_USERNAME="--unknown--"
 SOCKS_PASSWORD="0"
 3 BUILT
 
$F1A7CE1B1D558DC24E39B6B30FF217ECCEECF141~Kings,$EF29F69F49FF1C17CBDCFF8E11E10CD9F6B9DF95~raincat,$6207FC9DDE4EC78F45BB24C53C2EEE63DCC2E2B6~PrivacyRepublic
 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2016-04-21T17:43:05.790793
 SOCKS_USERNAME="arthuredelstein.github.io" SOCKS_PASSWORD="0"
 4 BUILT
 

Re: [tor-bugs] #17799 [Core Tor/Tor]: Hash All PRNG output before use

[Tor Bug Tracker & Wiki]

#17799: Hash All PRNG output before use
---+
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201604  |  Actual Points:
Parent ID: | Points:  small/medium-remaining
 Reviewer:  asn|Sponsor:
---+

Comment (by nickm):

 Thanks for those; I've fixed the two issues above in a fixup commit.

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

Re: [tor-bugs] #18741 [Applications/Tor Browser]: OCSP and favicon isolation is only partly working in ESR 45

[Tor Bug Tracker & Wiki]

#18741: OCSP and favicon isolation is only partly working in ESR 45
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  High | Status:
Component:  Applications/Tor Browser |  needs_information
 Severity:  Major|  Milestone:
 Keywords:  ff45-esr, tbb-6.0a5, |Version:
  TorBrowserTeam201604R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by mcs):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:8 arthuredelstein]:
 > OK, here's the new branch. I tested on Ubuntu and got all favicon and
 OCSP requests running through the first party domain:
 > https://github.com/arthuredelstein/tor-browser/commits/16326+3
 > Note there are three commits here.
 > * 483bd1684d437f0e03743b9573990240d77e8acc adds a fix for #16326
 > * 4117c6b544e4fba93d192262aeabc0be4f38c4d7 fixes favicon cache and
 network isolation

 Can you explain why the above patch is needed? Why aren't we passing the
 correct aNode in all cases? I am worried that we will poke around in the
 ancestor elements looking for a "firstparty" attribute in a lot more cases
 now, and I am not sure what the implications are (but I have not run the
 code yet).

 > * 8317e098f0b880eded1301fe40e3e9fd1b813fc3 adds network isolation
 testing to our cache isolation regression test patch

 It would have helped me if there was a comment inside the
 observeChannels() callback that explained how the check worked, e.g.,
 {{{
 // All "thirdPartyChild" resources are loaded from example.net, so we
 expect
 // the first party host to be .com or .org.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18865 [Metrics/CollecTor]: actively monitor resources like available storage space

[Tor Bug Tracker & Wiki]

#18865: actively monitor resources like available storage space
---+
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:  ctip
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 As the two incidents of at least temporary losses/unavailability of
 descriptors were due to insufficient memory (cf.
 
[https://trac.torproject.org/projects/tor/wiki/doc/CollecTor/AnalysisDescriptorCompleteness
 here], a timed tasked should check this (and possibly other parameters) at
 regular intervals (preferably in a timely manner before the next run) and
 raise the red flag when a problem is visible.

 Might this be useful? Or is storage only a current 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] #18821 [Applications/Tor Browser]: Make sure libmdns is Android only and disabled for Orfox

[Tor Bug Tracker & Wiki]

#18821: Make sure libmdns is Android only and disabled for Orfox
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 Priority:  High |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Critical |Version:
 Keywords:  ff45-esr, tbb-6.0a5, | Resolution:
  TorBrowserTeam201604R GeorgKoppen201604|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:5 gk]:
 > Yes, this is quite some amount of code and complexity. Good catch,
 although I am less worried about OS X as the preference
 (`dom.presentation.discovery.enabled` seems to get obeyed). I've fixed
 this in bug_18821_v3 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_18821_v3).

 This looks good except somehow you lost the word "false" in your commit
 message after the phrase "which is actually set to".

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

Re: [tor-bugs] #18800 [Applications/Tor Browser]: Remove localhost DNS lookup in nsProfileLock.cpp

[Tor Bug Tracker & Wiki]

#18800: Remove localhost DNS lookup in nsProfileLock.cpp
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, tbb-6.0a5, | Resolution:
  TorBrowserTeam201604R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:3 gk]:
 > Let's try that one. Just one nit "as the same time" -> "at the same
 time".

 Fixed. Please use this one:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug18800-02=1afada0068a11265f291b8c836854391f532e754

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

Re: [tor-bugs] #15621 [Core Tor/Tor]: Kill the pre-version 3 intro protocol code with fire.

[Tor Bug Tracker & Wiki]

#15621: Kill the pre-version 3 intro protocol code with fire.
---+---
 Reporter:  yawning|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:  Tor:
Component:  Core Tor/Tor   |  0.2.9.x-final
 Severity:  Normal |Version:
 Keywords:  tor-hs, TorCoreTeam201604  | Resolution:
Parent ID:  #6418  |  Actual Points:
 Reviewer:  asn| Points:  small
   |Sponsor:  SponsorR-can
---+---
Changes (by dgoulet):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:19 nickm]:
 > Ack on NM1...NM2.  I think that for NM3, you're right, but we should add
 a tor_fragile_assert() there to make intent more clear.  (Or even
 tor_assert_nonfatal_unreached().)
 >

 Yup. I see that as a refactoring also since this could imply to drop that
 intro version handler array because it's unused but we could actually make
 it useful also.

 > For NM4, the fingerprinting issue: The case I'm worried about is where
 we learn that an HS upgraded at the same time that some other view of the
 HS upgraded.  (eg, it's being used as a client too, and they're trying to
 keep the client identity separate from the HS identity, but both changes
 are observable.)  Am I being too paranoid here?
 >

 Hrm... so yes, it's somehow a possibility. I'm unsure how you can tell if
 a client has also upgraded to 029+ thus correlate but if there is a way,
 it's a tiny bit possible.

 Middle ground here. arma proposed to merge this patch only when 224 gets
 in so we do one big transition. If we are OK with that, for which I'm ok
 with, let's push this ticket to 0.2.??? (224 won't be in until
 0.2.10/0.3.0 imo)?

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

Re: [tor-bugs] #18863 [Applications/Tor Browser]: Disable MozTCPSocket for sure

[Tor Bug Tracker & Wiki]

#18863: Disable MozTCPSocket for sure
-+-
 Reporter:  gk   |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, tbb-6.0a5, | Resolution:
  TorBrowserTeam201604R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:1 gk]:
 > bug_18863 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_18863) has the patch, please review.

 r=mcs
 (although I wish the implementation was not in Tor Browser at all)

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

Re: [tor-bugs] #18854 [Applications/Orbot]: Orfox's UserAgent different than other TBB (was: Orfox is NOT ANONYMOUS - UserAgent different than other TBB)

[Tor Bug Tracker & Wiki]

#18854: Orfox's UserAgent different than other TBB
+--
 Reporter:  ikurua22|  Owner:  n8fr8
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  Orfox   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arma):

 * priority:  Very High => Medium


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

Re: [tor-bugs] #16747 [Applications/Tor Browser]: Tor-browser downloads favicon twice (and over different circuits) on Windows (was: Tor-browser downloads favicon twice (and over different circuits))

[Tor Bug Tracker & Wiki]

#16747: Tor-browser downloads favicon twice (and over different circuits) on
Windows
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Medium   | Status:
Component:  Applications/Tor Browser |  assigned
 Severity:  Major|  Milestone:
 Keywords:  tbb-linkability, |Version:
  TorBrowserTeam201603   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |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] #13972 [Applications/Tor Check]: check.torproject.org doesn't support TLS 1.2

[Tor Bug Tracker & Wiki]

#13972: check.torproject.org doesn't support TLS 1.2
+-
 Reporter:  mkral   |  Owner:  arlolra
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Major   | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #9417   | Points:
 Reviewer:  |Sponsor:
+-

Comment (by cypherpunks):

 Been months since the supposed fix yet still running on TLS 1.0.

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

Re: [tor-bugs] #8185 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.

[Tor Bug Tracker & Wiki]

#8185: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL.
Dropping.
--+
 Reporter:  mr-4  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor:
Component:  Core Tor/Tor  |  0.2.9.x-final
 Severity:  Normal|Version:  Tor:
 Keywords:  tor-relay, TorCoreTeam201604  |  0.2.4.9-alpha
Parent ID:| Resolution:
 Reviewer:  isis  |  Actual Points:
  | Points:  medium
  |Sponsor:
--+

Comment (by isis):

 I've tested:

  * 0.2.9-alpha
  * 0.2.8 (maint)
  * 0.2.8.1-alpha
  * 0.2.7.2-alpha
  * 0.2.7.6

 but I can't seem to trigger this bug anymore.

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

Re: [tor-bugs] #17216 [Applications/Tor Browser]: Make Tor Browser's updater work over Hidden Services

[Tor Bug Tracker & Wiki]

#17216: Make Tor Browser's updater work over Hidden Services
--+--
 Reporter:  isis  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs tbb-security   |  Actual Points:
Parent ID:| Points:  medium
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Not an expert, but should this be postponed until prop 224 and all related
 HS props that are nearly complete are deployed? I know HS as it is now is
 still probably as secure or more than a clearnet site but would like to
 hear whether it is in theory safer to do so then.

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

Re: [tor-bugs] #18860 [Applications/Tor Browser]: Text on reply button in Trac is not visible

[Tor Bug Tracker & Wiki]

#18860: Text on reply button in Trac is not visible
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  ff45-esr, tbb-usability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 Seems to have been a local glitch. Works for me now.

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

Re: [tor-bugs] #18864 [Applications]: Make sure Orfox is not affected by Android code using SOCKS_DGRAM

[Tor Bug Tracker & Wiki]

#18864: Make sure Orfox is not affected by Android code using SOCKS_DGRAM
--+---
 Reporter:  gk|  Owner:
 Type:  task  | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications  |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] #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:
 Priority:  Medium |  needs_revision
Component:  Applications/Tor Launcher  |  Milestone:
 Severity:  Normal |Version:
 Keywords:  tbb-bridges, TorBrowserTeam201604  | Resolution:
Parent ID: |  Actual Points:
 Reviewer: | Points:
   |Sponsor:
---+---

Comment (by gk):

 Replying to [comment:17 isis]:
 > Replying to [comment:8 gk]:
 > > Ok, I'll take the patch as is as we are running out of time and it is
 improving the situation I think. That said I am a fan of the persisting
 option + bringing the available bridge bandwidth into the equation. We
 know the operators and could ask them + hardcode the bandwidth using that
 value for distributing users even more fairly. These (and other)
 enhancements should be done in a follow-up ticket though.
 >
 > Should we close this ticket and make new tickets for persisting the
 ordering and another for hardcoding the bandwidth?  Is there any revision
 of my patch that still needs to be done?

 See: comment:6. I think at least item 1) and 3) are worth it. And, yes,
 for persisting the ordering and bandwidth hardcoding we should make
 separate tickets.

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

Re: [tor-bugs] #18859 [Core Tor]: A new SOCKS connection should use a pre-built circuit for its first stream

[Tor Bug Tracker & Wiki]

#18859: A new SOCKS connection should use a pre-built circuit for its first 
stream
-+-
 Reporter:  arthuredelstein  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Arthur: can you attach an event log (setevents circ stream) here to show
 the problem?

 That way when other people here try to reproduce it, they'll know whether
 they're seeing what you see or not.

 Incidentally, it *is* expected behavior that Tor tries to launch a circuit
 right around the time you make your stream request. That is because Tor
 should attach the new stream to the preemptively built circuit, and then
 very soon after it will notice that it doesn't have enough preemptively
 built circuits hanging around anymore, and launch a new one.

 So one of the first debugging steps is to make sure you're not seeing and
 misinterpreting that behavior.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 Priority:  Medium |  needs_revision
Component:  Applications/Tor Launcher  |  Milestone:
 Severity:  Normal |Version:
 Keywords:  tbb-bridges, TorBrowserTeam201604  | Resolution:
Parent ID: |  Actual Points:
 Reviewer: | Points:
   |Sponsor:
---+---

Comment (by isis):

 Replying to [comment:8 gk]:
 > Ok, I'll take the patch as is as we are running out of time and it is
 improving the situation I think. That said I am a fan of the persisting
 option + bringing the available bridge bandwidth into the equation. We
 know the operators and could ask them + hardcode the bandwidth using that
 value for distributing users even more fairly. These (and other)
 enhancements should be done in a follow-up ticket though.

 Should we close this ticket and make new tickets for persisting the
 ordering and another for hardcoding the bandwidth?  Is there any revision
 of my patch that still needs to be done?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 Priority:  Medium |  needs_revision
Component:  Applications/Tor Launcher  |  Milestone:
 Severity:  Normal |Version:
 Keywords:  tbb-bridges, TorBrowserTeam201604  | Resolution:
Parent ID: |  Actual Points:
 Reviewer: | Points:
   |Sponsor:
---+---

Comment (by isis):

 Replying to [comment:15 mrphs]:
 > Replying to [comment:11 teor]:
 >
 > > I'm not sure what you mean here, surely there can only be one "first"
 bridge each time Tor Browser launches.
 >
 > If you take a look at `bridge_prefs.js` file, the first obfs4 bridge
 starts with:
 >
 > {{{
 > pref("extensions.torlauncher.default_bridge.obfs4.1", "obfs4...
 > }}}
 > and the second one with
 >
 > {{{
 > pref("extensions.torlauncher.default_bridge.obfs4.2", "obfs4...
 > }}}
 > What happens if they all are `obfs4.1`? Does Tor Browser try to connect
 to all of them at once?

 If they are all `pref("extensions.torlauncher.default_bridge.obfs4.1",
 "obfs4...` then the pref is overwritten each time, and you'd only end up
 with one bridge, because FF prefs are key-values which expect keys to not
 collide.

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

Re: [tor-bugs] #18794 [Metrics/CollecTor]: add cobertura task

[Tor Bug Tracker & Wiki]

#18794: add cobertura task
---+
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by iwakeh):

 Cobertura 1.9.4 is way behind and has a problem with java 7.

 I attached a patch version for cobertura 2.1.1
 All other dependencies can be found in debian stable.

 I also separated the different classpath settings for javac, junit, and
 cobertura.

 And a new folder for all generated files is introduced, i.e. javadoc,
 cobertura report, classes, and
 test results all have their own folders in this "generated" folder (see
 build.xml).

 The cobertura check is currently set to zero values. It should be set to
 something we aim at once the test creation phase starts.

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

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

[Tor Bug Tracker & Wiki]

#18546: Review networking code for Firefox 45
-+-
 Reporter:  gk   |  Owner:
 Type:  task |  mikeperry
 Priority:  Very High| Status:
Component:  Applications/Tor Browser |  assigned
 Severity:  Critical |  Milestone:
 Keywords:  ff45-esr, MikePerry201604,   |Version:
  TorBrowserTeam201604   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:6 gk]:
 > Replying to [comment:4 mikeperry]:
 > > Here's the quick notes for stuff that really needs another set of
 eyes:
 > >  * We need to verify the proper application of our OCSP and NSS safety
 patches in security/nss. Last time we improperly applied the DNS patch
 while rebasing. That might happen again here, too.
 >
 > They look good to me.
 >
 > >  * We should make sure that ./netwerk/dns/mdns/libmdns/ is Android
 only and also disabled for OrFox
 >
 > This is #18821.
 >
 > >  * The "Presentation API" stuff seems new, but possibly not enabled
 yet. It has lots of networking things. We should make sure it is disabled.

 Yes, it is disabled. However, we already had libmdns things leaking into
 desktop/android builds which are related to the Presentation API (see:
 
https://wiki.mozilla.org/images/thumb/e/e6/Presentation_API_Architecture_overview.png
 /650px-Presentation_API_Architecture_overview.png). Thus, we should take a
 closer look at the whole picture when we move to ESR52: #18862

 > >  * The nsDNSService patches should be verified for the same reason as
 the NSS ones

 Looks good to me.

 > >  * There's some resolver stuff in Android that uses SOCK_DGRAM. We
 should make sure this is not active in OrFox

 Might be best to ask the Orfox people as this code is available for ages
 and IIRC Orfox is already supposed to be proxy bypass free: #18864.

 > >  * It looks like
 ./toolkit/modules/secondscreen/SimpleServiceDiscovery.jsm is included now?
 Can we kill it? And what is this second screen stuff?

 We take care of it by the patch mcs and brade wrote back for #16439
 (cafffd10e5be3dc27b3a666df1769ee53eb9b009 on tor-browser-45.0.2esr-6.x-1).

 > >  * dom.udpsocket and dom.moztcpsocket are still off, yes?

 The former, yes, for the latter there are no relevant changes compared to
 ESR38 it seems. However, this pref is not really exposed, so we may want
 to set it explicitly to avoid digging through code each time. This is
 #18863.

 > >  * We disabled/patched the debugger and related discovery stuff
 before, right? Is that still off?

 Yes and comparing the ESR38 prefs with the ESR45 show we are still good
 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] #18864 [Applications]: Make sure Orfox is not affected by Android code using SOCKS_DGRAM

[Tor Bug Tracker & Wiki]

#18864: Make sure Orfox is not affected by Android code using SOCKS_DGRAM
--+---
 Reporter:  gk|  Owner:
 Type:  task  | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:1 gk]:
 > amoghbl1, n8fr8: this code is included for ages and IIRC OrFox is not
 bypassing Tor. So, what prevents Orfox from hitting the resolver code
 using SOCKS_DGRAM?

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

Re: [tor-bugs] #18864 [Applications]: Make sure Orfox is not affected by Android code using SOCKS_DGRAM (was: Make sure OfFox is not affected by Android code using SOCKS_DGRAM)

[Tor Bug Tracker & Wiki]

#18864: Make sure Orfox is not affected by Android code using SOCKS_DGRAM
--+---
 Reporter:  gk|  Owner:
 Type:  task  | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications  |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] #18864 [Applications]: Make sure OfFox is not affected by Android code using SOCKS_DGRAM (was: Make sure OrFox is not affected by Android code using SOCKS_DGRAM)

[Tor Bug Tracker & Wiki]

#18864: Make sure OfFox is not affected by Android code using SOCKS_DGRAM
--+---
 Reporter:  gk|  Owner:
 Type:  task  | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Description changed by gk:

Old description:

> It seems Android includes resolver stuff using SOCKS_DGRAM
> (https://bugzilla.mozilla.org/show_bug.cgi?id=694325). We should make
> sure this is no risk for OrFox users.

New description:

 It seems Android includes resolver stuff using SOCKS_DGRAM
 (https://bugzilla.mozilla.org/show_bug.cgi?id=694325). We should make sure
 this is no risk for Orfox users.

--

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

Re: [tor-bugs] #18864 [Applications]: Make sure OrFox is not affected by Android code using SOCKS_DGRAM

[Tor Bug Tracker & Wiki]

#18864: Make sure OrFox is not affected by Android code using SOCKS_DGRAM
--+---
 Reporter:  gk|  Owner:
 Type:  task  | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 amoghbl1, n8fr8: this code is included for ages and IIRC OrFox is not
 bypassing Tor. So, what prevents OrFox from hitting the resolver code
 using SOCKS_DGRAM?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18864 [Applications]: Make sure OrFox is not affected by Android code using SOCKS_DGRAM

[Tor Bug Tracker & Wiki]

#18864: Make sure OrFox is not affected by Android code using SOCKS_DGRAM
--+-
 Reporter:  gk|  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 It seems Android includes resolver stuff using SOCKS_DGRAM
 (https://bugzilla.mozilla.org/show_bug.cgi?id=694325). We should make sure
 this is no risk for OrFox users.

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

Re: [tor-bugs] #18792 [Metrics/CollecTor]: tweak build.xml for new tasks and java 7

[Tor Bug Tracker & Wiki]

#18792: tweak build.xml for new tasks and java 7
---+
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID:  #18707 | Points:
 Reviewer: |Sponsor:
---+
Changes (by iwakeh):

 * status:  needs_review => needs_revision


Comment:

 Good, that this is not reviewed yet!

 Rather see the patch for the coverage ticket.

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

Re: [tor-bugs] #18863 [Applications/Tor Browser]: Disable MozTCPSocket for sure

[Tor Bug Tracker & Wiki]

#18863: Disable MozTCPSocket for sure
-+-
 Reporter:  gk   |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, tbb-6.0a5, | Resolution:
  TorBrowserTeam201604R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * component:  - Select a component => Applications/Tor Browser


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

Re: [tor-bugs] #18863 [- Select a component]: Disable MozTCPSocket for sure

[Tor Bug Tracker & Wiki]

#18863: Disable MozTCPSocket for sure
-+-
 Reporter:  gk   |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  - Select a component |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, tbb-6.0a5, | Resolution:
  TorBrowserTeam201604R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: mcs, brade (added)
 * keywords:  ff45-esr, tbb-6.0a5, TorBrowserTeam201604 => ff45-esr,
 tbb-6.0a5, TorBrowserTeam201604R
 * status:  new => needs_review


Comment:

 bug_18863 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_18863) has the patch, please 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] #18863 [- Select a component]: Disable MozTCPSocket for sure

[Tor Bug Tracker & Wiki]

#18863: Disable MozTCPSocket for sure
-+-
 Reporter:  gk   |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  - Select a   |Version:
  component  |   Keywords:  ff45-esr, tbb-6.0a5,
 Severity:  Normal   |  TorBrowserTeam201604
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 `dom.mozTCPSocket.enabled` is not really exposed in `about:config` (at
 least on desktop not). We should just set it to `false` to avoid any
 uncertainty about it.

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

Re: [tor-bugs] #18862 [Applications/Tor Browser]: Make sure the Presentation API is no risk for our users

[Tor Bug Tracker & Wiki]

#18862: Make sure the Presentation API is no risk for our users
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Some useful bugs to start:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1069230 and
 https://bugzilla.mozilla.org/show_bug.cgi?id=1115480 (for the mdns part).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18862 [Applications/Tor Browser]: Make sure the Presentation API is no risk for our users

[Tor Bug Tracker & Wiki]

#18862: Make sure the Presentation API is no risk for our users
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff52-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The presentation API allows web content to use external presentation-type
 displays. It comes with own discovery mechanisms (libmdns) and is supposed
 to be available on desktop and on mobile in the near future
 (https://wiki.mozilla.org/WebAPI/PresentationAPI). This is a pretty
 complex beast and we have to make sure that it poses no risk (be into
 proxy bypass or fingerinting/tracking) to our users.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18861 [Metrics/metrics-lib]: start thinking about using java8

[Tor Bug Tracker & Wiki]

#18861: start thinking about using java8
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 a. Oracle issued the following more than a year ago
 >Auto-update Notice and End of Public Updates for Oracle JDK 7
 >
 >As outlined in the Oracle JDK Support Roadmap, after April 2015, Oracle
 will not >post further updates of Java SE 7 to its public download sites.
 Customers who need >continued access to critical bug fixes and security
 fixes as well as general >maintenance for Java SE 7 or older versions can
 get long term support through Oracle >Java SE Support. The process of
 migrating users from Java 7 to Java 8 through the >auto update feature is
 expected to take place after the January 2015 CPU release.(quoted from
 http://www.oracle.com/technetwork/java/javase/eol-135779.html)
 a. OpenJDK8 has been available in stable debian for quite a while.
 a. Java8 has matured by now, i.e. there were numerous updates since the
 first release (cf. [http://www.oracle.com/technetwork/java/javase/8u-
 relnotes-2225394.html here]).
 a. [http://www.oracle.com/technetwork/java/javase/8-whats-new-2157071.html
 Java8 features] like lambdas, streams, easy parallelization, performance
 improvements for the `java.lang.String(byte[], *)` constructor and the
 `java.lang.String.getBytes()` method, parallel array sorting, standard
 encoding and decoding base64 might be quite useful for metrics-lib in
 particular.

 I think that switching to java8 in Onionoo, metrics-db, and metrics-lib
 should not pose any problems.
 I don't know about other projects that might use metrics-lib?

 Using the new features could be done step by step, in special java8
 branches.

 The metrics-lib
 [https://stem.torproject.org/_static/example/benchmark_metrics_lib.java
 benchmark code] could be integrated in the test codebase for metrics-lib
 and used for measuring performance.

 Nothing very urgent, but it seems a good thing to start thinking about it
 now.


 (And ... Java9 is waiting around the corner ;-)

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

Re: [tor-bugs] #18859 [Core Tor]: A new SOCKS connection should use a pre-built circuit for its first stream

[Tor Bug Tracker & Wiki]

#18859: A new SOCKS connection should use a pre-built circuit for its first 
stream
-+-
 Reporter:  arthuredelstein  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Do you mean the same as #18122? (Mind the original summary/component.)

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

Re: [tor-bugs] #18854 [Applications/Orbot]: Orfox is NOT ANONYMOUS - UserAgent different than other TBB

[Tor Bug Tracker & Wiki]

#18854: Orfox is NOT ANONYMOUS - UserAgent different than other TBB
+--
 Reporter:  ikurua22|  Owner:  n8fr8
 Type:  defect  | Status:  assigned
 Priority:  Very High   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  Orfox   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Replying to [comment:4 ikurua22]:
 > > the size of your screen/browser window would fairly clearly indicate
 you were on an Android device
 >
 > If the user enable(default) Javascript, right?
 > I turned off JS completely, so how the attacker know I'm using mobile?
 CSS, for one thing.

 Using the same UA string as Tor Browser would not prevent distinguishing
 Orfox, IMO. There are so many more fingerprinting vectors.

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

Re: [tor-bugs] #16673 [Applications/Tor Browser]: Isolate/Disable HTTP Alternative-Services

[Tor Bug Tracker & Wiki]

#16673: Isolate/Disable HTTP Alternative-Services
-+-
 Reporter:  mikeperry|  Owner:
 Type:  defect   |  arthuredelstein
 Priority:  Medium   | Status:  closed
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, tbb-linkability,   | Resolution:  fixed
  tbb-6.0a5, TorBrowserTeam201604R   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 This is commit c09f525e5fab36a204291a2cae018a98be92018a on tor-
 browser-45.0.2esr-6.x-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] #18800 [Applications/Tor Browser]: Remove localhost DNS lookup in nsProfileLock.cpp

[Tor Bug Tracker & Wiki]

#18800: Remove localhost DNS lookup in nsProfileLock.cpp
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, tbb-6.0a5, | Resolution:
  TorBrowserTeam201604R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Let's try that one. Just one nit "as the same time" -> "at the same time".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18860 [Applications/Tor Browser]: Text on reply button in Trac is not visible

[Tor Bug Tracker & Wiki]

#18860: Text on reply button in Trac is not visible
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff45-esr, tbb-
Actual Points:|  usability
   Points:|  Parent ID:
  Sponsor:|   Reviewer:
--+
 Strangely, the text on the reply button in our bug tracker is not visible
 with Tor Browser based on ESR45. I have no such issues with 6.0a4. The
 security slider setting does not matter. This is on a Linux box.

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

Re: [tor-bugs] #10534 [Applications/Tor Browser]: Let's not advertise help desk emails directly

[Tor Bug Tracker & Wiki]

#10534: Let's not advertise help desk emails directly
-+-
 Reporter:  lunar|  Owner:
 Type:  defect   |  mikeperry
 Priority:  High | Status:  closed
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  tbb-usability, tbb-easy, SponsorO,   | Resolution:  fixed
  TorBrowserTeam201604R  |  Actual Points:
Parent ID:  #10974   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Okay, this is merged to master (), maint-0.2.7 () and maint-0.2.9 (). I
 think we should close this one for now and open new tickets once we know
 for sure how our new user support will work (and once all is set up
 properly).

 However, we need to wait before we can start a build because we need new
 strings to appear. Phoul: how long does that usually take until at least
 the en ones are available for all locales we ship? Can one speed up that
 process?

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