Re: [tor-bugs] #20965 [Applications/Tor Browser]: Unable to update Tor Browser

[Tor Bug Tracker & Wiki]

#20965: Unable to update Tor Browser
--+--
 Reporter:  Stockton Joe  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 I think the way to update Tor Browser in Tails is to get a new Tails. They
 release a new version with every Tor Browser update (in case the latter
 contains fixes for critical vulnerabilities).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20479 [Applications/Tor Browser]: make closing and restart of Tor Browser as good as New Identity

[Tor Bug Tracker & Wiki]

#20479: make closing and restart of Tor Browser as good as New Identity
--+--
 Reporter:  adrelanos |  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 yawning):

 {{{
   circuit_mark_all_dirty_circs_as_unusable(); // <- The nonce stuff is
 equivalent to that.
   addressmap_clear_transient();
   rend_client_purge_state();
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20479 [Applications/Tor Browser]: make closing and restart of Tor Browser as good as New Identity

[Tor Bug Tracker & Wiki]

#20479: make closing and restart of Tor Browser as good as New Identity
--+--
 Reporter:  adrelanos |  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 cypherpunks):

 It looks like #19206 to use nonces for the SOCKS password was done several
 months ago. Is there any work to be done here?

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

Re: [tor-bugs] #20825 [Core Tor/Tor]: User-named guard selections

[Tor Bug Tracker & Wiki]

#20825: User-named guard selections
--+--
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:  #20822| Points:
 Reviewer:|Sponsor:
--+--

Comment (by chelseakomlo):

 It would be nice to do user testing for this, as it seems like quite a
 "power user" feature.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20763 [Metrics/Consensus Health]: Add shared random to consensus health

[Tor Bug Tracker & Wiki]

#20763: Add shared random to consensus health
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by tom):

 My plan is to implement #20917, #20763, and #20762 (and trial #20403) in
 January, but I won't be able to do it before then.

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

Re: [tor-bugs] #20813 [Obfuscation/Snowflake]: Start producing snowflakes

[Tor Bug Tracker & Wiki]

#20813: Start producing snowflakes
---+-
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by arlolra):

 Thanks saint!  As I said on GitHub, let me know how I can help.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20893 [Core Tor/Tor]: Add a fuzzing harness for the Tor directory protocol

[Tor Bug Tracker & Wiki]

#20893: Add a fuzzing harness for the Tor directory protocol
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fuzz  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by teor):

 (And yes, the approach looks sensible. 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] #20893 [Core Tor/Tor]: Add a fuzzing harness for the Tor directory protocol

[Tor Bug Tracker & Wiki]

#20893: Add a fuzzing harness for the Tor directory protocol
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fuzz  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Also see a few extra commits on my `fuzz-dir-extras` branch.
 We might want to keep the test cases separate, as the directory entry
 point expects HTTP headers.

 Let me know when you think the branch is ready for testing, and I will
 deploy it on a 20 core machine I have access to.

 (It would be nice to have a valid HTTP request for each descriptor GET and
 POST, and then we could strip out the descriptor content for the
 descriptor entry point. I'm thinking relay, bridge, HSDir, etc. Perhaps
 adding debug logging then running one of the comprehensive chutney
 networks would be the way to go here.)

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

Re: [tor-bugs] #20763 [Metrics/Consensus Health]: Add shared random to consensus health

[Tor Bug Tracker & Wiki]

#20763: Add shared random to consensus health
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by atagar):

 s/now/five months ago

 This isn't a new change. I added shared randomness parsing
 
[https://gitweb.torproject.org/stem.git/commit/?id=bccda333d40ba6a17131725475f9fdb025c4690a
 soon as it was added to the spec].

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20763 [Metrics/Consensus Health]: Add shared random to consensus health

[Tor Bug Tracker & Wiki]

#20763: Add shared random to consensus health
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 stem has shared random support now, so #20789 is no longer a blocker.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17469 [Applications/Tor Messenger]: Tor Messenger is not working on Windows XP

[Tor Bug Tracker & Wiki]

#17469: Tor Messenger is not working on Windows XP
+---
 Reporter:  gk  |  Owner:  boklm
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by arlolra):

 XP / Vista will be EOL after ESR 52
 https://bugzilla.mozilla.org/show_bug.cgi?id=1305453

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20966 [Core Tor/Tor]: Parts of deployed shared random protocol are specified only in the proposal

[Tor Bug Tracker & Wiki]

#20966: Parts of deployed shared random protocol are specified only in the 
proposal
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  SponsoR
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 In dir-spec.txt, commit c4ae4dd31 gave us lines like
 {{{
 +Denotes a directory authority commit for the shared randomness
 +protocol, containing the commitment value and potentially also
 the
 +reveal value. See sections [COMMITREVEAL] and [VALIDATEVALUES] of
 +proposal 250 on how to generate and validate these values.
 }}}

 That's a great improvement over just leaving it implicit. But if we have a
 goal of having Tor specified in the spec files (is that true?), then we
 should migrate the key sections from the proposal file to either dir-spec
 or a new srv-spec file.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20965 [Applications/Tor Browser]: Unable to update Tor Browser

[Tor Bug Tracker & Wiki]

#20965: Unable to update Tor Browser
--+--
 Reporter:  Stockton Joe  |  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:
--+--
Changes (by arma):

 * owner:   => tbb-team
 * component:  Applications => Applications/Tor Browser


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

[tor-bugs] #20965 [Applications]: Unable to update Tor Browser

[Tor Bug Tracker & Wiki]

#20965: Unable to update Tor Browser
--+-
 Reporter:  Stockton Joe  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Am unable to update Tor Browser from 6.0.7 to 6.0.8 from within Tails 2.7
 When I download 6.0.8 and try to run it within Tails, I get an error
 message "Cannot connect to Tor Control Port."

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19925 [Core Tor/Tor]: sr: Control event to get the shared random values

[Tor Bug Tracker & Wiki]

#19925: sr: Control event to get the shared random values
+--
 Reporter:  dgoulet |  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  sr, dirauth, control, spec  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:  SponsorR-must
+--

Comment (by arma):

 Same ticket as #17436?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20823 [Core Tor/Tor]: [controller, prop271] GETINFO support for new guard selection logic

[Tor Bug Tracker & Wiki]

#20823: [controller, prop271] GETINFO support for new guard selection logic
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard regression |  Actual Points:  .1 so
  TorCoreTeam201612  |  far
Parent ID:  #20822   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by chelseakomlo):

 * status:  needs_review => needs_revision


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20823 [Core Tor/Tor]: [controller, prop271] GETINFO support for new guard selection logic

[Tor Bug Tracker & Wiki]

#20823: [controller, prop271] GETINFO support for new guard selection logic
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard regression |  Actual Points:  .1 so
  TorCoreTeam201612  |  far
Parent ID:  #20822   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by chelseakomlo):

 Hey,

 This is a small patch, overall it looks good!

 I do get a test failure when I run `make test`:

 {{{
 entrynodes/retry_unreachable: [forking]
   FAIL src/test/test_entrynodes.c:2302: assert(g1->is_reachable OP_EQ
 GUARD_REACHABLE_NO): 2 vs 0
   [retry_unreachable FAILED]

 }}}

 as well as a bug assertion:

 {{{
 dir/purpose_needs_anonymity_returns_true_by_default: Dec 13 20:52:30.319
 [warn] purpose_needs_anonymity(): Bug: Called with dir_purpose=0,
 router_purp
 ose=0 (on Tor 0.3.0.0-alpha-dev 7a7240716eef1f54)
 OK
 }}}

 Not sure if you get these as well? I don't see these on master.

 One point about how we switch on whether we are running the legacy or
 post-271 algorithm.

 If you define two functions- one for the legacy behavior and one for the
 post-271 behavior, then when you remove the legacy algorithm, you won't
 need to change the post-271 method signature or implementation when you
 remove support for legacy in the future.

 So it could look something like:
 {{{
 STATIC char *
 legacy_getinfo_helper_format_single_entry_guard(const entry_guard_t *e)

 STATIC char *
 getinfo_helper_format_single_entry_guard(const entry_guard_t *e)
 }}}

 for the method signatures. The caller would then look like:

 {{{
 SMARTLIST_FOREACH_BEGIN(guards, const entry_guard_t *, e) {
   char *cp;
   #ifdef ENABLE_LEGACY_GUARD_ALGORITHM
 cp = legacy_getinfo_helper_format_single_entry_guard(e);
   #else
 cp = getinfo_helper_format_single_entry_guard(e);
   #endif
   smartlist_add(sl, cp);
 } SMARTLIST_FOREACH_END(e);
 }}}

 Again, this is minor and it might be less work to leave this as is.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20964 [Core Tor/Tor]: Clarify a comment in compute_frac_paths_available

[Tor Bug Tracker & Wiki]

#20964: Clarify a comment in compute_frac_paths_available
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  doc   |  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged!

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

Re: [tor-bugs] #20893 [Core Tor/Tor]: Add a fuzzing harness for the Tor directory protocol

[Tor Bug Tracker & Wiki]

#20893: Add a fuzzing harness for the Tor directory protocol
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fuzz  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 My `combined-fuzzing` branch is a work in progress at getting both fuzzers
 into a single 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] #20831 [Core Tor/Tor]: Support existing guard torrc options better with new guard code, or deprecate them.

[Tor Bug Tracker & Wiki]

#20831: Support existing guard torrc options better with new guard code, or
deprecate them.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard regression |  Actual Points:  .2
  TorCoreTeam201612  |
Parent ID:  #20822   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:7 nickm]:
 > >I'm not 100% persuaded that NumDirectoryGuards==3 actually offers much
 security, if the top primary guard is malicious. I remember the argument
 about malicious directory guards refusing to serve relay descriptors, but
 I kinda feel that we are screwed anyway if the top primary guard is evil
 since all circuits are going to go through it anyhow.
 >
 > Right.  My rationale here was more strongly influenced by one of the
 comments on #20909 or its kin about how having 3 directory guards
 prevented #20499 from causing major chaos on the network.
 >

 Hmm, interesting. In this case wouldn't it be ideal if Tor consulted the
 second primary guard, if and only if the first primary guard delivered
 expired/corrupted information? Instead of always picking at random between
 the top 3 guards?

 Because with the current patch we end up exposing ourselves to 3 primary
 guards anyhow even if the first primary guard is totally innocent.

 Are we afraid that implementing the above logic would be too much
 engineering time?

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

Re: [tor-bugs] #20831 [Core Tor/Tor]: Support existing guard torrc options better with new guard code, or deprecate them.

[Tor Bug Tracker & Wiki]

#20831: Support existing guard torrc options better with new guard code, or
deprecate them.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard regression |  Actual Points:  .2
  TorCoreTeam201612  |
Parent ID:  #20822   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I agree, it's important to have more than one directory guard for
 performance and reliability reasons. Security is secondary here.

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

Re: [tor-bugs] #20964 [Core Tor/Tor]: Clarify a comment in compute_frac_paths_available

[Tor Bug Tracker & Wiki]

#20964: Clarify a comment in compute_frac_paths_available
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  doc   |  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
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] #20963 [Core Tor/Tor]: [notice] The Tor Directory Consensus has changed how many circuits we must track to detect network failures from 0 to 20.

[Tor Bug Tracker & Wiki]

#20963: [notice] The Tor Directory Consensus has changed how many circuits we 
must
track to detect network failures from 0 to 20.
---+---
 Reporter:  arma   |  Owner:
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.8.9
 Severity:  Normal | Resolution:
 Keywords:  028-backport 029-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  new => needs_information


Comment:

 I think this is as designed:

 I bet you encountered condition 4 when you ran out of disk space:
 {{{
 /**
  * This function decides if CBT learning should be disabled. It returns
  * true if one or more of the following conditions are met:
  *
  *  1. If the cbtdisabled consensus parameter is set.
  *  2. If the torrc option LearnCircuitBuildTimeout is false.
  *  3. If we are a directory authority
  *  4. If we fail to write circuit build time history to our state file.
  *  5. If we are compiled or configured in Tor2web mode
  *  6. If we are configured in Single Onion mode
  */
 int
 circuit_build_times_disabled(void)
 }}}

 Which then led to:
 {{{
   if (!circuit_build_times_disabled()) {
 ...
   } else {
 /*
  * Adaptive timeouts are disabled; this might be because of the
  * LearnCircuitBuildTimes config parameter, and hence permanent, or
  * the cbtdisabled consensus parameter, so it may be a new condition.
  * Treat it like getting num == 0 above and free the circuit history
  * if we have any.
  */

 circuit_build_times_free_timeouts(cbt);
   }
 }}}

 Which then led to:
 {{{
 /**
  * Free the saved timeouts, if the cbtdisabled consensus parameter got
 turned
  * on or something.
  */

 void
 circuit_build_times_free_timeouts(circuit_build_times_t *cbt)
 {
   if (!cbt) return;

   if (cbt->liveness.timeouts_after_firsthop) {
 tor_free(cbt->liveness.timeouts_after_firsthop);
   }

   cbt->liveness.num_recent_circs = 0;
 }
 }}}

 And then the next time you loaded a consensus, that 0 was used as the
 value.

 So I can't see how we'd fix that, but we could make the error message
 better.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20893 [Core Tor/Tor]: Add a fuzzing harness for the Tor directory protocol

[Tor Bug Tracker & Wiki]

#20893: Add a fuzzing harness for the Tor directory protocol
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fuzz  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 I'm working on merging teor's harness with my harness for a combined
 harness.  Thanks here!

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

Re: [tor-bugs] #20893 [Core Tor/Tor]: Add a fuzzing harness for the Tor directory protocol

[Tor Bug Tracker & Wiki]

#20893: Add a fuzzing harness for the Tor directory protocol
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fuzz  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_revision


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20960 [Core Tor/Tor]: Extend sybil-detection to authorities as well

[Tor Bug Tracker & Wiki]

#20960: Extend sybil-detection to authorities as well
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 If it affects the test network, would it suffice to raise the limit for
 _all_ IPs on the test network, with the non-removed
 "AuthDirMaxServersPerAddr" option?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20960 [Core Tor/Tor]: Extend sybil-detection to authorities as well

[Tor Bug Tracker & Wiki]

#20960: Extend sybil-detection to authorities as well
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 (This might affect the tor test network, I have emailed the list.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20964 [Core Tor/Tor]: Clarify a comment in compute_frac_paths_available

[Tor Bug Tracker & Wiki]

#20964: Clarify a comment in compute_frac_paths_available
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  doc   |  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_review


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

[tor-bugs] #20964 [Core Tor/Tor]: Clarify a comment in compute_frac_paths_available

[Tor Bug Tracker & Wiki]

#20964: Clarify a comment in compute_frac_paths_available
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  doc
Actual Points:  0.1   |  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 Please see my github branch fix-frac-paths-comment.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20893 [Core Tor/Tor]: Add a fuzzing harness for the Tor directory protocol

[Tor Bug Tracker & Wiki]

#20893: Add a fuzzing harness for the Tor directory protocol
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fuzz  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_revision => needs_review
 * milestone:  Tor: 0.3.??? => Tor: 0.3.0.x-final


Comment:

 I have pushed a fuzz-dir-v2 branch to my github.

 Putting this in 0.3.0 so we can get it into master for the google fuzzer.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20336 [Applications/Tor Browser]: dmg background not showing on macOS Sierra

[Tor Bug Tracker & Wiki]

#20336: dmg background not showing on macOS Sierra
--+--
 Reporter:  arlolra   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arlolra):

 * status:  new => closed
 * cc: sukhbir (added)
 * resolution:   => invalid


Comment:

 This seems to have resolved itself in macOS 10.12.2

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

Re: [tor-bugs] #20960 [Core Tor/Tor]: Extend sybil-detection to authorities as well

[Tor Bug Tracker & Wiki]

#20960: Extend sybil-detection to authorities as well
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|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] #20963 [Core Tor/Tor]: [notice] The Tor Directory Consensus has changed how many circuits we must track to detect network failures from 0 to 20.

[Tor Bug Tracker & Wiki]

#20963: [notice] The Tor Directory Consensus has changed how many circuits we 
must
track to detect network failures from 0 to 20.
---+---
 Reporter:  arma   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.8.9
 Severity:  Normal | Resolution:
 Keywords:  028-backport 029-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:   => 028-backport 029-backport
 * milestone:   => Tor: 0.3.0.x-final


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

Re: [tor-bugs] #6359 [Applications/TorBirdy]: make use of stream isolation

[Tor Bug Tracker & Wiki]

#6359: make use of stream isolation
---+-
 Reporter:  proper |  Owner:  ioerror
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by JeremyRand):

 * cc: jeremy@… (added)


Comment:

 Replying to [comment:9 lunar]:
 > Tor Browser now uses SOCKS username/password to use different circuits
 for each domain. Does Thunderbird now support using SOCKS username
 password as well? Would it be complicated to get a different circuit for
 each account now that it's a reality?
 >
 > One corner case to be aware of is POP before SMTP. I don't know if these
 kind of setups are still in use, but they were popular at some point. It
 would probably be best if the same circuit can be used in such a case, as
 I believe some implementation would ensure that the same IP is in use for
 both POP and subsequent SMTP. This is still a minor use case and should
 not block getting proper isolation between accounts.
 >
 > Thanks!

 Yes, Thunderbird supports SOCKS authentication now.  The Tor Browser patch
 against Firefox to support SOCKS authentication was upstreamed to Mozilla
 in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1200802 ; it was
 merged by Mozilla on 2015 Nov 26.

 As far as I can tell, Icedove in Debian Jessie includes this support, see
 
https://sources.debian.net/src/icedove/1:45.2.0-1~deb8u1/mozilla/netwerk/base/nsIProxyInfo.idl/#L53
 .

 So as far as I can tell, it should be straightforward to use this in
 TorBirdy -- use the standard Mozilla hooks for setting proxy settings per
 connection (I assume these API's are identical between Firefox and
 Thunderbird), and set the "username" and "password" fields of the
 nsProxyInfo instance that you generate to whatever you want them to be.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20963 [Core Tor/Tor]: [notice] The Tor Directory Consensus has changed how many circuits we must track to detect network failures from 0 to 20.

[Tor Bug Tracker & Wiki]

#20963: [notice] The Tor Directory Consensus has changed how many circuits we 
must
track to detect network failures from 0 to 20.
--+--
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Running Tor 0.2.8.9 under Yawning's sandboxed-tor-browser, I got this
 strange log message:
 {{{
 2016/12/13 15:48:04 tor: Dec 13 20:48:04.000 [notice] The Tor Directory
 Consensus has changed how many circuits we must track to detect network
 failures from 0 to 20.
 }}}

 I haven't seen it before. Also, my system ran out of disk space for a
 while before this notice came up.

 A) I don't think the consensus changed its parameter here, so it's weird
 that my Tor thinks it did. 20 is the default:
 {{{
 or.h:#define CBT_DEFAULT_RECENT_CIRCUITS 20
 }}}
 So where did 0 come from?

 B) If "A" remains a mystery, we should make sure there isn't some
 underlying bug where for example Tor starts ignoring things in the
 consensus after an event like
 {{{
 2016/12/13 13:48:04 tor: Dec 13 18:48:04.000 [warn] Error writing to
 "/home/amnesia/tor/data/cached-microdesc-consensus": No space left on
 device
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20962 [Applications/Tor Browser Sandbox]: Remove support for the alpha/hardened channels?

[Tor Bug Tracker & Wiki]

#20962: Remove support for the alpha/hardened channels?
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 Ah gotcha.  I'm still a bit worried that, the next alpha series will break
 things.

 The fundamental concern I have is that the sandbox has lots of special
 casing and hand tuned things that need continuous updating as the upstream
 code changes like the seccomp-bpf whitelist, and the libraries/data files
 that are included in the container.  While it is probably manageable to
 maintain long term for say... release, anytime something major changes
 (like a new alpha series), I expect breakage that will take development
 time to resolve.

 If we are to support using "good" sandboxing in the long run, how to
 handle such transitions needs to be factored into the development plan
 (along with the currently open question of "how to keep the sandbox code
 up to date").

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20962 [Applications/Tor Browser Sandbox]: Remove support for the alpha/hardened channels?

[Tor Bug Tracker & Wiki]

#20962: Remove support for the alpha/hardened channels?
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by gk):

 Replying to [ticket:20962 yawning]:
 > Eg: 7.0a1 will be ESR52 based, and likely result in everything breaking.
 Going from 6.5 release to 7.0 release would be fine because I would have
 the entire 7.0 alpha period to work out bugs.

 7.0a1 won't be based on ESR52 yet. I think the earliest alpha where we
 will be able to include ESR52 is the one due when ESR52 gets released
 (which is supposed to happen at the begin of March 2017). Even that would
 be a novum, though. (we were not that early in the past)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20960 [Core Tor/Tor]: Extend sybil-detection to authorities as well

[Tor Bug Tracker & Wiki]

#20960: Extend sybil-detection to authorities as well
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * status:  needs_review => merge_ready


Comment:

 Looks good!

 (I didn't try compiling, so be sure to do that before merging. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20941 [Applications/Tor Browser]: Tor browser will resize it self after the dock is enabled and the browser is dragged to a new location

[Tor Bug Tracker & Wiki]

#20941: Tor browser will resize it self after the dock is enabled and the 
browser
is dragged to a new location
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-fingerprinting-resolution,   |  Actual Points:
  TorBrowserTeam201612   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: brade, mcs (added)


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

Re: [tor-bugs] #20440 [Metrics/metrics-lib]: endless wait in BlockingIteratorImpl

[Tor Bug Tracker & Wiki]

#20440: endless wait in BlockingIteratorImpl
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  new => assigned
 * owner:  karsten => iwakeh


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20521 [Metrics/metrics-lib]: Deprecate `DescriptorReader.setExcludeFiles()` and add two separate methods for loading and saving a history file

[Tor Bug Tracker & Wiki]

#20521: Deprecate `DescriptorReader.setExcludeFiles()` and add two separate 
methods
for loading and saving a history file
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Looks fine.

 I added another test and cure for a corrupt history file.
 Please see [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-20521-3=e02132ee0903994ec0702144ebd76cb425fb04cc
 my branch task-20521-3].

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10947 [Applications/Tor Messenger]: Instantbird documentation

[Tor Bug Tracker & Wiki]

#10947: Instantbird documentation
+-
 Reporter:  sukhbir |  Owner:
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10947 [Applications/Tor Messenger]: Instantbird documentation

[Tor Bug Tracker & Wiki]

#10947: Instantbird documentation
+--
 Reporter:  sukhbir |  Owner:
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>
 * severity:   => Normal


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13743 [Applications/Tor Messenger]: Size of Tor Messenger (and Instantbird) bundles

[Tor Bug Tracker & Wiki]

#13743: Size of Tor Messenger (and Instantbird) bundles
+--
 Reporter:  sukhbir |  Owner:
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>
 * severity:   => Normal


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10950 [Applications/Tor Messenger]: Share tor process with Tor Browser

[Tor Bug Tracker & Wiki]

#10950: Share tor process with Tor Browser
+-
 Reporter:  sukhbir |  Owner:
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10950 [Applications/Tor Messenger]: Share tor process with Tor Browser

[Tor Bug Tracker & Wiki]

#10950: Share tor process with Tor Browser
+--
 Reporter:  sukhbir |  Owner:
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13743 [Applications/Tor Messenger]: Size of Tor Messenger (and Instantbird) bundles

[Tor Bug Tracker & Wiki]

#13743: Size of Tor Messenger (and Instantbird) bundles
+-
 Reporter:  sukhbir |  Owner:
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17421 [Applications/Tor Messenger]: My task bar says "instantbird" for tor messenger

[Tor Bug Tracker & Wiki]

#17421: My task bar says "instantbird" for tor messenger
+-
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20826 [Core Tor/Tor]: Restrict GUARDS set to EntryNodes when the set of guards is restrictive

[Tor Bug Tracker & Wiki]

#20826: Restrict GUARDS set to EntryNodes when the set of guards is restrictive
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard regression |  Actual Points:  .1
  TorCoreTeam201612  |
Parent ID:  #20822   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 new comment lgtm. i think we can proceed with this.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20920 [Core Tor/Tor]: Lower MAX_SAMPLE_THRESHOLD by a lot

[Tor Bug Tracker & Wiki]

#20920: Lower MAX_SAMPLE_THRESHOLD by a lot
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #19877| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Hmm I can see how that makes sense. However, if we are trying to provide
 security for such tiny networks (30 nodes) we would probably have to
 change the rest of our guard picking strategy quite a bit as well.

 Anyhow, no strong opinions here and the code seems reasonable.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10945 [Applications/Tor Messenger]: Instantbird translations

[Tor Bug Tracker & Wiki]

#10945: Instantbird translations
+-
 Reporter:  sukhbir |  Owner:
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10945 [Applications/Tor Messenger]: Instantbird translations

[Tor Bug Tracker & Wiki]

#10945: Instantbird translations
+--
 Reporter:  sukhbir |  Owner:
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10944 [Applications/Tor Messenger]: Audit Instantbird's security

[Tor Bug Tracker & Wiki]

#10944: Audit Instantbird's security
+-
 Reporter:  sukhbir |  Owner:
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10944 [Applications/Tor Messenger]: Audit Instantbird's security

[Tor Bug Tracker & Wiki]

#10944: Audit Instantbird's security
+--
 Reporter:  sukhbir |  Owner:
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>
 * severity:   => Normal


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20831 [Core Tor/Tor]: Support existing guard torrc options better with new guard code, or deprecate them.

[Tor Bug Tracker & Wiki]

#20831: Support existing guard torrc options better with new guard code, or
deprecate them.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard regression |  Actual Points:  .2
  TorCoreTeam201612  |
Parent ID:  #20822   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 >I'm not 100% persuaded that NumDirectoryGuards==3 actually offers much
 security, if the top primary guard is malicious. I remember the argument
 about malicious directory guards refusing to serve relay descriptors, but
 I kinda feel that we are screwed anyway if the top primary guard is evil
 since all circuits are going to go through it anyhow.

 Right.  My rationale here was more strongly influenced by one of the
 comments on #20909 or its kin about how having 3 directory guards
 prevented #20499 from causing major chaos on the network.

 >Also, the patch only supports multiple entry guards when it comes to
 primary guards, and does not try to generalize the logic to the other
 guard picking cases.

 The choice that multiple entry guards only applies to primary guards was
 intentional, since if we're ever prevented from using all our primary
 guards, we want to be cautious about using more guards.

 >A spec patch is definitely useful for this.

 Can do, once we decide we should do something like this.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17485 [Applications/Tor Messenger]: Tor Messenger exits immediatly when clicking on the Menu

[Tor Bug Tracker & Wiki]

#17485: Tor Messenger exits immediatly when clicking on the Menu
+-
 Reporter:  torland |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17510 [Applications/Tor Messenger]: Store aliases locally

[Tor Bug Tracker & Wiki]

#17510: Store aliases locally
+-
 Reporter:  cypherpunks |  Owner:
 Type:  enhancement | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17510 [Applications/Tor Messenger]: Store aliases locally

[Tor Bug Tracker & Wiki]

#17510: Store aliases locally
+--
 Reporter:  cypherpunks |  Owner:
 Type:  enhancement | Status:  assigned
 Priority:  High|  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17485 [Applications/Tor Messenger]: Tor Messenger exits immediatly when clicking on the Menu

[Tor Bug Tracker & Wiki]

#17485: Tor Messenger exits immediatly when clicking on the Menu
+--
 Reporter:  torland |  Owner:
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17429 [Applications/Tor Messenger]: "So-and-so wants to chat with you; allow?" text is very subtle

[Tor Bug Tracker & Wiki]

#17429: "So-and-so wants to chat with you; allow?" text is very subtle
+-
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  UX  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17421 [Applications/Tor Messenger]: My task bar says "instantbird" for tor messenger

[Tor Bug Tracker & Wiki]

#17421: My task bar says "instantbird" for tor messenger
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17429 [Applications/Tor Messenger]: "So-and-so wants to chat with you; allow?" text is very subtle

[Tor Bug Tracker & Wiki]

#17429: "So-and-so wants to chat with you; allow?" text is very subtle
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  UX  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #16526 [Applications/Tor Messenger]: Import Pidgin configuration

[Tor Bug Tracker & Wiki]

#16526: Import Pidgin configuration
+-
 Reporter:  lunar   |  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #16526 [Applications/Tor Messenger]: Import Pidgin configuration

[Tor Bug Tracker & Wiki]

#16526: Import Pidgin configuration
+--
 Reporter:  lunar   |  Owner:
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  arlolra =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #16494 [Applications/Tor Messenger]: Port Tor Button-like functionality

[Tor Bug Tracker & Wiki]

#16494: Port Tor Button-like functionality
+-
 Reporter:  lunar   |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #16494 [Applications/Tor Messenger]: Port Tor Button-like functionality

[Tor Bug Tracker & Wiki]

#16494: Port Tor Button-like functionality
+--
 Reporter:  lunar   |  Owner:
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17517 [Applications/Tor Messenger]: Consider using different color for "Add Exception"

[Tor Bug Tracker & Wiki]

#17517: Consider using different color for "Add Exception"
+--
 Reporter:  ilv |  Owner:  huyvq
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  UX  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by huyvq):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18389 [Applications/Tor Messenger]: Support CAPTCHA-authorization

[Tor Bug Tracker & Wiki]

#18389: Support CAPTCHA-authorization
+-
 Reporter:  WitnessofTruth  |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18389 [Applications/Tor Messenger]: Support CAPTCHA-authorization

[Tor Bug Tracker & Wiki]

#18389: Support CAPTCHA-authorization
+--
 Reporter:  WitnessofTruth  |  Owner:
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17517 [Applications/Tor Messenger]: Consider using different color for "Add Exception"

[Tor Bug Tracker & Wiki]

#17517: Consider using different color for "Add Exception"
+-
 Reporter:  ilv |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  UX  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17517 [Applications/Tor Messenger]: Consider using different color for "Add Exception"

[Tor Bug Tracker & Wiki]

#17517: Consider using different color for "Add Exception"
+--
 Reporter:  ilv |  Owner:
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  UX  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10941 [Applications/Tor Messenger]: Secure messaging window

[Tor Bug Tracker & Wiki]

#10941: Secure messaging window
+-
 Reporter:  sukhbir |  Owner:
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10941 [Applications/Tor Messenger]: Secure messaging window

[Tor Bug Tracker & Wiki]

#10941: Secure messaging window
+--
 Reporter:  sukhbir |  Owner:
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:  sukhbir =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20941 [Applications/Tor Browser]: Tor browser will resize it self after the dock is enabled and the browser is dragged to a new location

[Tor Bug Tracker & Wiki]

#20941: Tor browser will resize it self after the dock is enabled and the 
browser
is dragged to a new location
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-fingerprinting-resolution,   |  Actual Points:
  TorBrowserTeam201612   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 I think this behavior is a result of our #14429 patch (which is only
 active in the alpha). When you disable dock autohiding, macOS apparently
 attempts to resize the window so that it no longer overlaps with the dock.
 Then the 14429 patch responds by resizing again to ensure that the content
 window has rounded dimensions (a multiple of 200 x 100).

 I think this behavior is essentially decreasing the fingerprintability, as
 intended. However, it would be good to check. Dbryrtfbcbhgf, if you could
 run this test again, could you please browse to
 https://jsfiddle.net/rv37t3dz/ and check that the window dimensions are
 correctly rounded after the resizing event?

 An additional wrinkle is that the horizontal size seems to be shrinking. I
 think this is probably the result of macOS shrinking the width by a small
 amount (maybe 1 pixel) and then 14429 responded by shrinking to the next
 lower rounded dimension. We could consider allowing a "rounding up" from
 99 pixels to 100 for situations like this.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20830 [Core Tor/Tor]: Remove legacy guard algorithm code

[Tor Bug Tracker & Wiki]

#20830: Remove legacy guard algorithm code
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:  #20822| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 If it's okay with you, I'd like to do it at-merge, in order to make the
 merge simpler.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20962 [Applications/Tor Browser Sandbox]: Remove support for the alpha/hardened channels?

[Tor Bug Tracker & Wiki]

#20962: Remove support for the alpha/hardened channels?
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 Alternatives:

  * Assuming things go smoothly, if I had a week or two with "this is semi-
 close to what will be shipped", I might be able to get all the changes
 into the agent to keep it happy, as long as people upgrade.

  * I could add a hard coded maxVersion variable or something beyond which
 it nags the user to update the agent, and refuses to update the bundle.
 Annoying, but this would only be an issue on the first release of an alpha
 series (eg: 7.0a1, 7.5a1, 8.0a1 etc etc 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] #20830 [Core Tor/Tor]: Remove legacy guard algorithm code

[Tor Bug Tracker & Wiki]

#20830: Remove legacy guard algorithm code
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:  #20822| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 If we plan to remove the legacy code in two alpha releases of 0.3.0
 anyway, I would not be opposed to removing it sooner (pre-merge), since I
 doubt someone is gonna rely on the legacy algorithm for those two alpha
 releases.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20831 [Core Tor/Tor]: Support existing guard torrc options better with new guard code, or deprecate them.

[Tor Bug Tracker & Wiki]

#20831: Support existing guard torrc options better with new guard code, or
deprecate them.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard regression |  Actual Points:  .2
  TorCoreTeam201612  |
Parent ID:  #20822   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Patch looks plausible, but I'm not entirely sold yet.

 I'm not 100% persuaded that `NumDirectoryGuards==3` actually offers much
 security, if the top primary guard is malicious. I remember the argument
 about malicious directory guards refusing to serve relay descriptors, but
 I kinda feel that we are screwed anyway if the top primary guard is evil
 since all circuits are going to go through it anyhow.

 Also, the patch only supports multiple entry guards when it comes to
 primary guards, and does not try to generalize the logic to the other
 guard picking cases. A spec patch is definitely useful for this.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19043 [Core Tor/Tor]: prop224: Implementation of ESTABLISH_INTRO cell

[Tor Bug Tracker & Wiki]

#19043: prop224: Implementation of ESTABLISH_INTRO cell
-+-
 Reporter:  alec.heif|  Owner:  asn
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 6.s194, |  Actual Points:
  TorCoreTeam201612, review-group-13 |
Parent ID:  #17241   | Points:  6
 Reviewer:  asn, dgoulet |Sponsor:
 |  SponsorR-must
-+-

Comment (by nickm):

 comments posted (to both pull requests).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19043 [Core Tor/Tor]: prop224: Implementation of ESTABLISH_INTRO cell

[Tor Bug Tracker & Wiki]

#19043: prop224: Implementation of ESTABLISH_INTRO cell
-+-
 Reporter:  alec.heif|  Owner:  asn
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 6.s194, |  Actual Points:
  TorCoreTeam201612, review-group-13 |
Parent ID:  #17241   | Points:  6
 Reviewer:  asn, dgoulet |Sponsor:
 |  SponsorR-must
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20826 [Core Tor/Tor]: Restrict GUARDS set to EntryNodes when the set of guards is restrictive

[Tor Bug Tracker & Wiki]

#20826: Restrict GUARDS set to EntryNodes when the set of guards is restrictive
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard regression |  Actual Points:  .1
  TorCoreTeam201612  |
Parent ID:  #20822   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I've added a bit of a comment to the 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] #20828 [Core Tor/Tor]: Should we provide a migration method from the old guard logic to the new one?

[Tor Bug Tracker & Wiki]

#20828: Should we provide a migration method from the old guard logic to the new
one?
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:  #20822| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 I would take a patch, but this seems like too much engineering effort
 right now. I'm also fine with 'no' here.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #20173, #20539, #20877, #20878, ...

[Tor Bug Tracker & Wiki]

Batch modification to #20173, #20539, #20877, #20878, #20880, #20881, #20882, 
#20912, #20914, #20926, #20942, #20945 by nickm:
component to Core Tor/Fallback Scripts
milestone to 

Comment:
Batch-move updateFallbackDirs.py tickets into a new component, and remove them 
from maint-0.3.0.

I'm doing this as a separate component, after discussion with teor, mainly 
because development here seems to be decoupled from development on tor itself: 
they don't need to have the same release schedules, for example.

--
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] #20826 [Core Tor/Tor]: Restrict GUARDS set to EntryNodes when the set of guards is restrictive

[Tor Bug Tracker & Wiki]

#20826: Restrict GUARDS set to EntryNodes when the set of guards is restrictive
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard regression |  Actual Points:  .1
  TorCoreTeam201612  |
Parent ID:  #20822   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Kind of a kludgy fix but I can see why it works! I wonder how we could do
 this more cleanly instead of special-casing restricted mode in that
 function.

 If no obvious better way, perhaps we can add a bit of motivation on the
 new comment?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20962 [Applications/Tor Browser Sandbox]: Remove support for the alpha/hardened channels?

[Tor Bug Tracker & Wiki]

#20962: Remove support for the alpha/hardened channels?
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 I'm not sure how I can stay ahead of major ESR transitions in such a way
 that doesn't result in people updating their bundle and not being able to
 launch Tor Browser in the sandbox.

 Eg: 7.0a1 will be ESR52 based, and likely result in everything breaking.
 Going from 6.5 release to 7.0 release would be fine because I would have
 the entire 7.0 alpha period to work out bugs.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20829 [Core Tor/Tor]: Document state format for prop271 guards

[Tor Bug Tracker & Wiki]

#20829: Document state format for prop271 guards
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-guard, review-group-13  |  Actual Points:
Parent ID:  #19877  | Points:
 Reviewer:  chelseakomlo, asn   |Sponsor:
+--
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Useful and good. Ready to 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] #20920 [Core Tor/Tor]: Lower MAX_SAMPLE_THRESHOLD by a lot

[Tor Bug Tracker & Wiki]

#20920: Lower MAX_SAMPLE_THRESHOLD by a lot
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #19877| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Maybe.  I'm thinking that there are network sizes where the fractional
 restriction matters more -- like on a 30-node network, for instance.  At
 least, that's what I had in mind.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20920 [Core Tor/Tor]: Lower MAX_SAMPLE_THRESHOLD by a lot

[Tor Bug Tracker & Wiki]

#20920: Lower MAX_SAMPLE_THRESHOLD by a lot
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #19877| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 I wonder if the fractional restriction is any useful now that we have the
 absolute restriction. In most cases the absolute restriction will take
 priority over fractional restriction (20% of total guards is like 110
 guards right now).

 I feel like the absolute restriction is more accurate and powerful. Maybe
 we can kill the fractional one to reduce code?

 Perhaps it would make sense to introduce the fractional restriction if it
 was based on guard bandwidth and not just number of guards.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20834 [Core Tor/Tor]: Write patches for all spec-deviations in prop271

[Tor Bug Tracker & Wiki]

#20834: Write patches for all spec-deviations in prop271
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tor-guard, review-group-13  |  Actual Points:
Parent ID:  #19877  | Points:
 Reviewer:  chelseakomlo, asn   |Sponsor:
+--
Changes (by nickm):

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


Comment:

 Merged this to torspec. THank you!

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

Re: [tor-bugs] #20960 [Core Tor/Tor]: Extend sybil-detection to authorities as well

[Tor Bug Tracker & Wiki]

#20960: Extend sybil-detection to authorities as well
--+
 Reporter:  nickm |  Owner:  nickm
 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:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review
 * actualpoints:   => .1


Comment:

 `ticket20960` in my public repository removes AuthDirMaxServersPerAuthAddr
 to implement this 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] #20922 [Core Tor/Tor]: Consider faster retry schedule for primary guards

[Tor Bug Tracker & Wiki]

#20922: Consider faster retry schedule for primary guards
--+
 Reporter:  nickm |  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:  #19877| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 I think this is a good change for the cases where we marked our primaries
 as down while we were offline, and now we are only dealing with confirmed
 guards. This change will make us go back to our primaries much faster.

 That said, this change has performance implications when the top primary
 guards are legitimately down, since we will have to wait about 2 minutes
 for each primary guard connection to timeout every 10 minutes.

 I currently think that this change is worth doing, but I would need to
 test this branch more in real life situations to see if the performance
 penalty is too annoying.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20834 [Core Tor/Tor]: Write patches for all spec-deviations in prop271

[Tor Bug Tracker & Wiki]

#20834: Write patches for all spec-deviations in prop271
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-guard, review-group-13  |  Actual Points:
Parent ID:  #19877  | Points:
 Reviewer:  chelseakomlo, asn   |Sponsor:
+--
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 spec changes look good to me. 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] #20960 [Core Tor/Tor]: Extend sybil-detection to authorities as well

[Tor Bug Tracker & Wiki]

#20960: Extend sybil-detection to authorities as well
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 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):

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


Comment:

 Roger says he's fine with this.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #12424, #17242, #18054, #18098, ...

[Tor Bug Tracker & Wiki]

Batch modification to #12424, #17242, #18054, #18098, #19647, #20524, #20657, 
#20699 by dgoulet:
milestone to Tor: 0.3.1.x-final

Comment:
Move the 0.3.??? prop224 tickets to the 031 milestone.

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

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

[Tor Bug Tracker & Wiki]

#20961: prop224: Implement consensus params to adjust portion of the protocol
---+
 Reporter:  dgoulet|  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  tor-hs, prop224
Actual Points: |  Parent ID:
   Points:  0.5|   Reviewer:
  Sponsor:  SponsorR-must  |
---+
 After discussion with developers and tor-dev@ thread here
 https://lists.torproject.org/pipermail/tor-dev/2016-December/011725.html,
 implementing consensus parameters to control some portion of the protocol.
 What comes to mind:

 - Default number of introduction points and maximum number
 - Timeframe and number of introduce before rotating an intro point.
 - Descriptor lifetime.
 - How many HSDir for a descriptor
 - Rendezvous timeout time.

 There are probably more.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20959 [Community/Tor Browser Manual]: Localized images for Tor Browser user manual

[Tor Bug Tracker & Wiki]

#20959: Localized images for Tor Browser user manual
--+
 Reporter:  arthuredelstein   |  Owner:
  |  arthuredelstein
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arthuredelstein):

 * status:  new => needs_review


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

Re: [tor-bugs] #20440 [Metrics/metrics-lib]: endless wait in BlockingIteratorImpl

[Tor Bug Tracker & Wiki]

#20440: endless wait in BlockingIteratorImpl
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * milestone:   => metrics-lib 1.6.0


Comment:

 This ought to be in 1.6.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] #20502 [Core Tor/Tor]: Setting UseBridges=1 UseEntryGuards=0 means you bypass your bridges

[Tor Bug Tracker & Wiki]

#20502: Setting UseBridges=1 UseEntryGuards=0 means you bypass your bridges
+
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  config review-group-13  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  chelseakomlo|Sponsor:
+

Comment (by neel):

 I have a patch which (hopefully) fixes it. Keep in mind that I had to add
 "UseEntryGuards 1" to some parts of test_options_validate_use_bridges in
 order to prevent some errors.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19043 [Core Tor/Tor]: prop224: Implementation of ESTABLISH_INTRO cell

[Tor Bug Tracker & Wiki]

#19043: prop224: Implementation of ESTABLISH_INTRO cell
-+-
 Reporter:  alec.heif|  Owner:  asn
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 6.s194, |  Actual Points:
  TorCoreTeam201612, review-group-13 |
Parent ID:  #17241   | Points:  6
 Reviewer:  asn, dgoulet |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Taking over this one from asn. Made a pass on nickm's comment in
 https://gitlab.com/asn/tor/merge_requests/7/diffs.

 The _new_ merge request is here containing all the fixups from the review
 in the above request:
 https://gitlab.com/dgoulet/tor/merge_requests/16/commits

 Branch: `ticket19043_030_03`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20759 [Metrics]: check if LICENSE file is up-to-date

[Tor Bug Tracker & Wiki]

#20759: check if LICENSE file is up-to-date
-+--
 Reporter:  iwakeh   |  Owner:  hiro
 Type:  task | Status:  needs_review
 Priority:  Low  |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  assigned => needs_review


Comment:

 @hiro:  Thanks!

 Setting ticket to 'needs_review', so the review is on the todo agenda.

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