Re: [tor-bugs] #19206 [Applications/Tor Browser]: SOCKS isolation should include a process identifier.

[Tor Bug Tracker & Wiki]

#19206: SOCKS isolation should include a process identifier.
--+
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201606R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arthuredelstein):

 * status:  needs_review => needs_revision


Comment:

 {{{
 function Nonce() {
 }}}

 My inclination for the sake of simplicity would be to drop the increment
 part and just make nonce() a simple function that returns a hex string.

 {{{
   // Hexlify the tag.
   for (var i = 0; i < tag.length; i++)
 hexTag += tag[i].toString(16);
 }}}

 This code drops the leading zero for octets with value < 16. Doesn't
 affect entropy much, but would probably be nice to behave as expected.
 Also I generally prefer `let` to `var`.

 {{{
 // Per-domain noncces are stored in a map, so simply regenerate.
 }}}

 Typo.

 Generally, we would precede the subject line for these two patches with
 "Bug 19206: ", because it makes sorting/searching easy.

 Otherwise these patches look good to me.

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

Re: [tor-bugs] #19206 [Applications/Tor Browser]: SOCKS isolation should include a process identifier.

[Tor Bug Tracker & Wiki]

#19206: SOCKS isolation should include a process identifier.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201606R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by yawning):

 * status:  needs_revision => needs_review


Comment:

 And pushed.  Someone that cares more than I do can add a pref for actually
 skipping the `NEWNYM`, since it should no longer be necessary as long as
 our isolation code is actually working as intended.

 My usecase never gives Tor Browser direct access to the control port
 anyway, so I'm just suppressing the signal there...

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

Re: [tor-bugs] #19254 [Core Tor/Tor]: Provide timestamps in the CIRC_BW and STREAM_BW events

[Tor Bug Tracker & Wiki]

#19254: Provide timestamps in the CIRC_BW and STREAM_BW events
--+--
 Reporter:  donncha   |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 I wonder if it might make sense to add a flag that made _all_ events get
 timestamps.  Or would that be useless overgeneralization?  Also I wonder
 if a fraction-of-seconds field would be helpful.

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

Re: [tor-bugs] #19254 [Core Tor/Tor]: Provide timestamps in the CIRC_BW and STREAM_BW events

[Tor Bug Tracker & Wiki]

#19254: Provide timestamps in the CIRC_BW and STREAM_BW events
--+--
 Reporter:  donncha   |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * keywords:   => 029-proposed


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

Re: [tor-bugs] #19206 [Applications/Tor Browser]: SOCKS isolation should include a process identifier.

[Tor Bug Tracker & Wiki]

#19206: SOCKS isolation should include a process identifier.
--+
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201606R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by yawning):

 * status:  needs_review => needs_revision


Comment:

 It occurs to me that, we probably *should* clear out the domain isolator
 `noncesForDomains` cache on new identity so that it's possible to suppress
 the `NEWNYM` for the system tor use case.  This appears trivial to add, so
 I'll do that on this branch as well, and re-submit it for review.

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

Re: [tor-bugs] #19206 [Applications/Tor Browser]: SOCKS isolation should include a process identifier.

[Tor Bug Tracker & Wiki]

#19206: SOCKS isolation should include a process identifier.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201606R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by yawning):

 * keywords:   => TorBrowserTeam201606R
 * status:  new => needs_review


Comment:

 https://git.schwanenlied.me/yawning/torbutton/src/feature19206

 Implemented as `128 bits of entropy (as a hex string, per domain) |
 counter`.  The counter was retained for "being useful for
 debugging/troubleshooting".

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

Re: [tor-bugs] #13081 [Core Tor/Tor]: Fix build with Visual Studio in Windows

[Tor Bug Tracker & Wiki]

#13081: Fix build with Visual Studio in Windows
-+-
 Reporter:  NewEraCracker|  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.???
 Keywords:  tor-relay, msvc, lorax, intro|Version:
  029-proposed   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:  medium
 |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-relay, msvc, lorax, intro => tor-relay, msvc, lorax, intro
 029-proposed
 * status:  needs_revision => needs_review


Comment:

 I think that applying the patches here would be a pretty fine thing,
 assuming they get reviewed again

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

[tor-bugs] #19262 [Applications/Tor Browser]: Clicking inside Tor Browser search box or opening its drop-down causes network activity

[Tor Bug Tracker & Wiki]

#19262: Clicking inside Tor Browser search box or opening its drop-down causes
network activity
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  fingerprinting,
 Severity:  Minor|  privacy, tracking, search
Actual Points:   |  Parent ID:  #5816
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Greetings,

 I have recently noticed that even the simple "offline" activities in TB
 mentioned above initiate some kind of network traffic. I unfortunately do
 not know how to see the specific contents of this traffic, but it is
 definitively there as I have viewed it from the activity of the FoxyProxy
 Add-On which I am using for a unique use-case. Regardless of the Add-On
 being outside TBB's scope, I believe that this is an issue that affects
 all Tor Browser users.

 Leaking traffic like this assists with fingerprinting users and improves
 correlation/timing-style attacks. It is also possible that some kind of
 tracking cookie or other information is exchanged in this traffic, see
 #5816.

 It would be good to know what is in this traffic, and furthermore, to
 disable this activity from a simple "offline" focus of the search box.
 Thank you.

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

Re: [tor-bugs] #19199 [Applications/Tor Browser]: Allow user to completely disable canvas content and related warning popup from a checkbox in TorButton's "Privacy Settings" (was: Completely disable c

[Tor Bug Tracker & Wiki]

#19199: Allow user to completely disable canvas content and related warning 
popup
from a checkbox in TorButton's "Privacy Settings"
+--
 Reporter:  cypherpunks |  Owner:  tbb-team
 Type:  defect  | Status:  reopened
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  privacy, anonymity, fingerprinting  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by cypherpunks):

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


Comment:

 Thanks gk, understood. In that case, I believe that such a toggle is
 absolutely appropriate in the dialog area just above the Security Slider
 in "Privacy & Security Settings..." as an additional checkbox.

 I propose that the box's description should read "Disable HTML5 Canvas
 content."

 Further comments welcome.

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

Re: [tor-bugs] #12595 [Core Tor/Tor]: Finalize design for improved guard-node behavior

[Tor Bug Tracker & Wiki]

#12595: Finalize design for improved guard-node behavior
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 Priority:  High |  assigned
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  tor-guard, TorCoreTeam201606,|Version:  Tor:
  028-triaged, mike-can, prop259, tor-guards-|  0.2.7
  revamp | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:  3
 |Sponsor:
 |  SponsorU-must
-+-
Changes (by asn):

 * keywords:
 tor-guard, TorCoreTeam201605, 028-triaged, mike-can, prop259, tor-
 guards-revamp
 =>
 tor-guard, TorCoreTeam201606, 028-triaged, mike-can, prop259, tor-
 guards-revamp


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

Re: [tor-bugs] #17262 [Core Tor/Tor]: Experimental prototype for guard selection algorithm

[Tor Bug Tracker & Wiki]

#17262: Experimental prototype for guard selection algorithm
-+-
 Reporter:  nickm|  Owner:  asn
 Type:  defect   | Status:
 Priority:  High |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  028-triage, TorCoreTeam201606,   |Version:
  prop259, tor-guard, tor-guards-revamp  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:  3
 |Sponsor:
 |  SponsorU-must
-+-
Changes (by asn):

 * keywords:  028-triage, TorCoreTeam201605, prop259, tor-guard, tor-guards-
 revamp => 028-triage, TorCoreTeam201606, prop259, tor-guard, tor-
 guards-revamp


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

Re: [tor-bugs] #19261 [Core Tor/Tor]: test suite failure rend_cache/store_v2_desc_as_client

[Tor Bug Tracker & Wiki]

#19261: test suite failure rend_cache/store_v2_desc_as_client
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by weasel):

 seems to be transient.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19261 [Core Tor/Tor]: test suite failure rend_cache/store_v2_desc_as_client

[Tor Bug Tracker & Wiki]

#19261: test suite failure rend_cache/store_v2_desc_as_client
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.3-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I had this fail on 0.2.8.3 on wheezy armel.

 {{{
 ..
 rend_cache/failure_remove: OK
 rend_cache/intro_failure_note: OK
 rend_cache/lookup: OK
 rend_cache/lookup_v2_desc_as_dir: OK
 rend_cache/store_v2_desc_as_client:
   FAIL ../src/test/test_rendcache.c:201: assert(ret OP_EQ -1): 0 vs -1
   [store_v2_desc_as_client FAILED]
 rend_cache/store_v2_desc_as_client_with_different_time: OK
 rend_cache/store_v2_desc_as_dir: OK
 ..
 1/716 TESTS FAILED. (1 skipped)
 }}}

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

[tor-bugs] #19260 [Metrics/Onionoo]: unit tests do not compile against DescripTor version > 1.0.0

[Tor Bug Tracker & Wiki]

#19260: unit tests do not compile against DescripTor version > 1.0.0
-+-
 Reporter:  iwakeh   |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The test classes `DummyBridgeStatus` and `DummyStatusEntry` only comply
 with
 DescripTor release 1.0.0 and fail to implement some methods from 1.1.0 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] #19259 [Metrics/Onionoo]: uncaught NFE

[Tor Bug Tracker & Wiki]

#19259: uncaught NFE
-+-
 Reporter:  iwakeh   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by iwakeh):

 And, also scan for `try`s w/o a `catch`. The try-with-resources closes the
 resource, but if an exception was the reason for that it should be logged.
 (the above code excerpt is surrounded by a try-with-resources statement).

 I see two tasks here:
 * checking for parsing statements that are not safeguarded against
 erroneous or unexpected input
 * check for `try`s w/o `catch`

 maybe, have a general try-catch inside `Main.run` to log unexpected
 exceptions?

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

Re: [tor-bugs] #19259 [Metrics/Onionoo]: uncaught NFE

[Tor Bug Tracker & Wiki]

#19259: uncaught NFE
-+-
 Reporter:  iwakeh   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by iwakeh):

 The data I used were the tars listed in #19249.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19259 [Metrics/Onionoo]: uncaught NFE

[Tor Bug Tracker & Wiki]

#19259: uncaught NFE
-+-
 Reporter:  iwakeh   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major|   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 While waiting for OOM in #19249 I encountered this
 {{{
 Exception in thread "main" java.lang.NumberFormatException: For input
 string: "0,86161974"
 at
 sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1250)
 at java.lang.Double.parseDouble(Double.java:540)
 at
 
org.torproject.onionoo.docs.WeightsStatus.setFromDocumentString(WeightsStatus.java:71)
 at
 
org.torproject.onionoo.docs.DocumentStore.retrieveParsedStatusFile(DocumentStore.java:500)
 at
 
org.torproject.onionoo.docs.DocumentStore.retrieveDocumentFile(DocumentStore.java:484)
 at
 org.torproject.onionoo.docs.DocumentStore.retrieve(DocumentStore.java:363)
 at
 
org.torproject.onionoo.updater.WeightsStatusUpdater.updateWeightsHistory(WeightsStatusUpdater.java:64)
 at
 
org.torproject.onionoo.updater.WeightsStatusUpdater.processRelayNetworkConsensus(WeightsStatusUpdater.java:54)
 at
 
org.torproject.onionoo.updater.WeightsStatusUpdater.processDescriptor(WeightsStatusUpdater.java:39)
 at
 
org.torproject.onionoo.updater.DescriptorSource.readArchivedDescriptors(DescriptorSource.java:197)
 at
 
org.torproject.onionoo.updater.DescriptorSource.readDescriptors(DescriptorSource.java:83)
 at org.torproject.onionoo.cron.Main.updateStatuses(Main.java:188)
 at org.torproject.onionoo.cron.Main.run(Main.java:122)
 at
 org.torproject.onionoo.cron.Main.runOrScheduleExecutions(Main.java:96)
 at org.torproject.onionoo.cron.Main.main(Main.java:32)

 }}}

 The code is
 
[https://gitweb.torproject.org/onionoo.git/tree/src/main/java/org/torproject/onionoo/docs/WeightsStatus.java#n70
 here]:
 {{{
double[] weights = new double[] { -1.0,
 Double.parseDouble(parts[5]),
 Double.parseDouble(parts[6]),
 Double.parseDouble(parts[7]),
 Double.parseDouble(parts[8]), -1.0, -1.0 };
 }}}

 Might be due to the locale of the server, but should be caught and logged.

 Maybe, use this ticket to scan the code for similar things?

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

Re: [tor-bugs] #8725 [Applications/Tor Browser]: resource:// URIs leak information

[Tor Bug Tracker & Wiki]

#8725: resource:// URIs leak information
-+-
 Reporter:  holizz   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Very High| Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Major|  Milestone:
 Keywords:  tbb-fingerprinting, tbb-rebase-  |Version:
  regression, tbb-testcase, tbb-firefox-patch,   | Resolution:
  TorBrowserTeam201606R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by yawning):

 * status:  new => needs_review
 * keywords:
 tbb-fingerprinting, tbb-rebase-regression, tbb-testcase, tbb-firefox-
 patch
 =>
 tbb-fingerprinting, tbb-rebase-regression, tbb-testcase, tbb-firefox-
 patch, TorBrowserTeam201606R


Comment:

 I pushed a change to also restrict `chrome://` URIs, regardless of
 `contentaccessible`, per discussion with gk.  It sort of sucks that
 certain addons will break, but they aren't the standard Tor Browser set.

 I leave it up to the Tor Browser people if they want to take that commit
 or not.

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

Re: [tor-bugs] #8725 [Applications/Tor Browser]: resource:// URIs leak information

[Tor Bug Tracker & Wiki]

#8725: resource:// URIs leak information
-+-
 Reporter:  holizz   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Very High| Status:  new
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Major|Version:
 Keywords:  tbb-fingerprinting, tbb-rebase-  | Resolution:
  regression, tbb-testcase, tbb-firefox-patch|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 
https://git.schwanenlied.me/yawning/torbutton/commit/0deee1b15b0b7fb6551d17827dc9cdd604ff35b9

 Was what I had in mind as far as how to integrate it into torbutton (Yes,
 it works).  Hopefully a real browser developer will take over from 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] #8725 [Applications/Tor Browser]: resource:// URIs leak information

[Tor Bug Tracker & Wiki]

#8725: resource:// URIs leak information
-+-
 Reporter:  holizz   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Very High| Status:  new
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Major|Version:
 Keywords:  tbb-fingerprinting, tbb-rebase-  | Resolution:
  regression, tbb-testcase, tbb-firefox-patch|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 Replying to [comment:22 cypherpunks]:
 > Although the example add-on is GPL-3, I licensed the content policy code
 under MPL-2. Is MPL too restrictive? (Then we'll need to consider a BSD or
 the MIT/X11 license.) But the Mozilla codebase is under MPL anyway...
 > https://notabug.org/desktopd/no-resource-uri-leak/src/master/src
 /resource-filter

 FWIW, the current torbutton license is
 https://gitweb.torproject.org/torbutton.git/tree/src/LICENSE (Which seems
 sort of historical).  And I don't really care either way, but it's
 ultimately not my call, I just want this fixed.

 My plan was to integrate it into torbutton, instead of having it be a
 separate addon, though I'll drop the idea if the browser developers tell
 me that this should be solved another 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] #19151 [Core Tor/Tor]: Looks like a memory leak?

[Tor Bug Tracker & Wiki]

#19151: Looks like a memory leak?
--+
 Reporter:  t-3.net   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Major | Resolution:
 Keywords:  unsolved  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by t-3.net):

 The system seems to have stabilized at 3.7x gigs of RAM with the 3gig
 setting, and Tor looks set to not crash OOM.

 Kinda weird, Libero used to not have anything where it had to be
 configured or else it would steadily eat its memory. I wonder what it's
 stashing in there, in particular if no other relays are seeing OOM
 crashes. I hope nothing in Libero's been messed with somehow.

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

Re: [tor-bugs] #8725 [Applications/Tor Browser]: resource:// URIs leak information

[Tor Bug Tracker & Wiki]

#8725: resource:// URIs leak information
-+-
 Reporter:  holizz   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Very High| Status:  new
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Major|Version:
 Keywords:  tbb-fingerprinting, tbb-rebase-  | Resolution:
  regression, tbb-testcase, tbb-firefox-patch|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Although the example add-on is GPL-3, I licensed the content policy code
 under MPL-2. Is MPL too restrictive? (Then we'll need to consider a BSD or
 the MIT/X11 license.) But the Mozilla codebase is under MPL anyway...
 https://notabug.org/desktopd/no-resource-uri-leak/src/master/src/resource-
 filter

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