date:20170214

Re: [tor-bugs] #20765 [Metrics/metrics-lib]: adapt to new lines in votes and consensus and make the adaption to protocol changes easier

2017-02-14 Thread Tor Bug Tracker & Wiki

#20765: adapt to new lines in votes and consensus and make the adaption to 
protocol
changes easier
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:5 karsten]:
 > And there's now [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-20765-2&id=3a990a48ca23ff4c5069d50b170761fadeb49018
 another commit] for the second half of the changes above.  Please review!

 Tests and checks pass.

 For a boolean return value I'd expect "is*" and not "get*", i.e.,
 `isSharedRandParticipate` instead of`getSharedRandParticipate`.

 ===

 One more comment on the previous commit:

 The new `private void parse*` methods just set a global variable each; why
 not have the `this.* = ParseHelper.parseProtocolVersions(line, line,
 parts);` lines in the switch stmt w/o the method calls?

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

Re: [tor-bugs] #21443 [Metrics/CollecTor]: CollecTor does not delete exit lists after three days anymore

2017-02-14 Thread Tor Bug Tracker & Wiki

#21443: CollecTor does not delete exit lists after three days anymore
---+-
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  CollecTor 1.2.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, pushed to master.  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] #20765 [Metrics/metrics-lib]: adapt to new lines in votes and consensus and make the adaption to protocol changes easier

2017-02-14 Thread Tor Bug Tracker & Wiki

#20765: adapt to new lines in votes and consensus and make the adaption to 
protocol
changes easier
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Replying to [comment:6 iwakeh]:
 > Replying to [comment:4 karsten]:
 > > Please review [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-20765-2&id=fd54cffa9335cac2f8c09398da34b85d4fabfd5d
 this commit] for the first half of the changes above.  Shared randomness
 follows later today, I hope.
 >
 > Tests and checks pass.

 Great!

 > For checking the upper limit it would be a little more readable to use
 `0x1__L` instead of 4294967296L.

 Changed.

 > (Just a thought, should `Number` be used instead of `Long` as the
 protocol numbers have unsigned int range?)

 Hmm, can you elaborate?

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

Re: [tor-bugs] #20765 [Metrics/metrics-lib]: adapt to new lines in votes and consensus and make the adaption to protocol changes easier

2017-02-14 Thread Tor Bug Tracker & Wiki

#20765: adapt to new lines in votes and consensus and make the adaption to 
protocol
changes easier
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Replying to [comment:7 iwakeh]:
 > Replying to [comment:5 karsten]:
 > > And there's now [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-20765-2&id=3a990a48ca23ff4c5069d50b170761fadeb49018
 another commit] for the second half of the changes above.  Please review!
 >
 > Tests and checks pass.

 Thanks for checking!

 > For a boolean return value I'd expect "is*" and not "get*", i.e.,
 `isSharedRandParticipate` instead of`getSharedRandParticipate`.

 Changed.

 > ===
 >
 > One more comment on the previous commit:
 >
 > The new `private void parse*` methods just set a global variable each;
 why not have the `this.* = ParseHelper.parseProtocolVersions(line, line,
 parts);` lines in the switch stmt w/o the method calls?

 I'm not sure.  I think the switch statement is more readable if we just
 make one simple method call per line and move the parsing logic to
 separate methods.  And what if this parsing logic ever gets more
 complicated and requires another line; would we have to move that logic to
 a new method then?  Let's just stick to the current scheme if you don't
 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] #19971 [Applications/TorBirdy]: Option to disable gnupg version dependent changes in the Enigmail settings

2017-02-14 Thread Tor Bug Tracker & Wiki

#19971: Option to disable gnupg version dependent changes in the Enigmail 
settings
---+---
 Reporter:  p.hansen   |  Owner:  sukhbir
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by intrigeri):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:6 sukhbir]:
 > This seems like a good solution in light of the GPG changes, compared to
 the HTTP proxy solution we have right now, which I feel is essentially
 broken.

 Cool :)

 > Before I merge: is there a reason why the
 `extensions.enigmail.agentAdditionalParam` preferences were removed?

 I don't remember. Looking at my branch again, I wonder if it was a mere
 mistake on my side, or if effectively
 `extensions.enigmail.agentAdditionalParam` is useless since we set the
 same prefs in the function my branch patches in
 `chrome/content/preferences.js`. I'll need to test my branch with GnuPG
 1.x to confirm; I might be able to do that later this week, but if I can't
 it'll have to wait until my next time slot allocated to this topic (mid-
 March)... unless someone else beats me to 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] #21278 [Core Tor/Tor]: Avoid signed integer underflow when comparing versions (Fix TROVE-2017-001)

2017-02-14 Thread Tor Bug Tracker & Wiki

#21278: Avoid signed integer underflow when comparing versions (Fix 
TROVE-2017-001)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:3 nickm]:
 > My branch `bug21278_024_v2` tries to fix this

 I pushed a `bug21278_024_v3` branch that has an extra commit to better
 document the new function.

 That said, I think your commits 2c768c2c0 and 54e2e027 are only for dir
 auths, right? So there isn't any point in backporting them earlier than
 0.2.9?

 Speaking of which, for 4e720ad7 which looks like the main fix here, the
 changelog stanza says {{{This bug is harmless, except when Tor has been
 build with --enable-expensive-hardening, which would turn it into a
 crash.}}} Am I remembering correctly that only recent Tor branches have
 put expensive-hardening on by default? That is, the earlier fix for this
 TROVE (i.e. disabling ftrapv) only went into 0.2.9.x and 0.3.0.x? Why
 backport a fix for a harmless bug so far 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] #21278 [Core Tor/Tor]: Avoid signed integer underflow when comparing versions (Fix TROVE-2017-001)

2017-02-14 Thread Tor Bug Tracker & Wiki

#21278: Avoid signed integer underflow when comparing versions (Fix 
TROVE-2017-001)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:3 nickm]:
 > Additionally, I found two more cases where we use the `if ((i = (a-b)))
 return i;` pattern to implement a comparison function.  I believe that
 they are both safe, but somebody should look them over.  The fixes for
 those are in my `bug21278_024_v2_extra` branch, on top of my
 `bug21278_024_v2` branch.

 I'm a big fan of what 0a2abb37 is doing (modulo the fixes that teor
 suggests). Since it's more of a belt-and-suspenders thing, is it more
 suited for 0.3.0?

 Whereas 557385874 is dir auth only (I think?), so there's no need for it
 to go earlier than 0.2.9. But you never know when sha1 collisions are
 going to drop, so I think putting it in 0.2.9 is reasonable if you want to
 do that. (On the other hand, once sha1 goes bad, "hey directory
 authorities, either start using the default value of --enable-fragile or
 upgrade to 0.3.0.x" seems like a totally doable statement 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] #21278 [Core Tor/Tor]: Avoid signed integer underflow when comparing versions (Fix TROVE-2017-001)

2017-02-14 Thread Tor Bug Tracker & Wiki

#21278: Avoid signed integer underflow when comparing versions (Fix 
TROVE-2017-001)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:6 teor]:
 > Also, I think we should patch the 64-bit to 32-bit truncation bug in
 #21450 at the same time as this.
 >
 > It means that 32-bit and 64-bit tors treat version components >=
 INT32_MAX differently.

 I can get behind this plan (to merge the fix for 21450 to 0.3.0, or to
 0.3.0 and 0.2.9, depending on how far back we decide to backport).

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

Re: [tor-bugs] #21450 [Core Tor/Tor]: Consistently parse tor versions regardless of word size

2017-02-14 Thread Tor Bug Tracker & Wiki

#21450: Consistently parse tor versions regardless of word size
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Should we take the opportunity to put a much lower bound on the range of
 version subcomponents? Like, even if we start putting out Tor
 0.3.0.20170215, that's still way lower than INT32_MAX. :)

 (I am also fine with "maybe but how will we pick the lower bound, let's
 just stick with INT32_MAX and have the discipline not to pick stupid
 version numbers.)

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

Re: [tor-bugs] #20894 [Core Tor/Tor]: Resolve read-off-end-of-buffer on atoi in fetch_from_buf_http (TROVE-2016-10-001)

2017-02-14 Thread Tor Bug Tracker & Wiki

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

Comment (by arma):

 Nickm tells me he's confident that the sentinel patch (already applied
 back through 0.2.4) has resolved the security issue. So this is just to
 clean up the code to make things better for our future? That sounds like a
 great thing to put into Tor 0.3.0 (like the body of this ticket suggests).

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

Re: [tor-bugs] #20323 [Metrics/metrics-lib]: avoid httpurl connection and use more robust approach

2017-02-14 Thread Tor Bug Tracker & Wiki

#20323: avoid httpurl connection and use more robust approach
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  needs_review
 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 karsten):

 * status:  needs_information => needs_review


Comment:

 Okay, please review [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-20765-2&id=1f6f0a808698bea06ba9637b38d8fd7e946b4d34
 this commit].

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

Re: [tor-bugs] #20509 [Core Tor/Tor]: Directory authorities should take away Guard flag from relays with #20499 bug

2017-02-14 Thread Tor Bug Tracker & Wiki

#20509: Directory authorities should take away Guard flag from relays with 
#20499
bug
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.9
 Severity:  Normal   | Resolution:
 Keywords:  028-backport, easy,  |  Actual Points:
  TorCoreTeam201612, review-group-15 |
Parent ID:   | Points:
 Reviewer:  teor, arma   |Sponsor:
-+-

Comment (by rubiate):

 Didn't [comment:15] conclude that the git tag isn't a problem?

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

[tor-bugs] #21451 [- Select a component]: Signatures on TPO are signed with incorrect key

2017-02-14 Thread Tor Bug Tracker & Wiki

#21451: Signatures on TPO are signed with incorrect key
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-


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

Re: [tor-bugs] #21027 [Core Tor/Tor]: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816: entry_guard_add_to_sample_impl: Non-fatal assertion !(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (o

2017-02-14 Thread Tor Bug Tracker & Wiki

#21027: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816:
entry_guard_add_to_sample_impl: Non-fatal assertion
!(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (on Tor 0.3.0.0
-alpha-dev 8b75261b6dc341de)
-+-
 Reporter:  asn  |  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, tor-guards-revamp,|  Actual Points:
  regression |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:16 nickm]:
 > Oh. Now I think I get it.  There's a possibility that the same bridge is
 listed twice among our bridges in bridge_list_get().  If that happens, if
 we go to add two bridges at a time for some reason, we'll add that bridge
 twice.
 >
 > Does my branch `bug21027_testing` branch make this bug go away?  Or does
 it change the warning at all?

 I think this is a good hypothesis!

 I managed to reproduce this non-fatal assert by using the following three
 Bridge lines  in my Tor Browser (which are actually the same underlying
 bridge with different PTs):
 {{{
 obfs3 83.212.101.3:80 A09D536DD1752D542E1FBB3C9CE4449D51298239
 scramblesuit 83.212.101.3:443 A09D536DD1752D542E1FBB3C9CE4449D51298239
 password=XTCXLG2JAMJKZW2POLBAOWOQETQSMASH
 obfs4 83.212.101.3:5 A09D536DD1752D542E1FBB3C9CE4449D51298239
 cert=lPRQ/MXdD1t5SRZ9MquYQNT9m5DV757jtdXdlePmRCudUU9CFUOX1Tm7/meFSyPOsud7Cw
 iat-mode=0
 }}}

 I can confirm that your patch silences the non-fatal assert, but I wonder
 if it implements the right behavior. What does a user expect by putting
 the above lines in their torrc?

 IMO a user would expect that each of those three Bridge lines will be
 treated as a separate entry guard and get sampled; whereas I think your
 patch will only add one of them to the sampled set.

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

Re: [tor-bugs] #21027 [Core Tor/Tor]: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816: entry_guard_add_to_sample_impl: Non-fatal assertion !(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (o

2017-02-14 Thread Tor Bug Tracker & Wiki

#21027: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816:
entry_guard_add_to_sample_impl: Non-fatal assertion
!(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (on Tor 0.3.0.0
-alpha-dev 8b75261b6dc341de)
-+-
 Reporter:  asn  |  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, tor-guards-revamp,|  Actual Points:
  regression |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 > IMO a user would expect that each of those three Bridge lines will be
 treated as a separate entry guard and get sampled; whereas I think your
 patch will only add one of them to the sampled set.

 Oh hm wow that's hard.  The current guard system really assumes that there
 is at most one guard per identity.  I'll have to think about design there.

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

[tor-bugs] #21452 [Applications/Tor Browser]: Fix search engines in TorBrowser

2017-02-14 Thread Tor Bug Tracker & Wiki

#21452: Fix search engines in TorBrowser
--+--
 Reporter:  antigonplexor |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 1. Google and Disconnect are space waste in list because Google blocks all
 tor traffic and disconnect is defunct

 2. Duckduckgo is using clearnet instead of onion url for search query

 3. add searx.me: better results than ddg and startpage and fully
 functional without JS even image search and has .onion URL too
 http://ulrn6sryqaifefld.onion/

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

Re: [tor-bugs] #21415 [Core Tor/Tor]: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circuit: Non-fatal assertion !(!guard_has_descriptor(guard)) failed.

2017-02-14 Thread Tor Bug Tracker & Wiki

#21415: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845:
select_entry_guard_for_circuit: Non-fatal assertion
!(!guard_has_descriptor(guard)) failed.
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Replying to [comment:4 nickm]:
 > The warning here seems to be here, in
 select_entry_guard_for_circuit()...
 > {{{
 >   SMARTLIST_FOREACH_BEGIN(gs->primary_entry_guards, entry_guard_t *,
 guard) {
 > entry_guard_consider_retry(guard);
 > if (! entry_guard_obeys_restriction(guard, rst))
 >   continue;
 > if (guard->is_reachable != GUARD_REACHABLE_NO) {
 >   if (need_descriptor && BUG(!guard_has_descriptor(guard))) {
 > continue;
 >   }
 > }}}
 >
 > And this, in turn, looks like a problem with our 21242 code. We're not
 supposed to be calling select_entry_guard_for_circuit() with
 need_descriptor set while
 guard_selection_have_enough_dir_info_to_build_circuits() is false, right?
 >
 > Though hm, that function only checks to make sure that the first
 num_primary possibly reachable guards all have descriptors.  If enough of
 them seem down, there's a decent chance that we'll turn to a position
 where we might have to update our 'can build circuits' flag.
 >
 > If that's so, then the right fix here is probably either to remove the
 BUG guard on the check.

 Hmm, it's a interesting point, that
 `guard_selection_have_enough_dir_info_to_build_circuits()` only checks for
 descriptors of reachable guards.

 This means that if one of our primary guards was considered unreachable
 (see `Proxy Client` errors in comment:2)  we would still get past
 `guard_selection_have_enough_dir_info_to_build_circuits()` even if we
 don't have its descriptor. Then after a few minutes, when that primary
 guard gets marked for retry, and we still dont have its descriptor, we
 could potentially trigger the non-fatal assert.

 I'm still a bit hazy with the code flow here, and whether the above is a
 possible, or if there are any alternative problems here.

 Your fix suggestion seems plausible here, but I'd like some more
 confidence that we have found the right bug. BTW note that the bug
 reporter is reproducing this bug using obfs4 '''bridges''', so IIUC we
 first call `select_entry_guard_for_circuit()` with
 `need_descriptor==False` (to get its descriptor) and then again with
 `need_descriptor==True` (to actually do traffic).

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

Re: [tor-bugs] #20765 [Metrics/metrics-lib]: adapt to new lines in votes and consensus and make the adaption to protocol changes easier

2017-02-14 Thread Tor Bug Tracker & Wiki

#20765: adapt to new lines in votes and consensus and make the adaption to 
protocol
changes easier
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:8 karsten]:
 > ...
 > > (Just a thought, should `Number` be used instead of `Long` as the
 protocol numbers have unsigned int range?)
 >
 > Hmm, can you elaborate?

 Basically a version is just a positive number and that the spec chose an
 unsigned int range is probably due to the fact that integer is the usual
 default chosen in programming, but not that anyone envisions that many
 versions.  To really have the concept of version number in java code a
 subclass of Number would be necessary that only accepts positive values,
 but that would be too much implementation for hardly any benefit.  Still,
 using metrics-lib api I might feel better to call intValue() on Number
 rather than on Long (the highest version I saw so far was 4).  But, that
 is a little 'esoteric' maybe.  As said just a thought.  I don't feel
 strongly about 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] #21446 [Core Tor/Tor]: Number of Introduction Points for a (SingleOnion?) HS seems variable, or degrades with time

2017-02-14 Thread Tor Bug Tracker & Wiki

#21446: Number of Introduction Points for a (SingleOnion?) HS seems variable, or
degrades with time
--+
 Reporter:  alecmuffett   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.9
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 This does not look good, but I'm also a bit confused.

 Looking at the gist, are we looking at the intro points of two separate
 tor daemons, and we cannot know which logs belong to which host? Are we
 certain there are two hosts in there?

 In general, some logs would help 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] #20765 [Metrics/metrics-lib]: adapt to new lines in votes and consensus and make the adaption to protocol changes easier

2017-02-14 Thread Tor Bug Tracker & Wiki

#20765: adapt to new lines in votes and consensus and make the adaption to 
protocol
changes easier
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:9 karsten]:
 > ...
 > > The new `private void parse*` methods just set a global variable each;
 why not have the `this.* = ParseHelper.parseProtocolVersions(line, line,
 parts);` lines in the switch stmt w/o the method calls?
 >
 > I'm not sure.  I think the switch statement is more readable if we just
 make one simple method call per line and move the parsing logic to
 separate methods.  And what if this parsing logic ever gets more
 complicated and requires another line; would we have to move that logic to
 a new method then?  Let's just stick to the current scheme if you don't
 mind.

 The switch is quite long and having the one line assignment there and
 method calls only when there is more to be done would save an unfamiliar
 reader from checking the method call to find that it just hides an
 assigment, but I don't feel strongly about this.  And, you're right that
 the newly created methods just continue the existing scheme.  Maybe, we
 should try to have a different approach in new classes :-)

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

Re: [tor-bugs] #20765 [Metrics/metrics-lib]: adapt to new lines in votes and consensus and make the adaption to protocol changes easier

2017-02-14 Thread Tor Bug Tracker & Wiki

#20765: adapt to new lines in votes and consensus and make the adaption to 
protocol
changes easier
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  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:  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] #20852 [Core Tor/Tor]: prop224: Update prop224 HSDir code to understand latest descriptor format

2017-02-14 Thread Tor Bug Tracker & Wiki

#20852: prop224: Update prop224 HSDir code to understand latest descriptor 
format
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, prop224, TorCoreTeam201612,  |  Actual Points:
  review-group-14|
Parent ID:   | Points:  3
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorR-can
-+-

Comment (by asn):

 Personal note: Part (b) of comment:2 is being done in #21334.

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

Re: [tor-bugs] #20765 [Metrics/metrics-lib]: adapt to new lines in votes and consensus and make the adaption to protocol changes easier

2017-02-14 Thread Tor Bug Tracker & Wiki

#20765: adapt to new lines in votes and consensus and make the adaption to 
protocol
changes easier
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Okay, I see your point on both the version numbers topic and the one-line
 methods.  But let's not overengineer/overthink this.  Squashed and merged.
 Thanks for the review!  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] #21027 [Core Tor/Tor]: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816: entry_guard_add_to_sample_impl: Non-fatal assertion !(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (o

2017-02-14 Thread Tor Bug Tracker & Wiki

#21027: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816:
entry_guard_add_to_sample_impl: Non-fatal assertion
!(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (on Tor 0.3.0.0
-alpha-dev 8b75261b6dc341de)
-+-
 Reporter:  asn  |  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, tor-guards-revamp,|  Actual Points:
  regression |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Further investigation:

 Fortunately, there aren't any ID->guard maps in the data structures.  The
 exported `entry_guard_get_by_id_digest*()` function, though, _does_ assume
 that "the guard with a given RSA ID" is a well-specified concept.  Nothing
 outside of circpathbias.c uses it, however.

 The get_sampled_guard_with_id() function (which appears to do the same
 thing!) is used by have_sampled_guard_with_id() and by
 get_sampled_guard_for_bridge().

 So I think the right answer here is to just back off on the assumption
 that RSA IDs are unique by bridges. But we'll need to have a better notion
 for bridge equality, and other improved functions. H.

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

Re: [tor-bugs] #21027 [Core Tor/Tor]: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816: entry_guard_add_to_sample_impl: Non-fatal assertion !(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (o

2017-02-14 Thread Tor Bug Tracker & Wiki

#21027: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816:
entry_guard_add_to_sample_impl: Non-fatal assertion
!(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (on Tor 0.3.0.0
-alpha-dev 8b75261b6dc341de)
-+-
 Reporter:  asn  |  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, tor-guards-revamp,|  Actual Points:
  regression |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
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] #17379 [Applications/Tor Browser]: Using the same build process in Tor Browser and Tor Messenger

2017-02-14 Thread Tor Bug Tracker & Wiki

#17379: Using the same build process in Tor Browser and Tor Messenger
--+---
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mcs):

 Kathy and I successfully ran `make alpha_nightly` on an Ubuntu 14.04 LTS
 system. Here is some quick feedback:

 a) It would be nice to have log output that provided a "high level" view
 of progress (e.g., Building tor for Linux64, Building pluggable transports
 for Linux64, Building firefox for Linux64) The old gitian-based build
 system does not do this very well either; maybe we should have two log
 files? Or something that is easy to grep for within the make output.

 b) How can we reduce the number of languages that we produce packages for?
 Doing that is useful when creating test builds since it speeds up
 packaging time.

 c) The resulting Linux build runs, but the OSX one does not (we did not
 yet try to run the Windows build). On OSX, libevent seems to be missing
 and tor.real has a dependency on this path:
  /var/tmp/dist/libevent/lib/libevent-2.0.5.dylib
 In current OSX builds (e.g., TB 7.0a1), tor.real has a dependency on:
  @executable_path/libevent-2.0.5.dylib

 After we copied libevent from TB 7.0a1 to the /var/tmp/... path, we got
 further: tor.real started up and completed the bootstrap phase but it
 exited immediately after that point:
  [notice] Owning controller connection has closed -- exiting now.

 We do not know why tor thinks the connection has closed (maybe the browser
 is closing the control port connection or maybe it is not). Is this a
 known problem?

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

Re: [tor-bugs] #21309 [Applications/Tor Browser]: Fix Omnibox for TBB/52ESR

2017-02-14 Thread Tor Bug Tracker & Wiki

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

Comment (by mcs):

 Replying to [comment:9 arthuredelstein]:
 > Unfortunately it doesn't work -- the language packs each contains a
 list.json file that overrides these settings. So we'll need to update the
 #18915 patch as I mentioned in comment:7.

 Here is a radical idea: modify browser/locales/search/list.json to only
 contain a "default" entry and remove the list.json file from each language
 pack during our packaging phase. I don't know if everything would work
 correctly if we did that, but it might.

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

Re: [tor-bugs] #20656 [Core Tor/Tor]: prop224: Tell protover about relay intro cells support

2017-02-14 Thread Tor Bug Tracker & Wiki

#20656: prop224: Tell protover about relay intro cells support
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #20657   | Points:  0.2
 Reviewer:   |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

 * status:  accepted => merge_ready
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.0.x-final


Comment:

 Ok badly triage!! My fault. I'm also merging #20571 (about HSDir) in this
 ticket because the patch is so trivial.

 Tor patch: `ticket20656_030_01`
 Spec patch: `ticket20656_01`

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

Re: [tor-bugs] #20656 [Core Tor/Tor]: prop224: Tell protover about relay and hsdir support (was: prop224: Tell protover about relay intro cells support)

2017-02-14 Thread Tor Bug Tracker & Wiki

#20656: prop224: Tell protover about relay and hsdir support
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #20657   | Points:  0.2
 Reviewer:   |Sponsor:  SponsorR-must
-+
Description changed by dgoulet:

Old description:

> For relay support in #17241 (parent ticket), we'll need to add version 4
> to protover `HSIntro` so client/service can know which relay they can
> pick for introduction.

New description:

 For relay support in #17241 (parent ticket), we'll need to add version 4
 to protover `HSIntro` so client/service can know which relay they can pick
 for introduction and version 2 to `HSDir`.

--

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

Re: [tor-bugs] #20571 [Core Tor/Tor]: When we are really satisfied that it is right, tell protover.c about prop224 HSDir support

2017-02-14 Thread Tor Bug Tracker & Wiki

#20571: When we are really satisfied that it is right, tell protover.c about
prop224 HSDir support
-+
 Reporter:  nickm|  Owner:  dgoulet
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #20657   | Points:  0.2
 Reviewer:   |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

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


Comment:

 Resolved by #20656.

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

Re: [tor-bugs] #21309 [Applications/Tor Browser]: Fix Omnibox for TBB/52ESR

2017-02-14 Thread Tor Bug Tracker & Wiki

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

Comment (by arthuredelstein):

 Replying to [comment:10 mcs]:
 > Replying to [comment:9 arthuredelstein]:
 > > Unfortunately it doesn't work -- the language packs each contains a
 list.json file that overrides these settings. So we'll need to update the
 #18915 patch as I mentioned in comment:7.
 >
 > Here is a radical idea: modify browser/locales/search/list.json to only
 contain a "default" entry and remove the list.json file from each language
 pack during our packaging phase. I don't know if everything would work
 correctly if we did that, but it might.

 I think that's a good suggestion and it might work. I will give it a try.

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

Re: [tor-bugs] #21376 [Metrics]: add javadoc metrics style

2017-02-14 Thread Tor Bug Tracker & Wiki

#21376: add javadoc metrics style
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by RaBe):

 * owner:  RaBe => metrics-team


Comment:

 I did not even touch the font of the default JavaDoc stylesheet :) But I
 agree with it being the mentioned known bug, so you can just remove the
 import line. On systems that have Deja Vu installed it will still be
 displayed, for other systems it falls back to Arial, which should be fine!

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

Re: [tor-bugs] #21376 [Metrics]: add javadoc metrics style

2017-02-14 Thread Tor Bug Tracker & Wiki

#21376: add javadoc metrics style
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Great, thanks for the confirmation!

 I just cherry-picked the two commits and pushed them to metrics-base
 master.  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

[tor-bugs] #21453 [Core Tor/Tor]: add ClientTransportPlugin configuration to tor-service-defaults-torrc by default

2017-02-14 Thread Tor Bug Tracker & Wiki

#21453: add ClientTransportPlugin configuration to tor-service-defaults-torrc by
default
--+-
 Reporter:  adrelanos |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Please add {{{ClientTransportPlugin}}} configuration to {{{/usr/share/tor
 /tor-service-defaults-torrc}}} by default. What I mean by that...

 {{{tor-browser/Browser/TorBrowser/Data/Tor/torrc-defaults}}} contains:

 {{{
 ## fteproxy configuration
 ClientTransportPlugin fte exec
 ./TorBrowser/Tor/PluggableTransports/fteproxy.bin --managed

 ## obfs4proxy configuration
 ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec
 ./TorBrowser/Tor/PluggableTransports/obfs4proxy

 ## meek configuration
 ClientTransportPlugin meek exec ./TorBrowser/Tor/PluggableTransports/meek-
 client-torbrowser -- ./TorBrowser/Tor/PluggableTransports/meek-client

 ## snowflake configuration
 ClientTransportPlugin snowflake exec ./TorBrowser/Tor/PluggableTransports
 /snowflake-client -url https://snowflake-reg.appspot.com/ -front
 www.google.com -ice stun:stun.l.google.com:19302
 }}}


 For {{{/usr/share/tor/tor-service-defaults-torrc}}} I suggest to add:


 {{{
 ## fteproxy configuration
 ClientTransportPlugin fte exec /usr/bin/fteproxy --managed

 ## obfs4proxy configuration
 ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec
 /usr/bin/obfs4proxy
 }}}

 (Left out meek and snowflake, because these are not yet in
 packages.debian.org. #13160 #19409)

 Why?

 * Improves usability. One step of configuration less. Fewer mistakes can
 be made. The user has no longer to add the {{{ClientTransportPlugin}}}
 line.
 * Using the canonical recommendation.
 * To be on par with Tor Browser.
 * {{{ClientTransportPlugin}}} does not have any effect as long as not
 adding a {{{Bridge}}} line.
 * {{{ClientTransportPlugin}}} lines do not change often.
 * {{{ClientTransportPlugin}}} can still be overwritten in
 {{{/etc/tor/torrc}}} by the user.

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

Re: [tor-bugs] #21448 [Applications/Tor Browser]: Identify what build flags we should be using for security, and use them

2017-02-14 Thread Tor Bug Tracker & Wiki

#21448: Identify what build flags we should be using for security, and use them
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 Relevant Mozilla Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=620058

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

Re: [tor-bugs] #21448 [Applications/Tor Browser]: Identify what build flags we should be using for security, and use them

2017-02-14 Thread Tor Bug Tracker & Wiki

#21448: Identify what build flags we should be using for security, and use them
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by arthuredelstein:

Old description:

> I think we are probably forgetting some configure/compiler/linker flags
> in Tor Browser that can improve security. Let's figure out what those are
> and add them. I would suggest child tickets for each new flag, so we can
> do this step by step.

New description:

 I think we may be able to add some configure/compiler/linker flags in Tor
 Browser that can improve security without many downsides. Let's figure out
 what those are and add them. I would suggest child tickets for each new
 flag, so we can do this step by step.

--

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

Re: [tor-bugs] #21027 [Core Tor/Tor]: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816: entry_guard_add_to_sample_impl: Non-fatal assertion !(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (o

2017-02-14 Thread Tor Bug Tracker & Wiki

#21027: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816:
entry_guard_add_to_sample_impl: Non-fatal assertion
!(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (on Tor 0.3.0.0
-alpha-dev 8b75261b6dc341de)
-+-
 Reporter:  asn  |  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, tor-guards-revamp,|  Actual Points:
  regression |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Okay, how about this branch here: `bug21027_v2`

 I think it removes the few places where I'd assumed that multiple
 bridge_info_t instances shouldn't share an ID.

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

Re: [tor-bugs] #21450 [Core Tor/Tor]: Consistently parse tor versions regardless of word size

2017-02-14 Thread Tor Bug Tracker & Wiki

#21450: Consistently parse tor versions regardless of word size
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:1 arma]:
 > Should we take the opportunity to put a much lower bound on the range of
 version subcomponents? Like, even if we start putting out Tor
 0.3.0.20170215, that's still way lower than INT32_MAX. :)

 `20170215 > 2^25`, so I can't see any smaller limit, at least on a byte
 boundary.

 > (I am also fine with "maybe but how will we pick the lower bound, let's
 just stick with INT32_MAX and have the discipline not to pick stupid
 version numbers.)

 +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

[tor-bugs] #21454 [Core Tor/Tor]: tor_version_compare and version spec comparison order are inconsistent

2017-02-14 Thread Tor Bug Tracker & Wiki

#21454: tor_version_compare and version spec comparison order are inconsistent
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 Similar to #21449, when we compare versions, we compare the status before
 the patchlevel, and then compare status tag and SCM information.

 But the spec says:
 {{{
 1. The Old Way
 ...
 We compare the elements in order (major, minor, micro, status, patchlevel,
 cvs)
 ...
 2. The New Way
 ...
 MAJOR, MINOR, MICRO, and PATCHLEVEL are numbers
 ...
 All versions should be distinguishable purely by those four numbers.

 The STATUS_TAG is purely informational
 ...
 If we *do* encounter two versions that differ only by status tag, we
 compare them lexically
 ...
 }}}

 This doesn't matter much at the moment because we don't use patchlevels.

 But we should fix this issue, probably by modifying the spec.

 Reported by arma.

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

Re: [tor-bugs] #21453 [Core Tor/Tor]: add ClientTransportPlugin configuration to tor-service-defaults-torrc by default

2017-02-14 Thread Tor Bug Tracker & Wiki

#21453: add ClientTransportPlugin configuration to tor-service-defaults-torrc by
default
--+-
 Reporter:  adrelanos |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 I think this is intended to be a ticket for the Tor deb?

 I think the suggested change is a fine idea, but I think we might want to
 work through the failure cases and make Tor handle them better. In
 particular, if the Tor deb added these ClientTransportPlugin lines, but it
 didn't require obfsproxy as a dependency, then everything would work fine
 until you add an obfs4 bridge, and then things would break, and there
 would be some mysterious log lines if you know how to look for log lines:
 {{{
 Feb 14 13:47:47.589 [warn] Could not launch managed proxy executable at
 '/usr/bin/obfs4proxy' ('No such file or directory').
 Feb 14 13:47:48.591 [warn] We were supposed to connect to bridge
 '18.18.18.18:443' using pluggable transport 'obfs4', but we can't find a
 pluggable transport proxy supporting 'obfs4'. This can happen if you
 haven't provided a ClientTransportPlugin line, or if your pluggable
 transport proxy stopped running.
 }}}

 Are there good ways to handle the missing dependency in a more usable way?

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

Re: [tor-bugs] #21453 [Core Tor/Tor]: add ClientTransportPlugin configuration to tor-service-defaults-torrc by default

2017-02-14 Thread Tor Bug Tracker & Wiki

#21453: add ClientTransportPlugin configuration to tor-service-defaults-torrc by
default
--+-
 Reporter:  adrelanos |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by adrelanos):

 Replying to [comment:1 arma]:
 > I think this is intended to be a ticket for the Tor deb?

 Yes. However, I guess the Tor source package ships also a {{{tor-service-
 defaults-torrc}}}?

 > I think the suggested change is a fine idea, but I think we might want
 to work through the failure cases and make Tor handle them better. In
 particular, if the Tor deb added these ClientTransportPlugin lines, but it
 didn't require obfsproxy as a dependency, then everything would work fine
 until you add an obfs4 bridge, and then things would break, and there
 would be some mysterious log lines if you know how to look for log lines:
 > {{{
 > Feb 14 13:47:47.589 [warn] Could not launch managed proxy executable at
 '/usr/bin/obfs4proxy' ('No such file or directory').
 > Feb 14 13:47:48.591 [warn] We were supposed to connect to bridge
 '18.18.18.18:443' using pluggable transport 'obfs4', but we can't find a
 pluggable transport proxy supporting 'obfs4'. This can happen if you
 haven't provided a ClientTransportPlugin line, or if your pluggable
 transport proxy stopped running.
 > }}}

 > Are there good ways to handle the missing dependency in a more usable
 way?

 The same would happen if the user just added a ClientTransportPlugin line
 as well as an an obfs4 bridge but forgot to install obfs4proxy package. Is
 this perhaps worth a separate ticket and not a blocker here?

 Another option is to shift responsibility on the related packages, i.e.
 obfs4proxy and fteproxy. Tell them to wait for Tor feature
 {{{torrc.d-style configuration directories}}} (#1922) and then ship an
 {{{/etc/torrc.d}}} config snippet?

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

Re: [tor-bugs] #21453 [Core Tor/Tor]: add ClientTransportPlugin configuration to tor-service-defaults-torrc by default

2017-02-14 Thread Tor Bug Tracker & Wiki

#21453: add ClientTransportPlugin configuration to tor-service-defaults-torrc by
default
--+-
 Reporter:  adrelanos |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 Actually, you're right, I get this on start-up even if I have no obfs4
 bridges configured:
 {{{
 Feb 14 13:58:07.593 [warn] Could not launch managed proxy executable at
 '/usr/bin/obfs4proxy' ('No such file or directory').
 }}}

 So just adding those lines to the deb's defaults would result in warns for
 everybody who didn't happen to also install some other debs.

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

Re: [tor-bugs] #21453 [Core Tor/Tor]: add ClientTransportPlugin configuration to tor-service-defaults-torrc by default

2017-02-14 Thread Tor Bug Tracker & Wiki

#21453: add ClientTransportPlugin configuration to tor-service-defaults-torrc by
default
--+-
 Reporter:  adrelanos |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 Replying to [comment:2 adrelanos]:
 > Replying to [comment:1 arma]:
 > > I think this is intended to be a ticket for the Tor deb?
 >
 > Yes. However, I guess the Tor source package ships also a {{{tor-
 service-defaults-torrc}}}?

 Please point to it if so, because I don't see one.

 That's all from choices made by the packager.

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

Re: [tor-bugs] #21452 [Applications/Tor Browser]: Fix search engines in TorBrowser

2017-02-14 Thread Tor Bug Tracker & Wiki

#21452: Fix search engines in TorBrowser
--+--
 Reporter:  antigonplexor |  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):

 1 Wrong. Google works sometimes.
 2 I confirm this.
 3 Honeypot.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21455 [Applications/Tor Browser]: Inconsistent New Window height on multiple monitors (Windows)

2017-02-14 Thread Tor Bug Tracker & Wiki

#21455: Inconsistent New Window height on multiple monitors (Windows)
--+--
 Reporter:  pjw0  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 (1) "New Window" or Ctrl+N creates a new window slightly offset from the
 current window, but the size of the new window is determined by the
 primary display (instead of the display the window is on).

 If the primary display is larger, this can push part of the window off the
 top of the display (e.g. primary 1920x1200, secondary 1280x1024: New
 Window on secondary display gets pushed off the top so only half the URL
 bar is visible).

 (2) Dragging a tab out of a window with multiple tabs creates a new window
 sized differently than "New Window", this new window is sized according to
 the display it is on.

 This is in 6.5 and 7.0a1 but not 6.08

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

Re: [tor-bugs] #21246 [User Experience]: Remove google recaptha

2017-02-14 Thread Tor Bug Tracker & Wiki

#21246: Remove google recaptha
-+--
 Reporter:  scootergrisen|  Owner:  lnl
 Type:  task | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cypherpunks):

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


Comment:

 Reread the question once again and think a bit why your answer and your
 "wontfix" has nothing common with the question asked.

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

Re: [tor-bugs] #21278 [Core Tor/Tor]: Avoid signed integer underflow when comparing versions (Fix TROVE-2017-001)

2017-02-14 Thread Tor Bug Tracker & Wiki

#21278: Avoid signed integer underflow when comparing versions (Fix 
TROVE-2017-001)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 > Am I remembering correctly that only recent Tor branches have put
 expensive-hardening on by default? That is, the earlier fix for this TROVE
 (i.e. disabling ftrapv) only went into 0.2.9.x and 0.3.0.x?

 This bug affects everybody who has trapv or ubsan turned on.  In
 0.2.9.1-alpha, we turned trapv on by default, which caused this bug to
 affect 0.2.9.1-alpha through 0.2.9.8.

 This bug will still affect all older versions if they have --enable-
 expensive-hardening turned on.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21456 [- Select a component]: Ship own TCP/IP stack with TorBrowser to prevent OS fingerprinting

2017-02-14 Thread Tor Bug Tracker & Wiki

#21456: Ship own TCP/IP stack with TorBrowser to prevent OS fingerprinting
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-


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

Re: [tor-bugs] #21456 [Applications/Tor Browser]: Ship own TCP/IP stack with TorBrowser to prevent OS fingerprinting

2017-02-14 Thread Tor Bug Tracker & Wiki

#21456: Ship own TCP/IP stack with TorBrowser to prevent OS fingerprinting
--+--
 Reporter:  cypherpunks   |  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 cypherpunks):

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


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

Re: [tor-bugs] #21451 [Applications/Tor Browser]: Signatures on TPO are signed with incorrect key

2017-02-14 Thread Tor Bug Tracker & Wiki

#21451: Signatures on TPO are signed with incorrect key
--+--
 Reporter:  cypherpunks   |  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 cypherpunks):

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


Comment:

 0xD1483FA6C3C07136 is used instead of 0x2E1AC68ED40814E0

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

Re: [tor-bugs] #16221 [Applications/Tor Browser]: Investigate WebRTC with TCP-ICE and hidden services (was: Investiate WebRTC with TCP-ICE and hidden services)

2017-02-14 Thread Tor Bug Tracker & Wiki

#16221: Investigate WebRTC with TCP-ICE and hidden services
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

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

[tor-bugs] #21457 [- Select a component]: Hide Firefox version from User-Agent

2017-02-14 Thread Tor Bug Tracker & Wiki

#21457: Hide Firefox version from User-Agent
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 ESR is released in predictable way, we usually know several ESR releases
 in advance. So I think that TorBrowser should always indicate the latest
 released Firefox version in User-Agent even if it has an older one.

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

Re: [tor-bugs] #21457 [Applications/Tor Browser]: Hide Firefox version from User-Agent

2017-02-14 Thread Tor Bug Tracker & Wiki

#21457: Hide Firefox version from User-Agent
--+--
 Reporter:  cypherpunks   |  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 cypherpunks):

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


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

[tor-bugs] #21458 [- Select a component]: Replace all the links of Tor Project in TBB (bookmarks, about, etc.) with the .onion ones.

2017-02-14 Thread Tor Bug Tracker & Wiki

#21458: Replace all the links of Tor Project in TBB (bookmarks, about, etc.) 
with
the .onion ones.
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-


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

Re: [tor-bugs] #21458 [Applications/Tor Browser]: Replace all the links of Tor Project in TBB (bookmarks, about, etc.) with the .onion ones.

2017-02-14 Thread Tor Bug Tracker & Wiki

#21458: Replace all the links of Tor Project in TBB (bookmarks, about, etc.) 
with
the .onion ones.
--+--
 Reporter:  cypherpunks   |  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 cypherpunks):

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


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

Re: [tor-bugs] #21321 [Applications/Tor Browser]: Convince Mozilla; .onion HTTP is SECURE.

2017-02-14 Thread Tor Bug Tracker & Wiki

#21321: Convince Mozilla; .onion HTTP is SECURE.
-+--
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-usability-website  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 It is not. https over .onion is secure. .onion is insecure and should be
 used only for decentralized DNS (insecure, the RSA-1024 is broken) and
 website position obfuscation.

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

Re: [tor-bugs] #21278 [Core Tor/Tor]: Avoid signed integer underflow when comparing versions (Fix TROVE-2017-001)

2017-02-14 Thread Tor Bug Tracker & Wiki

#21278: Avoid signed integer underflow when comparing versions (Fix 
TROVE-2017-001)
--+
 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:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Okay.  So here's where we stand:
   * I have a `bug21278_024_v4` that has only the minimal fix for the
 integer issue.  I propose that it go into 0.2.4.
   * I have a `bug21278_redux_029` that blocks the bogus versions at the
 directory level, and includes a changes file and roger's function
 documentation.  I propose that it go into 0.2.9.
   * I agree that it's okay to merge bug21278_024_v2_extra to 0.2.9. I have
 a `bug21278_extra_029` branch to port those forward.  I'm okay with taking
 that in 0.2.9 or 0.3.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] #21451 [Applications/Tor Browser]: Signatures on TPO are signed with incorrect key

2017-02-14 Thread Tor Bug Tracker & Wiki

#21451: Signatures on TPO are signed with incorrect key
--+--
 Reporter:  cypherpunks   |  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):

 Replying to [comment:1 cypherpunks]:
 > 0xD1483FA6C3C07136 is used instead of 0x2E1AC68ED40814E0
 Both keys are valid according to [https://www.torproject.org/docs/signing-
 keys.html].

 {{{
 pub   4096R/0x4E2C6E8793298290 2014-12-15 [expires: 2020-08-24]
   Key fingerprint = EF6E 286D DA85 EA2A 4BA7  DE68 4E2C 6E87 9329 8290
 uid   Tor Browser Developers (signing key) 
 sub   4096R/0x2E1AC68ED40814E0 2014-12-15 [expires: 2017-08-25]
 sub   4096R/0x7017ADCEF65C2036 2014-12-15 [expires: 2017-08-25]
 sub   4096R/0xD1483FA6C3C07136 2016-08-24 [expires: 2018-08-24]
 }}}

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

Re: [tor-bugs] #20894 [Core Tor/Tor]: Resolve read-off-end-of-buffer on atoi in fetch_from_buf_http (TROVE-2016-10-001)

2017-02-14 Thread Tor Bug Tracker & Wiki

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

 * status:  needs_revision => needs_review


Comment:

 > Can headers+headerlen can wrap here?

 I believe it can't, since headers is a pointer to a place in a buffer, and
 headerlen is an amount of memory that's readable at that point.

 I've forward-ported to 0.2.9, moved the unit test, added a correct use of
 STATIC, and credited AFL in a branch `bug20894_029_v3`.  I'm fine taking
 this in 0.3.0 or 0.2.9.

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

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

2017-02-14 Thread Tor Bug Tracker & Wiki

#21420: Link certificate start date in the future
--+
 Reporter:  mmcloughlin   |  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:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 I've commented stuff, renamed stuff, and fixed the comparison in a fixup
 commit on the same branch `bug21420_029` .

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

Re: [tor-bugs] #21450 [Core Tor/Tor]: Consistently parse tor versions regardless of word size

2017-02-14 Thread Tor Bug Tracker & Wiki

#21450: Consistently parse tor versions regardless of word size
--+
 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:|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => merge_ready


Comment:

 I'm fine with taking this along with the dirauth part of #21278.

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

Re: [tor-bugs] #20656 [Core Tor/Tor]: prop224: Tell protover about relay and hsdir support

2017-02-14 Thread Tor Bug Tracker & Wiki

#20656: prop224: Tell protover about relay and hsdir support
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #20657   | Points:  0.2
 Reviewer:   |Sponsor:  SponsorR-must
-+

Comment (by nickm):

 The tor patch looks okay.

 For the spec patch, I'd like to see it say what exactly it means by
 "supports HS protocol v2 as of proposal 224".  Like, what cells or what
 datatypes, in what formats.

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

Re: [tor-bugs] #21447 [Core Tor/Tor]: Rename 'make fuzz'

2017-02-14 Thread Tor Bug Tracker & Wiki

#21447: Rename 'make fuzz'
--+
 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:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 `bug21447` is a branch with a fix.

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

Re: [tor-bugs] #21121 [Core Tor/Fallback Scripts]: Update fallback whitelist

2017-02-14 Thread Tor Bug Tracker & Wiki

#21121: Update fallback whitelist
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by teor):

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


Comment:

 Now fallbacks-201702.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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.

2017-02-14 Thread 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.1.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):

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


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

Re: [tor-bugs] #20894 [Core Tor/Tor]: Resolve read-off-end-of-buffer on atoi in fetch_from_buf_http (TROVE-2016-10-001)

2017-02-14 Thread Tor Bug Tracker & Wiki

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

 * status:  needs_review => merge_ready


Comment:

 Looks good!
 `make check test-network-all` runs for me on macOS 10.12 x86_64 and i386.

 I can't see any reason to take this in 0.2.9, given that this changes
 quite a bit of code for a stable 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] #21283 [Core Tor/Tor]: Remove broken fallback directory mirrors

2017-02-14 Thread Tor Bug Tracker & Wiki

#21283: Remove broken fallback directory mirrors
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fallback, 028-backport,  |  Actual Points:
  029-backport   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 The whitelist and script changes are in #21121.
 The branch is now bad-fallbacks-201702-028, but I'll wait a week or two
 after contacting operators and re-run the script.

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

Re: [tor-bugs] #20894 [Core Tor/Tor]: Resolve read-off-end-of-buffer on atoi in fetch_from_buf_http (TROVE-2016-10-001)

2017-02-14 Thread Tor Bug Tracker & Wiki

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

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


Comment:

 hm, okay.  Taking it in 0.3.0, with no backport planned.

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

Re: [tor-bugs] #21283 [Core Tor/Tor]: Remove broken fallback directory mirrors

2017-02-14 Thread Tor Bug Tracker & Wiki

#21283: Remove broken fallback directory mirrors
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fallback, 028-backport,  |  Actual Points:
  029-backport   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 (I won't email tor-team, 31 emails is a few too many.)

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

Re: [tor-bugs] #20656 [Core Tor/Tor]: prop224: Tell protover about relay and hsdir support

2017-02-14 Thread Tor Bug Tracker & Wiki

#20656: prop224: Tell protover about relay and hsdir support
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 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  |  Actual Points:
Parent ID:  #20657   | Points:  0.2
 Reviewer:   |Sponsor:  SponsorR-must
-+
Changes (by nickm):

 * status:  merge_ready => needs_revision


Comment:

 (I've taken the tor part of this patch, but not the spec part 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

[tor-bugs] #21459 [Metrics/Atlas]: Make atlas fingerprint selectable by double-clicking

2017-02-14 Thread Tor Bug Tracker & Wiki

#21459: Make atlas fingerprint selectable by double-clicking
---+
 Reporter:  teor   |  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:  regression
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 When I use atlas on macOS 10.12 with the default Tor Browser window size
 (on a 1440 x 900 display), the relay fingerprint is wrapped across two
 lines.

 This means I can no longer select the fingerprint by double-clicking.
 (I only get the first 37 characters.)

 Can you please fix this regression?
 It worked fine in earlier versions.

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

Re: [tor-bugs] #21435 [Applications/Tor Browser]: Couldn't Load XPCOM tor 6.5

2017-02-14 Thread Tor Bug Tracker & Wiki

#21435: Couldn't Load XPCOM tor 6.5
--+--
 Reporter:  arron76   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arron76):

 I checked my hard drive and found bad sectors. I will put in a new one and
 that will probaly do the trick.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21460 [Core Tor/Fallback Scripts]: Fallback script check_existing mode ignores IPv6 addresses added to the whitelist

2017-02-14 Thread Tor Bug Tracker & Wiki

#21460: Fallback script check_existing mode ignores IPv6 addresses added to the
whitelist
---+--
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 I added an IPv6 address to the whitelist entry for a relay that was on the
 hard-coded fallback list.

 But since check_existing mode only checks the hard-coded list, it still
 showed up as a new address the next time the hard-coded list was run with
 check_existing mode.

 We could special-case this, or just re-add relays manually if this happens
 (it's pretty rare), or let them drop out and be added when we next rebuild
 the entire 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] #21278 [Core Tor/Tor]: Avoid signed integer underflow when comparing versions (Fix TROVE-2017-001)

2017-02-14 Thread Tor Bug Tracker & Wiki

#21278: Avoid signed integer underflow when comparing versions (Fix 
TROVE-2017-001)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:11 nickm]:
 > Okay.  So here's where we stand:
 >   * I have a `bug21278_024_v4` that has only the minimal fix for the
 integer issue.  I propose that it go into 0.2.4.

 This is ok, as anyone on a private network can stop their own relays
 misbehaving.
 `make check` passes for me on macOS 10.12 i386 and x86_64.

 >   * I have a `bug21278_redux_029` that blocks the bogus versions at the
 directory level, and includes a changes file and roger's function
 documentation.  I propose that it go into 0.2.9.

 This refuses to compile for me with:
 {{{
 src/or/routerparse.c::32: error: comparison of unsigned enum
 expression < 0
   is always false [-Werror,-Wtautological-compare]
 router_version->status < 0 ||
 }}}
 on:
 {{{
 clang -arch i386 --version >&5
 clang version 3.9.1 (tags/RELEASE_391/final)
 Target: i386-apple-darwin16.4.0
 Thread model: posix
 }}}

 The 64-bit arch compiles and passes `make check test-network-all`.

 I don't know what the extra newline is doing in f1c2cea165, but that's a
 nitpick.

 The changes file in 1ff289a745 includes trailing whitespace.

 >   * I agree that it's okay to merge bug21278_024_v2_extra to 0.2.9. I
 have a `bug21278_extra_029` branch to port those forward.  I'm okay with
 taking that in 0.2.9 or 0.3.0.

 I think 029, in case there is a security issue here.

 `make check test-network-all` passes for me on macOS 10.12 i386 and
 x86_64.

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

Re: [tor-bugs] #21278 [Core Tor/Tor]: Avoid signed integer underflow when comparing versions (Fix TROVE-2017-001)

2017-02-14 Thread Tor Bug Tracker & Wiki

#21278: Avoid signed integer underflow when comparing versions (Fix 
TROVE-2017-001)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 (After the nitpicks are fixed or ignored, I'm happy for this to go into
 marge-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] #21283 [Core Tor/Tor]: Remove broken fallback directory mirrors

2017-02-14 Thread Tor Bug Tracker & Wiki

#21283: Remove broken fallback directory mirrors
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fallback, 028-backport,  |  Actual Points:
  029-backport   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I emailed 12 operators about 15 relays.
 (The remaining 16 were long-term downtime or low averages, which operators
 can't fix.)

 11 relays were on very old or non-recommended versions.
 2 relays had added IPv6 addresses.
 1 relay required a manual IPv6 address update due to #21460.

 If everyone upgrades, we should be back to around ~160 fallbacks in a week
 or two when the list is regenerated.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21461 [Core Tor/Chutney]: Require authentication on all tor control ports

2017-02-14 Thread Tor Bug Tracker & Wiki

#21461: Require authentication on all tor control ports
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In #19765, I accidentally made control port authentication only on for
 clients.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21462 [Core Tor/Chutney]: Add a control socket for every tor instance

2017-02-14 Thread Tor Bug Tracker & Wiki

#21462: Add a control socket for every tor instance
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Maybe we'll need to disable this on Windows

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21463 [Core Tor/Chutney]: Chutney creates keys directory for clients

2017-02-14 Thread Tor Bug Tracker & Wiki

#21463: Chutney creates keys directory for clients
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Trivial   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 But clients don't ever use it.

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

[tor-bugs] #21464 [Core Tor/Chutney]: Make relay and client directory permissions consistent

2017-02-14 Thread Tor Bug Tracker & Wiki

#21464: Make relay and client directory permissions consistent
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Chutney creates the data directory with mode 0777, and when relays add
 keys to it, they modify the permissions to 0700.

 But clients never add keys, so they remain at 777.

 We can make this consistent by creating the directory with mode 0700 to
 begin with.

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

Re: [tor-bugs] #21465 [Core Tor/Tor]: Tor relays fix data directory permissions, but tor clients do not

2017-02-14 Thread Tor Bug Tracker & Wiki

#21465: Tor relays fix data directory permissions, but tor clients do not
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 The fix for this issue in chutney is #21464: we create all the directories
 in mode 0700.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21465 [Core Tor/Tor]: Tor relays fix data directory permissions, but tor clients do not

2017-02-14 Thread Tor Bug Tracker & Wiki

#21465: Tor relays fix data directory permissions, but tor clients do not
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-client
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+--
 When adding control socket support to chutney (#21462), I discovered that
 relays set their data directory permissions to 0700 as a side-effect of
 adding keys to the keys directory.

 But clients don't, because they don't have any (filesystem) keys.

 Is the client state file worth protecting with 0700?
 Would we have many fewer ControlSocket permissions errors if we changed
 the DataDirectory to 0700?

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

Re: [tor-bugs] #21461 [Core Tor/Chutney]: Require authentication on all tor control ports

2017-02-14 Thread Tor Bug Tracker & Wiki

#21461: Require authentication on all tor control ports
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 Fixed in my branch control-fixes on
 https://github.com/teor2345/chutney.git

 Merged: passes tor master's `make test-network-all` on macOS 10.12 and
 Ubuntu 16.04.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] #21462 [Core Tor/Chutney]: Add a control socket for every tor instance

2017-02-14 Thread Tor Bug Tracker & Wiki

#21462: Add a control socket for every tor instance
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 Fixed in my branch control-fixes on
 https://github.com/teor2345/chutney.git

 Merged: passes tor master's `make test-network-all` on macOS 10.12 and
 Ubuntu 16.04.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] #21464 [Core Tor/Chutney]: Make relay and client directory permissions consistent

2017-02-14 Thread Tor Bug Tracker & Wiki

#21464: Make relay and client directory permissions consistent
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 Required for control sockets to work.

 Fixed in my branch control-fixes on
 https://github.com/teor2345/chutney.git

 Merged: passes tor master's `make test-network-all` on macOS 10.12 and
 Ubuntu 16.04.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

[tor-bugs] #21466 [Core Tor/Chutney]: Get chutney's scripts working with standard shell script checking options

2017-02-14 Thread Tor Bug Tracker & Wiki

#21466: Get chutney's scripts working with standard shell script checking 
options
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:  easy intro
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We'll make fewer mistakes if we:
 {{{
 set -e
 set -u
 }}}
 at the top of every script.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21467 [Core Tor/Chutney]: Make chutney tools work with relative paths

2017-02-14 Thread Tor Bug Tracker & Wiki

#21467: Make chutney tools work with relative paths
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Chutney didn't work when called like:
 {{{
 chutney/tools/test-network.sh
 }}}

 In my 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] #21467 [Core Tor/Chutney]: Make chutney tools work with relative paths

2017-02-14 Thread Tor Bug Tracker & Wiki

#21467: Make chutney tools work with relative paths
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Old description:

> Chutney didn't work when called like:
> {{{
> chutney/tools/test-network.sh
> }}}
>
> In my branch

New description:

 Chutney didn't work when called like:
 {{{
 chutney/tools/test-network.sh
 }}}

--

Comment:

 This is fixed in my branch relative-paths, which works on macOS and Linux.

 Merging to master.

 Fixes a bug introduced in #9087.

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

Re: [tor-bugs] #21459 [Metrics/Atlas]: Make atlas fingerprint selectable by double-clicking

2017-02-14 Thread Tor Bug Tracker & Wiki

#21459: Make atlas fingerprint selectable by double-clicking
---+-
 Reporter:  teor   |  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords:  regression |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 The fingerprint got wrapped in #12685 and subsequently in #21350 using a
 different solution. Indeed this wrapping is what prevents double-clicking
 from selecting the entire fingerprint but triple-clicking still seems to
 work.

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

89 matches

Mail list logo