Re: [tor-bugs] #13908 [Core Tor/Tor]: Make it safe to set NumDirectoryGuards=1

[Tor Bug Tracker & Wiki]

#13908: Make it safe to set NumDirectoryGuards=1
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-client, needs-   |  Actual Points:
  design guards client-enumeration research- |
  program|
Parent ID:  #21006   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 What do we think about moving to 2 dir guards? We identified problems with
 1, and different problems with 3. Do we get the best of both worlds with
 2, or the worst of both worlds? :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25824 [Core Tor/Tor]: Integrate circuit max_cell_queue_size killer with DoS heartbeats

[Tor Bug Tracker & Wiki]

#25824: Integrate circuit max_cell_queue_size killer with DoS heartbeats
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We just merged #25226 so relays can kill circuits that queue up too many
 cells.

 But we're nervous about picking a threshold that isn't super high, since
 there's no feedback about whether relays are hitting this event in the
 wild: the logs are protocol-warn, so nobody, not us not them, will even
 know if it happens.

 teor suggested that we could tie the circuit killing into the DoS
 heartbeat logs. Something like "and I killed x circuits that had too many
 cells queued".

 This sounds to me like a great idea.

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

Re: [tor-bugs] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-test, 033-backport,|  Actual Points:
  review-group-34, 034-triage-20180328,  |
  034-included-20180401  |
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
 |  SponsorQ
-+-

Comment (by Hello71):

 I have pushed to https://cgit.alxu.ca/tor.git/log/?h=meson an
 implementation of the shared library approach (along with a bunch of other
 crap that I'll have to separate out). This approach seems to be the most
 reliable and, with `-static-libasan`, hopefully fixes all issues with asan
 incompatibilities. remaining problems:

 1. still need to actually build a shared library, so either #23846 or
 switch to a better build system.

 2. rustdoc doesn't take `-Z sanitizer` (https://github.com/rust-
 lang/rust/issues/43031), but I think maybe we can hack around that by
 cleaning first and just accept that doctests won't have sanitizers for
 now.

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

Re: [tor-bugs] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-

Comment (by neel):

 I have a new patch: `b25511-004.patch`.

 It also passes CI: https://github.com/torproject/tor/pull/51.

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

Re: [tor-bugs] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-
Changes (by neel):

 * Attachment "b25511-004.patch" added.

 Patch (Revision 4)

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

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1000 light years
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 [https://searxes.danwin1210.me/ Searxes] - probably the 1st search engine
 which warn Cloudflare websites

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:  1000
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 [https://searxes.danwin1210.me/ Searxes] is flagging Cloudflare websites
 for now

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

Re: [tor-bugs] #25818 [Core Tor/Tor]: Investigate using coveralls with travis

[Tor Bug Tracker & Wiki]

#25818: Investigate using coveralls with travis
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, 034-roadmap-subtask  |  Actual Points:
  029-backport 031-backport 032-backport |
  033-backport   |
Parent ID:  #25550   | Points:
 Reviewer:  isis |Sponsor:
-+-
Changes (by isis):

 * status:  needs_review => merge_ready


Comment:

 Reviewed and fiddled with some stuff on GH. It builds!
 https://coveralls.io/github/torproject/tor It looks great!

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

Re: [tor-bugs] #24658 [Core Tor/Tor]: Split/refactor crypto.h into smaller separate modules

[Tor Bug Tracker & Wiki]

#24658: Split/refactor crypto.h into smaller separate modules
-+-
 Reporter:  isis |  Owner:
 |  ffmancera
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto, refactor, review-|  Actual Points:
  group-32, review-group-34, |
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 I think I reviewed that as #24660 ?

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

Re: [tor-bugs] #25440 [Core Tor/Tor]: Broken openat syscall in Sandbox mode

[Tor Bug Tracker & Wiki]

#25440: Broken openat syscall in Sandbox mode
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, 033-must, regression,   |  Actual Points:
  033-triage-20180326, 033-included-20180326 |
  033-backport, AffectsTails |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Jigsaw52):

 I was wrong. The number of parameters is just strace pretty printing the
 call. The syscall is exactly the same on both cases.

 The problem is related to the constant AT_FDCWD.
 The changes on this branch fixed the problem on my machine:

 https://github.com/Jigsaw52/tor/tree/quick-fix-25440

 It does not work if I only change SCMP_CMP_STR to SCMP_CMP. The cast for
 uint32_t is needed. I do not know why and I think they will break on other
 machines but it seems like a good starting point for a better solution.

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

Re: [tor-bugs] #25762 [Core Tor/Tor]: Make periodic events array with flags including when they are enabled/disabled

[Tor Bug Tracker & Wiki]

#25762: Make periodic events array with flags including when they are
enabled/disabled
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, client, |  Actual Points:
  s8-perf|
Parent ID:  #25500   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by nickm):

 I left some comments on the PR.

 My main suggestion here would be:
   * Always initialize every periodic event.  Instead of initializing only
 some...
   * Only call `periodic_event_launch()` on the events that should be
 running.
   * Add a `periodic_event_disable()` that delegates to
 `mainloop_event_cancel()`; call that on the events that should not be
 running.

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

Re: [tor-bugs] #25818 [Core Tor/Tor]: Investigate using coveralls with travis

[Tor Bug Tracker & Wiki]

#25818: Investigate using coveralls with travis
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, 034-roadmap-subtask  |  Actual Points:
  029-backport 031-backport 032-backport |
  033-backport   |
Parent ID:  #25550   | Points:
 Reviewer:  isis |Sponsor:
-+-
Changes (by isis):

 * reviewer:   => isis


Comment:

 Adding myself as reviewer since teor reviewed #24378 which was one of my
 assigned reviews this week.

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

Re: [tor-bugs] #25515 [Core Tor/Tor]: Add a unit test for geoip_load_file()

[Tor Bug Tracker & Wiki]

#25515: Add a unit test for geoip_load_file()
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  isis  |Sponsor:
--+
Changes (by isis):

 * 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] #25515 [Core Tor/Tor]: Add a unit test for geoip_load_file()

[Tor Bug Tracker & Wiki]

#25515: Add a unit test for geoip_load_file()
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  isis  |Sponsor:
--+

Comment (by isis):

 Couple trivial things:

  1. We can remove the "is this necessary?" comments on things that are
 tested twice between `test_geoip_load_file()` and
 `test_geoip6_load_file()`. I think it's fine to test the same thing more
 than once; it's better than not testing at all, or assuming another test
 will catch the bad behaviour you have in mind.
  2. couple typos: s/1nd/1st/ s/2st/2nd/
  3. I think we might need `TT_FORK|SKIP_ON_WINDOWS` for
 `test_geoip6_load_file()`.
  4. Same as !#3, but also for `test_geoip_load_2nd_file()`.

 I've applied your patches to a `bug25515`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug25515 branch]
 based on the latest master, and [https://travis-
 ci.org/isislovecruft/tor/builds/367311635 the Travis tests fail] because
 of the unused variables `num_countries_geoip2` and `num_countries_geoip`.
 Since the patches didn't automatically apply for some reason, I went ahead
 and added some extra commits fixing the above nitpicks while I was
 manually applying.

 -

 Less trivial issues:

  1. In your `test_geoip_load_2nd_file()` test, there's a FIXME:

  {{{#!c
   int num_countries_geoip = geoip_get_n_countries();

   /* Load 2st geoip (empty) file */
   const char FNAME2[] = SRCDIR "/src/test/geoip_dummy";
   tt_int_op(0, OP_EQ, geoip_load_file(AF_INET, FNAME2));

   int num_countries_geoip2 = geoip_get_n_countries();
   /* FIXME: should not this be different? */
   /* tt_int_op(num_countries_geoip, OP_NE, num_countries_geoip2); */
  }}}

  The relevant bits of code from `geoip_load_file()` are:

  {{{#!c
 int
 geoip_load_file(sa_family_t family, const char *filename)
 {
   FILE *f;
   const char *msg = "";
   const or_options_t *options = get_options();
   int severity = options_need_geoip_info(options, ) ? LOG_WARN :
 LOG_INFO;
   crypto_digest_t *geoip_digest_env = NULL;

   tor_assert(family == AF_INET || family == AF_INET6);

   if (!(f = tor_fopen_cloexec(filename, "r"))) {
 log_fn(severity, LD_GENERAL, "Failed to open GEOIP file %s.  %s",
filename, msg);
 return -1;
   }
   if (!geoip_countries)
 init_geoip_countries();

   if (family == AF_INET) {
 if (geoip_ipv4_entries) {
   SMARTLIST_FOREACH(geoip_ipv4_entries, geoip_ipv4_entry_t *, e,
 tor_free(e));
   smartlist_free(geoip_ipv4_entries);
 }
 geoip_ipv4_entries = smartlist_new();
   } else { /* AF_INET6 */
 // [snip]
   }
   geoip_digest_env = crypto_digest_new();

   log_notice(LD_GENERAL, "Parsing GEOIP %s file %s.",
  (family == AF_INET) ? "IPv4" : "IPv6", filename);
   while (!feof(f)) {
 char buf[512];
 if (fgets(buf, (int)sizeof(buf), f) == NULL)
   break;
 crypto_digest_add_bytes(geoip_digest_env, buf, strlen(buf));
 /*  track full country name. */
 geoip_parse_entry(buf, family);
   }
   /* abort and return -1 if no entries/illformed?*/
   fclose(f);
  }}}

  So it's clearing all the ''entries'' (but curiously ''not'' the
 countries!), which is quite non-intuitive and doesn't appear to be
 documented anywhere, so I'm not even sure if this is the intended
 behaviour. Then you're hitting the `fclose()` there since the file is
 empty, so nothing else happens.

 I'm not sure what to do about the non-intuitive and possibly unintentional
 behaviour, i.e. whether we should also be clearing the countries in
 `geoip_load_file()` when we clear the entries? I think we actually want to
 be calling `clear_geoip_db()` in `geoip_load_file()`.

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

Re: [tor-bugs] #24659 [Core Tor/Tor]: Wrap our sha2 interface in Rust which implements the appropriate traits

[Tor Bug Tracker & Wiki]

#24659: Wrap our sha2 interface in Rust which implements the appropriate traits
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-crypto, review-group-34,   |  Actual Points:
  034-triage-20180328|
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  Sponsor3-can
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Added some initial thoughts on the code. I don't have much in the way of
 thinking about the linking issues though -- let me know if you want me to
 hack on those, or if we should merge without them and have them be a
 separate 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] #25733 [Core Tor/Tor]: Bug: Assertion bin_counts > 0 failed in circuit_build_times_get_xm at ../src/or/circuitstats.c:772.

[Tor Bug Tracker & Wiki]

#25733: Bug: Assertion bin_counts > 0 failed in circuit_build_times_get_xm at
../src/or/circuitstats.c:772.
-+--
 Reporter:  cstest   |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.10
 Severity:  Normal   | Resolution:
 Keywords:  034-proposed  crash  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by mikeperry):

 * status:  new => needs_review


Comment:

 Ok here is a branch to avoid the assert:
 https://oniongit.eu/mikeperry/tor/commits/bug25733_032

 If we like that, we should probably backport as far back as we go (what is
 that, 0.2.9?). Since this maybe could happen in some other rare case, we
 want both this and #23100 going forward.

 #23100 might be nice to backport too, so that this timeout miscalculation
 doesn't happen quite so easily for onion service clients. It was tested as
 a package deal with #23114, though..

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

Re: [tor-bugs] #25423 [Core Tor/Stem]: Treat 'ExitRelay 0' as a reject-all policy

[Tor Bug Tracker & Wiki]

#25423: Treat 'ExitRelay 0' as a reject-all policy
---+--
 Reporter:  atagar |  Owner:  dmr
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+--

Comment (by teor):

 Replying to [comment:6 dmr]:
 >
 >  4. Multiple configuration changes could cause our cache to be
 invalid
 > As alluded to above, I had to edit the cache invalidation anyway for
 this change.
 >
 > All of these torrc options, if changed, could invalidate our cache:
 (code snippet)
 > {{{
 > CONFIG_OPTIONS_AFFECTING_EXIT_POLICY = (
 >   'ExitRelay',
 >   'ExitPolicy',
 >   'ExitPolicyRejectPrivate',
 >   'ExitPolicyRejectLocalInterfaces',
 >   'IPv6Exit',
 > )
 > }}}
 >
 > See the corresponding commit.
 >

 The ExitPolicyRejectPrivate and ExitPolicyRejectLocalInterfaces also
 depend on:
 * Address
 * the addresses in any published or local *Port option
 * OutboundBindAddress*
 * possibly other options, which should be documented in the man page or
 the relevant function comments in tor. Maybe you'll have to read the code.

 Trying to find all the options that can change an exit policy could be
 difficult. tor doesn't guarantee the options that affect the exit policy,
 and these options have changed in previous versions. (Fortunately, those
 versions are now obsolete.)

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

Re: [tor-bugs] #23693 [Core Tor/Tor]: 0.3.1.7: Assertion threadpool failed in cpuworker_queue_work

[Tor Bug Tracker & Wiki]

#23693: 0.3.1.7: Assertion threadpool failed in cpuworker_queue_work
-+-
 Reporter:  alif |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.9
 Severity:  Normal   | Resolution:
 Keywords:  prop286, 034-triage-20180328,|  Actual Points:
  034-must crash 033-backport 032-backport   |
  031-backport   |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * reviewer:  dgoulet => asn


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

Re: [tor-bugs] #25440 [Core Tor/Tor]: Broken openat syscall in Sandbox mode

[Tor Bug Tracker & Wiki]

#25440: Broken openat syscall in Sandbox mode
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, 033-must, regression,   |  Actual Points:
  033-triage-20180326, 033-included-20180326 |
  033-backport, AffectsTails |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by Jigsaw52):

 * cc: danielpinto52@… (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] #25440 [Core Tor/Tor]: Broken openat syscall in Sandbox mode

[Tor Bug Tracker & Wiki]

#25440: Broken openat syscall in Sandbox mode
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, 033-must, regression,   |  Actual Points:
  033-triage-20180326, 033-included-20180326 |
  033-backport, AffectsTails |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by Jigsaw52):

 * Attachment "orconfig.h" 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] #25440 [Core Tor/Tor]: Broken openat syscall in Sandbox mode

[Tor Bug Tracker & Wiki]

#25440: Broken openat syscall in Sandbox mode
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, 033-must, regression,   |  Actual Points:
  033-triage-20180326, 033-included-20180326 |
  033-backport, AffectsTails |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by Jigsaw52):

 * Attachment "strace.log" 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] #25440 [Core Tor/Tor]: Broken openat syscall in Sandbox mode

[Tor Bug Tracker & Wiki]

#25440: Broken openat syscall in Sandbox mode
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, 033-must, regression,   |  Actual Points:
  033-triage-20180326, 033-included-20180326 |
  033-backport, AffectsTails |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by Jigsaw52):

 * Attachment "tor.log" 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] #25440 [Core Tor/Tor]: Broken openat syscall in Sandbox mode

[Tor Bug Tracker & Wiki]

#25440: Broken openat syscall in Sandbox mode
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, 033-must, regression,   |  Actual Points:
  033-triage-20180326, 033-included-20180326 |
  033-backport, AffectsTails |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Jigsaw52):

 I believe I am experiencing the same issue, with the master branch, on
 Ubuntu 18.04 64bits, which uses libc 2.27.

 I can confirm the string is being interned correctly: I have checked the
 pointers on the sandbox initialization and on the failing syscall and they
 are the same.

 I have tor run under strace and greped for openat calls and noticed
 something: the openat call that kills tor has and extra argument which all
 the others do not.
 I believe the cause of this problem could be related to this.

 I have attached my logs and my orconfig.h file.

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

Re: [tor-bugs] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:34 neel]:
 > New patch: `b25511-003.patch`.
 >
 > I also mocked `tor_gettimeofday()` here.
 Thanks! I think that's most of what we need.

 A few small changes, and I think we'll be good:
 * `mock_tor_gettimeofday()` can be in src/test/test_controller.c because
 nothing else uses it
 * `mock_tor_gettimeofday()` doesn't have to be declared with `MOCK_DECL()`
 nor defined with `MOCK_IMPL()`; it can be defined as `static` in
 src/test/test_controller.c

 Please feel free to force-push your updated changes to your GitHub pull
 request.

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

Re: [tor-bugs] #24660 [Core Tor/Tor]: Wrap our PRNG interface(s) in Rust with appropriate traits

[Tor Bug Tracker & Wiki]

#24660: Wrap our PRNG interface(s) in Rust with appropriate traits
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-crypto, rng, roadmap, 034  |  Actual Points:
  -roadmap-master, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:   | Points:  2
 Reviewer:  nickm|Sponsor:
 |  SponsorQ
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 I've added some comments and questions to the branch on github. Let's
 discuss more there.  Thanks, 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] #25691 [Core Tor/Tor]: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in onion_pick_cpath_exit

[Tor Bug Tracker & Wiki]

#25691: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in
onion_pick_cpath_exit
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, 034-must 033-backport|  Actual Points:
  033-maybe-must |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by teor):

 * reviewer:   => dgoulet


Comment:

 Assigning dgoulet as reviewer, because this branch covers #25691 and
 #25692, and dgoulet is reviewer on #25692.

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

Re: [tor-bugs] #25400 [Core Tor/Tor]: CIRC_BW event miscounts, should count all circ data

[Tor Bug Tracker & Wiki]

#25400: CIRC_BW event miscounts, should count all circ data
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-stats, review-group-34, 034  |  Actual Points:
  -roadmap-subtask, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #25546   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by mikeperry):

 Ok I rebased on to latest origin/master, and squashed and changed that
 second fixup commit message.

 Branch is mikeperry/bug25400_squashed.

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

Re: [tor-bugs] #23840 [Community/Tor Support]: Google's reCAPTCHA fails 100%

[Tor Bug Tracker & Wiki]

#23840: Google's reCAPTCHA fails 100%
+--
 Reporter:  cypherpunks |  Owner:  hiro
 Type:  defect  | Status:  reopened
 Priority:  Immediate   |  Milestone:
Component:  Community/Tor Support   |Version:
 Severity:  Blocker | Resolution:
 Keywords:  cloudflare,google,captcha,noscript  |  Actual Points:
Parent ID:  #18361  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Replying to [comment:62 soicey]:
 > So in conclusion, there is no solution and we are screwed?
 This is what you get when you allow a monopoly to take over other areas
 (Loolle Fonts, Loolle js CDN, Loolle Groups, Loolle Books, Loolle
 Captchas, Loolle Browser, ...). Support Mozilla and the Tor Project and
 stop telling your friends how secure Loolle Browser is and how the TB team
 should've went with Loolle Browser.

 It took PR uncomfortable Cloudflare 2 and something years to finally
 loosen the apartheid wall around Tor Browser users and to switch to gate
 keeping mode only for some. I wonder whether PR comfortable Loolle will
 ever care. Maybe they'll remove *.torproject.org domains in their search
 engine someday.

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

Re: [tor-bugs] #25823 [Applications/Tor Launcher]: Tor Launcher inconsistently sets TZ=UTC for tor process

[Tor Bug Tracker & Wiki]

#25823: Tor Launcher inconsistently sets TZ=UTC for tor process
---+---
 Reporter:  catalyst   |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  clock-skew, timezone   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * cc: mcs (added)


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

Re: [tor-bugs] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-

Old description:

> When we tell people that their clocks are wrong, it's frequently because
> they've set up their systems with the wrong time zone.  It would be
> helpful to tell torbrowser (or some other controller) about this
> information, so that it can give more useful error messages on time-
> related bootstrapping failures.
>
> ~~One complication here is (IIUC) TB runs, and runs tor, with its TZ set
> to UTC.~~
>
> Further investigation suggests that TB might not set `TZ` for the first
> time it starts tor.

New description:

 When we tell people that their clocks are wrong, it's frequently because
 they've set up their systems with the wrong time zone.  It would be
 helpful to tell torbrowser (or some other controller) about this
 information, so that it can give more useful error messages on time-
 related bootstrapping failures.

 ~~One complication here is (IIUC) TB runs, and runs tor, with its TZ set
 to UTC.~~

 Further investigation suggests that TB might not set `TZ` for the first
 time it starts tor.  Opened #25823 for the Tor Launcher behavior
 inconsistency.

--

Comment (by catalyst):

 Please direct further discussion about Tor Launcher's setting of `TZ` for
 tor to #25823.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25823 [Applications/Tor Launcher]: Tor Launcher inconsistently sets TZ=UTC for tor process

[Tor Bug Tracker & Wiki]

#25823: Tor Launcher inconsistently sets TZ=UTC for tor process
---+---
 Reporter:  catalyst   |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:  clock-skew,
   |  timezone
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 Some investigations done as part of #25511 suggest that the first time Tor
 Launcher runs tor, it either unsets or fails to change `TZ`.  If tor
 crashes or needs to be restarted for some reason, then it sets `TZ=UTC`.
 My summary of one instance of this behavior is at ticket:25511#comment:32.

 Tor Launcher should probably leave the time zone alone when starting tor,
 so tor can detect what local time for the machine is.  We should also
 consider the privacy impact of revealing a user's timezone through logging
 (see #18112 for one instance of this concern).

 In any case Tor Launcher should probably be consistent about which
 timezone it starts tor in.

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

Re: [tor-bugs] #25762 [Core Tor/Tor]: Make periodic events array with flags including when they are enabled/disabled

[Tor Bug Tracker & Wiki]

#25762: Make periodic events array with flags including when they are
enabled/disabled
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, client, |  Actual Points:
  s8-perf|
Parent ID:  #25500   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by dgoulet):

 Alpha version: `ticket25762_034_01`.

 This can probably be unit tested (at least for the double setup checks).

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

Re: [tor-bugs] #23840 [Community/Tor Support]: Google's reCAPTCHA fails 100%

[Tor Bug Tracker & Wiki]

#23840: Google's reCAPTCHA fails 100%
+--
 Reporter:  cypherpunks |  Owner:  hiro
 Type:  defect  | Status:  reopened
 Priority:  Immediate   |  Milestone:
Component:  Community/Tor Support   |Version:
 Severity:  Blocker | Resolution:
 Keywords:  cloudflare,google,captcha,noscript  |  Actual Points:
Parent ID:  #18361  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by soicey):

 So in conclusion, there is no solution and we are screwed?

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

Re: [tor-bugs] #17949 [Core Tor/Tor]: Make loopback address search more accurate

[Tor Bug Tracker & Wiki]

#17949: Make loopback address search more accurate
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy tor-client tor-relay loopback   |  Actual Points:
  weird-configuration|
Parent ID:  #17991   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by rl1987):

 * status:  needs_revision => needs_review


Comment:

 I made a new branch, rebased and cleaned up my git history. It seems that
 I cannot create pull request against torproject repo on Github as I'm not
 "officially" a fork (I think my fork historically predates torproject
 mirror repo). However I made a pull request against my git master which I
 keep in-sync with upstream:

 https://github.com/rl1987/tor/pull/2

 This should make the patch easier to read.

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

Re: [tor-bugs] #25423 [Core Tor/Stem]: Treat 'ExitRelay 0' as a reject-all policy

[Tor Bug Tracker & Wiki]

#25423: Treat 'ExitRelay 0' as a reject-all policy
---+--
 Reporter:  atagar |  Owner:  dmr
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+--

Comment (by dmr):

 > I ran into a further bug related to cache invalidation and still have it
 to file, but it's largely orthogonal, and it's not as straightforward of a
 fix, so I didn't just go fix it.
 Filed; see #25821.

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

Re: [tor-bugs] #25821 [Core Tor/Stem]: Stem getconf cache doesn't clear for CONF_CHANGED events; probably should set value

[Tor Bug Tracker & Wiki]

#25821: Stem getconf cache doesn't clear for CONF_CHANGED events; probably 
should
set value
---+
 Reporter:  dmr|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dmr):

 atagar: FYI, I'm happy to take on this ticket, but I won't be able to get
 to it for another week or so.

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

Re: [tor-bugs] #25821 [Core Tor/Stem]: Stem getconf cache doesn't clear for CONF_CHANGED events; probably should set value

[Tor Bug Tracker & Wiki]

#25821: Stem getconf cache doesn't clear for CONF_CHANGED events; probably 
should
set value
---+
 Reporter:  dmr|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dmr):

 So I propose that stem changes its cache behavior to //set// the
 `'getconf'` cache //only// within `_confchanged_listener()`, to the
 value(s) provided by the event.
 It seems superfluous to do it within `set_options()` if it's going to be
 set soon after.

 However, one advantage I could see to setting the cache in `set_options()`
 is so that code like this would work intuitively without issuing a GETCONF
 again:
 {{{
 #!python
 SETCONF ContactInfo=me

 def some_actions_together():
   global controller

   contact_1 = controller.get_conf('ContactInfo')
   controller.set_conf('ContactInfo', 'someone else')
   contact_2 = controller.get_conf('ContactInfo')
   print(contact_2)

 some_actions_together()
 }}}
 But code like this //currently doesn't// work intuitively because
 `load_conf()` doesn't have the configuration values
 [[https://gitweb.torproject.org/torspec.git/tree/control-
 spec.txt?id=d4a64fbf5aaba383638d9f3c70bd2951f8c5ad89#n1365|specified in
 its response]]:
 {{{
 #!python
 SETCONF ContactInfo=me

 def some_actions_together():
   global controller

   contact_1 = controller.get_conf('ContactInfo')

   new_config = controller.get_info('config-text').replace("ContactInfo
 me", "ContactInfo someone else")
   controller.load_conf(new_config)

   contact_2 = controller.get_conf('ContactInfo')

 some_actions_together()
 }}}
 (that could be improved if `load_conf()` clears the `'getconf'` cache.)

 No matter what we pick, I think there's potential for race conditions in
 complex scenarios...

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

Re: [tor-bugs] #25821 [Core Tor/Stem]: Stem getconf cache doesn't clear for CONF_CHANGED events; probably should set value

[Tor Bug Tracker & Wiki]

#25821: Stem getconf cache doesn't clear for CONF_CHANGED events; probably 
should
set value
---+
 Reporter:  dmr|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dmr):

 Here's the code as of
 
[[https://gitweb.torproject.org/stem.git/tree/stem/control.py?id=82b22046f40f49579ff37c4247db50050334998a#n1071|`82b22046f40f49579ff37c4247db50050334998a`]]:
 {{{
 #!python
 def _confchanged_listener(event):
   if self.is_caching_enabled():
 self._set_cache(dict((k, None) for k in event.config), 'getconf')

 # ...

 self.add_event_listener(_confchanged_listener, EventType.CONF_CHANGED)
 }}}

 This code actually usually won't clear the cache when it intends to. The
 cache key is `lower()`ed when set in `set_options()`
 
([[https://gitweb.torproject.org/stem.git/tree/stem/control.py?id=82b22046f40f49579ff37c4247db50050334998a#n2402|code
 link]]):
 {{{
 #!python
   if self.is_caching_enabled():
 to_cache = {}

 for param, value in params:
   param = param.lower()

   # ...

   to_cache[param] = value

   # ...

 # reset any getinfo parameters that can be changed by a SETCONF

 self._set_cache(dict([(k.lower(), None) for k in
 CACHEABLE_GETINFO_PARAMS_UNTIL_SETCONF]), 'getinfo')
 self._set_cache(None, 'listeners')

 self._set_cache(to_cache, 'getconf')
 self._set_cache({'get_custom_options': None})
 }}}
 ... but we can't guarantee that the event we receive will have a given
 case. In my tests, it was always the canonical torrc case, but that's not
 concretely specified in the control spec
 ([[https://gitweb.torproject.org/torspec.git/tree/control-
 spec.txt?id=d4a64fbf5aaba383638d9f3c70bd2951f8c5ad89#n259|"most keywords
 are case-sensitive")]].

 At first, this looks like a simple change to fix (use `k.lower()`), but
 when we consider what happens when a config options is set, we see it's
 not so straightforward - the cache gets cleared.

 Here's code for an adhoc test:
 {{{
 #!python
 # run this example interactively (don't copy/paste everything) in tor-
 prompt
 def print_getconf_cache_contents():
   global controller

   with controller._cache_lock:
 cache_keys = [k for k in controller._request_cache.keys() if
 k.startswith('getconf.')]
 if cache_keys:
   print("printing cache")
   for k in cache_keys:
 value = controller._request_cache[k]
 print("config cache %s has value: %s" % (k, value))
 else:
   print("cache is empty")

 def print_conf_event_and_cache(event):
   # blank line to make prettier at a prompt
   print('')

   for k,v in event.config.items():
 print("Config %s set to: %s" % (k, v))

   print_getconf_cache_contents()

 # in tor-prompt, controller is simply available for us to use
 controller.add_event_listener(print_conf_event_and_cache,
 stem.control.EventType.CONF_CHANGED)

 # for example simplicity WAIT for the output between each set_conf() call
 controller.set_conf('ContactInfo', 'hi there')
 # ^ generate output via our listener
 # with k.lower() implementation, note that the cache doesn't have
 'getconf.contactinfo'

 # simulate a SETCONF from another controller
 SETCONF ContactInfo="hello back"
 # ^ generate output via our listener
 # with unchanged implementation, note that the cache is still set to "hi
 there"
 # with k.lower() implementation, note that the cache doesn't have
 'getconf.contactinfo'

 # simulate a SETCONF from another controller
 SETCONF ContactInfo=
 # ^ generate output via our listener
 # with unchanged implementation, note that the cache is still set to "hi
 there"
 # with k.lower() implementation, note that the cache doesn't have
 'getconf.contactinfo'

 # clean up
 controller.remove_event_listener(print_conf_event_and_cache)
 }}}

 To do a simple change to the implementation, change this line in
 `_confchanged_listener()` from:
 {{{
 #!python
 self._set_cache(dict((k, None) for k in event.config), 'getconf')
 }}}
 to:
 {{{
 #!python
 self._set_cache(dict((k.lower(), None) for k in event.config),
 'getconf')
 }}}
 (adding `.lower()` after `k`)

 You can see that the cache doesn't clear, but when it does with a simple
 `.lower()` change... it doesn't really retain data for long (because the
 `set_conf()` causes a `CONF_CHANGED`, which clears the cache).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs 

Re: [tor-bugs] #25822 [Webpages/Website]: Relay search says that my relay "implements the v2 directory protocol or higher."

[Tor Bug Tracker & Wiki]

#25822: Relay search says that my relay "implements the v2 directory protocol or
higher."
--+
 Reporter:  Dbryrtfbcbhgf |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Dbryrtfbcbhgf):

 * Attachment "bug.png" added.

 photo showing the issue

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

[tor-bugs] #25822 [Webpages/Website]: Relay search says that my relay "implements the v2 directory protocol or higher."

[Tor Bug Tracker & Wiki]

#25822: Relay search says that my relay "implements the v2 directory protocol or
higher."
--+
 Reporter:  Dbryrtfbcbhgf |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Relay search says that my relay {{{This relay implements the v2 directory
 protocol or higher.}}} Even though the relay is running Tor 0.3.2.10 which
 should be a v3 directory protocol.
 
https://metrics.torproject.org/rs.html#details/5D86AFD7CE409251E67B373B4F0E780A0F41C944

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25821 [Core Tor/Stem]: Stem getconf cache doesn't clear for CONF_CHANGED events; probably should set value

[Tor Bug Tracker & Wiki]

#25821: Stem getconf cache doesn't clear for CONF_CHANGED events; probably 
should
set value
---+
 Reporter:  dmr|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 As mentioned in #25423, I found a cache-invalidation bug in
 `stem.control.Controller`.

 The tl;dr is that the `getconf` cache currently doesn't get cleared
 properly by the listener that intends to clear it, but //clearing//
 probably isn't what we actually want to do.

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

Re: [tor-bugs] #24378 [Core Tor/Tor]: Prune the list of supported consensus methods

[Tor Bug Tracker & Wiki]

#24378: Prune the list of supported consensus methods
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop290, 034-triage-20180328, fast-  |  Actual Points:
  fix|
Parent ID:   | Points:  .5
 Reviewer:  teor |Sponsor:
-+-
Changes (by isis):

 * reviewer:  isis, teor => teor


Comment:

 Replying to [comment:7 teor]:
 > I'm not sure if isis also wants to review this code.

 Nope, your review looks good! Thanks, teor! I'll take review on #25818 in
 place of 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] #25820 [- Select a component]: Can't create Reddit account (Captcha issue?)

[Tor Bug Tracker & Wiki]

#25820: Can't create Reddit account (Captcha issue?)
--+---
 Reporter:  soicey|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 Duplicate #23840

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25820 [- Select a component]: Can't create Reddit account (Captcha issue?)

[Tor Bug Tracker & Wiki]

#25820: Can't create Reddit account (Captcha issue?)
--+
 Reporter:  soicey|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hello,

 I am having issues using Tor to create a Reddit account.  I followed the
 suggestions given by users to disable Javascript, but doing that doesn't
 work for me.  So when I try without disabling it, I'm getting an error
 during Captcha saying something to the effect of they are receiving
 multiple requests from my computer or network and I cannot create an
 account at this time.  Is there any way to get around this??  Thanks in
 advance!!

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

Re: [tor-bugs] #25790 [Applications/Tor Browser]: Orfox lists external apps when the user clicks and holds an Android URI in a WebPage

[Tor Bug Tracker & Wiki]

#25790: Orfox lists external apps when the user clicks and holds an Android URI 
in
a WebPage
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #25703| Points:
 Reviewer:|Sponsor:
--+--
Changes (by igt0):

 * cc: sysrqb, gk (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] #25818 [Core Tor/Tor]: Investigate using coveralls with travis

[Tor Bug Tracker & Wiki]

#25818: Investigate using coveralls with travis
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, 034-roadmap-subtask  |  Actual Points:
  029-backport 031-backport 032-backport |
  033-backport   |
Parent ID:  #25550   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-ci, 034-roadmap-subtaskj =>
 tor-ci, 034-roadmap-subtask 029-backport 031-backport 032-backport
 033-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] #25792 [Core Tor/Tor]: 32 bit ASAN failures in _dl_get_tls_static_info

[Tor Bug Tracker & Wiki]

#25792: 32 bit ASAN failures in _dl_get_tls_static_info
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  jenkins   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mikeperry):

 * keywords:   => jenkins


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

Re: [tor-bugs] #25818 [Core Tor/Tor]: Investigate using coveralls with travis

[Tor Bug Tracker & Wiki]

#25818: Investigate using coveralls with travis
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-ci, 034-roadmap-subtaskj  |  Actual Points:
Parent ID:  #25550| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 See my branch `coveralls_029` against maint-0.2.9 .  Github PR at
 https://github.com/torproject/tor/pull/49

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

Re: [tor-bugs] #24378 [Core Tor/Tor]: Prune the list of supported consensus methods

[Tor Bug Tracker & Wiki]

#24378: Prune the list of supported consensus methods
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop290, 034-triage-20180328, fast-  |  Actual Points:
  fix|
Parent ID:   | Points:  .5
 Reviewer:  isis, teor   |Sponsor:
-+-

Comment (by nickm):

 Also see branch `bug24378_spec` in my torspec repo for the requested dir-
 spec changes.

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

Re: [tor-bugs] #24378 [Core Tor/Tor]: Prune the list of supported consensus methods

[Tor Bug Tracker & Wiki]

#24378: Prune the list of supported consensus methods
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop290, 034-triage-20180328, fast-  |  Actual Points:
  fix|
Parent ID:   | Points:  .5
 Reviewer:  isis, teor   |Sponsor:
-+-

Comment (by nickm):

 Added some fixup/squash commits to resolve your concerns above.

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

Re: [tor-bugs] #25423 [Core Tor/Stem]: Treat 'ExitRelay 0' as a reject-all policy

[Tor Bug Tracker & Wiki]

#25423: Treat 'ExitRelay 0' as a reject-all policy
---+--
 Reporter:  atagar |  Owner:  dmr
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+--
Changes (by dmr):

 * status:  assigned => needs_review
 * reviewer:   => atagar
 * cc: dmr (added)


Comment:

 atagar:
 I don't think the conflicting branch is "ready" to merge, per se, but I'm
 switching ticket status so you might be able to review the above.
 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] #25423 [Core Tor/Stem]: Treat 'ExitRelay 0' as a reject-all policy

[Tor Bug Tracker & Wiki]

#25423: Treat 'ExitRelay 0' as a reject-all policy
---+--
 Reporter:  atagar |  Owner:  dmr
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dmr):

 I've pushed a few commits for the issue here:
 `g...@github.com:dmr-x/stem.git`
 branch: `25423-get-exit-policy`
 revrange:
 
`2018f3fd2642f43aeab8e1e0d2142a6a4905e651..0f797ee5de4a7e25d307203d65a044ca1b9e9534`

 web link:
 https://github.com/dmr-x/stem/tree/25423-get-exit-policy

 These commits should address the issue almost entirely.


 However, in prepping these to submit, I saw that atagar recently addressed
 #25739. The changes are very similar (cool!) but overlap imperfectly (if
 they were identical, I'd be a bit freaked out!).
 I rebased my changes to //right before// the commits for #25739, but I'd
 need to spend some time to merge the changes together. (I can do that -
 it'll just likely not be for a week or so.)


 I'd like to provide some info in this Trac ticket.
 Namely: I'd like to go over the changes I pushed, as well as some
 rationale and what I think might remain with the issue after changes are
 merged.

 For reference, I tested against `Tor version 0.3.2.10 (git-
 0edaa32732ec8930).`

  1. Failure for `GETINFO exit-policy/full` to return info.
 I noticed in my testing that `GETINFO exit-policy/full` does not always
 return info.
 In that case, I've always seen this:
 {{{
 >>> GETINFO exit-policy/full
 551 router_get_my_routerinfo returned NULL
 }}}

 I've noticed two circumstances in which the exit-policy is unqueryable:
 * tor is configured as a relay, and it //has not yet learned its address//
 (i.e. `GETINFO address` also fails)
 * tor is configured as a client

 The former is transient and doesn't typically last long, but //could// for
 instance last a while if the relay doesn't have network access.
 The latter is persistent, i.e. the client-only configuration ALWAYS
 returns this:
 {{{
 >>> GETINFO exit-policy/full
 551 router_get_my_routerinfo returned NULL
 }}}

 `Controller.get_exit_policy()` has the `default` parameter. Without
 specifying a default, `get_exit_policy()` will raise an exception in these
 cases.

 So `Controller.get_exit_policy(None)` is handy to avoid an exception, as
 I've seen `nyx` and other parts of `stem` do. But since
 `get_exit_policy()` previously would ~always return something, and is now
 changing to a form that is less stable - and for clients always fails -
 consumers of this updated API have to be weary.
 As mentioned, I checked `nyx`'s code - luckily it always uses
 `default=None`, so that shouldn't cause any problems.

 Nonetheless, we can't be sure who all is using `stem` - maybe we need to
 note this possibility in the changelog?

 Or maybe we should change the functionality, so that consumers of
 `controller.get_exit_policy()` don't have this problem / have to wait?
 We could potentially do a `get_conf('ORPort')` and return `None`
 proactively if tor is running as a client (i.e. we don't have an `ORPort`
 configured).

  2. Potential tor bug: waiting for address in non-exit relays
 Of particular note:
 The behavior of returning NULL / waiting for knowing an address happens
 even in non-exit relays, i.e. even when the exit policy should be fully
 known as `reject *:*` beforehand by the config alone.

 atagar: Perhaps we should file this as a bug in tor?

  3. Fixed cache-invalidation bugs
 Two commits I pushed are related to existing cache-invalidation bugs, but
 I ran into them when testing for cache invalidation related to the
 changes.
 The crux was: `exitpolicy` instead of `exit_policy` cache key, and
 `exitpolicy` compared with (non-`lower()`ed) `ExitPolicy`.
 Since there weren't any tests (unit or integ) for the cache invalidation
 here, I added regression tests.

 I ran into a further bug related to cache invalidation and still have it
 to file, but it's largely orthogonal, and it's not as straightforward of a
 fix, so I didn't just go fix it.

  4. Multiple configuration changes could cause our cache to be invalid
 As alluded to above, I had to edit the cache invalidation anyway for this
 change.

 All of these torrc options, if changed, could invalidate our cache: (code
 snippet)
 {{{
 CONFIG_OPTIONS_AFFECTING_EXIT_POLICY = (
   'ExitRelay',
   'ExitPolicy',
   'ExitPolicyRejectPrivate',
   'ExitPolicyRejectLocalInterfaces',
   'IPv6Exit',
 )
 }}}

 See the corresponding commit.

  5. Additional event that can invalidate our cache
 If our relay's address changes, then our ExitPolicy may change (due to the
 default rule of rejecting its own address).

 In looking at the 

[tor-bugs] #25819 [Internal Services/Service - jenkins]: Email committers on jenkins compile+test failures

[Tor Bug Tracker & Wiki]

#25819: Email committers on jenkins compile+test failures
-+
 Reporter:  mikeperry|  Owner:  weasel
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Can we make a jenkins hook to email committers since the last successful
 build upon build failure?

 One reason that this has not been done in the past is because jenkins
 often has false positives in the form of dead/bad/incomplete build
 environments.

 So: How about this hook only bother to email people if a build has made it
 past ./configure and into actual compilation stage?

 Sure, there may be random things like ASAN executables that fail to run
 because of a bug in the new ASAN version for a platform, but that just
 means we should write autoconf tests to catch things like that.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25818 [Core Tor/Tor]: Investigate using coveralls with travis

[Tor Bug Tracker & Wiki]

#25818: Investigate using coveralls with travis
--+--
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-ci, 034-roadmap-subtaskj
Actual Points:|  Parent ID:  #25550
   Points:|   Reviewer:
  Sponsor:|
--+--
 Coveralls can let us know when pull requests would change test coverage,
 and by how much.

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

Re: [tor-bugs] #25741 [Applications/Tor Browser]: Create tor-browser for mobile branch based on mozilla-central

[Tor Bug Tracker & Wiki]

#25741: Create tor-browser for mobile branch based on mozilla-central
--+--
 Reporter:  gk|  Owner:  sysrqb
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201804  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * owner:  tbb-team => sysrqb
 * status:  new => assigned


Comment:

 Repo: https://git.torproject.org/user/sysrqb/tor-browser.git
 Branch: bug25741_orfox_patches

 Current status: The branch is actively being rebased, so don't expect
 stability. The branch does not include any tor-browser patches. Most Orfox
 patches are updated/rewritten. This branch does not include Orfox patches
 that rely on Orbot. From tor-browser-52.7.3esr-8.0-1-build2, the Orfox
 patches currently excluded from the above rebase-branch are:

 {{{
 c981d290167b8547789849194ed12dd763f1f892 - Orfox: Fix #1 - Improve build
 instructions
 d17c8a5eddfc5b1241c65ff8cba9684f8ddc9237 - Orfox: NetCipher enabled,
 checks if orbot is installed
 0642e45b991b25a0419dcb0e583320f10b17f0ed - Orfox: Centralized proxy
 applied to CrashReporter, SuggestClient, Distribution,
 AbstractCommunicator and BaseResources.
 ee7554ab2fc836445fabe93ec0d9b256e5665ede - Orfox: add BroadcastReceiver to
 receive Tor status from Orbot
 2a4853c5e267f7cfa75b771c65bf81232e66d14e - Orfox: queue URL Intents and
 Tab:Load events when Orbot is not yet started
 9bc0b6bf3fc49d07c07dbd3755db5d2ac6da60d6 - Orfox: receive Tor status in
 thread so they arrive when event sync blocks
 b5e9a36b9c333790fdea41e84c30d19b43aa58ac - Orfox: remove Tab:Load event
 queuing and only use Intent queuing
 85b696c5a0e3c9e5d22c06fa179b512abcf22816 - Orfox: disable screenshots and
 prevent page from being in "recent apps"
 acde62dc92325842ea70de678878f68117618448 - Orfox: hook up default panic
 trigger to "quit and clear"
 f69137ac1edb29e3b193b2feeb6f581b7ba4170a - Orfox: Disabling search widget.
 6e59d7eeb5ae4bf23dec2685d12bdd4f2b6e4df5 - Orfox: Adding GCM sender ID.
 28bbaf1fdc792d2ff67b28769cff6bcdd2249a9d - Orfox: Update orfox branding
 and icon
 f69137ac1edb29e3b193b2feeb6f581b7ba4170a - Orfox: Disabling search widget.
 6e59d7eeb5ae4bf23dec2685d12bdd4f2b6e4df5 - Orfox: Adding GCM sender ID.
 d5e91af5b5c6dc3812e9d85caed908e5ef07cc86 - Orfox: Strings fix, probably a
 WONTAPPLY ESR59.
 a3270e7c8c07a62ee093f3b248fe9bab1e2e0619 - fix crash with registerReceiver
 for Orbot status
 b88a0e4355a73561a542043c18eb1b2b7a617171 - addresses #9 to handle NPE on
 Distribution load
 9bd1a8972351ca0ff3ff12c3661fd8dc10914ade - fixes #10 disables attempts to
 access AccountManager
 61fc96d200948f725a77dacba9f8d0cac1142ef8 - handle #11 crash related to tor
 status receiver unregistering
 }}}

 We still must audit the code and confirm its proxy-safe. Some of the other
 patches are specifically for Orbot capability, and right now it seems
 unnecessary to introduce those patches and resolve rebasing conflict, if
 torlauncher is a dependency for the first alpha.

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

Re: [tor-bugs] #22874 [Obfuscation/Snowflake]: Standalone broker (independent of App Engine)

[Tor Bug Tracker & Wiki]

#22874: Standalone broker (independent of App Engine)
---+
 Reporter:  dcf|  Owner:  cmm32
 Type:  project| Status:  closed
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

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


Comment:

 Replying to [comment:7 dcf]:
 > Replying to [comment:6 dcf]:
 > > I think now we just need https://snowflake-reg.appspot.com/ to upload
 the code from [https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/appengine?id=36debdfdd24e978fc323ec352852fc4af0bc4ae5
 appengine] so that clients start communicating with the standalone broker.
 >
 > I think we're not going to regain access to https://snowflake-
 reg.appspot.com/. I think the way forward is to do #23947; i.e., move the
 proxy-hosting page away from keroserene.net, and then we configure the
 proxy on the new host to use the new broker.

 Done in comment:15:ticket:23947.

 The standalone broker is now the primary broker. Let's leave proxy-go
 instances running for the old App Engine broker for a time.

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

Re: [tor-bugs] #25817 [Applications/Tor Browser]: Add ansible scripts for setup of nigthly build server

[Tor Bug Tracker & Wiki]

#25817: Add ansible scripts for setup of nigthly build server
---+--
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  boklm201804, TorBrowserTeam201804  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 I started working on that in branch `bug_25817`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25817=b969c285a94b21ae41dd60227455685a9aec2d34

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

Re: [tor-bugs] #23947 [Obfuscation/Snowflake]: Move Snowflake proxy page somewhere devs can write

[Tor Bug Tracker & Wiki]

#23947: Move Snowflake proxy page somewhere devs can write
---+
 Reporter:  dcf|  Owner:  dcf
 Type:  project| Status:  closed
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

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


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

Re: [tor-bugs] #23947 [Obfuscation/Snowflake]: Move Snowflake proxy page somewhere devs can write

[Tor Bug Tracker & Wiki]

#23947: Move Snowflake proxy page somewhere devs can write
---+--
 Reporter:  dcf|  Owner:  dcf
 Type:  project| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:15 arlolra]:
 > > Here is a small patch for review. attachment:bug23947.patch​
 >
 > Looks like you missed:
 >
 > {{{
 > proxy/static/options.html:  https://keroserene.net/snowflake;>here.
 > }}}
 >
 > and maybe
 >
 > {{{
 > proxy/static/index.html:https://github.com/keroserene/snowflake;
 target="_blank">Snowflake
 > }}}
 >
 > should point to https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/

 Oops, good catch. For the second one, I think the intention was to show
 the project README, so I changed the link to point to the wiki page rather
 than the source code repo.

 All committed:
 https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=a762becbaa4b3e75b1e42e782f4cd426b4e345e9
 https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=a9630a82343f13b101dc4fc8ac7be3b94eb69cf3
 https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=947636ae817fdb393b4fcb2901bf52bca36cef65

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25817 [Applications/Tor Browser]: Add ansible scripts for setup of nigthly build server

[Tor Bug Tracker & Wiki]

#25817: Add ansible scripts for setup of nigthly build server
-+-
 Reporter:  boklm|  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  boklm201804,
 Severity:  Normal   |  TorBrowserTeam201804
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We should add to `tor-browser-build/tools/ansible` some ansible scripts to
 setup a nightly build machine.

 This would make it easier to reinstall a nightly build machine, and could
 also be used by other people who want to make nightly builds.

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

Re: [tor-bugs] #25692 [Core Tor/Tor]: onion_extend_cpath: Non-fatal assertion info || client failed.

[Tor Bug Tracker & Wiki]

#25692: onion_extend_cpath: Non-fatal assertion info || client failed.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-must 033-backport regression |  Actual Points:
  chutney 034-included-20180403 033-maybe-must   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * reviewer:   => dgoulet


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

Re: [tor-bugs] #25804 [Obfuscation/Snowflake]: Domain fronting to App Engine stopped working

[Tor Bug Tracker & Wiki]

#25804: Domain fronting to App Engine stopped working
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  moat   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

 * keywords:   => moat


Old description:

> On or about 2018-04-13 16:00:00 UTC, domain-fronted requests for
> snowflake-reg.appspot.com stopped working. It appears to affect fronting
> to all appspot.com domains, not only ours. This leaves all currently
> deployed clients unable to register themselves.
>
> Requests now fail with status code 502:
> {{{
> $ wget -q -O - --content-on-error -S https://www.google.com/ --header
> 'Host: snowflake-reg.appspot.com'
>   HTTP/1.1 502 Bad Gateway
>   Date: Sun, 15 Apr 2018 04:58:49 GMT
>   Content-Type: text/html
>   Server: HTTP server (unknown)
>   Content-Length: 209
>   X-XSS-Protection: 1; mode=block
>   X-Frame-Options: SAMEORIGIN
>   Alt-Svc: hq=":443"; ma=2592000; quic=51303432; quic=51303431;
> quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="42,41,39,35"
> 502 Bad Gateway\
> This HTTP request has a Host header that is not covered \
> by the TLS certificate used. Due to an infrastructure change, \
> this request cannot be processed.
> }}}
>
> This ticket is to document the issue; I'm not sure we can do anything
> about it directly.
>
> Other related tickets:
>  * #22782, use non-Google domain fronts
>  * #25594, use non-fronting-based registration

New description:

 On or about 2018-04-13 16:00:00 UTC, domain-fronted requests for
 *.appspot.com stopped working. It appears to affect fronting to all
 appspot.com domains, not only ours. This has broken Snowflake client
 registration and Moat (#25807).

 Requests now fail with status code 502:
 {{{
 $ wget -q -O - --content-on-error -S https://www.google.com/ --header
 'Host: snowflake-reg.appspot.com'
   HTTP/1.1 502 Bad Gateway
   Date: Sun, 15 Apr 2018 04:58:49 GMT
   Content-Type: text/html
   Server: HTTP server (unknown)
   Content-Length: 209
   X-XSS-Protection: 1; mode=block
   X-Frame-Options: SAMEORIGIN
   Alt-Svc: hq=":443"; ma=2592000; quic=51303432; quic=51303431;
 quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="42,41,39,35"
 502 Bad Gateway\
 This HTTP request has a Host header that is not covered \
 by the TLS certificate used. Due to an infrastructure change, \
 this request cannot be processed.
 }}}

 This ticket is to document the issue; I'm not sure we can do anything
 about it directly.

 Other related tickets:
  * #22782, use non-Google domain fronts
  * #25594, use non-fronting-based registration

--

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

Re: [tor-bugs] #25791 [Core Tor/Tor]: test_util_fgets_eagain fails on FreeBSD 0.2.9

[Tor Bug Tracker & Wiki]

#25791: test_util_fgets_eagain fails on FreeBSD 0.2.9
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  jenkins   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mikeperry):

 * keywords:   => jenkins


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

Re: [tor-bugs] #25758 [Core Tor/Tor]: Correction for Proposal 291

[Tor Bug Tracker & Wiki]

#25758: Correction for Proposal 291
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-spec, prop291  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 +1.  Internet-speak is fun, but the collective intellectual contribution
 of all non-native English speakers is more important.

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

Re: [tor-bugs] #23947 [Obfuscation/Snowflake]: Move Snowflake proxy page somewhere devs can write

[Tor Bug Tracker & Wiki]

#23947: Move Snowflake proxy page somewhere devs can write
---+--
 Reporter:  dcf|  Owner:  dcf
 Type:  project| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arlolra):

 > Here is a small patch for review. attachment:bug23947.patch​

 Looks like you missed:

 {{{
 proxy/static/options.html:  https://keroserene.net/snowflake;>here.
 }}}

 and maybe

 {{{
 proxy/static/index.html:https://github.com/keroserene/snowflake;
 target="_blank">Snowflake
 }}}

 should point to https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/

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

Re: [tor-bugs] #25691 [Core Tor/Tor]: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in onion_pick_cpath_exit

[Tor Bug Tracker & Wiki]

#25691: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in
onion_pick_cpath_exit
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, 034-must 033-backport|  Actual Points:
  033-maybe-must |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 I have a new branch that fixes this for me on chutney:
 `bug25691_033_again`.  The fix is more complicated this time,
 unfortunately -- so maybe we should merge it into 0.3.4 before we consider
 a backport?

 There's a pull request at https://github.com/torproject/tor/pull/48 .

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

Re: [tor-bugs] #25692 [Core Tor/Tor]: onion_extend_cpath: Non-fatal assertion info || client failed.

[Tor Bug Tracker & Wiki]

#25692: onion_extend_cpath: Non-fatal assertion info || client failed.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-must 033-backport regression |  Actual Points:
  chutney 034-included-20180403 033-maybe-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 See #25691 for a possible 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] #25816 [Metrics/Onionoo]: Release Onionoo 6.0-1.13.0

[Tor Bug Tracker & Wiki]

#25816: Release Onionoo 6.0-1.13.0
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Onionoo 1.13.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 Are there any tickets other than #25332 that we should include in this
 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] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.

[Tor Bug Tracker & Wiki]

#20283: Tor Browser should run without a `/proc` filesystem.
-+-
 Reporter:  yawning  |  Owner:
 |  pospeselr
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-sandboxing,  |  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:  #20773   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:24 tom]:
 > Is this something we should try to uplift?

 It already has r+ in https://bugzilla.mozilla.org/show_bug.cgi?id=859782.
 Sure, if we could get this into beta, great! But I am not so optimistic.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25816 [Metrics/Onionoo]: Release Onionoo 6.0-1.13.0

[Tor Bug Tracker & Wiki]

#25816: Release Onionoo 6.0-1.13.0
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Onionoo 1.13.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 We [https://metrics.torproject.org/onionoo.html#versions_6_0 announced]
 Onionoo's protocol version 6.0 to be released/deployed after April 14,
 2018. Let's do it in the next few days.

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

Re: [tor-bugs] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.

[Tor Bug Tracker & Wiki]

#20283: Tor Browser should run without a `/proc` filesystem.
-+-
 Reporter:  yawning  |  Owner:
 |  pospeselr
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-sandboxing,  |  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:  #20773   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 Is this something we should try to uplift?

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

Re: [tor-bugs] #23840 [Community/Tor Support]: Google's reCAPTCHA fails 100%

[Tor Bug Tracker & Wiki]

#23840: Google's reCAPTCHA fails 100%
+--
 Reporter:  cypherpunks |  Owner:  hiro
 Type:  defect  | Status:  reopened
 Priority:  Immediate   |  Milestone:
Component:  Community/Tor Support   |Version:
 Severity:  Blocker | Resolution:
 Keywords:  cloudflare,google,captcha,noscript  |  Actual Points:
Parent ID:  #18361  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 {{{
 Mike:
 1) On the thread with Google about ReCaptcha: To be honest, I think that
 reaching out to them like this is a waste of time. I should have
 objected to the idea earlier. Public pressure about exactly how bad this
 situation is will be the only thing that will move the needle in terms
 of them devoting resources to the problem. For pete's sake.. This is a
 company that is basically the primary/only gateway to much of the
 Internet, and it has decided that certain IP addresses *do not deserve
 access to that Internet*. Full stop. This is not a problem that gets
 solved by having our devs talk to their devs to "nerd harder". This
 should be a PR bloodbath..  We should have made it one months ago.
 }}}

 https://lists.torproject.org/pipermail/tor-project/2018-April/001738.html

 (BtW if you didn't know: chrome sucks, chromium sucks, v8 js engine sucks,
 chromum's networking stack sucks, recapatcha sucks, chromebooks suck,
 google sucks)

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

Re: [tor-bugs] #25758 [Core Tor/Tor]: Correction for Proposal 291

[Tor Bug Tracker & Wiki]

#25758: Correction for Proposal 291
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-spec, prop291  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

 * keywords:   => tor-spec, prop291
 * status:  new => closed
 * resolution:   => fixed


Comment:

 I pushed a fix. I agree that it is a funny word but can be especially
 confusing for non-English speaker.

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

Re: [tor-bugs] #25815 [Metrics/Onionoo]: Speed up hourly updater performance

[Tor Bug Tracker & Wiki]

#25815: Speed up hourly updater performance
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 [[Image(onionoo-start-end.png, 700px)]]

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

Re: [tor-bugs] #25815 [Metrics/Onionoo]: Speed up hourly updater performance

[Tor Bug Tracker & Wiki]

#25815: Speed up hourly updater performance
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * Attachment "onionoo-start-end.png" 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

[tor-bugs] #25815 [Metrics/Onionoo]: Speed up hourly updater performance

[Tor Bug Tracker & Wiki]

#25815: Speed up hourly updater performance
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 When looking at Onionoo's logs with irl the other day we noticed that the
 hourly updater sometimes takes as long as 45 minutes.

 We obviously need to be careful not to let this time get closer to 60
 minutes or even exceed that time.

 I just looked a little bit closer at the logs and made a graph. It shows
 three phases of the hourly updater:
  - before: from starting the updater to writing details documents;
  - write: writing details documents;
  - after: from after writing details documents to the end.

 The graph compares total runtimes on the x axis with the three phases on
 the y axis. I'm reading two things in this graph.
  - Writing details documents really takes a long time. It's never faster
 than 15 minutes and can take longer than 30 minutes in some cases.
  - Whenever an hourly update takes longer than, say, 40 minutes, it's not
 just the details documenting that takes longer than usual, but also the
 phase before takes longer. I guess the system is just generally slower at
 those times.

 I'd say let's look at details document writing for optimizing runtime.
 Maybe we can decide early that we don't have to update a file. But that's
 just guessing, we should add more logging to that code, as right now the
 logs are silent for those 30 to 45 minutes.

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

Re: [tor-bugs] #25226 [Core Tor/Tor]: Circuit cell queue can fill up memory

[Tor Bug Tracker & Wiki]

#25226: Circuit cell queue can fill up memory
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, tor-relay, tor-dos,|  implemented
  033-must, review-group-34, security,   |  Actual Points:
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-

Comment (by nickm):

 merged that too; 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] #25786 [Core Tor/Tor]: Policies for HTTPTunnelPort

[Tor Bug Tracker & Wiki]

#25786: Policies for HTTPTunnelPort
--+--
 Reporter:  pyhedgehog|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #25803 [Core Tor/Tor]: Infinite restart loop when daemon crashes

[Tor Bug Tracker & Wiki]

#25803: Infinite restart loop when daemon crashes
---+--
 Reporter:  tiejohg2sahth  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  systemd?   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dgoulet):

 * keywords:   => systemd?
 * component:  - Select a component => Core Tor/Tor
 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #25226 [Core Tor/Tor]: Circuit cell queue can fill up memory

[Tor Bug Tracker & Wiki]

#25226: Circuit cell queue can fill up memory
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, tor-relay, tor-dos,|  implemented
  033-must, review-group-34, security,   |  Actual Points:
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-

Comment (by dgoulet):

 Spec change: `ticket25226_01`.

 It mentions 0.3.3.6-rc which isn't released yet so we can either merge it
 now or when we release. No strong opinion.

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

Re: [tor-bugs] #25813 [Internal Services/Service - jenkins]: Update tor-rust builds to use new correct tor-rust-dependencies location

[Tor Bug Tracker & Wiki]

#25813: Update tor-rust builds to use new correct tor-rust-dependencies location
-+
 Reporter:  nickm|  Owner:  weasel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 done

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

Re: [tor-bugs] #25691 [Core Tor/Tor]: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in onion_pick_cpath_exit

[Tor Bug Tracker & Wiki]

#25691: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in
onion_pick_cpath_exit
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, 034-must 033-backport|  Actual Points:
  033-maybe-must |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  reopened => accepted


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

Re: [tor-bugs] #25692 [Core Tor/Tor]: onion_extend_cpath: Non-fatal assertion info || client failed.

[Tor Bug Tracker & Wiki]

#25692: onion_extend_cpath: Non-fatal assertion info || client failed.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-must 033-backport regression |  Actual Points:
  chutney 034-included-20180403 033-maybe-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted
 * milestone:  Tor: 0.3.4.x-final => Tor: 0.3.2.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] #25805 [Applications/Tor Browser]: Setting zoom.minPercent to 150 requires additional manual zooming

[Tor Bug Tracker & Wiki]

#25805: Setting zoom.minPercent to 150 requires additional manual zooming
--+---
 Reporter:  heyjoe|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mcs):

 I think this is also a Firefox issue in that there is no way to set the
 default zoom level.  Here is some more info: https://support.mozilla.org
 /en-US/questions/1147570

 I am pretty sure that `zoom.minPercent` sets the lowest value to which you
 can change the page-specific zoom level, but does not increase the default
 value. You might have better luck changing `layout.css.devPixelsPerPx`
 which seems like the right thing to do to accommodate a high-dpi display.
 Please let us know if that works for you.

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

Re: [tor-bugs] #24659 [Core Tor/Tor]: Wrap our sha2 interface in Rust which implements the appropriate traits

[Tor Bug Tracker & Wiki]

#24659: Wrap our sha2 interface in Rust which implements the appropriate traits
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-crypto, review-group-34,   |  Actual Points:
  034-triage-20180328|
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  Sponsor3-can
-+-
Changes (by asn):

 * reviewer:  catalyst => nickm


Comment:

 (Switching reviewer from catalyst to nickm)

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

Re: [tor-bugs] #24378 [Core Tor/Tor]: Prune the list of supported consensus methods

[Tor Bug Tracker & Wiki]

#24378: Prune the list of supported consensus methods
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop290, 034-triage-20180328, fast-  |  Actual Points:
  fix|
Parent ID:   | Points:  .5
 Reviewer:  isis, teor   |Sponsor:
-+-
Changes (by teor):

 * reviewer:  isis => isis, teor


Comment:

 Looks good to me, I left a review on github with two nitpick changes:
 * fix some missing words in a commit message
 * please don't remove a unit test for a far future consensus method

 We will also need a dir-spec change like this one:
 {{{
 [ As of 0.2.6.1-alpha, authorities no longer advertise or negotiate
   any consensus methods lower than 13. ]
 }}}

 I'm not sure if isis also wants to review this code.

 Let's also make sure someone has run "make test-network-all" on this
 branch on an IPv6/mixed system, with tor-stable linked to 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] #25226 [Core Tor/Tor]: Circuit cell queue can fill up memory

[Tor Bug Tracker & Wiki]

#25226: Circuit cell queue can fill up memory
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, tor-relay, tor-dos,|  implemented
  033-must, review-group-34, security,   |  Actual Points:
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 LGTM; merging to 0.3.3 and forward.

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

Re: [tor-bugs] #25226 [Core Tor/Tor]: Circuit cell queue can fill up memory

[Tor Bug Tracker & Wiki]

#25226: Circuit cell queue can fill up memory
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, tor-relay, tor-dos,|  Actual Points:
  033-must, review-group-34, security,   |
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_revision => merge_ready


Comment:

 Replying to [comment:34 arma]:
 > Tiny but potentially fun bug:
 >
 > {{{
 > +static int32_t max_circuit_cell_queue_size;
 > }}}
 >
 > That starts it out at 0, right?

 Well that is a great catch! lol...

 >
 > So until the relay gets (or has) a consensus (e.g. because it just
 restarted and it's trying to bootstrap but somebody starts using it
 anyway), any circuits get closed if they get a cell?
 >
 > Maybe we should initialize it to RELAY_CIRC_CELL_QUEUE_SIZE_DEFAULT at
 the very start?

 Fixup commit: `3d1243f6f2a42324`

 Again:

 Branch (with fixup): `bug25226_033_01`
 Branch (squashed): `bug25226_033_02`

 Going in `merge_ready` for nickm's eyes.

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

Re: [tor-bugs] #25811 [Applications/Tor Browser]: yahoo search is useless and should be removed from the search options

[Tor Bug Tracker & Wiki]

#25811: yahoo search is useless and should be removed from the search options
--+
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 Yes, I did try Yahoo search from the URL bar and searching for "free tax
 filing" (without the quotes) gives me again numerous results. FWIW: Your
 Tor Browser does not seem to work properly as your onion icon is crossed
 out red. Not sure if that's related to your problems. You could try
 downloading a clean, new Tor Browser checking whether you can reproduce
 your issue with 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] #25814 [Core Tor/Tor]: Should Travis use "make distcheck"?

[Tor Bug Tracker & Wiki]

#25814: Should Travis use "make distcheck"?
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, 034-roadmap-subtask  |  Actual Points:
Parent ID:  #25550   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-ci, 034-roadmap-master, 034-triage-20180328,
 034-included-20180328 => tor-ci, 034-roadmap-subtask


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25814 [Core Tor/Tor]: Should Travis use "make distcheck"?

[Tor Bug Tracker & Wiki]

#25814: Should Travis use "make distcheck"?
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-ci, 034-roadmap-master,
 Severity:  Normal   |  034-triage-20180328, 034-included-20180328
Actual Points:   |  Parent ID:  #25550
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 I just noticed that we had broken "make dist" on master, because one of
 the jenkins builders wasn't passing.  I fixed it with 197d1992dba2fe.

 Should our Travis builds be reconfigured to use "make distcheck" instead
 of "make all && make check"?  It takes only a little bit longer, but it
 would help us be sure that we weren't running into any issues like the one
 above, or #25732.

 Instead of passing things to "configure" directly in this case, we would
 need to use the `DISTCHECK_CONFIGURE_FLAGS` flag to set the configuration
 options that distcheck would use.

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

Re: [tor-bugs] #25811 [Applications/Tor Browser]: yahoo search is useless and should be removed from the search options

[Tor Bug Tracker & Wiki]

#25811: yahoo search is useless and should be removed from the search options
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 it does give brief three-result returns on kanye west and maybe some info
 on him off to the right, but i'm not really searching for kanye west
 this is almost as useless as disconnect.us

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

Re: [tor-bugs] #25811 [Applications/Tor Browser]: yahoo search is useless and should be removed from the search options

[Tor Bug Tracker & Wiki]

#25811: yahoo search is useless and should be removed from the search options
--+
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * Attachment "goagain.png" added.

 it doesn't even give results to their own trending searches

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25813 [Internal Services/Service - jenkins]: Update tor-rust builds to use new correct tor-rust-dependencies location

[Tor Bug Tracker & Wiki]

#25813: Update tor-rust builds to use new correct tor-rust-dependencies location
-+
 Reporter:  nickm|  Owner:  weasel
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 It appears that some of the tor-rust* builds are failing because they are
 taking their Rust dependencies from
 https://git.torproject.org/user/sebastian/tor-rust-dependencies .

 This URL is no longer correct: the official URL is now (and should remain)
 https://git.torproject.org/tor-rust-dependencies.git

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

Re: [tor-bugs] #25792 [Core Tor/Tor]: 32 bit ASAN failures in _dl_get_tls_static_info

[Tor Bug Tracker & Wiki]

#25792: 32 bit ASAN failures in _dl_get_tls_static_info
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 This seems to have "gotten better" somehow. I sure didn't do anything to
 fix it, though.

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

Re: [tor-bugs] #25804 [Obfuscation/Snowflake]: Domain fronting to App Engine stopped working

[Tor Bug Tracker & Wiki]

#25804: Domain fronting to App Engine stopped working
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by mcs):

 * cc: brade, mcs (added)


Old description:

> On or about 2018-03-13 16:00:00 UTC, domain-fronted requests for
> snowflake-reg.appspot.com stopped working. It appears to affect fronting
> to all appspot.com domains, not only ours. This leaves all currently
> deployed clients unable to register themselves.
>
> Requests now fail with status code 502:
> {{{
> $ wget -q -O - --content-on-error -S https://www.google.com/ --header
> 'Host: snowflake-reg.appspot.com'
>   HTTP/1.1 502 Bad Gateway
>   Date: Sun, 15 Apr 2018 04:58:49 GMT
>   Content-Type: text/html
>   Server: HTTP server (unknown)
>   Content-Length: 209
>   X-XSS-Protection: 1; mode=block
>   X-Frame-Options: SAMEORIGIN
>   Alt-Svc: hq=":443"; ma=2592000; quic=51303432; quic=51303431;
> quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="42,41,39,35"
> 502 Bad Gateway\
> This HTTP request has a Host header that is not covered \
> by the TLS certificate used. Due to an infrastructure change, \
> this request cannot be processed.
> }}}
>
> This ticket is to document the issue; I'm not sure we can do anything
> about it directly.
>
> Other related tickets:
>  * #22782, use non-Google domain fronts
>  * #25594, use non-fronting-based registration

New description:

 On or about 2018-04-13 16:00:00 UTC, domain-fronted requests for
 snowflake-reg.appspot.com stopped working. It appears to affect fronting
 to all appspot.com domains, not only ours. This leaves all currently
 deployed clients unable to register themselves.

 Requests now fail with status code 502:
 {{{
 $ wget -q -O - --content-on-error -S https://www.google.com/ --header
 'Host: snowflake-reg.appspot.com'
   HTTP/1.1 502 Bad Gateway
   Date: Sun, 15 Apr 2018 04:58:49 GMT
   Content-Type: text/html
   Server: HTTP server (unknown)
   Content-Length: 209
   X-XSS-Protection: 1; mode=block
   X-Frame-Options: SAMEORIGIN
   Alt-Svc: hq=":443"; ma=2592000; quic=51303432; quic=51303431;
 quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="42,41,39,35"
 502 Bad Gateway\
 This HTTP request has a Host header that is not covered \
 by the TLS certificate used. Due to an infrastructure change, \
 this request cannot be processed.
 }}}

 This ticket is to document the issue; I'm not sure we can do anything
 about it directly.

 Other related tickets:
  * #22782, use non-Google domain fronts
  * #25594, use non-fronting-based registration

--

Comment:

 I corrected the month in the ticket description (April instead of March).

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

Re: [tor-bugs] #25804 [Obfuscation/Snowflake]: Domain fronting to App Engine stopped working

[Tor Bug Tracker & Wiki]

#25804: Domain fronting to App Engine stopped working
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by gk):

 * cc: gk (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] #25140 [Core Tor/Tor]: Parse only .torrc files in torrc.d directory

[Tor Bug Tracker & Wiki]

#25140: Parse only .torrc files in torrc.d directory
-+
 Reporter:  iry  |  Owner:  Jigsaw52
 Type:  task | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.3.1-alpha
 Severity:  Major| Resolution:
 Keywords:  034-triage-20180328  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+
Changes (by asn):

 * reviewer:   => ahf


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

Re: [tor-bugs] #24688 [Core Tor/Tor]: timing wheels should use 32-bit math on 32-bit platforms

[Tor Bug Tracker & Wiki]

#24688: timing wheels should use 32-bit math on 32-bit platforms
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  cpu, 32-bit, timing, |  Actual Points:
  034-triage-20180328, fast-fix  |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor8-can
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #17949 [Core Tor/Tor]: Make loopback address search more accurate

[Tor Bug Tracker & Wiki]

#17949: Make loopback address search more accurate
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy tor-client tor-relay loopback   |  Actual Points:
  weird-configuration|
Parent ID:  #17991   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:29 rl1987]:
 > Updated branch: https://github.com/rl1987/tor/commits/feature17949_cont
 >
 > I am not sure if Windows part of this is right. Can anyone give it some
 attention? Does `make test` pass on Windows?

 Hi rl1987! Thanks for this. You think I can ask you to submit a PR against
 torproject/tor.git on Github? Second thing, the current commit structure
 is a bit intense I would say. You think you can squash some commits in
 there together (like the fixes on previous commits) so the structure is
 just a bit more logical for us to understand. 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