[tor-bugs] #20119 [- Select a component]: Fails to create the pid file when an enclosing directory is missing

[Tor Bug Tracker & Wiki]

#20119: Fails to create the pid file when an enclosing directory is missing
--+--
 Reporter:  yurivict271   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.2.8.7
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Running with the option: --PidFile /var/run/tor/tor.pid
 Directory /var/run/tor is missing. Tor starts without any warnings. It has
 to either create the directory, or complain that it can't create the pid
 file.

 FreeBSD 10.3

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

Re: [tor-bugs] #20118 [Applications/Tor bundles/installation]: Don't unpack HTTPS Everywhere anymore while bundling Tor Browser

[Tor Bug Tracker & Wiki]

#20118: Don't unpack HTTPS Everywhere anymore while bundling Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, TorBrowserTeam201609  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20118 [Applications/Tor bundles/installation]: Don't unpack HTTPS Everywhere anymore while bundling Tor Browser

[Tor Bug Tracker & Wiki]

#20118: Don't unpack HTTPS Everywhere anymore while bundling Tor Browser
-+-
 Reporter:  gk   |  Owner:  erinn
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |   Keywords:  tbb-usability,
 Severity:  Normal   |  TorBrowserTeam201609
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We ship support for unpacked HTTPS Everywhere soon. As it does not need to
 be unpacked anymore (since 5.2.2) we should not do this either in our
 bundling step.

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

Re: [tor-bugs] #10281 [Applications/Tor Browser]: Investigate usage of alternate memory allocators and memory hardening options

[Tor Bug Tracker & Wiki]

#10281: Investigate usage of alternate memory allocators and memory hardening
options
-+-
 Reporter:  mikeperry|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-hardened,  |  Actual Points:
  TorBrowserTeam201609   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by waxmiguel):

 Replying to [ticket:10281 mikeperry]:
 > One thing we can do to improve security of TBB is to build it with an
 alternate semi-hardened malloc implementation that attempts to randomize
 the allocation pattern and performs some minimal checks to guard against
 heap overflows an reference count issues in Firefox (perhaps by also
 enabling some additional reference count debugging features already in
 Firefox).
 >
 > Such allocator behavior may make exploitation of various use-after-free
 vulnerabilities more difficult, as it would be harder to predict the
 location of reallocated regions during exploitation in order to get a
 target object to overlay an incorrectly freed object.
 >
 > The downside is this will likely come at the performance costs of loss
 of locality, increased fragmentation, and additional overhead of reference
 count checks, but this may be an acceptable cost for improved hardening
 against exploits.
 >
 > The first question is: are there any existing drop-in replacement memory
 allocators we can use in place of Firefox's current jemalloc
 implementation?
 >
 > The second question is will any of the Firefox refcounting checks
 actually help, or will they just increase runtime for no real benefit?

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

Re: [tor-bugs] #20117 [Core Tor/Tor]: Update PathsNeededToBuildCircuits man page entry with actual default

[Tor Bug Tracker & Wiki]

#20117: Update PathsNeededToBuildCircuits man page entry with actual default
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy doc 029-proposed|  Actual Points:
  CoreTorTeam201609  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => needs_review
 * keywords:  easy doc => easy doc 029-proposed CoreTorTeam201609


Comment:

 Please see my branch bug20117 on github

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20117 [Core Tor/Tor]: Update PathsNeededToBuildCircuits man page entry with actual default

[Tor Bug Tracker & Wiki]

#20117: Update PathsNeededToBuildCircuits man page entry with actual default
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy doc
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+--
 "if the directory authorities do not choose a value, Tor will use 0.6."

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

Re: [tor-bugs] #20055 [Core Tor/Tor]: Remove relays that fail to rotate onion keys from the consensus

[Tor Bug Tracker & Wiki]

#20055: Remove relays that fail to rotate onion keys from the consensus
---+--
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  torspec, 030-proposed  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+--

Comment (by nickm):

 I don't think I would object to 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

Re: [tor-bugs] #19999 [Core Tor/Tor]: Maybe test-cases should complete without BUG warnings?

[Tor Bug Tracker & Wiki]

#1: Maybe test-cases should complete without BUG warnings?
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  testing TorCoreTeam201609  |  Actual Points:  3
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 Applied as 63e34e9e49e8514e2edfdc8e964bfc5752ca6326

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

Re: [tor-bugs] #19999 [Core Tor/Tor]: Maybe test-cases should complete without BUG warnings?

[Tor Bug Tracker & Wiki]

#1: Maybe test-cases should complete without BUG warnings?
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  testing TorCoreTeam201609  |  Actual Points:  3
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 Thanks!  I thought I'd caught all of those...

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

Re: [tor-bugs] #17857 [Core Tor/Tor]: Create a consensus param to disable (netflow) padding if RSOS is enabled

[Tor Bug Tracker & Wiki]

#17857: Create a consensus param to disable (netflow) padding if RSOS is enabled
---+--
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rsos, sos, tor-hs, isaremoved  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 A reminder that if we merge Single Onion Services (#17178) and Netflow
 Padding (#16861) in 0.2.9, we'll likely want a Consensus Parameter to
 Disable Netflow Padding For Single Onion Services (#17857) as well.

 I think we should do a consensus parameter for Tor2web as well. It also
 makes a lot of connections to many HSDir and intro point relays (and rend
 point relays if Tor2webRendezvousPoints is not set).

 The parameters could be named:
 * nf_pad_single_onion
 * nf_pad_tor2web

 Individual operators can override the consensus parameter using the torrc
 option.

 And I think both parameters should operate as follows:
 * 0: No Padding
 * 1: Full Padding (Default)

 Do we want to have a value for reduced padding, or is that a client-
 controlled option only?

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

Re: [tor-bugs] #17178 [Core Tor/Tor]: Rendezvous Single Onion Services: One-Hop Intro Point and Rendezvous

[Tor Bug Tracker & Wiki]

#17178: Rendezvous Single Onion Services: One-Hop Intro Point and Rendezvous
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor-hs, TorCoreTeam201608, |  Actual Points:  13.5
  TorCoreTeam201609, review-group-5, review- |
  group-8|
Parent ID:   | Points:  6.5
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by teor):

 A reminder that if we merge Single Onion Services (#17178) and Netflow
 Padding (#16861) in 0.2.9, we'll likely want a Consensus Parameter to
 Disable Netflow Padding For Single Onion Services (#17857) as well.

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

Re: [tor-bugs] #16861 [Core Tor/Tor]: Pad Tor connections to collapse netflow records

[Tor Bug Tracker & Wiki]

#16861: Pad Tor connections to collapse netflow records
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  028-triage, 028-triaged, |  Actual Points:
  pre028-patch, 201511-deferred, |
  201512-deferred, tor-guard, TorCoreTeam-   |
  postponed-201604, nickm-deferred-20160905  |
Parent ID:   | Points:  2
 Reviewer:  nickm|Sponsor:
 |  SponsorU-can
-+-

Comment (by teor):

 A reminder that if we merge Single Onion Services (#17178) and Netflow
 Padding (#16861) in 0.2.9, we'll likely want a Consensus Parameter to
 Disable Netflow Padding For Single Onion Services (#17857) as well.

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

Re: [tor-bugs] #20109 [Core Tor/Tor]: something wrong with commit 41cc1f612bd2112ab7cec0cc4fdeb68c26e231bf

[Tor Bug Tracker & Wiki]

#20109: something wrong with commit 41cc1f612bd2112ab7cec0cc4fdeb68c26e231bf
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 This was probably caused by #18693.
 It could help to have chutney tests for this feature as well - otherwise
 we could break it, and never know.

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

Re: [tor-bugs] #20055 [Core Tor/Tor]: Remove relays that fail to rotate onion keys from the consensus

[Tor Bug Tracker & Wiki]

#20055: Remove relays that fail to rotate onion keys from the consensus
---+--
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  torspec, 030-proposed  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Actually, I think the correct fix is to say that onion keys MUST be
 rotated every 7 days in the spec. And then ban keys that haven't been
 rotated for 7*N days, where N is in (2,3,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] #20007 [Core Tor/Tor]: Sandbox causing crash when setting HidServAuth when there is a hidden service running

[Tor Bug Tracker & Wiki]

#20007: Sandbox causing crash when setting HidServAuth when there is a hidden
service running
+
 Reporter:  segfault|  Owner:
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal  | Resolution:
 Keywords:  regression, tor-hs  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  new => needs_information
 * keywords:   => regression, tor-hs


Comment:

 I don't have enough information to diagnose this issue.

 What are you really trying to do?
 * HidServAuth is a client option, but you are running a hidden service.
 Did you mean to use HiddenServiceAuthorizeClient instead?

 What is actually happening?
 * What is the full log? I'd like to see notice level.
 * Does the hidden service work with the Sandbox on startup (without the
 SETCONF)? Is this simply a permissions problem on the directory?

 What is actually causing the issue?
 * rend_parse_service_authorization() parses client HidServAuth entries, it
 doesn't read any service HiddenServiceDirectory files. So it might be that
 any SETCONF is your problem here, not specifically HidServAuth. What
 happens when you issue a `SETCONF ClientOnly=1` instead of HidServAuth?
 (ClientOnly is ignored on clients, it has no effect).
 * rend_services_add_filenames_to_lists() implements the Sandbox for each
 HiddenServiceDirectory, using the following lines:
 {{{
   rend_service_add_filenames_to_list(open_lst, s);
   smartlist_add(stat_lst, tor_strdup(s->directory));
 }}}
 As far as I can see, this code is working correctly, and should make
 the hidden service directory available via the sandbox at startup. Maybe
 this directory isn't being added to the sandbox at startup? Maybe SETCONF
 isn't using the sandbox-approved way to access the directory?
 * The log error you provided is logged by check_private_dir(), which is
 called by the HiddenServiceDirectory-handling code, not the HidServAuth
 code.
 {{{
   /* Open directory.
* O_NOFOLLOW to ensure that it does not follow symbolic links */
   fd = open(sandbox_intern_string(dirname), O_NOFOLLOW);

   /* Was there an error? Maybe the directory does not exist? */
   if (fd == -1) {

 if (errno != ENOENT) {
   /* Other directory error */
   log_warn(LD_FS, "Directory %s cannot be read: %s", dirname,
strerror(errno));
   return -1;
 }
 }}}

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

Re: [tor-bugs] #19999 [Core Tor/Tor]: Maybe test-cases should complete without BUG warnings?

[Tor Bug Tracker & Wiki]

#1: Maybe test-cases should complete without BUG warnings?
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  testing TorCoreTeam201609  |  Actual Points:  3
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+---

Comment (by rubiate):

 If util/time fails it doesn't call teardown_capture_of_logs()


 {{{
 diff --git a/src/test/test_util.c b/src/test/test_util.c
 index 5949eb9..224ec7b 100644
 --- a/src/test/test_util.c
 +++ b/src/test/test_util.c
 @@ -262,7 +262,6 @@ test_util_time(void *arg)
time_t t_res;
int i;
struct timeval tv;
 -  int old_log_level = 0;

/* Test tv_udiff and tv_mdiff */

 @@ -1112,8 +,7 @@ test_util_time(void *arg)
  #undef CHECK_TIMEGM_ARG_OUT_OF_RANGE

   done:
 -  if (old_log_level)
 -teardown_capture_of_logs();
 +  teardown_capture_of_logs();
  }

  static void
 }}}


 Similarly for tortls:

 {{{
 diff --git a/src/test/test_tortls.c b/src/test/test_tortls.c
 index 790c331..8502e8a 100644
 --- a/src/test/test_tortls.c
 +++ b/src/test/test_tortls.c
 @@ -2278,7 +2278,6 @@ test_tortls_finish_handshake(void *ignored)

X509 *c1 = read_cert_from(validCertString);
SESS_CERT_local *sess = NULL;
 -  int log_level = 0;

ctx = SSL_CTX_new(method);

 @@ -2298,7 +2297,6 @@ test_tortls_finish_handshake(void *ignored)
expect_single_log_msg_containing("For some reason, wasV2Handshake
 didn't "
 "get set.");
teardown_capture_of_logs();
 -  log_level = 0;

tls->wasV2Handshake = 1;
ret = tor_tls_finish_handshake(tls);
 @@ -2337,8 +2335,7 @@ test_tortls_finish_handshake(void *ignored)
tor_free(tls);
SSL_CTX_free(ctx);
tor_free(method);
 -  if (log_level)
 -teardown_capture_of_logs();
 +  teardown_capture_of_logs();
  }
  #endif
 }}}

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

Re: [tor-bugs] #19733 [Applications/Tor Browser]: GETINFO response parser doesn't handle AF_UNIX entries.

[Tor Bug Tracker & Wiki]

#19733: GETINFO response parser doesn't handle AF_UNIX entries.
-+-
 Reporter:  yawning  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very Low |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  tbb-sandbox, tbb-torbutton,  |  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks, applied with commit 5ea022aadf6416a1f046eac47a3ec28ea2a5dd7d.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 Doing the Right Thing sounds good to me as well.

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

[tor-bugs] #20116 [Applications/GetTor]: Get @get_tor twitter account verified

[Tor Bug Tracker & Wiki]

#20116: Get @get_tor twitter account verified
-+---
 Reporter:  mrphs|  Owner:  mrphs
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 `femme` pointed out on IRC that we should get @get_tor account verified.
 With the new request form that twitter has made, this should be easy. I'm
 making this ticket so I wont forget about this task.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20115 [- Select a component]: check.tpo reports false negative on known exit IP?

[Tor Bug Tracker & Wiki]

#20115: check.tpo reports false negative on known exit IP?
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 check.tpo says:
 {{{
  Sorry. You are not using Tor.

 Your IP address appears to be: 162.243.117.41
 }}}

 onionoo knows that IP as an exit relay's IP:

 https://atlas.torproject.org/#search/162.243.117.41
 uptime 2d15h:
 https://atlas.torproject.org/#details/47BAD834309368640EA066913DF741AF413EDE5E
 uptime 8h:
 https://atlas.torproject.org/#details/C765F758204810421C1059FC182209569551609D

 how come? is onionoo data more current then torDNSEL?

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

Re: [tor-bugs] #19999 [Core Tor/Tor]: Maybe test-cases should complete without BUG warnings?

[Tor Bug Tracker & Wiki]

#1: Maybe test-cases should complete without BUG warnings?
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  testing TorCoreTeam201609  |  Actual Points:  3
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  accepted => 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] #19999 [Core Tor/Tor]: Maybe test-cases should complete without BUG warnings?

[Tor Bug Tracker & Wiki]

#1: Maybe test-cases should complete without BUG warnings?
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  testing TorCoreTeam201609  |  Actual Points:  3
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:  testing => testing TorCoreTeam201609
 * owner:   => nickm
 * status:  new => accepted
 * actualpoints:   => 3


Comment:

 Down to 0

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by arthuredelstein):

 Replying to [comment:1 mcs]:
 > Kathy and I looked at this and soon realized that we cannot simply
 modify torrc-defaults (SocksPort) and the browser default preferences
 (network.proxy.socks) to use a socket path. This approach will not work
 because we need to insert a full path, and we do not know what the path is
 until the browser is starting up (it won't work to use a relative path, at
 least not on OSX where the TorBrowser-Data directory may be located in one
 of two different locations). Possibly solutions:
 > * Modify Tor Launcher to Do The Right Thing and configure tor and the
 browser correctly. This is how we handled the ControlPort.
 > * Modify the browser and tor (possibly with help from Tor Launcher) so
 we can use a placeholder within network.proxy.socks and SocksPort, e.g.,
 >   network.proxy.socks="file:///--PROFILEDIR--/../../Tor/socks.socket"
 >
 > Comments? Do you have a better idea? Kathy and I favor the first
 approach.

 To use a ControlPort via a domain socket, Tor Launcher will need to
 specify the ControlPort socket path as a command argument, correct? So the
 first approach sounds pretty natural and simple to me, where you also
 specify a path for the SocksPort and then set the network.proxy.socks pref
 in the browser.

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

Re: [tor-bugs] #20114 [Applications/Tor Check]: Tor Browser v6.0.4 on Linux reported that exiting via node 162.243.117.41 was "not connected through tor" on check.torproject.org

[Tor Bug Tracker & Wiki]

#20114: Tor Browser v6.0.4 on Linux reported that exiting via node 
162.243.117.41
was "not connected through tor" on check.torproject.org
+-
 Reporter:  6h72Q484AddGha8H|  Owner:  arlolra
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by cypherpunks):

 * owner:   => arlolra
 * component:  - Select a component => Applications/Tor Check


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

Re: [tor-bugs] #19709 [Applications/Tor Messenger]: Add support for blocking users

[Tor Bug Tracker & Wiki]

#19709: Add support for blocking users
+-
 Reporter:  sukhbir |  Owner:
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 Some related upstream bugs,

 https://bugzilla.mozilla.org/show_bug.cgi?id=953582
 https://bugzilla.mozilla.org/show_bug.cgi?id=954139
 https://bugzilla.mozilla.org/show_bug.cgi?id=954140
 https://bugzilla.mozilla.org/show_bug.cgi?id=954320

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

Re: [tor-bugs] #20112 [Core Tor/Stem]: test_with_ephemeral_hidden_services_basic_auth [FAILURE]

[Tor Bug Tracker & Wiki]

#20112: test_with_ephemeral_hidden_services_basic_auth   [FAILURE]
---+
 Reporter:  toralf |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Stem  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Great! Fix pushed, thanks for the catch!

 https://gitweb.torproject.org/stem.git/commit/?id=be9cc74

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

Re: [tor-bugs] #19426 [Obfuscation/meek]: meek-client on ubuntu requires apparmor profile adjustment for system_tor

[Tor Bug Tracker & Wiki]

#19426: meek-client on ubuntu requires apparmor profile adjustment for 
system_tor
--+-
 Reporter:  6h72Q484AddGha8H  |  Owner:  dcf
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by 6h72Q484AddGha8H):

 Replying to [comment:7 arma]:
 > I'm trying the meek component here -- it isn't perfect but we don't have
 a better one. (Unless the better one is the ubuntu bug tracker? Is this
 meek-client thing in ubuntu itself? If so then that's probably the best
 place for this ticket.)

 @arma -- no meek-client is coming from infinity0's repository at:

 https://people.debian.org/~infinity0/apt

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

Re: [tor-bugs] #19426 [Obfuscation/meek]: meek-client on ubuntu requires apparmor profile adjustment for system_tor

[Tor Bug Tracker & Wiki]

#19426: meek-client on ubuntu requires apparmor profile adjustment for 
system_tor
--+-
 Reporter:  6h72Q484AddGha8H  |  Owner:  dcf
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by 6h72Q484AddGha8H):

 @arma -- no meek-client is coming from infinity0's repository at:

 https://people.debian.org/~infinity0/apt

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20114 [- Select a component]: Tor Browser v6.0.4 on Linux reported that exiting via node 162.243.117.41 was "not connected through tor" on check.torproject.org

[Tor Bug Tracker & Wiki]

#20114: Tor Browser v6.0.4 on Linux reported that exiting via node 
162.243.117.41
was "not connected through tor" on check.torproject.org
--+-
 Reporter:  6h72Q484AddGha8H  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Tor Browser v6.0.4 on Linux reported that exiting via node 162.243.117.41
 was "not connected through tor" on check.torproject.org

 This seemed very odd, so we wanted to report it in case something
 anomalous is going on.

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

Re: [tor-bugs] #20112 [Core Tor/Stem]: test_with_ephemeral_hidden_services_basic_auth [FAILURE]

[Tor Bug Tracker & Wiki]

#20112: test_with_ephemeral_hidden_services_basic_auth   [FAILURE]
---+
 Reporter:  toralf |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Stem  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by toralf):

 bingo - nw the test passes.

 (In fact I bisected 3 different intervalls before to ensure that I do
 really blame the code and not myself to be a moron due to the fact, that
 the "bad" commit was so harmless :-D ...)

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4 (was: Difficult-to-reproduce crash on OpenBSD: tor invoked from Tor Browser 6.0.4)

[Tor Bug Tracker & Wiki]

#20103: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4
--+--
 Reporter:  attila|  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

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

Re: [tor-bugs] #20112 [Core Tor/Stem]: test_with_ephemeral_hidden_services_basic_auth [FAILURE]

[Tor Bug Tracker & Wiki]

#20112: test_with_ephemeral_hidden_services_basic_auth   [FAILURE]
---+
 Reporter:  toralf |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Stem  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

 * owner:   => atagar
 * component:  Core Tor => Core Tor/Stem


Comment:

 Interesting! Actually, this looks like a Stem testing bug to me, swapping
 this over to my component.

 I'm having some difficulty reproing this but I think I see the fix.
 toralf, if you change 'stem/test/integ/control/controller.py' line 688
 from...

 {{{
 self.assertEqual(['bob'], response.client_auth.keys())
 }}}

 ... to...

 {{{
 self.assertEqual(['bob'], list(response.client_auth.keys()))
 }}}

 ... does it work?

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

Re: [tor-bugs] #19999 [Core Tor/Tor]: Maybe test-cases should complete without BUG warnings?

[Tor Bug Tracker & Wiki]

#1: Maybe test-cases should complete without BUG warnings?
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  testing   |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Down to 17.

 Also, as of 3269307dafafa8c7c2c3e0be5d5c3cb5e7df3153 , it counts as a test
 failure any time that tor_assert_nonfatal() fails.

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Difficult-to-reproduce crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Difficult-to-reproduce crash on OpenBSD: tor invoked from Tor Browser 
6.0.4
--+--
 Reporter:  attila|  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by attila):

 I should also point out that all of the packages for testing that I point
 at on `bits.haqistan.net` are of course unsigned.  They are only for
 testing.  They are not official anything and we don't sign the binary
 packages we produce for testing.  The `pkg_add` command will complain
 about this and ask you to confirm that you are installing unsigned
 packages.  This is normal.

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

Re: [tor-bugs] #20112 [Core Tor]: test_with_ephemeral_hidden_services_basic_auth [FAILURE]

[Tor Bug Tracker & Wiki]

#20112: test_with_ephemeral_hidden_services_basic_auth   [FAILURE]
--+
 Reporter:  toralf|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Weird -- 70fd23f is just a version bump.

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Difficult-to-reproduce crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Difficult-to-reproduce crash on OpenBSD: tor invoked from Tor Browser 
6.0.4
--+--
 Reporter:  attila|  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by attila):

 After a few more hours of testing and screwing around I've found this is
 not hard to reproduce at all:

 1. start TBB;
 2. load a page (I've been using https://blog.torproject.org but I don't
 think it matters much);
 3. wait :-)

 Under OpenBSD-current/amd64 as of the 5 Sept snap you'll eventually get a
 crash like the one I dissected above; there's a more recent snap and I'm
 working on upgrading to it.

 I now have gdb attached to the last instance of tor that TBB started and
 am waiting for it to die so I can learn more, but it crashed for me
 overnight and the tail end of the logs might be interesting to someone who
 knows more than me (I cranked up logging to debug before having TBB
 restart tor):

 {{{
 ...
 Sep 08 15:54:58.000 [debug] relay_lookup_conn(): found conn for stream
 23866.
 Sep 08 15:54:58.000 [debug] circuit_receive_relay_cell(): Sending to
 origin.
 Sep 08 15:54:58.000 [debug] connection_edge_process_relay_cell(): Now seen
 3005 relay cells here (command 2, stream 23866).
 Sep 08 15:54:58.000 [debug] connection_edge_process_relay_cell(): circ
 deliver_window now 966.
 Sep 08 15:54:58.000 [debug] connection_or_process_cells_from_inbuf(): 24:
 starting, inbuf_datalen 514 (0 pending in tls object).
 Sep 08 15:54:58.000 [debug] channel_queue_cell(): Directly handling
 incoming cell_t 0x7f7f4880 for channel 0x477f126c000 (global ID 3)
 Sep 08 15:54:58.000 [debug] circuit_get_by_circid_channel_impl():
 circuit_get_by_circid_channel_impl() returning circuit 0x477f126c800 for
 circ_id 2778626874, channel ID 3 (0x477f126c000)
 Sep 08 15:54:58.000 [debug] relay_lookup_conn(): found conn for stream
 23866.
 Sep 08 15:54:58.000 [debug] circuit_receive_relay_cell(): Sending to
 origin.
 Sep 08 15:54:58.000 [debug] connection_edge_process_relay_cell(): Now seen
 3006 relay cells here (command 3, stream 23866).
 Sep 08 15:54:58.000 [info] connection_edge_process_relay_cell(): -1: end
 cell (closed normally) for stream 23866. Removing stream.
 Sep 08 15:54:58.000 [debug] connection_or_process_cells_from_inbuf(): 24:
 starting, inbuf_datalen 0 (0 pending in tls object).
 Sep 08 15:54:58.000 [debug] conn_close_if_marked(): Cleaning up connection
 (fd -
 Sep 08 15:54:58.000 [debug] conn_close_if_marked(): Flushed last 2115
 bytes from a linked conn; 0 left; flushlen 0; wants-to-flush==0
 Sep 08 15:54:58.000 [debug] circuit_detach_stream(): Removing stream 23866
 from circ 2778626874
 Sep 08 15:54:58.000 [debug] connection_remove(): removing socket -1 (type
 Socks), n_conns now 8
 Sep 08 15:54:58.000 [info] connection_free_(): Freeing linked Socks
 connection [open] with 0 bytes on inbuf, 0 on outbuf.
 Sep 08 15:54:58.000 [debug] conn_read_callback(): socket -1 wants to read.
 Sep 08 15:54:58.000 [debug] fetch_from_buf_http(): headerlen 198, bodylen
 612109.
 Sep 08 15:54:58.000 [debug] connection_dir_client_reached_eof(): Received
 response from directory server '66.111.2.20:9001': 200 "OK" (purpose: 14)
 Sep 08 15:54:58.000 [debug] router_new_address_suggestion(): Got X-Your-
 Address-Is: my.home.ip.address
 Sep 08 15:54:58.000 [debug] connection_dir_client_reached_eof(): Time on
 received directory is within tolerance; we are 0 seconds skewed.  (That's
 okay.)
 Sep 08 15:54:58.000 [info] connection_dir_client_reached_eof(): Received
 consensus directory (size 1403277) from server '66.111.2.20:9001'
 Sep 08 15:54:58.000 [info] A consensus needs 5 good signatures from
 recognized authorities for us to accept it. This one has 8 (dannenberg
 tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
 }}}

 This last message is the same message that appeared in the log from the
 original crash that George called to my attention (which I forgot to
 mention in the initial ticket, sorry), which ended thus:

 {{{
 Sep 07 09:57:05.000 [debug] connection_dir_client_reached_eof(): Received
 response from directory server '66.111.2.20:9001': 200 "OK" (purpose: 14)
 Sep 07 09:57:05.000 [debug] router_new_address_suggestion(): Got X-Your-
 Address-Is: a.b.c.d
 Sep 07 09:57:05.000 [debug] connection_dir_client_reached_eof(): Time on
 received directory is within tolerance; we are -3 seconds skewed.  (That's
 okay.)
 Sep 07 09:57:05.000 [info] connection_dir_client_reached_eof(): Received
 consensus directory (size 1401858) from server '66.111.2.20:9001'
 Sep 07 09:57:05.000 [info] A consensus needs 5 good signatures from
 recogn

[tor-bugs] #20113 [Internal Services/Service - lists]: New mailinglist for Tor+Cloudflare+other CDN coordination

[Tor Bug Tracker & Wiki]

#20113: New mailinglist for Tor+Cloudflare+other CDN coordination
---+-
 Reporter:  mikeperry  |  Owner:  qbi
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Can we make a new mailinglist tor-acc...@lists.torproject.org with the
 list of emails mentioned in the Cloudflare coordination tor-internal
 thread initially subscribed?

 We want it moderated, and those emails whitelisted. Ideally it would be
 easy for a few different people to add more whitelisted emails.

 I don't want to dump the list of emails here.

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

Re: [tor-bugs] #18753 [Core Tor/Tor]: Unix socket paths cannot contain spaces

[Tor Bug Tracker & Wiki]

#18753: Unix socket paths cannot contain spaces
-+--
 Reporter:  special  |  Owner:  yawning
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  nickm-deferred-20160905  |  Actual Points:
Parent ID:   | Points:  1
 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

[tor-bugs] #20112 [Core Tor]: test_with_ephemeral_hidden_services_basic_auth [FAILURE]

[Tor Bug Tracker & Wiki]

#20112: test_with_ephemeral_hidden_services_basic_auth   [FAILURE]
--+
 Reporter:  toralf|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 get this with 0.2.9.x series :
 {{{
 Running tests...

   control.controller.test_with_ephemeral_hidden_services_basic_auth...
 failed (0.02s)
 test_with_ephemeral_hidden_services_basic_auth   [FAILURE]

 ==
 FAIL: test_with_ephemeral_hidden_services_basic_auth
 --
 Traceback (most recent call last):
   File "/home/tfoerste/devel/stem/test/runner.py", line 127, in wrapped
 return func(self, *args, **kwargs)
   File "/home/tfoerste/devel/stem/test/runner.py", line 144, in wrapped
 return func(self, *args, **kwargs)
   File "/home/tfoerste/devel/stem/test/integ/control/controller.py", line
 688, in test_with_ephemeral_hidden_services_basic_auth
 self.assertEqual(['bob'], response.client_auth.keys())  # newly
 created credentials were only created for bob
 AssertionError: ['bob'] != dict_keys(['bob'])

 --
 Ran 1 test in 0.019s

 FAILED (failures=1)
 }}}
 at a hardened 64bit stable Gentoo desktop. The hardened feature shouldn't
 play a big role here, neither in pax.log nor in grsec.log are any
 suspicious entries.

 A 1st attempt to bisect gives tor-0.2.9.0-root-769-g70fd23f - and I
 checked twice that that the previous commit is good and that commit is bad
 - but I don't have any clue how that commit id should harm the test case.

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

Re: [tor-bugs] #20109 [Core Tor/Tor]: something wrong with commit 41cc1f612bd2112ab7cec0cc4fdeb68c26e231bf

[Tor Bug Tracker & Wiki]

#20109: something wrong with commit 41cc1f612bd2112ab7cec0cc4fdeb68c26e231bf
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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

[Tor Bug Tracker & Wiki]

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

 * status:  new => needs_information
 * cc: arthuredelstein (added)


Comment:

 Kathy and I looked at this and soon realized that we cannot simply modify
 torrc-defaults (SocksPort) and the browser default preferences
 (network.proxy.socks) to use a socket path. This approach will not work
 because we need to insert a full path, and we do not know what the path is
 until the browser is starting up (it won't work to use a relative path, at
 least not on OSX where the TorBrowser-Data directory may be located in one
 of two different locations). Possibly solutions:
 * Modify Tor Launcher to Do The Right Thing and configure tor and the
 browser correctly. This is how we handled the ControlPort.
 * Modify the browser and tor (possibly with help from Tor Launcher) so we
 can use a placeholder within network.proxy.socks and SocksPort, e.g.,
   network.proxy.socks="file:///--PROFILEDIR--/../../Tor/socks.socket"

 Comments? Do you have a better idea? Kathy and I favor the first approach.

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

Re: [tor-bugs] #14273 [Applications/Tor Browser]: Investigate missing Tor Browser patches to make Unix Domain Socket option work

[Tor Bug Tracker & Wiki]

#14273: Investigate missing Tor Browser patches to make Unix Domain Socket 
option
work
-+-
 Reporter:  gk   |  Owner:
 |  mikeperry
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-security, TorBrowserTeam201608R  |  Actual Points:
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by mcs):

 Replying to [comment:13 gk]:
 > > Do you want Kathy and me to create appropriate patches for tor-browser
 and builders/tor-browser-bundle?
 >
 > That would be neat. You could use #14270 for that or create a new child
 ticket of it for this task I guess.

 I created a new ticket because we need to discuss some design issues:
 #20111.

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

[Tor Bug Tracker & Wiki]

#20111: use Unix domain sockets for SOCKS port by default
--+--
 Reporter:  mcs   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #14270
   Points:|   Reviewer:
  Sponsor:|
--+--
 We should use Unix domain sockets by default in Tor Browser. The patch for
 #14272 takes care of doing that for the control port (via the
 extensions.torlauncher.control_port_use_socket = true default preference).
 For the SOCKS port we need additional changes in tor-browser and builders
 /tor-browser-bundle at least.

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

Re: [tor-bugs] #19733 [Applications/Tor Browser]: GETINFO response parser doesn't handle AF_UNIX entries.

[Tor Bug Tracker & Wiki]

#19733: GETINFO response parser doesn't handle AF_UNIX entries.
-+-
 Reporter:  yawning  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very Low |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:
 Keywords:  tbb-sandbox, tbb-torbutton,  |  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  tbb-sandbox, tbb-torbutton, TorBrowserTeam201609 => tbb-
 sandbox, tbb-torbutton, TorBrowserTeam201609R
 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:11 gk]:
 > Looks good with one nit: I guess removing the very first line in
 `torbutton.js` is just an oversight? I think we should keep that one. :)

 Yes indeed. Here is a revised patch:
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19733-04&id=5ea022aadf6416a1f046eac47a3ec28ea2a5dd7d

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

Re: [tor-bugs] #19902 [Core Tor/Tor]: Dual-install of libevent 1 and libevent 2 on openbsd confuses our autoconf logic

[Tor Bug Tracker & Wiki]

#19902: Dual-install of libevent 1 and libevent 2 on openbsd confuses our 
autoconf
logic
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  openbsd, review-group-8, regression  |  Actual Points:  .2
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * actualpoints:   => .2


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

Re: [tor-bugs] #19902 [Core Tor/Tor]: Dual-install of libevent 1 and libevent 2 on openbsd confuses our autoconf logic

[Tor Bug Tracker & Wiki]

#19902: Dual-install of libevent 1 and libevent 2 on openbsd confuses our 
autoconf
logic
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  openbsd, review-group-8  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 Sorry for the delay here -- the first half-a-dozen times I looked at this,
 it looked wrong to me.  But now I understand: I think this should work
 okay.

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

Re: [tor-bugs] #19902 [Core Tor/Tor]: Dual-install of libevent 1 and libevent 2 on openbsd confuses our autoconf logic

[Tor Bug Tracker & Wiki]

#19902: Dual-install of libevent 1 and libevent 2 on openbsd confuses our 
autoconf
logic
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  openbsd, review-group-8, regression  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  openbsd, review-group-8 => openbsd, review-group-8, regression
 * status:  needs_revision => closed
 * resolution:   => fixed


Comment:

 Merged as fe9cfeba6ec96c11d009f4d57bf03f0019e34c9d. Thank you!

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

Re: [tor-bugs] #20101 [Core Tor/Tor]: rend-spec.txt: Clarify that 'signature\n' is also signed along with all onion descriptor fields

[Tor Bug Tracker & Wiki]

#20101: rend-spec.txt: Clarify that 'signature\n' is also signed along with all
onion descriptor fields
--+
 Reporter:  twim  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged!

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

Re: [tor-bugs] #20110 [Core Tor/Tor]: Clang's -Wthread-safety requires annotations we aren't using

[Tor Bug Tracker & Wiki]

#20110: Clang's -Wthread-safety requires annotations we aren't using
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 f3cda3272a2504 is the fix here.

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

[tor-bugs] #20110 [Core Tor/Tor]: Clang's -Wthread-safety requires annotations we aren't using

[Tor Bug Tracker & Wiki]

#20110: Clang's -Wthread-safety requires annotations we aren't using
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

Re: [tor-bugs] #20089 [Core Tor/DirAuth]: Require "p" lines in consensuses

[Tor Bug Tracker & Wiki]

#20089: Require "p" lines in consensuses
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 squashed and merged; 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] #20089 [Core Tor/DirAuth]: Require "p" lines in consensuses

[Tor Bug Tracker & Wiki]

#20089: Require "p" lines in consensuses
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Sebastian):

 * status:  needs_revision => needs_review


Comment:

 Ouch. Yeah. I thought we required ipv6. Hrm. I think I'll leave the ipv6
 part out and we can revisit that when we're ready to mandate v6 support.
 added a fixup commit.

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

Re: [tor-bugs] #20109 [Core Tor/Tor]: something wrong with commit 41cc1f612bd2112ab7cec0cc4fdeb68c26e231bf

[Tor Bug Tracker & Wiki]

#20109: something wrong with commit 41cc1f612bd2112ab7cec0cc4fdeb68c26e231bf
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:   => regression
 * cc: teor (added)
 * milestone:   => Tor: 0.2.9.x-final


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

Re: [tor-bugs] #20107 [Core Tor/Tor]: somthings wrong about function channel_get_actual_remote_address()

[Tor Bug Tracker & Wiki]

#20107: somthings wrong about function channel_get_actual_remote_address()
-+-
 Reporter:  DLP_ripper   |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  channel ip address 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  channel ip address => channel ip address 028-backport
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.2.9.x-final


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

Re: [tor-bugs] #20089 [Core Tor/DirAuth]: Require "p" lines in consensuses

[Tor Bug Tracker & Wiki]

#20089: Require "p" lines in consensuses
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 I think this is incorrect; p6 does _not_ appear exactly once in each
 microdesc, even when the consensus is produced with method 15 or later.
 It only seems to appear when IPv6 is supported.

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

Re: [tor-bugs] #20066 [Core Tor/Tor]: Make test-memwipe work better on OpenBSD

[Tor Bug Tracker & Wiki]

#20066: Make test-memwipe work better on OpenBSD
-+
 Reporter:  rubiate  |  Owner:
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  openbsd, review-group-8  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 Applied as 08d1ac4f2ae81a79d19cbb830c3c88cb2998cb6e; thank you!

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

Re: [tor-bugs] #20066 [Core Tor/Tor]: Make test-memwipe work better on OpenBSD

[Tor Bug Tracker & Wiki]

#20066: Make test-memwipe work better on OpenBSD
-+
 Reporter:  rubiate  |  Owner:
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  openbsd, review-group-8  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by rubiate):

 Here's another patch with an attempt at a changes file.

 Without this patch, reliably and repeatably:

 $ src/test/test-memwipe
 Segmentation fault (core dumped)

 With:

 $ src/test/test-memwipe
 It appears that memset is good enough on this platform. Good.
 OKAY: memwipe seems to work.

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

Re: [tor-bugs] #20108 [User Experience/Website]: Tor Mirror Update 09/08/2016

[Tor Bug Tracker & Wiki]

#20108: Tor Mirror Update 09/08/2016
-+---
 Reporter:  aquintex |  Owner:  Sebastian
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  mirror update|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by Sebastian):

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


Comment:

 Cherry-picked the top commit, thanks! Please reset your branch so it
 doesn't contain the readme creation/deletion commits anymore.

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

Re: [tor-bugs] #19528 [Applications/Tor Browser]: The build id stays the same with every Firefox update

[Tor Bug Tracker & Wiki]

#19528: The build id stays the same with every Firefox update
---+---
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201609R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * keywords:  tbb-gitian, TorBrowserTeam201609 => tbb-gitian,
 TorBrowserTeam201609R
 * status:  needs_revision => needs_information


Comment:

 One question regarding:
 {{{
 +my $appfile = "$tmpdir/application.ini" if -f
 "$tmpdir/application.ini";
 +$appfile = "$tmpdir/Contents/Resources/application.ini"
 +if -f "$tmpdir/application.ini";
 }}}
 I think I understand the first line but I have a hard time doing so wrt
 the second and third: why is `appfile` getting
 `$tmpdir/Contents/Resources/application.ini` assigned if
 `$tmpdir/application.ini` exists? It already got assigned
 `$tmpdir/application.ini` in that case.

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

Re: [tor-bugs] #20007 [Core Tor/Tor]: Sandbox causing crash when setting HidServAuth when there is a hidden service running

[Tor Bug Tracker & Wiki]

#20007: Sandbox causing crash when setting HidServAuth when there is a hidden
service running
--+
 Reporter:  segfault  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by segfault):

 * status:  needs_information => new


Old description:

> When the sandbox is enabled and there is a hidden service configured,
> setting HidServAuth via SETCONF results in a permission error.
>
> Steps to reproduce:
>
> Start Tor with a hidden service:
>
> {{{
> /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc
> --RunAsDaemon 0 --Log debug --CookieAuthentication 0  --Sandbox 1
> --HiddenServiceDir /var/lib/tor/hidden_service/ --HiddenServicePort 80 >
> tor.log
> }}}
>
> Try setting HidServAuth via the control port:
>
> {{{
> echo "AUTHENTICATE
> SETCONF HidServAuth=\"prkszpeygn2a3kxo.onion iGwsXkMwZEHuq/0YCD6IGQ\"" |
> nc -U /var/run/tor/control
> }}}
>
> Output:
>
> {{{
> 250 OK
> 513 Unacceptable option value: Failed to configure rendezvous options.
> See logs for details.
> }}}
>
> Log:
>
> {{{
> Aug 27 15:31:55.000 [warn] Directory /var/lib/tor/hidden_service/ cannot
> be read: Permission denied
> Aug 27 15:31:55.000 [warn] Controller gave us config lines that didn't
> validate: Failed to configure rendezvous options. See logs for details.
> }}}
>
> If we start Tor without a hidden service, it works without errors:
>
> {{{
> /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc
> --RunAsDaemon 0 --Log debug --CookieAuthentication 0  --Sandbox 1 >
> tor.log
> }}}
>
> Set HidServAuth via the control port:
>
> {{{
> echo "AUTHENTICATE
> SETCONF HidServAuth=\"prkszpeygn2a3kxo.onion iGwsXkMwZEHuq/0YCD6IGQ\"" |
> nc -U /var/run/tor/control
> }}}
>
> Output:
>
> {{{
> 250 OK
> 250 OK
> }}}

New description:

 When the sandbox is enabled and there is a hidden service configured,
 setting HidServAuth via SETCONF results in a permission error.

 Steps to reproduce:

   Start Tor with a hidden service:

 {{{
 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc
 --RunAsDaemon 0 --Log debug --CookieAuthentication 0  --Sandbox 1
 --HiddenServiceDir /var/lib/tor/hidden_service/ --HiddenServicePort 80
 }}}
   Try setting HidServAuth via the control port:

 {{{
 echo "AUTHENTICATE
 SETCONF HidServAuth=\"prkszpeygn2a3kxo.onion iGwsXkMwZEHuq/0YCD6IGQ\"" |
 nc -U /var/run/tor/control
 }}}
   Output:

 {{{
 250 OK
 513 Unacceptable option value: Failed to configure rendezvous options. See
 logs for details.
 }}}
   Log:

 {{{
 Aug 27 15:31:55.000 [warn] Directory /var/lib/tor/hidden_service/ cannot
 be read: Permission denied
 Aug 27 15:31:55.000 [warn] Controller gave us config lines that didn't
 validate: Failed to configure rendezvous options. See logs for details.
 }}}
 If we start Tor without a hidden service or without the sandbox, it works
 without errors:

   Without hidden service:

 {{{
 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc
 --RunAsDaemon 0 --Log debug --CookieAuthentication 0  --Sandbox 1
 }}}
   or without sandbox:

 {{{
 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc
 --RunAsDaemon 0 --Log debug --CookieAuthentication 0  --Sandbox 0
 --HiddenServiceDir /var/lib/tor/hidden_service/ --HiddenServicePort 80
 }}}
   Set HidServAuth via the control port:

 {{{
 echo "AUTHENTICATE
 SETCONF HidServAuth=\"prkszpeygn2a3kxo.onion iGwsXkMwZEHuq/0YCD6IGQ\"" |
 nc -U /var/run/tor/control
 }}}
   Output:

 {{{
 250 OK
 250 OK
 }}}

--

Comment:

 > What happens when you turn sandbox off and hidden service auth on?
 Without the sandbox it works as expected. I updated the description to
 include this case.

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

Re: [tor-bugs] #20109 [Core Tor/Tor]: something wrong with commit 41cc1f612bd2112ab7cec0cc4fdeb68c26e231bf

[Tor Bug Tracker & Wiki]

#20109: something wrong with commit 41cc1f612bd2112ab7cec0cc4fdeb68c26e231bf
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

 * component:  Core Tor => Core Tor/Tor


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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Difficult-to-reproduce crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Difficult-to-reproduce crash on OpenBSD: tor invoked from Tor Browser 
6.0.4
--+--
 Reporter:  attila|  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * component:  Core Tor => Core Tor/Tor


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

Re: [tor-bugs] #19472 [Applications/Tor Browser]: Ongoing downloads icon not working

[Tor Bug Tracker & Wiki]

#19472: Ongoing downloads icon not working
--+---
 Reporter:  torbacchi |  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 torbacchi):

 > Did that work for you on Tor Browser 5.5.x?

 Yes. And it does work on current version too. Only, sometimes it stops
 working.

 > Do you get error messages when clicking on it in the browser console
 (Ctrl + Shift + J)?

 No.

 > How did you get the download icon on the toolbar?

 ? AFAIK it's always been there

 I tried removing it from the toolbar and then re-adding it. But it still
 won't work.

 The only solution I found so far is to restart the browser.

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

Re: [tor-bugs] #19528 [Applications/Tor Browser]: The build id stays the same with every Firefox update

[Tor Bug Tracker & Wiki]

#19528: The build id stays the same with every Firefox update
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201609  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by boklm):

 I pushed a new branch `bug_19528-v5` which does not use a buildid.txt file
 anymore:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 bundle.git/commit/?h=bug_19528-v5

 The buildid is extracted from the `application.ini` file from the first
 mar file. The platformVersion is not extracted yet, I will do it in a
 separate bug.

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

Re: [tor-bugs] #20007 [Core Tor/Tor]: Sandbox causing crash when setting HidServAuth when there is a hidden service running

[Tor Bug Tracker & Wiki]

#20007: Sandbox causing crash when setting HidServAuth when there is a hidden
service running
--+
 Reporter:  segfault  |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * cc: asn (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] #20004 [Core Tor/Tor]: prop224: Add a trunnel subdirectory specifically for HS

[Tor Bug Tracker & Wiki]

#20004: prop224: Add a trunnel subdirectory specifically for HS
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, review-group-8  |  Actual Points:  0.5
Parent ID:  #17241   | Points:  1
 Reviewer:  asn  |Sponsor:  SponsorR-
 |  must
-+-

Comment (by asn):

 Also, in `cell_introduce1.trunnel`:

 - I don't see anywhere the `CLIENT_PK` or `MAC` fields of the `INTRODUCE1`
 cell as specified in section `[NTOR-WITH-EXTRA-DATA]`. Also, if we have a
 MAC we also need the appropriate `ptr`s.

 - `s/Link specificer/Link specifier/`

 - Also can we replace the magic number of `rend_cookie[20]` with some sort
 of name? The actual code is using `REND_COOKIE_LEN`, but I guess we can't
 reuse that. No worries if there is no good solution here, just leave it as
 is.

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

Re: [tor-bugs] #20004 [Core Tor/Tor]: prop224: Add a trunnel subdirectory specifically for HS

[Tor Bug Tracker & Wiki]

#20004: prop224: Add a trunnel subdirectory specifically for HS
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, review-group-8  |  Actual Points:  0.5
Parent ID:  #17241   | Points:  1
 Reviewer:  asn  |Sponsor:  SponsorR-
 |  must
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Hello. I did some more reading of this branch.

 I think that the INTRODUCE1 trunnel def is missing the `ONION_KEY_TYPE`
 field.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20109 [Core Tor]: something wrong with commit 41cc1f612bd2112ab7cec0cc4fdeb68c26e231bf

[Tor Bug Tracker & Wiki]

#20109: something wrong with commit 41cc1f612bd2112ab7cec0cc4fdeb68c26e231bf
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 If DNSPort is set , it lokks like it has NoDNSRequest is always set as
 well , even if DNSRequest is appended :

 {{{
 [warn] Refusing to connect to hostname [scrubbed] because Port has
 NoDNSRequest set.
 }}}

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

[tor-bugs] #20108 [User Experience/Website]: Tor Mirror Update 09/08/2016

[Tor Bug Tracker & Wiki]

#20108: Tor Mirror Update 09/08/2016
-+---
 Reporter:  aquintex |  Owner:  Sebastian
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:  mirror update
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 All,
 Please find the updates to the mirror list at:

 ​https://github.com/aquintex/torproject.org.git

 Thanks!
 John

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

Re: [tor-bugs] #20106 [User Experience/Website]: Tor Mirror Update 09/08/2016

[Tor Bug Tracker & Wiki]

#20106: Tor Mirror Update 09/08/2016
-+--
 Reporter:  aquintex |  Owner:  aquintex
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  mirror update|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by aquintex):

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


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

Re: [tor-bugs] #20106 [User Experience/Website]: Tor Mirror Update 09/08/2016

[Tor Bug Tracker & Wiki]

#20106: Tor Mirror Update 09/08/2016
-+--
 Reporter:  aquintex |  Owner:  aquintex
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  mirror update|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by aquintex):

 * owner:  Sebastian => aquintex
 * status:  new => assigned


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

Re: [tor-bugs] #20106 [User Experience/Website]: Tor Mirror Update 09/08/2016

[Tor Bug Tracker & Wiki]

#20106: Tor Mirror Update 09/08/2016
-+---
 Reporter:  aquintex |  Owner:  Sebastian
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  mirror update|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by aquintex):

 Hello everyone, here is a hopefully successful mirror update!

 This is my first attempt using TRAC.

 ​https://github.com/aquintex/torproject.org.git is the summary of changes.

 John

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

Re: [tor-bugs] #20107 [Core Tor/Tor]: somthings wrong about function channel_get_actual_remote_address()

[Tor Bug Tracker & Wiki]

#20107: somthings wrong about function channel_get_actual_remote_address()
+
 Reporter:  DLP_ripper  |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.8.7
 Severity:  Normal  | Resolution:
 Keywords:  channel ip address  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by gk):

 * component:  - Select a component => Core Tor/Tor


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

Re: [tor-bugs] #19733 [Applications/Tor Browser]: GETINFO response parser doesn't handle AF_UNIX entries.

[Tor Bug Tracker & Wiki]

#19733: GETINFO response parser doesn't handle AF_UNIX entries.
-+-
 Reporter:  yawning  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very Low |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:
 Keywords:  tbb-sandbox, tbb-torbutton,  |  Actual Points:
  TorBrowserTeam201609   |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-sandbox, tbb-torbutton, TorBrowserTeam201609R => tbb-
 sandbox, tbb-torbutton, TorBrowserTeam201609
 * status:  needs_review => needs_revision


Comment:

 Looks good with one nit: I guess removing the very first line in
 `torbutton.js` is just an oversight? I think we should keep that one. :)

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

Re: [tor-bugs] #20106 [User Experience/Website]: Tor Mirror Update 09/08/2016 (was: Tor Mirror Update as of 201609080044 Central Time - tar file attached)

[Tor Bug Tracker & Wiki]

#20106: Tor Mirror Update 09/08/2016
-+---
 Reporter:  aquintex |  Owner:  Sebastian
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  mirror update|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

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

[tor-bugs] #20107 [- Select a component]: somthings wrong about function channel_get_actual_remote_address()

[Tor Bug Tracker & Wiki]

#20107: somthings wrong about function channel_get_actual_remote_address()
--+
 Reporter:  DLP_ripper|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  - Select a component  |Version:  Tor: 0.2.8.7
 Severity:  Normal|   Keywords:  channel ip address
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 == description ==
 function '''channel_get_actual_remote_address''' is written to get the ip
 address of a channel, but when we use it in function
 '''command_process_created_cell''', we find that it get the same ip
 address about ''circ->n_chan'' and ''TO_OR_CIRCUIT(circ)->p_chan''.
 But actually they have different ip address because
 ''TO_OR_CIRCUIT(circ)->p_chan'' is not equals to ''circ->n_chan'', and
 ''TO_OR_CIRCUIT(circ)->p_circ_id'' is not equals to ''circ->n_circ_id''.

 == test ==

 If you want to check whether I am right, you can add this code into the
 last line in function '''command_process_created_cell''', the funtion is
 written in the  file
 ''command.c''. I have check it in tor-0.2.8.7 and tor-0.2.7.6.



 {{{
 log_notice(LD_GENERAL, "p_ip_addr:%s, p_circ_id:%u, n_ip_addr:%s,
 n_circ_id:%u",
 channel_get_actual_remote_address(TO_OR_CIRCUIT(circ)->p_chan),
 TO_OR_CIRCUIT(circ)->p_circ_id,
 channel_get_actual_remote_address(circ->n_chan),
 cell->circ_id);
 }}}

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

Re: [tor-bugs] #19934 [Metrics/CollecTor]: CollecTor should use new metrics-lib json classes

[Tor Bug Tracker & Wiki]

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

Comment (by karsten):

 Replying to [comment:4 iwakeh]:
 > Some thoughts:
 >
 > 1. The implementation of #18910 requires CollecTor to have a Java
 representation of index.json to choose the documents to download from the
 partner-synch-Collector instance(s), especially with the pick-and-choose
 requirements from comment:11 in #18910.

 So, this is about using metrics-lib `*Node` classes for obtaining
 descriptors, not for providing `index.json*` files, right?

 I don't recall the exact requirements we discussed for #18910, and I think
 we discussed quite a few variations there.  But what we can already do is
 specify an array of directories to synchronize.  The local CollecTor
 instance would then decide locally from looking at synchronized files
 which ones to keep and copy over and which ones to ignore.

 What we ''could'' do is pass a list of excluded paths to
 `DescriptorCollector`, which would contain paths of consensuses and votes,
 possibly even with last modified times, that we already have and that we
 don't want to synchronize.  However, this feels a bit like premature
 optimization.  There's no big harm in downloading the entire `recent/`
 folder from a remote CollecTor instance and decide locally what to do with
 the data.  We're moving around larger chunks of bytes than that.

 > 2. Shouldn't a CollecTor instance have more fine grained control when
 creating index.json? More than just specifying a directory. Currently it
 includes already `recent` and `archive`.

 Well, we could accept an array of directories instead of just one, if that
 helps.  Or a base directory and an array of contained subdirectories to
 include.  Whatever is most intuitive and does the job.

 > 3. The package was designated as '''alpha''' to prevent too early
 reliance on the new API to have more flexibility when implementing #18910.
 It is well tested in metrics-lib.

 Oh, I'm not worried that it might not be tested well enough.  I'm worried
 about making the API bigger and having to maintain these parts in the
 future.  This whole `index.json*` stuff is something that library users
 ideally shouldn't have to worry about.  That's why I'm still trying hard
 to hide it away as best as I can.  If this turns out to be impossible or
 impracticable, so be it.  But I'm not there yet. :)

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

Re: [tor-bugs] #19856 [Applications/Tor Browser]: Gitian build for OS X is not matching on some machines

[Tor Bug Tracker & Wiki]

#19856: Gitian build for OS X is not matching on some machines
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:  fixed
 Keywords:  tbb-gitian, GeorgKoppen201608,   |  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks. This is commit 73a698d2e1875763c153282a0eb19c259bd3788b on master.

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

Re: [tor-bugs] #19417 [Applications/Tor Browser]: asm.js files should not be cached to disk in Tor Browser and no linkability risk

[Tor Bug Tracker & Wiki]

#19417: asm.js files should not be cached to disk in Tor Browser and no 
linkability
risk
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-disk-leak, tbb-linkability,  |  Actual Points:
  GeorgKoppen201609, TorBrowserTeam201609|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 tbb-disk-leak, tbb-linkability, GeorgKoppen201609,
 TorBrowserTeam201609R
 =>
 tbb-disk-leak, tbb-linkability, GeorgKoppen201609,
 TorBrowserTeam201609
 * status:  needs_review => needs_revision


Comment:

 Dang :/ Testing patches beforehand actually helps I guess.

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