date:20161019

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-19 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:62 iwakeh]:
 > Replying to [comment:61 karsten]:
 > > Alright, please find [https://gitweb.torproject.org/karsten/metrics-
 db.git/log/?h=task-18910-4 branch task-18910-4 in my repository].
 >
 > This branch doesn't exist yet.

 Oops, it should exist 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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-19 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:61 karsten]:
 > Alright, please find [https://gitweb.torproject.org/karsten/metrics-
 db.git/log/?h=task-18910-4 branch task-18910-4 in my repository].

 This branch doesn't exist 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] #20410 [Core Tor/Tor]: Tor master breaks bridge clients

2016-10-19 Thread Tor Bug Tracker & Wiki

#20410: Tor master breaks bridge clients
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * cc: chelseakomlo (added)


Comment:

 Looks like the refactor in #20077 changed tor's behaviour:

 {{{
 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
 0   libsystem_kernel.dylib  0x7fff9f528dda __pthread_kill
 + 10
 1   libsystem_pthread.dylib 0x7fff9f613797 pthread_kill +
 90
 2   libsystem_c.dylib   0x7fff9f48e440 abort + 129
 3   tor 0x00010e96c856
 directory_initiate_command_rend + 1654 (directory.c:1146)
 }}}

 {{{
 Oct 20 12:19:07.000 [notice] Bootstrapped 0%: Starting
 Oct 20 12:19:07.000 [notice] Delaying directory fetches: No running
 bridges
 Oct 20 12:19:08.000 [err] tor_assertion_failed_(): Bug:
 src/or/directory.c:1147: directory_initiate_command_rend: Assertion
 anonymized_connection || rend_non_anonymous_mode_enabled(options) failed;
 aborting. (on Tor 0.3.0.0-alpha-dev )
 Oct 20 12:19:08.000 [err] Bug: Assertion anonymized_connection ||
 rend_non_anonymous_mode_enabled(options) failed in
 directory_initiate_command_rend at src/or/directory.c:1147. Stack trace:
 (on Tor 0.3.0.0-alpha-dev )
 Oct 20 12:19:08.000 [err] Bug: 0   tor
 0x00010ea0c775 log_backtrace + 69 (on Tor 0.3.0.0-alpha-dev )
 Oct 20 12:19:08.000 [err] Bug: 1   ???
 0x6d796e6f6e61206e 0x0 + 7888457647188418670 (on Tor 0.3.0.0-alpha-dev )
 }}}

--
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] #20410 [Core Tor/Tor]: Tor master breaks bridge clients

2016-10-19 Thread Tor Bug Tracker & Wiki

#20410: Tor master breaks bridge clients
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 When I run 'make test-network-all' on master (0.3.0-alpha-dev), both
 bridge tests are broken, apparently because the bridge client crashes:
 {{{
 $ make test-network-all
 $CHUTNEY_PATH was not set.
 Assuming test-network.sh will find ./../chutney
 mkdir -p ./test_network_log
 ping6 ::1 succeeded, running IPv6 flavors: bridges+ipv6-min ipv6-exit-min
 hs-ipv6 single-onion-ipv6.
 tor-stable not found, skipping mixed flavors: mixed.
 SKIP: mixed
 PASS: basic-min
 FAIL: bridges-min
 PASS: hs-min
 PASS: single-onion
 FAIL: bridges+ipv6-min
 PASS: ipv6-exit-min
 PASS: hs-ipv6
 PASS: single-onion-ipv6
 Log and result files are available in ./test_network_log.
 make: *** [test-network-all] Error 1
 }}}

 This is consistent across Linux 64-bit, macOS 64-bit, and macOS 32-bit.
 0.2.8.9 and 0.2.9.4-alpha work fine, so it's probably #20389 or #20077 or
 #19858 or #13827 or #6769.

--
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] #20409 [Core Tor/Chutney]: When some chutney tors die, clean up the rest

2016-10-19 Thread Tor Bug Tracker & Wiki

#20409: When some chutney tors die, clean up the rest
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+--
 Chutney should clean up all the tor processes it starts, and leave all
 other processes alone.

 I think this means adding `pkill -P $$` to the end of chutney/tools/test-
 network.sh , and making sure it's executed even if chutney returns
 failure.

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

Re: [tor-bugs] #20403 [Metrics]: Make it easier for relay operators to find their observed bandwidth

2016-10-19 Thread Tor Bug Tracker & Wiki

#20403: Make it easier for relay operators to find their observed bandwidth
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:1 tom]:
 > So depictor (consensus-health) uses stem to get its info, so it's really
 easy for me to include any information here:
 https://stem.torproject.org/api/descriptor/router_status_entry.html   It's
 really difficult to get anything else - downloading descriptors for the
 network would take a _lot_ of time, just downloading the votes and
 consesnsuses takes 10+ minutes.

 I think I might be asking for the "bandwidth (int) -- bandwidth claimed by
 the relay (in kb/s)", but I am not sure how it is sourced.

 > I'm a little confused by the terms you're using.  When you say "observed
 bandwidth" do you mean the relay's 'advertised bandwidth' a relay operator
 puts in the config, the unit-less values the bwauths calculate and vote
 on, or a third thing I'm not recalling? (And if it is the third thing,
 where does that get exposed: Consensus, MicroConsensus, Descriptor,
 Microdescriptor, or ExtraInfo?)

 By "observed bandwdith" I mean the "bandwdith-observed" figure from the
 descriptor "bandwdith" line:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n418

 I'd like it more easily available because it's one of the two figures that
 an operator doesn't set themselves - the other is the measured bandwidth.

 And used in conjunction with the advertised bandwidth to calculate the
 bandwidth in the consensus "w" line:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2268

 (That figure is useful, but more confusing, because it's sometimes the
 advertised bandwidth, and sometimes the observed bandwidth.)

 >  And then the same question for "consensus weight".

 Whatever Atlas uses for consensus weight in the relay details page.
 I assume it's measured bandwidth from the consensus w line, but I'm not
 sure.

 If it is, it's already there in the consensus column of the relay flags
 table.

 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2274

 > Looking closer at the stem documentation, I might have done things wrong
 in #20372 actually. Adding Damian to confirm the below is correct:
 >
 > - On a vote .measured is the bwauth's vote for the relay's (unitless)
 bandwidth value
 > - On a consensus .measured is the average* of the bwauths votes for the
 relay's (unitless) bandwidth value
 > - On a vote or consensus .bandwidth is the _relay's_ advertised
 bandwidth (and is what teor wants available)

 Not quite, I think it's the minimum of advertised and observed, which
 confuses a lot of operators, because sometimes it's controlled by the
 torrc, and other times by their relay's self-reported performance:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n418

 > *not really average but let's pretend it is for simplicity

 (low-median)

 > (Currently, the value on each Authority is the .measured but the value
 on the consensus is .bandwidth - which would be wrong as the consensus
 would be reporting the self-reported advertised bandwidth...)

 That's strange, because all the figures in the table appear to be a low-
 median (consensus .measured) 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] #20284 [Core Tor/Tor]: consensus weight case 2b3 does not follow dir-spec

2016-10-19 Thread Tor Bug Tracker & Wiki

#20284: consensus weight case 2b3 does not follow dir-spec
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  needs_review
 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):

 * status:  merge_ready => needs_review


Comment:

 This would be trouble if we merged it as-is: it changes
 networkstatus_compute_bw_weights_v10, which is invoked from
 networkstatus_compute_consensus.  We need all the authorities who are
 using the same consensus_method to produce the same output for the
 consensus, or else it won't be a consensus.

 As a fix, I would suggest having networkstatus_compute_bw_weights_v10()
 take an argument that says what the actual consensus_method is, and
 allocating a new consensus_method for doing this bandwidth calculation
 correctly.  Also we'd need to document the old way and the new way in dir-
 spec.txt

 Also, mikeperry did most of the work on these equations; I'm hoping we can
 get his feedback about whether he believes more in the code or in dir-
 spec.txt.

--
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] #20389 [Core Tor/Tor]: Say 'Invalid argument' instead of unclear 'Unrecognized' in HSFETCH

2016-10-19 Thread Tor Bug Tracker & Wiki

#20389: Say 'Invalid argument' instead of unclear 'Unrecognized' in HSFETCH
-+
 Reporter:  twim |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  control, tor-hs  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:  dgoulet  |Sponsor:  SponsorR-can
-+
Changes (by nickm):

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


Comment:

 lgtm too; merged!

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

Re: [tor-bugs] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

2016-10-19 Thread Tor Bug Tracker & Wiki

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  refactor, 030-proposed,  |  Actual Points:
  TorCoreTeam201610  |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

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


--
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] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

2016-10-19 Thread Tor Bug Tracker & Wiki

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, 030-proposed,  |  Actual Points:
  TorCoreTeam201610  |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by nickm):

 merged to master! (which is now 0.3.0).  Thanks!

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

Re: [tor-bugs] #19858 [Core Tor/Tor]: Move guard state out of globals per new guard plan

2016-10-19 Thread Tor Bug Tracker & Wiki

#19858: Move guard state out of globals per new guard plan
-+
 Reporter:  andrea   |  Owner:  andrea
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:  implemented
 Keywords:  nickm-deferred-20161005  |  Actual Points:  6
Parent ID:  #19877   | Points:  3
 Reviewer:   |Sponsor:  SponsorU-must
-+
Changes (by nickm):

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


Comment:

 Merged!

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

Re: [tor-bugs] #13827 [Core Tor/Tor]: Cell handling code duplication in channel.c

2016-10-19 Thread Tor Bug Tracker & Wiki

#13827: Cell handling code duplication in channel.c
---+
 Reporter:  rl1987 |  Owner:  pingl
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  refactoring, easy  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer:  dgoulet, nickm |Sponsor:
---+
Changes (by nickm):

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


Comment:

 Merged!

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

Re: [tor-bugs] #6769 [Core Tor/Tor]: Relays (and bridges) don't use microdescriptors

2016-10-19 Thread Tor Bug Tracker & Wiki

#6769: Relays (and bridges) don't use microdescriptors
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged into master

--
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] #18580 [Core Tor/Tor]: exit relay fails with 'unbound' DNS resolver when lots of requests time-out

2016-10-19 Thread Tor Bug Tracker & Wiki

#18580: exit relay fails with 'unbound' DNS resolver when lots of requests 
time-out
--+--
 Reporter:  Dhalgren  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Dhalgren):

 After coming to understand the issue and tune for it, I created an alarm
 that triggers whenever the output from 'unbound-control dump_requestlist'
 command exceeds 200 entries (400 actually, as two DNS worker threads are
 configured and the command shows only thread 0).  This has been hit twice
 now and today I managed to look at it while the event was still in
 progress.

 This time instead of GoDaddy, the DNS enumeration target was a major
 Australian DNS provider and they, like GoDaddy, blocked DNS etc. traffic
 from the exit node.

 The tuning appears to work as the node continued to be usable with good
 performance when "setconf ExitNodes=" is applied for testing on a
 client.  I observe a 15% or so drop-off in traffic per the ISP utilization
 graph at the time of the alarm, with full recovery occurrng in about one
 hour.  Hard to say whether the drop-off was the result of a performance
 impact from the DNS abuse or whether it's because the attacker gave up
 using the node just after I started looking--dump_requestlist began
 shrinking rapidly then.

 In any case the node did vastly better than at the time of the original
 attack before the eventdns tuning was applied.  At that time the relay was
 effectively taken down for two days.  That attacker left their abuse-
 program running and didn't notice that GoDaddy had put and end to the
 scan.

 A look at the utilization graph for the earlier alarm incident showed no
 performance impact, but that one occurred during off-peak hours when
 utilization runs significantly lower.

--
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] #20404 [Metrics/metrics-lib]: DescriptorIndexCollector should be default implementation

2016-10-19 Thread Tor Bug Tracker & Wiki

#20404: DescriptorIndexCollector should be default implementation
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Please take a look at this pre-release tarball and let me know if it's
 good to go, in which case it'll simply become the release tarball:
 https://people.torproject.org/~karsten/volatile/descriptor-1.5.0-pre.tar.gz

--
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] #20408 [Metrics/CollecTor]: Move index.json* to index/ subdirectory

2016-10-19 Thread Tor Bug Tracker & Wiki

#20408: Move index.json* to index/ subdirectory
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

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


Comment:

 Great, thanks for looking!  Merged to master.  Closing.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-19 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Alright, please find [https://gitweb.torproject.org/karsten/metrics-
 db.git/log/?h=task-18910-4 branch task-18910-4 in my repository].

 Things left to do:

  - Let me know if the change log looks okay.
  - Find out why unit tests fail.
  - Upgrade to next metrics-lib as soon as it's released.
  - Test on a server.
  - Squash commits and merge.

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

Re: [tor-bugs] #20111 [Applications/Tor Browser]: use Unix domain sockets for SOCKS port by default

2016-10-19 Thread Tor Bug Tracker & Wiki

#20111: use Unix domain sockets for SOCKS port by default
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security, tbb-|  Actual Points:
  sandboxing, TorBrowserTeam201610   |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:27 bugzilla]:
 > Seems you didn't see ticket:18047#comment:3.

 I am sure I saw it but did not realize there were implications for
 isolation.

 > You'll be more surprised to know that webpages continue to stay in a
 cache, so that it's possible to reopen them in a old state.

 I am not sure if that is a problem or not. Network traffic may be more of
 a concern, especially if isolation does not occur.

 > (also you've just disclosed your timezone ;)

 Thanks. That is not a big concern to me, but it might be for some people.

--
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] #20373 [Applications/Tor Browser]: Privacy and Security Settings window opens twice

2016-10-19 Thread Tor Bug Tracker & Wiki

#20373: Privacy and Security Settings window opens twice
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:5 arthuredelstein]:
 > I think you're right that this approach would likely work, too. I hadn't
 thought of using it. If you or gk would prefer I can add a follow-on
 patch.

 For me this is not essential, especially given the other tasks we all have
 on our plates.

--
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] #20408 [Metrics/CollecTor]: Move index.json* to index/ subdirectory

2016-10-19 Thread Tor Bug Tracker & Wiki

#20408: Move index.json* to index/ subdirectory
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * status:  needs_review => merge_ready


--
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] #20408 [Metrics/CollecTor]: Move index.json* to index/ subdirectory

2016-10-19 Thread Tor Bug Tracker & Wiki

#20408: Move index.json* to index/ subdirectory
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Looks good.

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

Re: [tor-bugs] #19437 [Metrics/Onionoo]: Find more reliable and universal way to get ASN and ASorg mappings

2016-10-19 Thread Tor Bug Tracker & Wiki

#19437: Find more reliable and universal way to get ASN and ASorg mappings
-+-
 Reporter:  twim |  Owner:
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  asn, as, geoip, maxmind, bgp,|  Actual Points:
  organisations, diversity   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by twim):

 Replying to [comment:14 phoul]:
 > https://iptoasn.com/ run by Frank Denis of OVH might be useful.

 Thanks. Do you know is there a writeup about this service and the sources
 of the data there? I can't find any.

--
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] #20394 [Applications/Tor Browser]: Remove dead code in torbutton

2016-10-19 Thread Tor Bug Tracker & Wiki

#20394: Remove dead code in torbutton
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-code-cleanup,|  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-code-cleanup, TorBrowserTeam201610 => tbb-code-cleanup,
 TorBrowserTeam201610R
 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:2 gk, comment 2]:
 > Two things:
 >
 > 1) What about the `contents.rdf` file in `chrome/skin`?
 > 2) There is not `P0` anymore in `torbutton.js` after your clean-up,
 right? We should change comment on the first line accordingly then:
 s/P0/P1/

 Replying to [comment:3 gk, comment 3]:
 > Oh, and a bug number in your commit message would be good. (although I
 am usually fixing this if it's missing ;) )

 All good points. Sorry for forgetting the bug number! Here is the branch
 with fixes:
 https://github.com/arthuredelstein/torbutton/commit/20394+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] #20404 [Metrics/metrics-lib]: DescriptorIndexCollector should be default implementation

2016-10-19 Thread Tor Bug Tracker & Wiki

#20404: DescriptorIndexCollector should be default implementation
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:5 karsten]:
 > I think we're leaving third-party jars out of the release jar on
 purpose.  The idea is to avoid version conflicts where we'd be shipping an
 older or newer version of a library that people use in their applications.
 I vaguely remember that our version might take precedence over theirs, and
 that can be bad.

 I vaguely remember the discussion back then.

 >
 > So, in `CONTRIB.md` we write: "Whenever we add a new dependency, that's
 clearly a major change that needs to be written into the change log,
 because applications will have to add this dependency, too."  We also
 write: "For minor changes, we'd bump to x.x.1."
 >
 > The question now is whether we can justify putting out a point release
 with a major change.  I lean towards no.  And even a medium change might
 require a bump to 1.5.0, though I'm less certain about that being a great
 idea.  The question is: should we just call this one 1.5.0 and bulk-change
 tickets to move them to 1.6.0?  Happy to create a milestone for that.  Let
 me know!

 Yes, 1.5.0 is right in the view of our earlier definition. (It might even
 turn into 2.0.0 instead of 1.6.0, but I need to go back and lock at the
 planned items for that release.)

--
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] #20408 [Metrics/CollecTor]: Move index.json* to index/ subdirectory

2016-10-19 Thread Tor Bug Tracker & Wiki

#20408: Move index.json* to index/ subdirectory
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  new => needs_review


Comment:

 https://gitweb.torproject.org/karsten/metrics-db.git/log/?h=task-20408

--
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] #20408 [Metrics/CollecTor]: Move index.json* to index/ subdirectory

2016-10-19 Thread Tor Bug Tracker & Wiki

#20408: Move index.json* to index/ subdirectory
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 As discussed elsewhere, branch follows shortly.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-19 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:59 karsten]:
 > Those three commits look good!  Mind if I merge the first two into
 
[https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910-4=b998073dbf8ce8e6e728b6154b2b3ad8dcfc69ed
 b998073]?

 That's fine.

 >
 > (Do you know how to use `git commit --fixup b998073` or `git commit
 --squash b998073`?  I find those really helpful to avoid changing existing
 commits and yet making it clear how commits may be squashed during the
 merge for future generations to make sense of them.)

 Yes, but just didn't think of using them.

 >
 > And yes, we'll need to update to the next metrics-lib release once it's
 out.
 >
 > Oh, here's another thing we still need to do: we should make the change
 log more comprehensible for other operators.  I have some ideas for
 improving what's there, but if you'd like to give that a try first, please
 feel free.

 Just go ahead, I'm still too much in the technical mindset right 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] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

2016-10-19 Thread Tor Bug Tracker & Wiki

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, 030-proposed,  |  Actual Points:
  TorCoreTeam201610  |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by chelseakomlo):

 Sure, I was wondering whether the default case would be needed.

 Refactor to use switch statement:
 
https://github.com/chelseakomlo/tor_patches/commit/471b0c5175521bb2bc49eb7e30d78f656a3a2843

 Fix for #20077:
 
https://github.com/chelseakomlo/tor_patches/commit/195ccce94e250a150e208f7a8fb9ba8375b6fe89

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-19 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Those three commits look good!  Mind if I merge the first two into
 
[https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910-4=b998073dbf8ce8e6e728b6154b2b3ad8dcfc69ed
 b998073]?

 (Do you know how to use `git commit --fixup b998073` or `git commit
 --squash b998073`?  I find those really helpful to avoid changing existing
 commits and yet making it clear how commits may be squashed during the
 merge for future generations to make sense of them.)

 And yes, we'll need to update to the next metrics-lib release once it's
 out.

 Oh, here's another thing we still need to do: we should make the change
 log more comprehensible for other operators.  I have some ideas for
 improving what's there, but if you'd like to give that a try first, please
 feel free.

--
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] #20404 [Metrics/metrics-lib]: DescriptorIndexCollector should be default implementation

2016-10-19 Thread Tor Bug Tracker & Wiki

#20404: DescriptorIndexCollector should be default implementation
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 I think we're leaving third-party jars out of the release jar on purpose.
 The idea is to avoid version conflicts where we'd be shipping an older or
 newer version of a library that people use in their applications.  I
 vaguely remember that our version might take precedence over theirs, and
 that can be bad.

 So, in `CONTRIB.md` we write: "Whenever we add a new dependency, that's
 clearly a major change that needs to be written into the change log,
 because applications will have to add this dependency, too."  We also
 write: "For minor changes, we'd bump to x.x.1."

 The question now is whether we can justify putting out a point release
 with a major change.  I lean towards no.  And even a medium change might
 require a bump to 1.5.0, though I'm less certain about that being a great
 idea.  The question is: should we just call this one 1.5.0 and bulk-change
 tickets to move them to 1.6.0?  Happy to create a milestone for that.  Let
 me know!

--
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] #19437 [Metrics/Onionoo]: Find more reliable and universal way to get ASN and ASorg mappings

2016-10-19 Thread Tor Bug Tracker & Wiki

#19437: Find more reliable and universal way to get ASN and ASorg mappings
-+-
 Reporter:  twim |  Owner:
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  asn, as, geoip, maxmind, bgp,|  Actual Points:
  organisations, diversity   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by phoul):

 https://iptoasn.com/ run by Frank Denis of OVH might be useful.

--
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] #20407 [Internal Services/Service - trac]: Black border around trac menu items

2016-10-19 Thread Tor Bug Tracker & Wiki

#20407: Black border around trac menu items
--+-
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 There is a black border around the menu items at the top (View Tickets,
 Browse Source, Roadmap, etc.) which looks like it shouldn't be there.
 FWICT this started after #20213 got fixed.

 The CSS responsible for this border lives in
 https://trac.torproject.org/tor.css and is defined as follows;
 {{{
 #mainnav {
  background: #f7f7f7 0 0;
  border: 1px solid #000;
  font: normal 10px verdana,'Bitstream Vera Sans',helvetica,arial,sans-
 serif;
  margin: .66em 0 .33em;
  padding: .2em 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] #20406 [Core Tor/Tor]: compute_num_cpus() purports to clamp to 16, but doesn't.

2016-10-19 Thread Tor Bug Tracker & Wiki

#20406: compute_num_cpus() purports to clamp to 16, but doesn't.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 This is a duplicate of #19968.

--
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] #20111 [Applications/Tor Browser]: use Unix domain sockets for SOCKS port by default

2016-10-19 Thread Tor Bug Tracker & Wiki

#20111: use Unix domain sockets for SOCKS port by default
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security, tbb-|  Actual Points:
  sandboxing, TorBrowserTeam201610   |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by bugzilla):

 Replying to [comment:26 mcs]:
 > It surprises me that Firefox does not cancel all network activity as a
 browser tab is closed, but maybe that hurts performance. I don't think any
 harm is done in this case because, even though the catch all circuit would
 be used, there is no tor to talk to any more. But I wonder if this same
 situation can happen when closing a window or tab without exiting the
 browser. Probably we should open a new ticket for this issue.
 Seems you didn't see ticket:18047#comment:3. You'll be more surprised to
 know that webpages continue to stay in a cache, so that it's possible to
 reopen them in a old state.
 (also you've just disclosed your timezone ;)

--
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] #20363 [Internal Services/Tor Sysadmin Team]: New VM/domain for services needed by our testnet

2016-10-19 Thread Tor Bug Tracker & Wiki

#20363: New VM/domain for services needed by our testnet
-+-
 Reporter:  dgoulet  |  Owner:
 |  
 Type:  task | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


Comment:

 instance togashii.torproject.org created.

 For individual service setup, please coordinate (irc, new tickets, etc).

--
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] #19858 [Core Tor/Tor]: Move guard state out of globals per new guard plan

2016-10-19 Thread Tor Bug Tracker & Wiki

#19858: Move guard state out of globals per new guard plan
-+
 Reporter:  andrea   |  Owner:  andrea
 Type:  task | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  nickm-deferred-20161005  |  Actual Points:  6
Parent ID:  #19877   | Points:  3
 Reviewer:   |Sponsor:  SponsorU-must
-+
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 lgtm

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

Re: [tor-bugs] #20111 [Applications/Tor Browser]: use Unix domain sockets for SOCKS port by default

2016-10-19 Thread Tor Bug Tracker & Wiki

#20111: use Unix domain sockets for SOCKS port by default
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security, tbb-|  Actual Points:
  sandboxing, TorBrowserTeam201610   |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:25 gk]:
 > The Torbutton patch looks good to me (although I am not happy either
 with having a copy of `_strUnescape()` there as well; I thought a bit
 about using the one from TorLauncher there, too, but that is probably a
 bad idea as we want to support the no-TorLauncher case as well).

 Yes, that is why we did not rely on making a call into Tor Launcher.

 > Just two minor nits for the TorLauncher one:
 >
 > 1)
 > {{{
 > +// If extensions.torlauncher.socks_ipc_path is empty, a default
 > +// default path is used (/socks.socket).
 > }}}
 > "default" once should be enough :)
 >
 > 2)
 > {{{
 > +if (useIPC)
 > +  TorLauncherLogger.log(3, "ipcFile: " +
 this.mSOCKSPortInfo.ipcFile.path);
 > +else
 > +{
 > +  TorLauncherLogger.log(3, "SOCKS host: " +
 this.mSOCKSPortInfo.host);
 > +  TorLauncherLogger.log(3, "SOCKS port: " +
 this.mSOCKSPortInfo.port);
 > +}
 > }}}
 > Please don't mix code parts with and without curly braces in one if-else
 construct. This is too error-prone for my taste.

 Thanks for the review. We will fix both of these issue and post a new
 patch.

 > That said I tested the patches again with the proposed fix for bug
 1311044 and there is not shutdown hang anymore. However, seeing all the
 output after `tor` is supposedly shut down still makes me nervous. I think
 we should have the behavior we currently have in this regard (at least it
 seems to me we have it that way at the moment): first no traffic anymore,
 then `tor` gets shut down and then the browser goes away.

 This is not new behavior. We were able to reproduce it using TB 6.5a3 when
 running with TCP control and SOCKS ports. I will attach a log.

 It surprises me that Firefox does not cancel all network activity as a
 browser tab is closed, but maybe that hurts performance. I don't think any
 harm is done in this case because, even though the catch all circuit would
 be used, there is no tor to talk to any more. But I wonder if this same
 situation can happen when closing a window or tab without exiting the
 browser. Probably we should open a new ticket for this issue.

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

Re: [tor-bugs] #20403 [Metrics]: Make it easier for relay operators to find their observed bandwidth

2016-10-19 Thread Tor Bug Tracker & Wiki

#20403: Make it easier for relay operators to find their observed bandwidth
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by tom):

 * cc: atagar (added)


Comment:

 So depictor (consensus-health) uses stem to get its info, so it's really
 easy for me to include any information here:
 https://stem.torproject.org/api/descriptor/router_status_entry.html   It's
 really difficult to get anything else - downloading descriptors for the
 network would take a _lot_ of time, just downloading the votes and
 consesnsuses takes 10+ minutes.

 I'm a little confused by the terms you're using.  When you say "observed
 bandwidth" do you mean the relay's 'advertised bandwidth' a relay operator
 puts in the config, the unit-less values the bwauths calculate and vote
 on, or a third thing I'm not recalling? (And if it is the third thing,
 where does that get exposed: Consensus, MicroConsensus, Descriptor,
 Microdescriptor, or ExtraInfo?)  And then the same question for "consensus
 weight".



 Looking closer at the stem documentation, I might have done things wrong
 in #20372 actually. Adding Damian to confirm the below is correct:

 - On a vote .measured is the bwauth's vote for the relay's (unitless)
 bandwidth value
 - On a consensus .measured is the average* of the bwauths votes for the
 relay's (unitless) bandwidth value
 - On a vote or consensus .bandwidth is the _relay's_ advertised bandwidth
 (and is what teor wants available)

 *not really average but let's pretend it is for simplicity

 (Currently, the value on each Authority is the .measured but the value on
 the consensus is .bandwidth - which would be wrong as the consensus would
 be reporting the self-reported advertised bandwidth...)

--
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] #20404 [Metrics/metrics-lib]: DescriptorIndexCollector should be default implementation

2016-10-19 Thread Tor Bug Tracker & Wiki

#20404: DescriptorIndexCollector should be default implementation
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Oh, I wasn't aware of metrics-lib not including the dependencies inthe
 release jar.

 As with the other releases a metrics-lib release jar should contain all of
 its dependencies.
 We should provide gson with the release jar of metrics-lib, and thus, hide
 the internal choice of implementation.
 (Onionoo could then even get rid of that dependency as metrics-lib comes
 with gson.)  But, I think the better solution will be the metrics-tools
 lib that wraps any JSON-protocol implementation.

 Can that be changed with this release, i.e. include dependencies?  Then it
 could even go up 1.5.0 I think.

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

Re: [tor-bugs] #20405 [Metrics/metrics-lib]: create metrics-tools with all of the index.json processing code as first content

2016-10-19 Thread Tor Bug Tracker & Wiki

#20405: create metrics-tools with all of the index.json processing code as first
content
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.5.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Couple of thoughts:

  - We might consider metrics-lib as the library to facilitate data
 exchange between CollecTor and other applications/services processing
 CollecTor data.

  - As a result, we could grant CollecTor access to implementation packages
 of metrics-lib that applications/services should not touch.  There's a
 tight coupling between CollecTor and metrics-lib anyway, so we wouldn't
 have to inform "those other CollecTor devs over there" to update their
 code, because we're deprecating a feature.

  - Before we start a new library, we should look at what functionality
 we're currently missing and whether that would fit into metrics-lib.
 Examples are date formatting and parsing, which could be solved by either
 introducing a new date class in metrics-lib instead of passing `long`
 values around, or it could be solved by providing a utilities class for
 processing those `long` values.  Another example is fingerprint handling,
 where we'd provide methods for calculating the digest, for converting from
 hex to base64, and so on.  Maybe we'll end up with a very short list for
 the new library that we decide it's not worth creating one; at the price
 of making metrics-lib more powerful.  That being said, if something
 doesn't fit in, we shouldn't force 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] #20404 [Metrics/metrics-lib]: DescriptorIndexCollector should be default implementation

2016-10-19 Thread Tor Bug Tracker & Wiki

#20404: DescriptorIndexCollector should be default implementation
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Merged, together with a change log entry.

 However, this is a major change, because we're now requiring Gson for all
 applications.  Does that mean we should call it 1.5.0 and not 1.4.1?!
 Hm.

--
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] #20334 [Metrics/metrics-lib]: explicitly log, which implementation is served by DescriptorSourceFactory

2016-10-19 Thread Tor Bug Tracker & Wiki

#20334: explicitly log, which implementation is served by 
DescriptorSourceFactory
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Merged.  Closing.  Thanks!

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

Re: [tor-bugs] #20039 [Metrics/metrics-lib]: integrate `DescriptorIndexCollector` in a fully backward-compatible way

2016-10-19 Thread Tor Bug Tracker & Wiki

#20039: integrate `DescriptorIndexCollector` in a fully backward-compatible way
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Merged.  Please close if this concludes the ticket.  Thanks!

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

Re: [tor-bugs] #20388 [Applications/Tor Browser]: Consolidate prefs usage in torbutton.js

2016-10-19 Thread Tor Bug Tracker & Wiki

#20388: Consolidate prefs usage in torbutton.js
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  tbb-code-cleanup,|  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:7 bugzilla]:
 > Replying to [comment:6 arthuredelstein]:
 > > I would like to keep a new issue such as this one in a separate ticket
 so we don't lose it.
 > OK, so you mean that TBB Team prefer anybody filing a new ticket for
 even minor inconsistencies, so that it'll look like a Q & A site with
 separate discussion for every question. Right?

 Yes, absolutely. If the issue is unrelated to the subject of the ticket,
 then it will be overlooked because it won't appear as a separate item in
 query results. Especially if the ticket, like this one, is already closed.
 "Out of sight, out of mind." The rule is: one ticket per issue.

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

Re: [tor-bugs] #20373 [Applications/Tor Browser]: Privacy and Security Settings window opens twice

2016-10-19 Thread Tor Bug Tracker & Wiki

#20373: Privacy and Security Settings window opens twice
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:4 mcs]:
 > I know this is a late comment (and the patch looks OK to me), but rather
 than tracking open windows inside Torbutton I would have used
 nsIWindowMediator.getMostRecentWindow() to find the dialog if it is open
 (we would need to add a unique type attribute to the dialog XUL). Or maybe
 there is a reason why that approach would not work in this situation.

 I think you're right that this approach would likely work, too. I hadn't
 thought of using it. If you or gk would prefer I can add a follow-on
 patch.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-19 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 The changes look good.

 Please take a look at the top three commits
 [https://gitweb.torproject.org/user/iwakeh/collector.git?h=task-18910-4
 here].

 Just to not forget:
 The metrics-lib version needs to be updated after the 1.4.1 release.

--
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] #19898 [Applications/Tor Browser]: Use default search in about:tor in our alpha builds

2016-10-19 Thread Tor Bug Tracker & Wiki

#19898: Use default search in about:tor in our alpha builds
--+--
 Reporter:  f451022   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201610  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: alison (added)
 * keywords:   => TorBrowserTeam201610
 * type:  defect => enhancement


Comment:

 Replying to [comment:3 bugzilla]:
 > #20397 is a duplicate.

 That bug is about the text which gets shown on `about:tor`. But I guess we
 can take care of that one here as well when we change the search engine.
 Putting it on our radar.

--
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] #19898 [Applications/Tor Browser]: Use default search in about:tor in our alpha builds

2016-10-19 Thread Tor Bug Tracker & Wiki

#19898: Use default search in about:tor in our alpha builds
--+--
 Reporter:  f451022   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 #20397 is a duplicate.

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

Re: [tor-bugs] #20397 [Applications/Tor Browser]: "Search securely with Disconnect.me" still appears when Tor Browser opens

2016-10-19 Thread Tor Bug Tracker & Wiki

#20397: "Search securely with Disconnect.me" still appears when Tor Browser 
opens
--+---
 Reporter:  alison|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by bugzilla):

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


Comment:

 Closed as a duplicate of #19898.

--
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] #19025 [Core Tor/Tor]: Exit relays always return DNS TTL 60 to tor clients

2016-10-19 Thread Tor Bug Tracker & Wiki

#19025: Exit relays always return DNS TTL 60 to tor clients
-+-
 Reporter:  phw  |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  dns, TorCoreTeam201607,  |  Actual Points:
  029-proposed   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Throwing this and #19769 into 0.3.0: see
 https://lists.torproject.org/pipermail/tor-talk/2016-October/042445.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] #13464 [Applications/Tor Browser]: NoScript blocks right-click searching of text

2016-10-19 Thread Tor Bug Tracker & Wiki

#13464: NoScript blocks right-click searching of text
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript, tbb-usability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 #16425 is a duplicate.

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

Re: [tor-bugs] #16425 [Applications/Tor Browser]: Searching via Disconnect should show no XSS false positive warnings

2016-10-19 Thread Tor Bug Tracker & Wiki

#16425: Searching via Disconnect should show no XSS false positive warnings
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by bugzilla):

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


Comment:

 Closed as a duplicate of #13464.

--
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] #20406 [Core Tor/Tor]: compute_num_cpus() purports to clamp to 16, but doesn't.

2016-10-19 Thread Tor Bug Tracker & Wiki

#20406: compute_num_cpus() purports to clamp to 16, but doesn't.
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  0 |   Reviewer:
  Sponsor:|
--+
 Our compute_num_cpus() code is not supposed to report more than
 MAX_DETECTABLE_CPUS, since if you are somehow running Tor on a 64-core
 system, you should have to ask Tor before it decides to use all 64.

 But it doesn't: the code logs a notice, and then does nothing.

 This causes the following test failure on systems with more than 16 cores:
 {{{
 util/num_cpus:
   FAIL ../src/test/test_util.c:3827: assert(num OP_LE 16): 18 vs 16
 }}}


 ''029 rationale: this is apparently making our tests fail in the debian
 reproducible build QA system.''

--
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] #20406 [Core Tor/Tor]: compute_num_cpus() purports to clamp to 16, but doesn't.

2016-10-19 Thread Tor Bug Tracker & Wiki

#20406: compute_num_cpus() purports to clamp to 16, but doesn't.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted


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

Re: [tor-bugs] #18532 [Applications/Tor Browser]: Now search.disconnect.me through catchall too

2016-10-19 Thread Tor Bug Tracker & Wiki

#18532: Now search.disconnect.me through catchall too
--+--
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

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


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

Re: [tor-bugs] #18532 [Applications/Tor Browser]: Now search.disconnect.me through catchall too

2016-10-19 Thread Tor Bug Tracker & Wiki

#18532: Now search.disconnect.me through catchall too
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  duplicate
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by bugzilla):

 Reopening this bug as it's not about #16324, where
 > the issue *I* had and which was the reason why *I* created this bug is a
 non-issue.

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

Re: [tor-bugs] #19769 [Core Tor/Tor]: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)

2016-10-19 Thread Tor Bug Tracker & Wiki

#19769: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-proposed, dns,   |  Actual Points:
  TorCoreTeam201609  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Throwing this and #19025 into 0.3.0 : see
 https://lists.torproject.org/pipermail/tor-talk/2016-October/042445.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] #19769 [Core Tor/Tor]: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)

2016-10-19 Thread Tor Bug Tracker & Wiki

#19769: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-proposed, dns,   |  Actual Points:
  TorCoreTeam201609  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.2.??? => 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] #20390 [Applications/Tor Browser]: Tor Crashes

2016-10-19 Thread Tor Bug Tracker & Wiki

#20390: Tor Crashes
--+---
 Reporter:  mwolfe|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:5 mwolfe]:
 > Checking in Activity Monitor, I only have 6 MB memory available. Maybe
 that's causing the crashes?

 Yes, that is what I think looking at your stack trace + looking at the
 older bugs you filed. Can you try to increase the amount of usable memory
 for Tor Browser and report back? A test of a vanilla Firefox 45 ESR might
 shed some light on your problem as well.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-19 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Thanks for working through all that code so quickly!

 Replying to [comment:56 karsten]:
 > Alright!  Please find [https://gitweb.torproject.org/karsten/metrics-
 db.git/log/?h=task-18910-3 branch task-18910-3 in my repository].  I
 created fixup/squash commits for most things I found.  Please take a close
 look and challenge anything you don't like to be squashed into your
 commit.  In particular, please take a look why the unit tests don't pass
 anymore. ;)

 Fine. I'll start testing after finishing this reply.

 >
 > More comments below:
 >
 >  - I believe that index.json would include the `.tmp` files written
 during sync, because we're only skipping files starting with `.`.  And
 that's not even a new issue, because the `.tmp` files written during
 normal updating would also be included.  The issue will only become more
 prevalent.  I'd say we adapt the indexer, which can happen in a separate
 commit.  Or we could change temporary files to start with `.`, but that
 seems a bit more error-prone.  Suggestion: '''fix'''

 That's ok.  Eventually the regular modules should use the classes in
 o.t.c.persist for storing descriptors (that will reduce the line count in
 them tremendously and finally unify writing descriptors).  So, using the
 "." prefix here now is fine.

 >
 >  - As mentioned before somewhere, we're appending server/extra-info
 descriptors to different files in the synchronization run than in the
 earlier update run.  The reason is that `SyncManager` creates its own
 `collectionDate` in the constructor.  However, we cannot just pass a
 `Date` instance to both `SyncManager` and `ArchiveWriter`, because then
 `SyncManager` would append to a file that we're already serving, in which
 case the file size would change once we're done synchronizing, and we
 should try to avoid that.  Let's fix this as soon as the current updaters
 are modules just like the synchronization module, and let's keep in mind
 not to close and rename temporary files to their final names between
 modules.  Suggestion: '''postpone'''

 Agreed.

 >
 >  - As said earlier, let's release metrics-lib and use that new release
 as basis for this patch.  Then we won't have to import and instantiate
 `org.torproject.descriptor.index.DescriptorIndexCollector` anymore, and we
 can change defaults for the `*SyncOrigins` properties in
 `collector.properties` back to `https://collector.torproject.org`.
 Suggestion: '''change'''

 Fine!
 All these changes are reasons for metrics-lib release 1.4.1.

 >
 >  - Regarding comment 25 above, I'm still a fan of using `printf` as
 opposed to creating `SimpleDateFormat` instances and concatenating
 strings.  I also believe it would be more efficient.  But I'm happy to
 postpone that change.  Suggestion: '''postpone'''

 Yes, it might be good to think a little about that.  The timestamp to
 string functionality might also be a candidate for 'metrics-tools' (cf.
 #20405), b/c it's used throughout Metrics' products.

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

Re: [tor-bugs] #20111 [Applications/Tor Browser]: use Unix domain sockets for SOCKS port by default

2016-10-19 Thread Tor Bug Tracker & Wiki

#20111: use Unix domain sockets for SOCKS port by default
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security, tbb-|  Actual Points:
  sandboxing, TorBrowserTeam201610   |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-torbutton, tbb-security, tbb-sandboxing,
 TorBrowserTeam201610R => tbb-torbutton, tbb-security, tbb-sandboxing,
 TorBrowserTeam201610
 * status:  needs_review => needs_revision


Comment:

 The Torbutton patch looks good to me (although I am not happy either with
 having a copy of `_strUnescape()` there as well; I thought a bit about
 using the one from TorLauncher there, too, but that is probably a bad idea
 as we want to support the no-TorLauncher case as well). Just two minor
 nits for the TorLauncher one:

 1)
 {{{
 +// If extensions.torlauncher.socks_ipc_path is empty, a default
 +// default path is used (/socks.socket).
 }}}
 "default" once should be enough :)

 2)
 {{{
 +if (useIPC)
 +  TorLauncherLogger.log(3, "ipcFile: " +
 this.mSOCKSPortInfo.ipcFile.path);
 +else
 +{
 +  TorLauncherLogger.log(3, "SOCKS host: " +
 this.mSOCKSPortInfo.host);
 +  TorLauncherLogger.log(3, "SOCKS port: " +
 this.mSOCKSPortInfo.port);
 +}
 }}}
 Please don't mix code parts with and without curly braces in one if-else
 construct. This is too error-prone for my taste.

 That said I tested the patches again with the proposed fix for bug 1311044
 and there is not shutdown hang anymore. However, seeing all the output
 after `tor` is supposedly shut down still makes me nervous. I think we
 should have the behavior we currently have in this regard (at least it
 seems to me we have it that way at the moment): first no traffic anymore,
 then `tor` gets shut down and then the browser goes away.

--
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] #20401 [Core Tor/Tor]: minor memory leak in threadpool_queue_update()

2016-10-19 Thread Tor Bug Tracker & Wiki

#20401: minor memory leak in threadpool_queue_update()
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.2.9.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] #16920 [Applications/Tor Browser]: Referer Header should be disabled for new tabs

2016-10-19 Thread Tor Bug Tracker & Wiki

#16920: Referer Header should be disabled for new tabs
--+--
 Reporter:  someone_else  |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * status:  new => needs_review
 * keywords:   => tbb-linkability
 * severity:   => Normal


Comment:

 Makes sense in a part that it
 > should not be preserved for cross-origin navigation

--
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] #14828 [Core Tor/Tor]: Multiple hidden services can share a pk_digest/service_id.

2016-10-19 Thread Tor Bug Tracker & Wiki

#14828: Multiple hidden services can share a pk_digest/service_id.
--+
 Reporter:  yawning   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Very Low  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7
 Severity:  Minor | Resolution:
 Keywords:  easy tor-hs   |  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:  SponsorR-can
--+
Changes (by nickm):

 * milestone:  Tor: 0.2.??? => 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] #20390 [Applications/Tor Browser]: Tor Crashes

2016-10-19 Thread Tor Bug Tracker & Wiki

#20390: Tor Crashes
--+---
 Reporter:  mwolfe|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mwolfe):

 Checking in Activity Monitor, I only have 6 MB memory available. Maybe
 that's causing the crashes?

--
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] #20390 [Applications/Tor Browser]: Tor Crashes

2016-10-19 Thread Tor Bug Tracker & Wiki

#20390: Tor Crashes
--+---
 Reporter:  mwolfe|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mwolfe):

 4GB. Old Macintosh 2.66 Ghz Intel Core i7, 4GB 1067 Mhz DDR3.
 Windows 10 running in Boot Camp.

 Still using OS X 10.6 on Mac side.

 Do not have normal Firefox installed. For insecure, I use old Safari on
 Mac side and Internet Explorer on Windows side.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-19 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Alright!  Please find [https://gitweb.torproject.org/karsten/metrics-
 db.git/log/?h=task-18910-3 branch task-18910-3 in my repository].  I
 created fixup/squash commits for most things I found.  Please take a close
 look and challenge anything you don't like to be squashed into your
 commit.  In particular, please take a look why the unit tests don't pass
 anymore. ;)

 More comments below:

  - I believe that index.json would include the `.tmp` files written during
 sync, because we're only skipping files starting with `.`.  And that's not
 even a new issue, because the `.tmp` files written during normal updating
 would also be included.  The issue will only become more prevalent.  I'd
 say we adapt the indexer, which can happen in a separate commit.  Or we
 could change temporary files to start with `.`, but that seems a bit more
 error-prone.  Suggestion: '''fix'''

  - As mentioned before somewhere, we're appending server/extra-info
 descriptors to different files in the synchronization run than in the
 earlier update run.  The reason is that `SyncManager` creates its own
 `collectionDate` in the constructor.  However, we cannot just pass a
 `Date` instance to both `SyncManager` and `ArchiveWriter`, because then
 `SyncManager` would append to a file that we're already serving, in which
 case the file size would change once we're done synchronizing, and we
 should try to avoid that.  Let's fix this as soon as the current updaters
 are modules just like the synchronization module, and let's keep in mind
 not to close and rename temporary files to their final names between
 modules.  Suggestion: '''postpone'''

  - As said earlier, let's release metrics-lib and use that new release as
 basis for this patch.  Then we won't have to import and instantiate
 `org.torproject.descriptor.index.DescriptorIndexCollector` anymore, and we
 can change defaults for the `*SyncOrigins` properties in
 `collector.properties` back to `https://collector.torproject.org`.
 Suggestion: '''change'''

  - Regarding comment 25 above, I'm still a fan of using `printf` as
 opposed to creating `SimpleDateFormat` instances and concatenating
 strings.  I also believe it would be more efficient.  But I'm happy to
 postpone that change.  Suggestion: '''postpone'''

--
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] #20404 [Metrics/metrics-lib]: DescriptorIndexCollector should be default implementation

2016-10-19 Thread Tor Bug Tracker & Wiki

#20404: DescriptorIndexCollector should be default implementation
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  assigned => needs_review
 * priority:  Medium => High


Comment:

 Please review [https://gitweb.torproject.org/user/iwakeh/metrics-
 
lib.git/commit/?h=task-20404-for-1.4.1=2aa8593eba68b6b91abd4197c1456edc74b740ee
 the change].

--
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] #20334 [Metrics/metrics-lib]: explicitly log, which implementation is served by DescriptorSourceFactory

2016-10-19 Thread Tor Bug Tracker & Wiki

#20334: explicitly log, which implementation is served by 
DescriptorSourceFactory
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  assigned => needs_review
 * priority:  Medium => High


Comment:

 Please review [https://gitweb.torproject.org/user/iwakeh/metrics-
 
lib.git/commit/?h=task-20334-for-1.4.1=edf4e880b249098ee29c4846d80afef482be8135
 this 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] #20039 [Metrics/metrics-lib]: integrate `DescriptorIndexCollector` in a fully backward-compatible way

2016-10-19 Thread Tor Bug Tracker & Wiki

#20039: integrate `DescriptorIndexCollector` in a fully backward-compatible way
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * priority:  Medium => High
 * status:  assigned => needs_review


Comment:

 set to high.

--
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] #20039 [Metrics/metrics-lib]: integrate `DescriptorIndexCollector` in a fully backward-compatible way

2016-10-19 Thread Tor Bug Tracker & Wiki

#20039: integrate `DescriptorIndexCollector` in a fully backward-compatible way
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Please review the two commits on this
 [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/?h=task-20039-for-1.4.1 branch].  The first commit is just adding
 unused-imports-check to checkstyle.

--
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] #20405 [Metrics/metrics-lib]: create metrics-tools with all of the index.json processing code as first content (was: all of the index.json processing code should be in metrics-lib)

2016-10-19 Thread Tor Bug Tracker & Wiki

#20405: create metrics-tools with all of the index.json processing code as first
content
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.5.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Actually, as was discussed a while ago:

 There should be another lib, `metrics-tools` (working title), that
 contains functionality on one hand needed by Metrics products and on the
 other hand not really in scope of any product.

 The index-json functionality qualifies for being provided by metrics-tools
 as both CollecTor and metrics-lib depend on it, but is out of scope for
 either one.  And, this would shield the actual json-processing lib used,
 e.g. a switch from gson to something better would be easier in future.

 Changing the title to reflect the topic drift.

--
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] #20394 [Applications/Tor Browser]: Remove dead code in torbutton

2016-10-19 Thread Tor Bug Tracker & Wiki

#20394: Remove dead code in torbutton
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-code-cleanup,|  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Oh, and a bug number in your commit message would be good. (although I am
 usually fixing this if it's missing ;) )

--
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] #20394 [Applications/Tor Browser]: Remove dead code in torbutton

2016-10-19 Thread Tor Bug Tracker & Wiki

#20394: Remove dead code in torbutton
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-code-cleanup,|  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-code-cleanup, TorBrowserTeam201610R => tbb-code-cleanup,
 TorBrowserTeam201610
 * status:  needs_review => needs_revision


Comment:

 Two things:

 1) What about the `contents.rdf` file in `chrome/skin`?
 2) There is not `P0` anymore in `torbutton.js` after your clean-up, right?
 We should change comment on the first line accordingly then: s/P0/P1/

--
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] #20399 [Applications/Tor Browser]: browser.display.max_font_* prefs are obsolete

2016-10-19 Thread Tor Bug Tracker & Wiki

#20399: browser.display.max_font_* prefs are obsolete
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-code-cleanup,|  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 This looks good to me and I applied the fixes to torbutton master (commit
 2d88aa4d7239c3d386c69396c8d0d40ddd23a952) and tor-browser-45.4.0esr-6.5-1
 (commit 62d6468cedbdd1ae08b1e4a7192184c3aa92137c).

--
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] #19934 [Metrics/CollecTor]: CollecTor should use new metrics-lib json classes

2016-10-19 Thread Tor Bug Tracker & Wiki

#19934: CollecTor should use new metrics-lib json classes
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * status:  needs_review => assigned


Comment:

 Maybe change this based on #20405.
 Set to assigned until #20405 is finished.

--
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] #13714 [Applications/Tor Browser]: Replace startpage.com with duckduckgo (startpage is hostile tor Tor users)

2016-10-19 Thread Tor Bug Tracker & Wiki

#13714: Replace startpage.com with duckduckgo (startpage is hostile tor Tor 
users)
--+--
 Reporter:  duS3u_uus9usu |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * status:  new => closed
 * version:  Tor: 0.2.6.1-alpha =>
 * resolution:   => fixed
 * severity:   => Normal


Comment:

 Startpage is no longer the default search engine.

--
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] #20405 [Metrics/metrics-lib]: all of the index.json processing code should be in metrics-lib

2016-10-19 Thread Tor Bug Tracker & Wiki

#20405: all of the index.json processing code should be in metrics-lib
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.5.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 cf. #20039 and #19934

 Any better ideas to resolve this issue?

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #20334, #20404

2016-10-19 Thread Tor Bug Tracker & Wiki

Batch modification to #20334, #20404 by iwakeh:


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] #20039 [Metrics/metrics-lib]: integrate `DescriptorIndexCollector` in a fully backward-compatible way

2016-10-19 Thread Tor Bug Tracker & Wiki

#20039: integrate `DescriptorIndexCollector` in a fully backward-compatible way
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_review => assigned
 * milestone:  metrics-lib 1.5.0 => metrics-lib 1.4.1


Comment:

 I'll add the appropriate changes to the branch from comment:3, i.e. when
 there is only a base url download from `/index/index.json`.

--
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] #20398 [Internal Services/Service - trac]: troodi used instead of trac in bug tracker URLs

2016-10-19 Thread Tor Bug Tracker & Wiki

#20398: troodi used instead of trac in bug tracker URLs
--+---
 Reporter:  teor  |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

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


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

Re: [tor-bugs] #19459 [Applications/Tor Browser]: Write (C++) patch for window resizing parts

2016-10-19 Thread Tor Bug Tracker & Wiki

#19459: Write (C++) patch for window resizing parts
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton-conversion,|  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by bugzilla):

 How about to make the window properly sized (keep the proper size) after
 adding/removing toolbars?

--
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] #20388 [Applications/Tor Browser]: Consolidate prefs usage in torbutton.js

2016-10-19 Thread Tor Bug Tracker & Wiki

#20388: Consolidate prefs usage in torbutton.js
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  tbb-code-cleanup,|  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by bugzilla):

 Replying to [comment:6 arthuredelstein]:
 > I would like to keep a new issue such as this one in a separate ticket
 so we don't lose it.
 OK, so you mean that TBB Team prefer anybody filing a new ticket for even
 minor inconsistencies, so that it'll look like a Q & A site with separate
 discussion for every question. Right?
 > That being said, all "lastUpdate" prefs on my TBB are in units of
 seconds, either rounded or not. What is unusual is that this is a string
 pref instead of an integer pref, but I don't think that is a problem.
 Mozilla obviously uses string prefs for reals and big integers. And your
 pref is a string, so it points to it is expected to be a big int, perhaps,
 for milliseconds.

--
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] #20334 [Metrics/metrics-lib]: explicitly log, which implementation is served by DescriptorSourceFactory

2016-10-19 Thread Tor Bug Tracker & Wiki

#20334: explicitly log, which implementation is served by 
DescriptorSourceFactory
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.4.1
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * milestone:  metrics-lib 1.5.0 => metrics-lib 1.4.1


Comment:

 As we're changing the default in this milestone the logging should be
 added too.

--
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] #20395 [Metrics/metrics-lib]: metrics-lib should be able to handle large descriptor files

2016-10-19 Thread Tor Bug Tracker & Wiki

#20395: metrics-lib should be able to handle large descriptor files
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.5.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * milestone:   => metrics-lib 1.5.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] #20395 [Metrics/metrics-lib]: metrics-lib should be able to handle large descriptor files

2016-10-19 Thread Tor Bug Tracker & Wiki

#20395: metrics-lib should be able to handle large descriptor files
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by iwakeh):

 One remedy for the out-of-memory would be using
 [https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileChannel.html
 FileChannel]s for reading descriptor files.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-19 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 metrics-lib 1.4.1 sounds good, I just created a milestone for that.
 Thanks!

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

Re: [tor-bugs] #20379 [Applications/Tor Browser]: Can't initially connect to bridges after new network connection

2016-10-19 Thread Tor Bug Tracker & Wiki

#20379: Can't initially connect to bridges after new network connection
--+--
 Reporter:  qbi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by qbi):

 I'll bisect the problem and report back.

--
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] #20379 [Applications/Tor Browser]: Can't initially connect to bridges after new network connection

2016-10-19 Thread Tor Bug Tracker & Wiki

#20379: Can't initially connect to bridges after new network connection
--+--
 Reporter:  qbi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Thanks for looking into it. It seems we can put 1. and 2. on the
 backburner for now (and maybe have different tickets for them).

 6.5a1 is the first alpha that uses 0.2.8.3-alpha, the previous one was on
 0.2.8.2-alpha. Do you think you can bisect the problem? Replacing `tor` in
 `Browser/TorBrowser/Tor` with the respective one you compiled should do
 the trick. Before you start doing that, though, you could make sure
 whether 0.2.8.3-alpa is really the culprit here by copying `tor` from
 6.5a1 over to a 6.0a5 bundle.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-19 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Yes, a release would be great!
 All three changes you name are important for CollecTor 1.1.0.

 Should it be metrics-lib 1.4.1?
 We need a new milestone for tracking the release.

 I'll look again, but I think these are the most relevant for now.  And,
 it's better to keep the release small in order to have it out quickly.

--
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] #20398 [Internal Services/Service - trac]: troodi used instead of trac in bug tracker URLs

2016-10-19 Thread Tor Bug Tracker & Wiki

#20398: troodi used instead of trac in bug tracker URLs
--+-
 Reporter:  teor  |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 This seems like a duplicate of #19874.

--
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

91 matches

Mail list logo