Re: [tor-bugs] #7830 [Core Tor/Tor]: UDP over Tor

[Tor Bug Tracker & Wiki]

#7830: UDP over Tor
--+
 Reporter:  proper|  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: very long
Component:  Core Tor/Tor  |  term
 Severity:  Normal|Version:
 Keywords:  tor-relay needs-proposal  | Resolution:
Parent ID:|  Actual Points:
 Reviewer:| Points:
  |Sponsor:
--+
Changes (by arthuredelstein):

 * cc: arthuredelstein@… (added)
 * severity:   => Normal


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

[tor-bugs] #18920 [Core Tor/Tor]: Make consensus GETINFO return 551 when using microdescs

[Tor Bug Tracker & Wiki]

#18920: Make consensus GETINFO return 551 when using microdescs
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  small |   Reviewer:
  Sponsor:|
--+--
 The tor control-spec says that 551 should be returned for "dir/status"
 queries where microdescs are in use, and so full descriptors are
 unavailable.
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n737

 This doesn't happen for dir/status-vote/current/consensus when tor only
 has a microdesc consensus, instead, tor returns "552 Unrecognized key "dir
 /status-vote/current/consensus".
 https://gitweb.torproject.org/tor.git/tree/src/or/control.c#n2004

 The 552 is misleading and not to spec, instead, we should return 551 with
 a helpful error message.

 Credit to s0rlxmh0 for reporting this issue.

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

Re: [tor-bugs] #18917 [- Select a component]: Have Questions, need help

[Tor Bug Tracker & Wiki]

#18917: Have Questions, need help
--+---
 Reporter:  Swoopswag |  Owner:
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 Looks like tellthebell.com blocks Tor Exit relays.
 This is not a bug in Tor.

 And we can't really help you obtain a new IP address, or reset cookies, or
 evade whatever other broken methods the survey website uses to ensure user
 uniqueness.

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

Re: [tor-bugs] #18919 [Applications/Tor Browser]: Remove swig and unused PGP keys

[Tor Bug Tracker & Wiki]

#18919: Remove swig and unused PGP keys
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  TorBrowserTeam201604R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18919 [Applications/Tor Browser]: Remove swig and unused PGP keys

[Tor Bug Tracker & Wiki]

#18919: Remove swig and unused PGP keys
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Trivial   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Some PGP keys (LXML, PYTHON, M2CRYPTO, flashproxy) are no longer needed
 because the software they are for has been removed.

 swig was only needed for the m2crypto build.

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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Relay fails to self-test its DirPort with AccountingMax enabled

[Tor Bug Tracker & Wiki]

#18616: Relay fails to self-test its DirPort with AccountingMax enabled
-+-
 Reporter:  toralf   |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201604, TorCoreTeam201605   |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  dgoulet, arma|  Actual Points:  20
 |  hours
 | Points:  medium
 |Sponsor:
-+-
Changes (by teor):

 * reviewer:  dgoulet => dgoulet, arma
 * actualpoints:  16 hours => 20 hours


Comment:

 Replying to [comment:22 arma]:
 > 1)
 > {{{
 > \ No newline at end of file
 > }}}
 > for the changes file will produce surprising results when somebody cats
 all the changes files together.

 A1: 2c9b85d fixup! Changes file for #18616
 Also fixes a typo in the changes file name, and rewords one of the changes
 to make it clearer.

 > 2)
 > {{{
 > +static int router_reachability_checks_disabled(void)
 >  {
 >const or_options_t *options = get_options();
 > }}}
 > As a static helper function, it might be a bit cleaner to pass in
 {{{options}}} to it, especially since one of the two callers already has
 an 'options' hanging out ready to be passed in. We're certainly not
 consistent about this, but I think it's the righter thing to do.

 It also makes it slightly easier to unit test the function.

 A2: a12df41 Refactor common code out of reachability checks

 > 3) I like 004e1c2704 but it looks like it does two things -- first is
 the refactor, and second is the change where
 check_whether_orport_reachable() considers net_is_disabled(). "Refactor"
 commits are easiest to review when they don't also change behavior. This
 could become two commits, the first adding the net_is_disabled() to
 check_whether_orport_reachable(), and the second adding the modular
 function along with a note "no actual changes in behavior" to make it
 clear that it's just a refactor.

 A3:
 0a4ac3e Reverts original commit 004e1c2, so I can split it up without a
 force push
 00bb4d7 Avoid checking ORPort reachability when the network is disabled
 a12df41 Refactor common code out of reachability checks

 > 3b) Does the behavior change from 004e1c2704 warrant a changelog entry?
 I think it probably does.

 A3b: 00bb4d7 Avoid checking ORPort reachability when the network is
 disabled

 > 3c) in control.c:
 > {{{
 > } else if (!strcmp(question, "status/reachability-succeeded/or")) {
 >   *answer = tor_strdup(check_whether_orport_reachable() ? "1" :
 "0");
 > } else if (!strcmp(question, "status/reachability-succeeded/dir")) {
 >   *answer = tor_strdup(check_whether_dirport_reachable() ? "1" :
 "0");
 > } else if (!strcmp(question, "status/reachability-succeeded")) {
 >   tor_asprintf(answer, "OR=%d DIR=%d",
 >check_whether_orport_reachable() ? 1 : 0,
 >check_whether_dirport_reachable() ? 1 : 0);
 > }}}
 > are documented as
 > {{{
 > "status/reachability-succeeded/or"
 >   0 or 1, depending on whether we've found our ORPort reachable.
 > "status/reachability-succeeded/dir"
 >   0 or 1, depending on whether we've found our DirPort reachable.
 > "status/reachability-succeeded"
 > }}}
 > I think the "we aren't trying to test reachability on it, so return 1"
 behavior might be surprising here. On the other hand, the reachability did
 *succeed*, in that we're not unhappy with the current state of things.
 Yuck. No need to fix it here but maybe we want to clean this up in the
 future?

 #18851 contains a branch with a control spec patch to clarify this
 behaviour

 > 4) In commit 4dda75fc0 we end up with a new function
 decide_to_advertise_begindir(), that looks like it shares a lot of code
 with the place you cut-and-pasted it from (decide_to_advertise_dirport())?
 Leaving these two functions in place together is begging for bugs in the
 future where one gets out of sync from the other.

 A4: 4e0e555 Refactor DirPort & begindir descriptor checks

 The logic is slightly more complex now, but I think it's better than the
 alternatives:
 * duplicate code,
 * a macro that expands to the function body
 * a third variable in the refactored function indicating either a DirPort
 or begindir check

 > 5)
 > {{{
 > +  /* redundant - if DirPort is unreachable, we don't publish a
 descriptor */
 >if (!check_whether_dirport_reachable())
 > 

[tor-bugs] #18918 [Core Tor/Tor]: Clarify directory and ORPort checking functions

[Tor Bug Tracker & Wiki]

#18918: Clarify directory and ORPort checking functions
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal|   Keywords:  easy doc code refactor
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The OR and dir checking functions in router.c are somewhat confusing. We
 could document them better, or modify their names, or restructure.

 In #18616, we added:
 * decide_to_advertise_begindir

 We already had:
 * check_whether_orport_reachable
 * check_whether_dirport_reachable
 * router_has_bandwidth_to_be_dirserver
 * router_should_be_directory_server
 * dir_server_mode
 * decide_to_advertise_dirport
 * consider_testing_reachability

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18917 [- Select a component]: Have Questions, need help

[Tor Bug Tracker & Wiki]

#18917: Have Questions, need help
--+-
 Reporter:  Swoopswag |  Owner:
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 I have tried many proxy servers, but have had no luck with them. I am a
 cashier at Tacobell, and we have a website where customers had do surveys
 for the store, how can I do the multiple times on the same computer.
 Should this website work?

 Website- tellthebell.com

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18916 [- Select a component]: Have questions need help.

[Tor Bug Tracker & Wiki]

#18916: Have questions need help.
--+-
 Reporter:  Swoopswag |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 So I have tried many proxy servers to try and get this done and have no
 luck. I am cashier for Tacobell, and for work they have us encourage
 customer to do surveys. we get rewarded on who is the best. I have tried
 many ways to get people to do them but sometimes a need help getting a
 couple more surveys. Would I be able to spam multiple surveys on this
 browser? Or if you know a way I could possibly do it. that would be great.
 Open for Ideas.

 Website- Tellthebell.com

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18915 [Applications/Tor Browser]: Omnibox in a non-english Tor Browser has no Disconnect.me as search engine in 6.0a5

[Tor Bug Tracker & Wiki]

#18915: Omnibox in a non-english Tor Browser has no Disconnect.me as search 
engine
in 6.0a5
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff45-esr,
 Severity:  Critical |  TorBrowserTeam201604
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We lost Disconnect.me as search engine somehow in our non-en-US bundles.
 Seems #11236 is showing its ugly head again (see comment 9 and
 https://bugzilla.mozilla.org/show_bug.cgi?id=1126722). Sad that our test
 suite is broken by the transition to ESR45 as well otherwise we would have
 caught this one earlier (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] #18882 [Core Tor/Chutney]: chutney reads the system torrc when generating the router key

[Tor Bug Tracker & Wiki]

#18882: chutney reads the system torrc when generating the router key
--+--
 Reporter:  anonym|  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Can confirm this does work on my system. I ran into this bug today. Thank
 you for the 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] #12407 [HTTPS Everywhere/HTTPS Everywhere: Chrome]: HTTPS Everywhere breaks embed video

[Tor Bug Tracker & Wiki]

#12407: HTTPS Everywhere breaks embed video
-+-
 Reporter:  NewEraCracker|  Owner:  zyan
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/HTTPS Everywhere:   |Version:
  Chrome | Resolution:  fixed
 Severity:  Normal   |  Actual Points:
 Keywords:  httpse-ruleset-bug   | Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by NewEraCracker):

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


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

Re: [tor-bugs] #13374 [HTTPS Everywhere/HTTPS Everywhere: Chrome]: Amazon Web Services rule breaks ge.tt Download

[Tor Bug Tracker & Wiki]

#13374: Amazon Web Services rule breaks ge.tt Download
-+-
 Reporter:  NewEraCracker|  Owner:  zyan
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/HTTPS Everywhere:   |Version:
  Chrome | Resolution:  fixed
 Severity:  Normal   |  Actual Points:
 Keywords:  httpse-ruleset-bug   | Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by NewEraCracker):

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


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

Re: [tor-bugs] #12171 [HTTPS Everywhere/HTTPS Everywhere: Chrome]: HTTPS Everywhere breaks HostGator suspended pages.

[Tor Bug Tracker & Wiki]

#12171: HTTPS Everywhere breaks HostGator suspended pages.
-+-
 Reporter:  NewEraCracker|  Owner:  zyan
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/HTTPS Everywhere:   |Version:
  Chrome | Resolution:  fixed
 Severity:  Normal   |  Actual Points:
 Keywords:  httpse-ruleset-bug   | Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by NewEraCracker):

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


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

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

[Tor Bug Tracker & Wiki]

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

Comment (by iwakeh):

 Replying to [comment:3 karsten]:
 > I'll need a quiet moment to look at the patch, which I don't have today.
 But here's some quick feedback on the cobertura requirement.
 >
 Thanks, for taking the time!

 Your suggestion is far from being crazy. I perfectly agree with the first
 requirement.
 The relaxed requirements in the last two are not necessary in order to
 accommodate using
 the newer cobertura here and the newer checkstyle in #18793, I think.

 Checkstyle and cobertura just help improve development, but it is possible
 to achieve the same
 quality without them. These tasks just help us to avoid checking things
 manually, not a single line
 of code is created or compiled using them.

 And, you're right people who develop usually know what libraries to use or
 even have their preferred versions at hand and would override our versions
 anyway. At least that is what I often do when
 looking at other projects. (unless it breaks, of course ;-)

 Summary (to be added to the Contributor's Guide and FAQ):
 Use only libraries from Debian stable as reference for compiling,
 packaging, and running CollecTor.
 That also includes source generation (which is not in use at the time) and
 javadoc generation.

 Any tools for determining quality metrics and quality reports are
 unrestricted. But, we have some suggested tasks added to our build file
 which aim at debian stable and only deviate for a good reason.

 Hope this is in line with your thoughts.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18914 [Applications/Tor Browser]: Consider removing

[Tor Bug Tracker & Wiki]

#18914: Consider removing 
--+--
 Reporter:  mcs   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff45-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Mozilla is thinking about removing support for  HTML element.
 References:
  https://developer.mozilla.org/en-US/docs/Web/HTML/Element/isindex
  https://groups.google.com/forum/#!topic/mozilla.dev.platform/DV3YBf7wI3M
 and
  https://bugzilla.mozilla.org/show_bug.cgi?id=1266495

 The reason we might want to do this for TB 6.0 is that  generates
 a form that has a label that contains text that comes from the browser's
 UI locale (thus leaking that information).

 There is a risk that some sites are using this tag.

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

Re: [tor-bugs] #13239 [Core Tor/Tor]: Maybe we want three preemptive internal circs for hidden services?

[Tor Bug Tracker & Wiki]

#13239: Maybe we want three preemptive internal circs for hidden services?
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  tor-client, tor-hs,  |Version:
  TorCoreTeam201605  | Resolution:
Parent ID:  #5271|  Actual Points:
 Reviewer:  asn  | Points:  small
 |Sponsor:
 |  SponsorR-can
-+-
Changes (by asn):

 * keywords:  tor-client, tor-hs, TorCoreTeam201604 => tor-client, tor-hs,
 TorCoreTeam201605


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

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

[Tor Bug Tracker & Wiki]

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

 * keywords:  028-triage, TorCoreTeam201604, prop259, tor-guard, tor-guards-
 revamp => 028-triage, TorCoreTeam201605, prop259, tor-guard, tor-
 guards-revamp
 * status:  assigned => 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] #17262 [Core Tor/Tor]: Experimental prototype for guard selection algorithm

[Tor Bug Tracker & Wiki]

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

 * owner:  isis => asn
 * status:  needs_revision => assigned


Comment:

 Changing to May tag, and assigning myself as the owner because that's
 probably closer to the truth than isis.

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

Re: [tor-bugs] #16943 [Core Tor/Tor]: Implement prop250 (Random Number Generation During Tor Voting)

[Tor Bug Tracker & Wiki]

#16943: Implement prop250 (Random Number Generation During Tor Voting)
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:  Tor:
Component:  Core Tor/Tor   |  0.2.9.x-final
 Severity:  Normal |Version:
 Keywords:  tor-hs, TorCoreTeam201605  | Resolution:
Parent ID:  #8244  |  Actual Points:
 Reviewer:  nickm  | Points:  large
   |Sponsor:  SponsorR-must
---+---
Changes (by asn):

 * keywords:  tor-hs, TorCoreTeam201604 => tor-hs, TorCoreTeam201605


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

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

[Tor Bug Tracker & Wiki]

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

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


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

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

[Tor Bug Tracker & Wiki]

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

Comment (by karsten):

 I'll need a quiet moment to look at the patch, which I don't have today.
 But here's some quick feedback on the cobertura requirement.

 How about we distinguish three types of requirements:

 - All packages that are required to run a service on a host system should
 really be in Debian stable.  That is, if somebody takes collector.jar,
 they only need to install openjdk-7-jre, apache2, and maybe a few others,
 but all of those are available via apt-get.

 - Packages required for releasing CollecTor should preferably be in Debian
 stable, but we can make exceptions if there are good reasons.

 - Any packages required for developing only can come from wherever, with a
 slight preference towards Debian stable packages.

 The latter two requirements are more relaxed, because we can expect
 somebody who develops on or releases CollecTor to securely fetch their
 packages from anywhere.  But the first requirement is still as strict as
 before, because we don't want somebody who runs a CollecTor instance to
 juggle versions of arbitrary libraries we decided to use here and there.

 Note that this would also make #18793 a bit easier.

 How crazy does this sound?

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

Re: [tor-bugs] #17983 [Core Tor/Tor]: Build tor with -ftrapv by default

[Tor Bug Tracker & Wiki]

#17983: Build tor with -ftrapv by default
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 Priority:  High |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  TorCoreTeam201604, tor-sponsorS- |Version:
  orphan | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:  small
 |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 I now have a branch 'ftrapv_v2' that implements this.  To make sure that
 things built with the right flags, I used "make V=1 >build_log", and then
 a bunch of grep.  Needs review.

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

Re: [tor-bugs] #18710 [Core Tor/Tor]: dnsserv.c asserts when no supported questions are requested

[Tor Bug Tracker & Wiki]

#18710: dnsserv.c asserts when no supported questions are requested
-+-
 Reporter:  geekmug  |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.???
 Keywords:  dns dnsport tor-client 029-proposed  |Version:  Tor:
Parent ID:   |  0.2.7.6
 Reviewer:  nickm| Resolution:
 |  Actual Points:
 | Points:  very
 |  small
 |Sponsor:
-+-
Changes (by nickm):

 * keywords:  dns dnsport tor-client 027-backport TorCoreTeam201604 => dns
 dnsport tor-client 029-proposed
 * status:  needs_review => needs_revision
 * priority:  Very High => Medium
 * points:   => very small
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.2.???


Comment:

 I've tested Tor 0.2.5 and forward with MX queries to verify that they
 don't actually crash.  It appears they don't. I'm testing by only sending
 a single MX query in the request.

 (Please correct me if I'm wrong!)

 Assuming that there isn't _really_ a crash bug, this is just ugly code,
 nothing more. So it can be a cleanup fix for 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] #13818 [Applications/Tor Browser]: [PATCH] Active tab looks ugly (inherits system color scheme only partially)

[Tor Bug Tracker & Wiki]

#13818: [PATCH] Active tab looks ugly (inherits system color scheme only 
partially)
--+--
 Reporter:  gentoo_root   |  Owner:  mcs
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * keywords:  ff38-esr =>
 * owner:  tbb-team => mcs
 * status:  needs_review => assigned


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

Re: [tor-bugs] #18710 [Core Tor/Tor]: dnsserv.c asserts when no supported questions are requested

[Tor Bug Tracker & Wiki]

#18710: dnsserv.c asserts when no supported questions are requested
-+-
 Reporter:  geekmug  |  Owner:
 Type:  defect   | Status:
 Priority:  Very High|  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  dns dnsport tor-client 027-backport  |Version:  Tor:
  TorCoreTeam201604  |  0.2.7.6
Parent ID:   | Resolution:
 Reviewer:  nickm|  Actual Points:
 | Points:
 |Sponsor:
-+-

Comment (by nickm):

 It looks like this code, currently in dnsserv.c, prevents us from reaching
 the assert?

 {{{
   if (err != DNS_ERR_NONE || !supported_q) {
 /* We got an error?  There's no question we're willing to answer? Then
  * send back an answer immediately; we're done. */
 evdns_server_request_respond(req, err);
 return;
   }
 }}}

 The code as it stands _does_ look wrong, though.  And it looks like
 qtype_all would also have hit this test.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18913 [Applications/Torbutton]: about:tor should not have chrome privileges

[Tor Bug Tracker & Wiki]

#18913: about:tor should not have chrome privileges
+-
 Reporter:  mcs |  Owner:  mcs
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 We should ensure that about:tor runs with only content privileges.

 Changing the getURIFlags() function in src/components/aboutTor.js to
 include {{{Ci.nsIAboutModule.URI_SAFE_FOR_UNTRUSTED_CONTENT}}} in the
 value returned should do the trick, but other things will need to be fixed
 as a result of that change.

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

Re: [tor-bugs] #18710 [Core Tor/Tor]: dnsserv.c asserts when no supported questions are requested

[Tor Bug Tracker & Wiki]

#18710: dnsserv.c asserts when no supported questions are requested
-+-
 Reporter:  geekmug  |  Owner:
 Type:  defect   | Status:
 Priority:  Very High|  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  dns dnsport tor-client 027-backport  |Version:  Tor:
  TorCoreTeam201604  |  0.2.7.6
Parent ID:   | Resolution:
 Reviewer:  nickm|  Actual Points:
 | Points:
 |Sponsor:
-+-

Comment (by nickm):

 It looks like qtype_all is broken by this patch, assuming that qtype_all
 worked?

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

Re: [tor-bugs] #16886 [Applications/Tor Browser]: "Add-on compatibility check dialog" contains Firefox logo

[Tor Bug Tracker & Wiki]

#16886: "Add-on compatibility check dialog" contains Firefox logo
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-branding  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 It looks like Mozilla is removing this, although I have not looked at the
 following bug report in detail:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1262880

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

Re: [tor-bugs] #18901 [Core Tor/Tor]: Should we stop appling --enable-expensive-hardening to constant-time code ?

[Tor Bug Tracker & Wiki]

#18901: Should we stop appling --enable-expensive-hardening to constant-time 
code ?
---+--
 Reporter:  nickm  |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  029-backport 029-proposed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by nickm):

 * status:  new => needs_review


Comment:

 My ftrapv_v2 branch (for #17983) does 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] #17442 [Applications/Tor Browser]: adjust or remove updater cert pinning

[Tor Bug Tracker & Wiki]

#17442: adjust or remove updater cert pinning
--+--
 Reporter:  mcs   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201604  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * status:  needs_information => closed
 * keywords:  TorBrowserTeam201604R => TorBrowserTeam201604
 * resolution:   => fixed


Comment:

 I filed #18912 to track the remaining work (add tests).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18912 [Applications/Tor Browser]: add automated tests for updater cert pinning

[Tor Bug Tracker & Wiki]

#18912: add automated tests for updater cert pinning
--+--
 Reporter:  mcs   |  Owner:  mcs
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff45-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This is a spinoff of #17442. We want to add automated tests to ensure that
 we notice if Mozilla changes something that breaks the updater cert
 pinning.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18911 [- Select a component]: bitcoin donations via BitPay don't work properly for tor users (BitPay uses Cloudflare)

[Tor Bug Tracker & Wiki]

#18911: bitcoin donations via BitPay don't work properly for tor users (BitPay 
uses
Cloudflare)
--+-
 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:|
--+-
 steps to reproduce:

 opened https://www.torproject.org
 clicked on Donate
 clicked on "Other Ways to Donate"
 entered amount to donate
 clicked on the "bitcoin donate now" button
 solve 3 captchas
 finally ended up on https://bitpay.com/checkout

 That page says:
 "
 Oops... that page doesn't exist!
 If it seems like there should be something here, please let us know.
 "

 https://lists.torproject.org/pipermail/tor-talk/2016-April/040750.html

 BitPay will not disable CAPTCHA for tor users trying to donate to the
 torproject:

 To answer your question:
 "would you be willing to disable CAPTCHAs for Tor users to make donations
 work out of the box? "


 This was my first request to BitPay management. The answer was no. I then
 asked if we could offer a payment button that worked through Cloudflare
 and the answer was "not at this time".


 I am very sorry to bring you this news. This issue is also very important
 to me personally. I think people should be able to donate bitcoin to the
 Tor Project from the Tor Browser without jumping through hoops, but this
 is the state of things at the moment.

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

Re: [tor-bugs] #18199 [Applications/Tor Browser]: Firefox icon for browser after update

[Tor Bug Tracker & Wiki]

#18199: Firefox icon for browser after update
--+--
 Reporter:  cypherpunks   |  Owner:  mcs
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * owner:  tbb-team => mcs
 * cc: brade (added)
 * status:  needs_information => assigned


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

Re: [tor-bugs] #17891 [Applications/Tor Browser]: Window classes change after update restart

[Tor Bug Tracker & Wiki]

#17891: Window classes change after update restart
--+--
 Reporter:  cypherpunks   |  Owner:  mcs
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * owner:  tbb-team => mcs
 * status:  new => assigned
 * cc: brade (added)


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

Re: [tor-bugs] #18719 [Metrics/CollecTor]: provide executable jar

[Tor Bug Tracker & Wiki]

#18719: provide executable jar
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

 * status:  needs_information => assigned


Comment:

 Onionoo includes the classes from the required jars (cf.
 
[https://gitweb.torproject.org/onionoo.git/tree/build.xml?id=eedbcbe52160d0250d31bb4f6ee7644815fd989d#n163
 jar task])
 (It is not possible to add jars inside a jar to the classpath. That's why
 we used `zipgroupfileset` in Onionoo.)

 For CollecTor the jar collector.jar will also include the necessary
 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] #18707 [Metrics/CollecTor]: use java 7

[Tor Bug Tracker & Wiki]

#18707: use java 7
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 depends on #18794

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+--
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:  ctip
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Karsten's suggestions:

 == Spam Prevention
 ... a working solution for fetching descriptors from other CollecTor hosts
 without risking being spammed forever: we simply add *multiple* @source
 annotations to a descriptor, one for each source (directory authority IP,
 other CollecTor host IP,
 etc.).  If we later find out that one source was spamming us, we can
 easily delete all descriptors that *only* have the @source annotation with
 the spamming host's IP address.

 Here's an example how the tor daemon annotates descriptors:
 {{{
 @uploaded-at 2016-04-18 18:49:25
 @source "81.17.16.43"
 router pairoj 81.17.16.43 443 0 80
 platform Tor 0.2.6.10 on Linux
 [...]
 }}}
 It's important that we'd only add those @source annotations to
 archived descriptors, not to recent descriptors, or we'd serve those
 descriptors as new every time we're adding a @source.

 It would also be useful to have stats on the number of newly added
 @source annotations per hour, so that we learn if we're getting
 spammed, and to have a script for deleting descriptors that only have
 a given @source annotation.

 == Statistics
 ... one nice thing we could do here is get statistics on
 descriptor completeness out of the box: we just count how many
 descriptors have @source annotations from known CollecTor mirrors vs.
 directory authorities or from wherever we're fetching from.  That will
 tell us immediately how many descriptors we'd have missed without mirrors.

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