Re: [tor-bugs] #16926 [Applications/Tor Browser]: Multiple OS: Tor Browser leaks domains to system DNS management.

[Tor Bug Tracker & Wiki]

#16926: Multiple OS: Tor Browser leaks domains to system DNS management.
--+--
 Reporter:  DrMikeTwiddle |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Dbryrtfbcbhgf):

 * cc: jackiam2003@… (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] #16926 [Applications/Tor Browser]: Multiple OS: Tor Browser leaks domains to system DNS management.

[Tor Bug Tracker & Wiki]

#16926: Multiple OS: Tor Browser leaks domains to system DNS management.
--+--
 Reporter:  DrMikeTwiddle |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Dbryrtfbcbhgf):

 * cc: jackiam2003@… (removed)


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

Re: [tor-bugs] #22712 [Applications/Tor Browser Sandbox]: AT-SPI: Could not obtain desktop path or name

[Tor Bug Tracker & Wiki]

#22712: AT-SPI: Could not obtain desktop path or name
--+--
 Reporter:  cypherpunks   |  Owner:  yawning
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by yawning):

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


Comment:

 After rethinking this, I'll suppress the error if it's that easy 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

[tor-bugs] #22793 [Applications/Tor Browser]: Printing does not work under specific circumstances with Tor Browser

[Tor Bug Tracker & Wiki]

#22793: Printing does not work under specific circumstances with Tor Browser
--+--
 Reporter:  Td8F  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Printing freezes the browser (all tabs) and does not print under the
 following circumstances:

 1. Tor Browser 7.0.1 (latest)
 2. PDFCreator 2.5 (latest as of yesterday)
 3. Printing an Alphabay page

 I found that printing other pages or using a pre 7.0 Tor Browser version
 makes the problem go away. I therefore think the bug lies with Tor Browser
 and not with PDFCreator.

 So this URL can be printed: https://blockchainbdgpzk.onion/
 (blockchain.info)

 And this can not: http://pwoah7foa6au2pul.onion/login.php (Alphabay login.
 This page does not show any products or any objectionable content so it is
 safe to visit).

 I'll see if I can attach screenshots.

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

Re: [tor-bugs] #22793 [Applications/Tor Browser]: Printing does not work under specific circumstances with Tor Browser

[Tor Bug Tracker & Wiki]

#22793: Printing does not work under specific circumstances with Tor Browser
--+--
 Reporter:  Td8F  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Td8F):

 Note, that cancelling printing freezes all pages which is another
 indication it's a browser 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] #22793 [Applications/Tor Browser]: Printing does not work under specific circumstances with Tor Browser

[Tor Bug Tracker & Wiki]

#22793: Printing does not work under specific circumstances with Tor Browser
--+--
 Reporter:  Td8F  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Td8F):

 I reproduced it in a VM so I'm quite certain OS is fairly clean. Both
 times I used Windows 7 x64.

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

Re: [tor-bugs] #22712 [Applications/Tor Browser Sandbox]: AT-SPI: Could not obtain desktop path or name

[Tor Bug Tracker & Wiki]

#22712: AT-SPI: Could not obtain desktop path or name
--+-
 Reporter:  cypherpunks   |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

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


Comment:

 https://gitweb.torproject.org/tor-browser/sandboxed-tor-
 browser.git/commit/?id=bbd4094157fa8858ca847954fddc63ae15fff815

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

Re: [tor-bugs] #20775 [Applications/Tor Browser Sandbox]: Use Tor Browser's integrated `AF_LOCAL` support on alpha.

[Tor Bug Tracker & Wiki]

#20775: Use Tor Browser's integrated `AF_LOCAL` support on alpha.
--+--
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by yawning):

 * status:  new => assigned


Comment:

 This looks as simple as:

 Set the `TOR_SOCKS_IPC_PATH` env var to point to the SOCKS AF_LOCAL
 socket.
 Set the `TOR_CONTROL_IPC_PATH` env var to point to the control AF_LOCAL
 socket.

 (It is somewhat annoying that the location of these two is split across
 torbutton/torlauncher, but at least I found them.)

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

Re: [tor-bugs] #20775 [Applications/Tor Browser Sandbox]: Use Tor Browser's integrated `AF_LOCAL` support on alpha.

[Tor Bug Tracker & Wiki]

#20775: Use Tor Browser's integrated `AF_LOCAL` support on alpha.
--+--
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Hm, I did those things in a branch, updated the control port surrogate's
 `net/listeners/socks` response, and cleaned up the stub, but I don't get a
 functioning browser.

 As far as I can tell, torbutton claims that it will use the AF_LOCAL
 socket, but goes and opens an AF_INET socket instead for some inexplicable
 reason, resulting in a white window, where I expect content to be.
 Nothing helpful is logged either.

 I might just punt on this, what's there is a bit messy, but it works, and
 there's no reason why it won't continue to work indefinitely.

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

Re: [tor-bugs] #20775 [Applications/Tor Browser Sandbox]: Use Tor Browser's integrated `AF_LOCAL` support on alpha.

[Tor Bug Tracker & Wiki]

#20775: Use Tor Browser's integrated `AF_LOCAL` support on alpha.
--+--
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by yawning):

 * priority:  High => Medium


Comment:

 Tor Browser apparently doesn't work as advertised, or there's more to it,
 and it's not actually high priority because the stub works 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] #20775 [Applications/Tor Browser Sandbox]: Use Tor Browser's integrated `AF_LOCAL` support on alpha.

[Tor Bug Tracker & Wiki]

#20775: Use Tor Browser's integrated `AF_LOCAL` support on alpha.
--+--
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Unsandboxed Tor Browser 7.0.1:
 {{{
 socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 67
 fcntl(67, F_GETFL)  = 0x2 (flags O_RDWR)
 fcntl(67, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
 socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 68
 close(68)   = 0
 socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 68
 fcntl(68, F_GETFL)  = 0x2 (flags O_RDWR)
 fcntl(68, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
 close(68)   = 0
 setsockopt(67, SOL_TCP, TCP_NODELAY, [1], 4) = 0

 socket(AF_UNIX, SOCK_STREAM, 0) = 68
 fcntl(68, F_GETFL)  = 0x2 (flags O_RDWR)
 fcntl(68, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
 close(67)   = 0
 connect(68, {sa_family=AF_UNIX, sun_path="/var/run/tor/socks"}, 106) = 0
 }}}

 Without looking into the Firefox source, what I assume is happening in my
 branch is that the creation of the `AF_INET`/`AF_INET6` sockets fail (with
 `ENOSYS`) due to the seccomp-bpf rules, and Firefox decides not to
 actually open the connection that will work.

 When Tor Browser is configured to use `AF_LOCAL`, the two prior calls
 shouldn't happen to begin with.

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

Re: [tor-bugs] #20775 [Applications/Tor Browser Sandbox]: Use Tor Browser's integrated `AF_LOCAL` support on alpha.

[Tor Bug Tracker & Wiki]

#20775: Use Tor Browser's integrated `AF_LOCAL` support on alpha.
--+--
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Sandboxed Tor Browser 7.0.1 + Bug 20775 feature branch:
 {{{
 2017/07/02 13:58:47 firefox: tbb_stub: socket(2, 0x0001, 0)
 2017/07/02 13:58:47 firefox: tbb_stub: socket(2, 0x0001, 0)
 }}}

 In the context of `socket()`, `2`, is `AF_INET`.  For debugging purposes,
 the stub is returning `-1`, with `errno` set to `EAFNOSUPPORT`, on the off
 chance that Firefox is freaking out about the `ENOSYS` response.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22794 [Applications/Tor Browser Sandbox]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
-+-
 Reporter:  yawning  |  Owner:  yawning
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser Sandbox|   Keywords:  tbb-security, tbb-
 Severity:  Normal   |  sandboxing
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Discovered when trying to resolve #20775.

 Unsandboxed Tor Browser 7.0.1:
 {{{
 socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 67
 fcntl(67, F_GETFL)  = 0x2 (flags O_RDWR)
 fcntl(67, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
 socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 68
 close(68)   = 0
 socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 68
 fcntl(68, F_GETFL)  = 0x2 (flags O_RDWR)
 fcntl(68, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
 close(68)   = 0
 setsockopt(67, SOL_TCP, TCP_NODELAY, [1], 4) = 0

 socket(AF_UNIX, SOCK_STREAM, 0) = 68
 fcntl(68, F_GETFL)  = 0x2 (flags O_RDWR)
 fcntl(68, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
 close(67)   = 0
 connect(68, {sa_family=AF_UNIX, sun_path="/var/run/tor/socks"}, 106) = 0
 }}}

 If the first `socket` (`AF_INET`) call fails (as it will due to seccomp-
 bpf) the AF_LOCAL socket never gets created, and pages don't load.  The
 failure mode doesn't appear to depend on `errno` (at least, it didn't make
 a difference if it was `ENOSYS` or `EAFNOSUPPORT`).

 Using IPC should mean, "Tor Browser uses IPC, and only IPC", and not "Tor
 Browser refuses to work if non-IPC socket creation fails", because the
 whole point of using IPC in the first place is so that Tor Browser can be
 ran in a way that disallows non-IPC connections.

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

Re: [tor-bugs] #20775 [Applications/Tor Browser Sandbox]: Use Tor Browser's integrated `AF_LOCAL` support on alpha.

[Tor Bug Tracker & Wiki]

#20775: Use Tor Browser's integrated `AF_LOCAL` support on alpha.
--+--
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Opened #22794.  This won't happen till that's fixed, because allowing non-
 AF_LOCAL socket creation in the seccomp-bpf policy is totally out of the
 question.

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

Re: [tor-bugs] #22794 [Applications/Tor Browser Sandbox]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security, tbb-sandboxing  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 A minimal/self contained LD_PRELOAD that can reproduce the behavior:
 {{{
 #include 
 #include 
 #include 
 #include 

 #define _GNU_SOURCE
 #include 
 #include 

 int socket(int domain, int type, int protocol) {
   fprintf(stderr, "stub: socket(%d, 0x%08x, %d)\n", domain, type,
 protocol);
   if (domain != AF_LOCAL) {
 fprintf(stderr, "stub: domain is not AF_LOCAL, rejecting\n");
 errno = EAFNOSUPPORT;
 return -1;
   }
   return syscall(SYS_socket, domain, type, protocol);
 }
 }}}

 And commenting out the rejection (as in always calling `syscall()`,
 regardless of the domain), magically makes things start 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] #22789 [Core Tor/Tor]: Tor 0.3.1.4-alpha crash on OpenBSD-current

[Tor Bug Tracker & Wiki]

#22789: Tor 0.3.1.4-alpha crash on OpenBSD-current
--+
 Reporter:  fredzupy  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.1.4-alpha
 Severity:  Major | Resolution:
 Keywords:  tor crash inet_pton ???-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 if to pass "0x" to OpenBSD's strtol it will return src==next

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

Re: [tor-bugs] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs needs-insight needs-  |  Actual Points:
  diagnosis  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by DrWhax):

 Saw this today as well under 0.3.0.8 Debian Jessie

 {{{
 Jul 01 06:41:33.000 [notice] Tor 0.3.0.8 (git-72ffaeea27041e95) opening
 new log file.
 Jul 01 07:49:53.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 08:21:28.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 10:47:06.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 11:48:21.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 12:05:19.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 12:14:40.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 12:22:32.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 12:23:20.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 12:31:30.000 [notice] Heartbeat: Tor's uptime is 20 days 0:00
 hours, with 3811 circuits open. I've sent 62231.98 GB and received
 61576.32 GB.
 Jul 01 12:31:30.000 [notice] Circuit handshake stats since last time:
 12900/12900 TAP, 111930/111930 NTor.
 Jul 01 12:31:30.000 [notice] Since startup, we have initiated 0 v1
 connections, 0 v2 connections, 0 v3 connections, and 35407 v4 connections;
 and received 2434 v1 connections, 1737 v2 connections, 10107 v3
 connections, and 977409 v4 connections.
 Jul 01 12:58:13.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 13:14:03.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 16:47:35.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 17:00:43.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 17:54:01.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 18:31:30.000 [notice] Heartbeat: Tor's uptime is 20 days 6:00
 hours, with 3854 circuits open. I've sent 62438.97 GB and received
 61780.52 GB.
 Jul 01 18:31:30.000 [notice] Circuit handshake stats since last time:
 7931/7931 TAP, 136428/136428 NTor.
 Jul 01 18:31:30.000 [notice] Since startup, we have initiated 0 v1
 connections, 0 v2 connections, 0 v3 connections, and 35782 v4 connections;
 and received 2450 v1 connections, 1756 v2 connections, 10159 v3
 connections, and 993920 v4 connections.
 Jul 01 20:25:13.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 20:59:04.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 22:26:56.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 01 23:02:34.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 02 00:21:16.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 02 00:31:30.000 [notice] Heartbeat: Tor's uptime is 20 days 12:00
 hours, with 7998 circuits open. I've sent 62679.06 GB and received
 62018.22 GB.
 Jul 02 00:31:30.000 [notice] Circuit handshake stats since last time:
 8533/8533 TAP, 168507/168507 NTor.
 Jul 02 00:31:30.000 [notice] Since startup, we have initiated 0 v1
 connections, 0 v2 connections, 0 v3 connections, and 36075 v4 connections;
 and received 2470 v1 connections, 1769 v2 connections, 10252 v3
 connections, and 1011297 v4 connections.
 Jul 02 02:33:25.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 Jul 02 04:25:30.000 [warn] T

Re: [tor-bugs] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs needs-insight needs-  |  Actual Points:
  diagnosis  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by s7r):

 My relay running 0.3.1.2-alpha-dev (git-1763aa058b08a1c5)reported this on
 Jul 01 (yesterday) and Jul 02 (today) more than usual (it usually logs
 this warn few times per month) but just yesterday and today 24 times, at
 few hours interval between each warning.

 Maybe this occurs when the relay in question is being used as an
 introduction point (or HSDir maybe) that someone tries to attack / de-
 anonymize using some weird technique? I am keeping an eye on this and I
 can't find a logical explanation why sometimes we see it, sometimes not...
 not being able to reproduce 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] #21321 [Applications/Tor Browser]: .onion HTTP is shown as non-secure in Tor Browser

[Tor Bug Tracker & Wiki]

#21321: .onion HTTP is shown as non-secure in Tor Browser
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  ff52-esr, tbb-usability, ux-team,|  Actual Points:
  TorBrowserTeam201706   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:34 linda]:
 > Hi, the UX team has reviewed this ticket, and we recommend removing the
 warnings as soon as possible and working on messaging thereafter.
 >
 > I think that there are two problems to solve, 1) the password and
 padlock warnings are misleading users, telling them that something is
 insecure when it isn't 2) educating users on what secure means. I think
 that we can, and should, solve these issues independently. Getting rid of
 the warnings will be a much better improvement than leaving them up, even
 if there is no explanation.
 >
 > Of course, it would be good to educate users on why .onion sites are
 secure. When we onboard users to Tor, we should mention .onion sites and
 other features on first use, and show information on .onion sites when
 they first visit an onion website. Additionally, we can also put a message
 when you click on or hover over the "secure" indicator (something like
 [https://share.riseup.net/#fi-f_QKZqY8pV8Kf0BXR9g this]) that says why
 .onion sites are safe, for people who are wondering why it is safe.
 >

 I think this is a very reasonable course of action. +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] #22789 [Core Tor/Tor]: Tor 0.3.1.4-alpha crash on OpenBSD-current

[Tor Bug Tracker & Wiki]

#22789: Tor 0.3.1.4-alpha crash on OpenBSD-current
--+
 Reporter:  fredzupy  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.1.4-alpha
 Severity:  Major | Resolution:
 Keywords:  tor crash inet_pton ???-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by fredzupy):

 I'm on i386 architecture :
 kern.version=OpenBSD 6.1-current (GENERIC.MP) #150: Sat Jun 24 22:22:03
 MDT 2017
 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP

 It only happens once. I can't induce it, for now.

 Relaunch about 12h ago and it did not happen 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] #22789 [Core Tor/Tor]: Tor 0.3.1.4-alpha crash on OpenBSD-current

[Tor Bug Tracker & Wiki]

#22789: Tor 0.3.1.4-alpha crash on OpenBSD-current
--+
 Reporter:  fredzupy  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.1.4-alpha
 Severity:  Major | Resolution:
 Keywords:  tor crash inet_pton ???-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 fredzupy, can I ask you privately to visit some url via your client?

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

Re: [tor-bugs] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs needs-insight needs-  |  Actual Points:
  diagnosis  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 I've made this reproducible but with a change to the tor code... I wanted
 to test my theory that basically at least _two_ `ESTABLISH_RENDEZVOUS`
 cells are sent to the RP on the same circuit. I've modified Tor to pin a
 RP I control and then made it call twice
 `rend_client_rendcirc_has_opened()` in `circuit_has_opened()`.

 And here you go, you can see this log being triggered on my relay (the
 RP):

 {{{
 Jul 02 18:31:47.000 [warn] Tried to establish rendezvous on non-OR circuit
 with purpose Acting as rendevous (pending)
 }}}

 This means somehow that either the tor client can call twice
 `circuit_has_opened()` and which means it can send two cells on the same
 circuit (#21084) or then some other client implementation out there is
 doing the wrong thing triggering warning everywhere.

 We should probably downgrade that log_warn to a PROTOCOL warning because
 anyone out there can send two cells on the same circuit just "for fun"...

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

Re: [tor-bugs] #22789 [Core Tor/Tor]: Tor 0.3.1.4-alpha crash on OpenBSD-current

[Tor Bug Tracker & Wiki]

#22789: Tor 0.3.1.4-alpha crash on OpenBSD-current
--+
 Reporter:  fredzupy  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.1.4-alpha
 Severity:  Major | Resolution:
 Keywords:  tor crash inet_pton ???-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by fredzupy):

 No_0x told me via IRC to access 0xtrololo via Tor and effectively it crash
 with the same assert.

 Something like :
 $ telnet 0xquux 80

 ends with the following lines in log :
 Jul  2 22:25:37 ethnao Tor[42555]: tor_assertion_failed_(): Bug:
 src/common/compat.c:2597: tor_inet_pton: Assertion next != src failed;
 aborting. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
 Jul  2 22:25:37 ethnao Tor[42555]: Bug: Assertion next != src failed in
 tor_inet_pton at src/common/compat.c:2597. (Stack trace not available) (on
 Tor 0.3.1.4-alpha fab91a290ded3e74)

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

Re: [tor-bugs] #22593 [Webpages/Website]: Minify HTML, CSS and JavaScript resources on all websites of the torproject.org to save a bit of bandwidth

[Tor Bug Tracker & Wiki]

#22593: Minify HTML, CSS and JavaScript resources on all websites of the
torproject.org to save a bit of bandwidth
--+---
 Reporter:  cypherpunks   |  Owner:  linda
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

 * priority:  Medium => High
 * severity:  Normal => Major


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22795 [Core Tor/Tor]: torrc has an optional final newline

[Tor Bug Tracker & Wiki]

#22795: torrc has an optional final newline
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 doc/torrc_format.txt says that every line has to have a linefeed:

 In https://gitweb.torproject.org/tor.git/tree/doc/torrc_format.txt#n33

 But tor actually makes the final newline in the file optional.

 Also, don't we allow CRLF as a line ending on Windows?
 (Or did we never make that happen?)

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

Re: [tor-bugs] #21074 [Core Tor/Tor]: setrlimit fails OSX Sierra

[Tor Bug Tracker & Wiki]

#21074: setrlimit fails OSX Sierra
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.6-rc
 Severity:  Normal   | Resolution:
 Keywords:  OSX Sierra setrlimit, tbb-wants  |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by ugyballoons):

 Same issue here- have also just installed 32bit version of Ableton Live 9.

 Tor now exits with error as above.
 Using previous OS X version, however- 10.11.6

 Is this still a common issue or has it been opened and filleted on another
 ticket?

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

Re: [tor-bugs] #10089 [Applications/Tor Browser]: middlemouse.contentLoadURL is set to true by default

[Tor Bug Tracker & Wiki]

#10089: middlemouse.contentLoadURL is set to true by default
-+-
 Reporter:  WDXfjqDN4QKGYrlY |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  middlemouse, privacy, tbb-firefox-   |  Actual Points:
  patch  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by discram):

 This just happened to me and was completely unintended and unexpected (and
 confusing as I hadn't intentionally copied the URL to begin with, although
 I had visited it earlier in another browser).  This setting is actually
 turned off by default in Firefox Linux, but not Tor Linux.

 I obviously have no data to back this up, but I'd imagine that the
 majority of users who do this do it unintentionally (although perhaps
 intentional users do it frequently).

 Given the potential to reveal your identity and the ease of switching it
 back on, I see this as an easy change to default off.

 In case it isn't clear from the rest of the ticket, middleclicking
 ANYWHERE on a page except on a link will immediately navigate to the URL
 in the clipboard.

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

Re: [tor-bugs] #22593 [Webpages/Website]: Minify HTML, CSS and JavaScript resources on all websites of the torproject.org to save a bit of bandwidth

[Tor Bug Tracker & Wiki]

#22593: Minify HTML, CSS and JavaScript resources on all websites of the
torproject.org to save a bit of bandwidth
--+---
 Reporter:  cypherpunks   |  Owner:  linda
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arma):

 Don't browsers do compression generally?

 So the numbers from the above comment don't actually represent the savings
 we'd get?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22796 [- Select a component]: Default browser in Ubuntu doesn't work properly

[Tor Bug Tracker & Wiki]

#22796: Default browser in Ubuntu doesn't work properly
--+--
 Reporter:  macho.p   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.3.0.9
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When I set tor as the default browser, and click on a link in another
 application (e.g. Thunderbird), the tab doesn't open. I can use the tor
 browser properly, and a corresponding onion logo appears in Ubuntu's
 launcher when I do. With tor set as default, when you click a link, you
 can see another blue world logo, also labeled tor browser, briefly appear
 in the launcher before closing without ever displaying the page.

 my /etc/apt/sources.list includes this:

  $ dpkg -l tor tor-browser
 Desired=Unknown/Install/Remove/Purge/Hold
 | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-
 pend
 |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
 ||/ Name   Version  Architecture Description
 +++-==---=
 ii  tor0.3.0.9-1~ze amd64anonymizing overlay network
 for T
 ii  tor-browser6.5.1-1~webu amd64Tor Browser Bundle

 $ uname -a
 Linux basic 4.10.0-26-generic #30-Ubuntu SMP Tue Jun 27 09:30:12 UTC 2017
 x86_64 x86_64 x86_64 GNU/Linux

 $ sudo update-alternatives --config x-www-browser
 There are 3 choices for the alternative x-www-browser (providing
 /usr/bin/x-www-browser).

   SelectionPathPriority   Status
 
   0/usr/bin/chromium-browser40auto mode
   1/usr/bin/chromium-browser40manual mode
   2/usr/bin/firefox 40manual mode
 * 3/usr/bin/tor-browser-en.sh   1 manual mode

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

Re: [tor-bugs] #22796 [- Select a component]: Default browser in Ubuntu doesn't work properly

[Tor Bug Tracker & Wiki]

#22796: Default browser in Ubuntu doesn't work properly
--+--
 Reporter:  macho.p   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.3.0.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by macho.p):

 Hmm some of my message got munged but I think you get the 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] #20105 [Applications/Tor Browser]: Selecting Open With TorBrowser on a Mac Opens the File in Default Browser Instead

[Tor Bug Tracker & Wiki]

#20105: Selecting Open With TorBrowser on a Mac Opens the File in Default 
Browser
Instead
--+--
 Reporter:  hdub  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #17670| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Replying to [comment:9 mcs]:
 > Replying to [comment:8 cypherpunks]:
 > > This behaviour appears to be fixed in 7.0.1 on macOS 10.12.5, but it
 now also opens a second TorBrowser window when you open a local file in
 TorBrowser.
 >
 > What is happening in this case is that the first window (the one that
 contains the "Open With" file) is opened before Tor Launcher has finished
 setting up the Tor network connection. Tor Launcher tries to block startup
 of the browser until bootstrapping completes, but another part of the
 browser handles the open request anyway.
 >
 >
 > The right fix is probably to do what teor said at the end of comment:2.
 Unfortunately, it may be a lot of work to modify the Firefox code that Tor
 Browser is based on to queue open file requests rather than processing
 them right away.

 I think an extra window is something we can live with: it's not a security
 issue any more, because opening links and documents with Tor Browser as
 the default browser works in 7.0.1.

 Do you want to close this ticket, mcs?

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

Re: [tor-bugs] #17670 [Applications/Tor Browser]: Mac OSX mistakes Tor as Firefox default browser

[Tor Bug Tracker & Wiki]

#17670: Mac OSX mistakes Tor as Firefox default browser
--+--
 Reporter:  patrickbateman|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Opening links and documents with Tor Browser as the default browser works
 in 7.0.1, probably because #21724 was fixed.

 Do you want to close this ticket, mcs or arthuredelstein?

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

Re: [tor-bugs] #21732 [Applications/Tor Browser]: Stop the Meek Tor Browser opening links or documents on macOS

[Tor Bug Tracker & Wiki]

#21732: Stop the Meek Tor Browser opening links or documents on macOS
--+--
 Reporter:  teor  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  meek  |  Actual Points:
Parent ID:  #17670| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Opening links and documents with Tor Browser as the default browser works
 in 7.0.1, probably because #21724 was fixed. That means that this bug is
 probably fixed as well.

 Do you want to close this, mcs or dcf?

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

Re: [tor-bugs] #22796 [- Select a component]: Default browser in Ubuntu doesn't work properly

[Tor Bug Tracker & Wiki]

#22796: Default browser in Ubuntu doesn't work properly
--+--
 Reporter:  macho.p   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.3.0.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 First issue: it looks like you're using the torbrowserlauncher deb? That
 isn't made by us, so you might have better luck filing a ticket about it
 in the debian bts. But alas, I expect you won't have much luck there
 either.

 Second issue: is making tor browser your default browser even supposed to
 work? That is, are there any howtos out there that explain how to do it in
 a way that's actually safe? I have seen several people wanting to do this,
 and each time they hacked together something that was really unsafe.

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

Re: [tor-bugs] #22796 [- Select a component]: Default browser in Ubuntu doesn't work properly

[Tor Bug Tracker & Wiki]

#22796: Default browser in Ubuntu doesn't work properly
--+--
 Reporter:  macho.p   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.3.0.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Oh, third issue: tor browser 6.5.1 is insecure and old and out of date.
 Nobody should be using it, and any place that gives you that version when
 you install tor browser is bad news.

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

Re: [tor-bugs] #12763 [Applications/Tor Browser]: -no-remote prevents using Tor Browser as default browser

[Tor Bug Tracker & Wiki]

#12763: -no-remote prevents using Tor Browser as default browser
-+-
 Reporter:  micahlee |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  torbrowser-launcher, tbb, default|  Actual Points:
  browser|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cacahuatl):

 * severity:   => Normal


Comment:

 See torbrowser-launcher's issue [https://github.com/micahflee/torbrowser-
 launcher/issues/157 #157 ] for a graphic example of exactly how this goes
 wrong and why it shouldn't be attempted outside of carefully considered
 use-cases like Tails'.

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

Re: [tor-bugs] #22453 [Core Tor/Tor]: We should rip out the bandwidth self-test

[Tor Bug Tracker & Wiki]

#22453: We should rip out the bandwidth self-test
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:2 teor]:
 > It's useful as a fallback if we lose 2 bwauths, which almost happened
 yesterday.
 > And also, the bwauths depend on this test to provide their ratios
 between the observed and measured bandwidths.

 No, I think measuring and self-reporting bandwidth is useful for both the
 reasons you describe, but doing a little 500KB blitz of traffic at start
 time is not really helpful for either of those things.

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

Re: [tor-bugs] #8247 [Core Tor/Tor]: Some day soon, a 50KB bandwidth test will be too low for the Fast flag

[Tor Bug Tracker & Wiki]

#8247: Some day soon, a 50KB bandwidth test will be too low for the Fast flag
--+--
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Replying to [comment:3 arma]:
 > In sum. a vestigial tiny bw self-test seems silly to keep around.

 I opened a separate ticket for this one: #22453

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

Re: [tor-bugs] #22387 [Webpages/Blog]: Make unapproved comments visually different from approved comments

[Tor Bug Tracker & Wiki]

#22387: Make unapproved comments visually different from approved comments
---+
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+
Changes (by arma):

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


Comment:

 I'm going to close this one as good enough, since there's a clear word
 'approve' and also you can search for that word in the page. We can tackle
 the "make it look better" side as needed in the other tickets. 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] #21862 [Applications/Tor Browser]: Make rust code in ESR 52 proxy safe

[Tor Bug Tracker & Wiki]

#21862: Make rust code in ESR 52 proxy safe
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201706R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by manish.earth):

 In the next ESR (and already in the current release), `--enable-rust` will
 not exist.

 When we say "third party" code it means vendored dependencies necessary
 for building Firefox that are not directly maintained in the mozilla-
 central repo. This is not something that can/should be ripped out.
 Currently, the third_party directory is only used for vendored Rust
 dependencies, however other vendored code may move there in the future.

 In fact, rust-url is maintained by Servo, which is a Mozilla project.
 However, there are other crates under third_party which are not maintained
 by Mozilla. We intend to do some auditing before shipping. The currently
 shipping crates are all maintained by the Servo or Rust projects.


 Currently (as of a recent nightly), the Rust code in mozilla-central
 consists of:

  - The mp4 parser. Enabled by default. Should not hit the network.
  - Stylo (enabled recently); servo's style system in Firefox. Built by
 default, preffed off , planned to be preffed on on 57. Can be disabled; is
 a large chunk of code. May become mandatory a few release cycles after 57.
 This should not hit the network on its own, we thread through Gecko
 networking code.
  - Webrender. Built by default, preffed off. Should not hit the network.
  - encoding-rs. I believe this is built by default and preffed on, but I
 am unsure. Should not hit the network.
  - rust-url for parsing, serialization, and manipulation of URLs. built by
 default, preffed off. This is a currently-stalled experiment which won't
 be enabled before we make it work well with everything. While this itself
 shouldn't be hitting the network (it's only for dealing with the URL data,
 not making requests), it will be audited more rigorously before being
 enabled (right now it's just there for experimentation)
  - We unconditionally use rust-url's IPV6 parsing code as of
 https://bugzilla.mozilla.org/show_bug.cgi?id=1324243 . This code shouldn't
 hit the network.


 The call to `getaddrinfo` mentioned here exists because there is a
 `ToSocketAddrs` implementation for URL; an implementation which is never
 invoked.

 However, we can probably add a build time option to remove them.

 All the Rust code in Firefox gets built into
 `$objdir/toolkit/library/$target/(debug or release)/libgkrust.a`, so
 inspecting that binary may be useful in ensuring that getaddrinfo is never
 called. Currently none of the Rust code being used should be calling it.
 However, the standard library does include a call to getaddrinfo that goes
 unused, which still turns up in that file -- I'm not sure how to
 differentiate between used and unused here -- I tried creating a test Rust
 staticlib that didn't do anything and even with `-Clto` the final
 staticlib still had an unlinked getaddrinfo symbol. If y'all know the
 correct linker args and `nm` / `objdump` invocation to use, let me know
 and I'll run it on my local all-rust-enabled Firefox build.

 Let me know if you need more info!

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

Re: [tor-bugs] #22520 [Core Tor/Tor]: Incorrect encoding for error message

[Tor Bug Tracker & Wiki]

#22520: Incorrect encoding for error message
-+-
 Reporter:  Vort |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.2-alpha
 Severity:  Minor| Resolution:
 Keywords:  encoding windows russian nt-service  |  Actual Points:
  win32  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Vort):

 The easiest solution is to change error message language to English.
 This should not be a problem, since all other messages in Tor are also in
 English.

 Here is the patch for this variant:
 attachment:english_error_message.patch.

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

Re: [tor-bugs] #22520 [Core Tor/Tor]: Incorrect encoding for error message

[Tor Bug Tracker & Wiki]

#22520: Incorrect encoding for error message
-+-
 Reporter:  Vort |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.2-alpha
 Severity:  Minor| Resolution:
 Keywords:  encoding windows russian nt-service  |  Actual Points:
  win32  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => needs_review
 * milestone:  Tor: unspecified => Tor: 0.3.2.x-final


Comment:

 I think this is a good and simple change, but I can't test it.
 Can someone else who isn't the patch author make sure it works?

 Also, I think this is a good idea in general because it means that we
 don't log the user's language settings. (Which isn't that important on a
 relay, but it's still good.)

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

Re: [tor-bugs] #22453 [Core Tor/Tor]: We should rip out the bandwidth self-test

[Tor Bug Tracker & Wiki]

#22453: We should rip out the bandwidth self-test
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Ok, so should we send AuthDirFastGuarantee*10 (1MB) instead?
 (Enough to get the Fast flag?)

 Or AuthDirGuardGuarantee*10 (20MB)?
 (Enough to get the guard flag?)

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

Re: [tor-bugs] #22542 [Applications/Tor Browser]: Tor Browser 7.0 Security Settings Window too small on macOS 10.12

[Tor Bug Tracker & Wiki]

#22542: Tor Browser 7.0 Security Settings Window too small on macOS 10.12
-+-
 Reporter:  teor |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  tbb-security-slider, TorBrowserTeam201706R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 This works for me using macOS 10.12.5 outside a VM (retina), but doesn't
 work inside a VM (non-retina).

 I am running macOS 10.12.5 with Tor Browser 7.0.1 and Tor Button 1.9.7.4
 in both environments.

 I think it's better than it used to be, but there are still 2 lines of
 text missing at the bottom on non-retina. (And on retina, there are a few
 pixels still hidden at the bottom, which makes it possible to trigger the
 scroll bar.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22797 [Core Tor/Tor]: macOS should use ULIMIT_BUFFER for open files

[Tor Bug Tracker & Wiki]

#22797: macOS should use ULIMIT_BUFFER for open files
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  macOS file-limits
Actual Points:|  Parent ID:  #21074
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+
 The workaround to use OPEN_MAX for open files doesn't subtract
 ULIMIT_BUFFER from the limit that's used.

 This was introduced in tor-0.2.0.10-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

[tor-bugs] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

[Tor Bug Tracker & Wiki]

#22798: Windows relay is several times slower than Linux relay
-+-
 Reporter:  Vort |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:  Tor: 0.2.9.11
  Tor/Tor|
 Severity:  Major|   Keywords:  tor-relay network performance win32
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 I have launched two relays: first one in native mode on Windows, second
 one in virtual machine on Linux.

 Then measured their bandwidth using three-hop circuit: refEntry, myRelay,
 refExit
 refEntry is
 
[[https://atlas.torproject.org/#details/13B2354C74CCE29815B4E1F692F2F0E86C7F13DD|13B2354C74CCE29815B4E1F692F2F0E86C7F13DD]]
 refExit is
 
[[https://atlas.torproject.org/#details/07C05ED4825F51D5BE4CDBBAA80BFA484132A2F5|07C05ED4825F51D5BE4CDBBAA80BFA484132A2F5]]

 Windows version of Tor was able to provide 51 KiB/s.
 Linux version - 163 KiB/s, which is three times higher.

 But this was my measurements.
 BwAuth ratings for this relays are far more different:
 Windows one have weight = 18 (19/13/22/18).
 Linux one got weight = 1030 (293/1030/1460).

 Which leads to actual traffic rising from 1 KiB/s to ~500 KiB/s.

 I can keep relay in virtual machine for a while, but it would be much
 better if Windows version gets fixed.

 Here are the versions of software used in tests:
 OS: Windows 7 SP1 x64 (host)
 OS: Ubuntu 16.04 x64 (guest)
 VM: VirtualBox 5.1.22
 Tor: 0.2.9.11 (Linux)
 Tor: 0.2.9.11, 0.3.0.8 (Windows)

 Also I have obtained TCP packets dump from relay's network interface:
 https://yadi.sk/d/2XrUmz3A3KgqZb

 Packets 1-1584 are slow transfer (Windows relay).
 Packets 1585-8659 are fast transfer (Linux VM relay).

 I can made additional tests and provide additional information if needed.

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

Re: [tor-bugs] #22797 [Core Tor/Tor]: macOS should use ULIMIT_BUFFER for open files

[Tor Bug Tracker & Wiki]

#22797: macOS should use ULIMIT_BUFFER for open files
---+
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  macOS file-limits  |  Actual Points:
Parent ID:  #21074 | Points:  0.2
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  new => needs_review


Comment:

 Please see my branch bug22797-031 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

Re: [tor-bugs] #21074 [Core Tor/Tor]: setrlimit fails OSX Sierra

[Tor Bug Tracker & Wiki]

#21074: setrlimit fails OSX Sierra
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.7
 Severity:  Normal   | Resolution:
 Keywords:  OSX Sierra setrlimit, tbb-wants  |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * version:  Tor: 0.2.9.6-rc => Tor: 0.2.6.7
 * milestone:  Tor: unspecified => Tor: 0.3.1.x-final


Comment:

 Thanks for letting us know this is still happening.
 I made #22797 to fix a bug in this code, but it probably won't fix this
 issue.

 We still need more information.
 If you have this issue:
 * do you have Ableton Live installed?
 * what do you see when you open Terminal.app and type:
 {{{
 ulimit -n -S
 ulimit -S -n 10240
 ulimit -n -S
 ulimit -n -H
 }}}
   For example, I see:
 {{{
 base:~ dev$ ulimit -n -S
 256
 base:~ dev$ ulimit -S -n 10240
 base:~ dev$ ulimit -n -S
 10240
 base:~ dev$ ulimit -n -H
 unlimited
 }}}
 * what happens if you create another user?
   * does Tor work for that user?
   * what do you get from the Terminal commands above for that user?

 This seems to be an issue with Ableton Live:
 * does tor work if you quit Ableton Live?
 * does tor work if you uninstall Ableton Live?
 * what do you get from the Terminal commands above:
   * before you have ever installed Ableton Live?
   * after you install Ableton Live?
   * after you uninstall Ableton Live?

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

Re: [tor-bugs] #22593 [Webpages/Website]: Minify HTML, CSS and JavaScript resources on all websites of the torproject.org to save a bit of bandwidth

[Tor Bug Tracker & Wiki]

#22593: Minify HTML, CSS and JavaScript resources on all websites of the
torproject.org to save a bit of bandwidth
--+---
 Reporter:  cypherpunks   |  Owner:  linda
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by teor):

 Replying to [comment:4 arma]:
 > Don't browsers do compression generally?
 >
 > So the numbers from the above comment don't actually represent the
 savings we'd get?

 Most sites that minify, minify then rely on the server/browser to
 negotiate compression.
 (For example, non-local scoped identifier names can't be minified, but
 they can be compressed.)

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

Re: [tor-bugs] #22687 [Webpages/Website]: Please remove text from "Jobs" webpage

[Tor Bug Tracker & Wiki]

#22687: Please remove text from "Jobs" webpage
--+
 Reporter:  ewyatt|  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by hiro):

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


Comment:

 Text was removed.

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

Re: [tor-bugs] #22593 [Webpages/Website]: Minify HTML, CSS and JavaScript resources on all websites of the torproject.org to save a bit of bandwidth

[Tor Bug Tracker & Wiki]

#22593: Minify HTML, CSS and JavaScript resources on all websites of the
torproject.org to save a bit of bandwidth
--+--
 Reporter:  cypherpunks   |  Owner:  hiro
 Type:  enhancement   | Status:  accepted
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by hiro):

 * owner:  linda => hiro
 * status:  new => accepted


Comment:

 I'd love to see the page speed module integrated in our apache config.
 Meanwhile I'll minify resources myself and since I am the one updating the
 current website more frequently I'll make sure to maintain 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