[tor-bugs] #24779 [Core Tor/Tor]: Investigate Windows 11(?) AF_UNIX support

[Tor Bug Tracker & Wiki]

#24779: Investigate Windows 11(?) AF_UNIX support
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  windows, socket
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:|
--+
 Windows has added AF_UNIX to their developer builds:
 https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-
 windows/

 We should make sure this doesn't cause any security issues in Tor.
 And maybe we should support it eventually.

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

Re: [tor-bugs] #24737 [Core Tor/Tor]: Recommend a MaxMemInQueues value in the Tor man page

[Tor Bug Tracker & Wiki]

#24737: Recommend a MaxMemInQueues value in the Tor man page
+
 Reporter:  starlight   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  doc, tor-relay  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+

Comment (by teor):

 Moved conversation from #22255.

 Replying to [ticket:22255#comment:80 starlight]:
 > Replying to [ticket:22255#comment:79 teor]:
 > > I'd still like to see someone repeat this analysis with 0.3.2.8-rc,
 and post the results to #24737.
 > > It's going to be hard for us to close that ticket without any idea of
 the effect of our changes.
 >
 > I'm not willing to run a newer version till one is declared LTS, but can
 say that even when my relay is not under attack memory consumption goes to
 1.5G with the 1G max queue setting.  Seems to me the 2x max queues memory
 consumption is a function of the overheads associated with tor daemon
 queues and related processing, including malloc slack space.

 Saying 2x is a useful guide, but I think we can do better. Because I see
 very different behaviour on systems with a lot more RAM.

 This is how the overheads work on my 0.3.0 relay with 8 GB per tor
 instance, and a high MaxMemInQueues:
 * 512 MB per instance with no circuits
 * 256 - 512 MB extra per instance with relay circuits
 * 256 - 512 MB extra per instance with exit streams
 The RAM usage will occasionally spike to a few gigabytes, but I've never
 seen it all used.

 So I think we should document the following RAM usage and MaxMemInQueues
 settings:
 * Relays: minimum 768 MB, set MaxMemInQueues to (RAM per instance - 512
 MB)*N
 * Exits: minimum 1GB, set MaxMemInQueues to (RAM per instance - 768 MB)*N

 For all versions without the destroy cell patch (0.3.2.7-rc and all
 current versions as of 1 January 2018), N should be 0.5 or lower. It's
 reasonable to expect destroy cell queues and other objects to take up
 approximately the same amount of RAM as the queues.

 For all versions with the destroy cell patch (0.3.2.8-rc and all versions
 released after 1 January 2018), N should be 0.75 or lower. It's reasonable
 to expect destroy cell queues and other objects to take up a third of the
 queue RAM.

 Now we just have to turn this into a man page patch and wiki entry.

 > Anyone running a busy relay on an older/slower system and with
 MaxMemInQueues=1024MB can check /proc//status to see how much memory
 is consumed.  Be sure DisableAllSwap=1 is set and the queue limit is not
 higher since the point is to observe actual memory consumed relative to a
 limit likely to be approached under normal operation.
 >
 > Another idea is to add an option to the daemon to cause queue memory
 preallocation.  This would be a nice hardening feature as it will reduce
 malloc() calls issued under stress, and of course would allow more
 accurate estimates of worst-case memory consumption.  If OOM strikes with
 preallocated queues that would indicate memory leakage.

 Please open a ticket for this feature in 0.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] #22255 [Core Tor/Tor]: Frequent OOM kills of tor process

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor process
--+
 Reporter:  DeS   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:80 starlight]:
 > Replying to [comment:79 teor]:
 > > I'd still like to see someone repeat this analysis with 0.3.2.8-rc,
 and post the results to #24737.
 > > It's going to be hard for us to close that ticket without any idea of
 the effect of our changes.
 >
 > I'm not willing to run a newer version till one is declared LTS, but can
 say that even when my relay is not under attack memory consumption goes to
 1.5G with the 1G max queue setting.  Seems to me the 2x max queues memory
 consumption is a function of the overheads associated with tor daemon
 queues and related processing, including malloc slack space.
 >
 > Anyone running a busy relay on an older/slower system and with
 MaxMemInQueues=1024MB can check /proc//status to see how much memory
 is consumed.  Be sure DisableAllSwap=1 is set and the queue limit is not
 higher since the point is to observe actual memory consumed relative to a
 limit likely to be approached under normal operation.
 >
 > Another idea is to add an option to the daemon to cause queue memory
 preallocation.  This would be a nice hardening feature as it will reduce
 malloc() calls issued under stress, and of course would allow more
 accurate estimates of worst-case memory consumption.  If OOM strikes with
 preallocated queues that would indicate memory leakage.

 I have answered this on #24737, because it will get lost on a closed
 ticket.
 Please move all future discussion there.

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

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

[Tor Bug Tracker & Wiki]

#21074: setrlimit fails OSX Sierra
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.7
 Severity:  Normal   | Resolution:
 Keywords:  OSX Sierra setrlimit, tbb-needs, |  Actual Points:
  031-backport   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:31 Dbryrtfbcbhgf]:
 > Replying to [comment:30 teor]:
 > > Apparently some users encountered this issue after a 10.11.6 security
 update:
 > > https://tor.stackexchange.com/questions/16033/tor-unexpectedly-exited-
 this-might-be-due-to-a-bug-in-tor-itself-another-progr
 > >
 > > And raising file descriptors using sudo fixes it in some cases.
 > >
 > > So yes, I think we should presume that some configurations cause
 setrlimit to fail, and change tor to make setrlimit failures non-fatal.
 > > (I have multiple Tor Browser instances on admin and non-admin users,
 so it's not a simple permissions issue.)
 > This user noticed something that may be the cause of the bug.
 > https://trac.torproject.org/projects/tor/ticket/24764#comment:20
 > https://trac.torproject.org/projects/tor/ticket/24764#comment:21

 Calling launchctl to set the file limit per-user is the wrong way for
 JBridgeM to make this change. It should either:
 * create a separate user and set the limit on that user, or
 * set the limit on its own process, rather than all processes run by the
 user.

 But as far as Tor is concerned, this is something that will come up in
 some users' configurations, so we should make the setrlimit call non-
 fatal, and test using the same commands as:

 https://trac.torproject.org/projects/tor/ticket/24764#comment:21

 to make sure we have caught all the possible failure modes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  nickm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.7
 Severity:  Normal   | Resolution:
 Keywords:  OSX Sierra setrlimit, tbb-needs, |  Actual Points:
  031-backport   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:30 teor]:
 > Apparently some users encountered this issue after a 10.11.6 security
 update:
 > https://tor.stackexchange.com/questions/16033/tor-unexpectedly-exited-
 this-might-be-due-to-a-bug-in-tor-itself-another-progr
 >
 > And raising file descriptors using sudo fixes it in some cases.
 >
 > So yes, I think we should presume that some configurations cause
 setrlimit to fail, and change tor to make setrlimit failures non-fatal.
 > (I have multiple Tor Browser instances on admin and non-admin users, so
 it's not a simple permissions issue.)
 This user noticed something that may be the cause of the bug.
 https://trac.torproject.org/projects/tor/ticket/24764#comment:20
 https://trac.torproject.org/projects/tor/ticket/24764#comment:21

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

Re: [tor-bugs] #24764 [Core Tor/Tor]: OSX 10.13.2 (17C88) - Instant crash on startup

[Tor Bug Tracker & Wiki]

#24764: OSX 10.13.2 (17C88) - Instant crash on startup
--+-
 Reporter:  thomasd3  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.7-rc
 Severity:  Critical  | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:21 thomasd3]:
 > Looking at this, I found the something: I have a tool called jBridgeM
 (it's used to wrap x86 audio plugins in a x64 container) and can be found
 here: https://jstuff.wordpress.com/jbridgem/
 >
 > It is the one that installed the plist files with maxfiles / maxproc,
 not the OS update
 >
 > The content of the file is:
 >
 > [thomas:/Library/LaunchDaemons] $ cat limit.maxfiles.plist
 > 
 > http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
 > 
 > 
 > Label
 > limit.maxfiles
 > ProgramArguments
 > 
 > launchctl
 > limit
 > maxfiles
 > 8192
 > 9223372036854775807
 > 
 > RunAtLoad
 > 
 > ServiceIPC
 > 
 > CreatedByjBridgeM
 > 
 >  
 > 
 >
 >
 You can post this information on #21074 to see if it may be helpful to
 fixing the issue

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

Re: [tor-bugs] #24764 [Core Tor/Tor]: OSX 10.13.2 (17C88) - Instant crash on startup

[Tor Bug Tracker & Wiki]

#24764: OSX 10.13.2 (17C88) - Instant crash on startup
--+-
 Reporter:  thomasd3  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.7-rc
 Severity:  Critical  | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:20 thomasd3]:
 > Yes, that fixed the problem!
 >
 > btw, in the very last update of the OS, these appeared:
 >
 >  [loaded]limit.maxfiles.plist (Apple, Inc. - installed 2017-12-27)
 >  [loaded]limit.maxproc.plist (Apple, Inc. - installed 2017-12-27)
 >
 > I am not sure if this is related, but the problem appeared at about the
 same time.
 Torproject's developers should be able to fix this issue permanently, Keep
 up-to-date on their progress by subscribing to this ticket #21074

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

Re: [tor-bugs] #24778 [Core Tor/Tor]: Mark prop#283 as Accepted

[Tor Bug Tracker & Wiki]

#24778: Mark prop#283 as Accepted
+--
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop283, ipv6, regression, torspec  |  Actual Points:  0.1
Parent ID:  #20916  | Points:  0.1
 Reviewer:  |Sponsor:
|  SponsorV-can
+--
Changes (by teor):

 * status:  assigned => merge_ready


Comment:

 Please see my torspec branch ticket24778, which updates prop283's status,
 ticket, and implemented-in.

 My torspec is at https://github.com/teor2345/torspec.git

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

Re: [tor-bugs] #23898 [Core Tor/Tor]: tor-spec: move IPv6 addresses from microdescs to microdesc consensus

[Tor Bug Tracker & Wiki]

#23898: tor-spec: move IPv6 addresses from microdescs to microdesc consensus
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  proposal, ipv6, tor-spec, prop283,   |  implemented
  review-group-26|  Actual Points:  1.0
Parent ID:  #20916   | Points:  0.5
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * sponsor:   => SponsorV-can


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24778 [Core Tor/Tor]: Mark prop#283 as Accepted

[Tor Bug Tracker & Wiki]

#24778: Mark prop#283 as Accepted
--+
 Reporter:  teor  |  Owner:  teor
 Type:| Status:  assigned
  enhancement |
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core  |Version:
  Tor/Tor |
 Severity:  Normal|   Keywords:  prop283, ipv6, regression, torspec
Actual Points:  0.1   |  Parent ID:  #20916
   Points:  0.1   |   Reviewer:
  Sponsor:|
  SponsorV-can|
--+
 We have merged all the spec changes and half the code, so we've definitely
 accepted this 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] #20916 [Core Tor/Tor]: Proposal: Put Relay IPv6 Addresses in the microdesc consensus

[Tor Bug Tracker & Wiki]

#20916: Proposal: Put Relay IPv6 Addresses in the microdesc consensus
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop283, ipv6, regression  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorV-can
---+---
Changes (by teor):

 * keywords:  needs-proposal, ipv6, regression => prop283, ipv6, regression
 * type:  defect => task
 * sponsor:   => SponsorV-can


Comment:

 Once #23975 and #24573 close, we are done here.
 We can close this ticket after marking prop#283 as "Closed".
 (The spec changes have already been merged as part of #23898.)

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

Re: [tor-bugs] #24777 [Core Tor/Tor]: Make relays try IPv6 ORPorts for directory uploads and downloads

[Tor Bug Tracker & Wiki]

#24777: Make relays try IPv6 ORPorts for directory uploads and downloads
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay  |  Actual Points:
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * parent:  #17217 => #24403


Comment:

 Actually, hang on, we want relays to start doing this before clients start
 doing it, so we get cover traffic (and discover bugs).

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

Re: [tor-bugs] #24777 [Core Tor/Tor]: Make relays try IPv6 ORPorts for directory uploads and downloads

[Tor Bug Tracker & Wiki]

#24777: Make relays try IPv6 ORPorts for directory uploads and downloads
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay  |  Actual Points:
Parent ID:  #17217   | Points:  1
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * parent:  #24403 => #17217


Comment:

 Parent to client IPv6 ticket, not relay IPv6 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

[tor-bugs] #24777 [Core Tor/Tor]: Make relays try IPv6 ORPorts for directory uploads and downloads

[Tor Bug Tracker & Wiki]

#24777: Make relays try IPv6 ORPorts for directory uploads and downloads
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  ipv6, tor-relay
Actual Points:|  Parent ID:  #24403
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 Using IPv6 ORPorts will make relay behaviour consistent with future client
 behaviour.

 The only difference is that relays will also use IPv4 DirPorts, but
 clients will not.

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

Re: [tor-bugs] #22255 [Core Tor/Tor]: Frequent OOM kills of tor process

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor process
--+
 Reporter:  DeS   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 Also allow me to remind that memory is cheap.  Is better to set the queue
 max conservatively (or buy more memory) than to experience OOM crashes.

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

Re: [tor-bugs] #22255 [Core Tor/Tor]: Frequent OOM kills of tor process

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor process
--+
 Reporter:  DeS   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by starlight):

 * cc: starlight@… (added)


Comment:

 Replying to [comment:79 teor]:
 > I'd still like to see someone repeat this analysis with 0.3.2.8-rc, and
 post the results to #24737.
 > It's going to be hard for us to close that ticket without any idea of
 the effect of our changes.

 I'm not willing to run a newer version till one is declared LTS, but can
 say that even when my relay is not under attack memory consumption goes to
 1.5G with the 1G max queue setting.  Seems to me the 2x max queues memory
 consumption is a function of the overheads associated with tor daemon
 queues and related processing, including malloc slack space.

 Anyone running a busy relay on an older/slower system and with
 MaxMemInQueues=1024MB can check /proc//status to see how much memory
 is consumed.  Be sure DisableAllSwap=1 is set and the queue limit is not
 higher since the point is to observe actual memory consumed relative to a
 limit likely to be approached under normal operation.

 Another idea is to add an option to the daemon to cause queue memory
 preallocation.  This would be a nice hardening feature as it will reduce
 malloc() calls issued under stress, and of course would allow more
 accurate estimates of worst-case memory consumption.  If OOM strikes with
 preallocated queues that would indicate memory leakage.

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

Re: [tor-bugs] #24764 [Core Tor/Tor]: OSX 10.13.2 (17C88) - Instant crash on startup

[Tor Bug Tracker & Wiki]

#24764: OSX 10.13.2 (17C88) - Instant crash on startup
--+-
 Reporter:  thomasd3  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.7-rc
 Severity:  Critical  | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by thomasd3):

 Looking at this, I found the something: I have a tool called jBridgeM
 (it's used to wrap x86 audio plugins in a x64 container) and can be found
 here: https://jstuff.wordpress.com/jbridgem/

 It is the one that installed the plist files with maxfiles / maxproc, not
 the OS update

 The content of the file is:

 [thomas:/Library/LaunchDaemons] $ cat limit.maxfiles.plist
 
 http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
 
 
 Label
 limit.maxfiles
 ProgramArguments
 
 launchctl
 limit
 maxfiles
 8192
 9223372036854775807
 
 RunAtLoad
 
 ServiceIPC
 
 CreatedByjBridgeM
 
  
 

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

Re: [tor-bugs] #24764 [Core Tor/Tor]: OSX 10.13.2 (17C88) - Instant crash on startup

[Tor Bug Tracker & Wiki]

#24764: OSX 10.13.2 (17C88) - Instant crash on startup
--+-
 Reporter:  thomasd3  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.7-rc
 Severity:  Critical  | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by thomasd3):

 Yes, that fixed the problem!

 btw, in the very last update of the OS, these appeared:

  [loaded]limit.maxfiles.plist (Apple, Inc. - installed 2017-12-27)
  [loaded]limit.maxproc.plist (Apple, Inc. - installed 2017-12-27)

 I am not sure if this is related, but the problem appeared at about the
 same time.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_information => new


Comment:

 Apparently some users encountered this issue after a 10.11.6 security
 update:
 https://tor.stackexchange.com/questions/16033/tor-unexpectedly-exited-
 this-might-be-due-to-a-bug-in-tor-itself-another-progr

 And raising file descriptors using sudo fixes it in some cases.

 So yes, I think we should presume that some configurations cause setrlimit
 to fail, and change tor to make setrlimit failures non-fatal.
 (I have multiple Tor Browser instances on admin and non-admin users, so
 it's not a simple permissions 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] #22255 [Core Tor/Tor]: Frequent OOM kills of tor process

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor process
--+
 Reporter:  DeS   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:78 starlight]:
 > please allow me to jump in here with some advice:
 >
 > 0.3.2.8-rc fixed the problem for you most likely due to #24666, which
 dramatically reduces memory consumption w/r/t DESTROY cells
 >
 > however I see above an assumption that on a 4G machine
 MaxMemInQueues=1650MB is reasonable -- without a doubt this value is much
 too high
 >
 > empirical observation indicates the daemon consumes 2x MaxMemInQueues
 once the actual maximum has been obtained (most likely due to sniper
 attacks)

 I'd still like to see someone repeat this analysis with 0.3.2.8-rc, and
 post the results to #24737.
 It's going to be hard for us to close that ticket without any idea of the
 effect of our changes.

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

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

[Tor Bug Tracker & Wiki]

#21074: setrlimit fails OSX Sierra
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.7
 Severity:  Normal   | Resolution:
 Keywords:  OSX Sierra setrlimit, tbb-needs, |  Actual Points:
  031-backport   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by Dbryrtfbcbhgf):

 Duplicate #24764

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

Re: [tor-bugs] #24764 [Core Tor/Tor]: OSX 10.13.2 (17C88) - Instant crash on startup

[Tor Bug Tracker & Wiki]

#24764: OSX 10.13.2 (17C88) - Instant crash on startup
--+-
 Reporter:  thomasd3  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.7-rc
 Severity:  Critical  | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by Dbryrtfbcbhgf):

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


Comment:

 Duplicate of #21074

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

Re: [tor-bugs] #24764 [Core Tor/Tor]: OSX 10.13.2 (17C88) - Instant crash on startup

[Tor Bug Tracker & Wiki]

#24764: OSX 10.13.2 (17C88) - Instant crash on startup
--+---
 Reporter:  thomasd3  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.7-rc
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by Dbryrtfbcbhgf):

 * version:   => Tor: 0.3.2.7-rc


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

Re: [tor-bugs] #24764 [Core Tor/Tor]: OSX 10.13.2 (17C88) - Instant crash on startup

[Tor Bug Tracker & Wiki]

#24764: OSX 10.13.2 (17C88) - Instant crash on startup
--+---
 Reporter:  thomasd3  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by Dbryrtfbcbhgf):

 * component:  Applications/Tor Browser => 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] #24764 [Applications/Tor Browser]: OSX 10.13.2 (17C88) - Instant crash on startup

[Tor Bug Tracker & Wiki]

#24764: OSX 10.13.2 (17C88) - Instant crash on startup
--+---
 Reporter:  thomasd3  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:15 thomasd3]:
 > Firefox 57 worked properly for me. I got this laptop in August 2017, so
 I can't say for Firefox releases prior to that date.
 It looks like it is related to the errors below and not Firefox
 {{{[warn] Failed to parse/validate config: Problem with ConnLimit value.
 See logs for details.}}}
 {{{[warn] Couldn't set maximum number of file descriptors: Invalid
 argument}}}

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

Re: [tor-bugs] #22255 [Core Tor/Tor]: Frequent OOM kills of tor process

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor process
--+
 Reporter:  DeS   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 please allow me to jump in here with some advice:

 0.3.2.8-rc fixed the problem for you most likely due to #24666, which
 dramatically reduces memory consumption w/r/t DESTROY cells

 however I see above an assumption that on a 4G machine
 MaxMemInQueues=1650MB is reasonable -- without a doubt this value is much
 too high

 empirical observation indicates the daemon consumes 2x MaxMemInQueues once
 the actual maximum has been obtained (most likely due to sniper attacks)

 therefore to truly harden tor daemon against OOM kills on a 4G machine,
 one should set MaxMemInQueues=1024MB

 for further detail and additional tuning tips see #24737

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

Re: [tor-bugs] #22255 [Core Tor/Tor]: Frequent OOM kills of tor process

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor process
--+
 Reporter:  DeS   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Replying to [comment:74 cypherpunks]:
 > Hi,
 > could you upgrade to 0.3.2.8-rc to test if the latest fixes solve your
 problem?
 > thanks!
 done, runs stable for a couple days now. so the problem seems to be fixed.

 would it be helpful to do a version bisection to see where the bug was
 fixed? the root cause still seems to be unknown if i got this correctly.

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

Re: [tor-bugs] #24764 [Applications/Tor Browser]: OSX 10.13.2 (17C88) - Instant crash on startup

[Tor Bug Tracker & Wiki]

#24764: OSX 10.13.2 (17C88) - Instant crash on startup
--+---
 Reporter:  thomasd3  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by thomasd3):

 Firefox 57 worked properly for me. I got this laptop in August 2017, so I
 can't say for Firefox releases prior to that date.

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

Re: [tor-bugs] #24764 [Applications/Tor Browser]: OSX 10.13.2 (17C88) - Instant crash on startup

[Tor Bug Tracker & Wiki]

#24764: OSX 10.13.2 (17C88) - Instant crash on startup
--+---
 Reporter:  thomasd3  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by thomasd3):

 [thomas:~/Downloads/Tor] $ ./tor
 Jan 01 16:47:14.630 [notice] Tor 0.3.2.7-rc running on Darwin with
 Libevent 2.0.22-stable, OpenSSL 1.0.2n, Zlib 1.2.11, Liblzma N/A, and
 Libzstd N/A.
 Jan 01 16:47:14.631 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Jan 01 16:47:14.631 [notice] Configuration file
 "/var/tmp/dist/tor/etc/tor/torrc" not present, using reasonable defaults.
 Jan 01 16:47:14.634 [warn] Couldn't set maximum number of file
 descriptors: Invalid argument
 Jan 01 16:47:14.634 [warn] Failed to parse/validate config: Problem with
 ConnLimit value. See logs for details.
 Jan 01 16:47:14.634 [err] Reading config failed--see warnings above.


 It doesn't start, I get this error right away.

 I tried this too:

 [thomas:~/Downloads/Tor] $ mkdir /var/tmp/dist/tor/etc/tor
 [thomas:~/Downloads/Tor] $ cp /usr/local/etc/tor/torrc
 /var/tmp/dist/tor/etc/tor/
 [thomas:~/Downloads/Tor] $ ./tor
 Jan 01 17:45:14.797 [notice] Tor 0.3.2.7-rc running on Darwin with
 Libevent 2.0.22-stable, OpenSSL 1.0.2n, Zlib 1.2.11, Liblzma N/A, and
 Libzstd N/A.
 Jan 01 17:45:14.798 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Jan 01 17:45:14.798 [notice] Read configuration file
 "/var/tmp/dist/tor/etc/tor/torrc".
 Jan 01 17:45:14.801 [warn] ControlPort is open, but no authentication
 method has been configured.  This means that any program on your computer
 can reconfigure your Tor.  That's bad!  You should upgrade your Tor
 controller as soon as possible.
 Jan 01 17:45:14.801 [warn] Couldn't set maximum number of file
 descriptors: Invalid argument
 Jan 01 17:45:14.801 [warn] Failed to parse/validate config: Problem with
 ConnLimit value. See logs for details.
 Jan 01 17:45:14.801 [err] Reading config failed--see warnings above.

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

[tor-bugs] #24776 [- Select a component]: Tor won't start : "Could not connect to Tor control port"

[Tor Bug Tracker & Wiki]

#24776: Tor won't start : "Could not connect to Tor control port"
--+
 Reporter:  Arlock|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hello,

 I've been trying to use Tor, I installed the full package with firefox
 included, but every time I try to start it I get the same pop-up error
 message : "Could not connect to Tor control port"
 In the meantime I can use firefox with no Internet issues.

 Actually I re installed it, and after a reinstallation it works fine. The
 problem is that the next time I try to use Tor, I need to make another new
 installation...

 I tried to install it in several folders, desktop, non system partition...
 It's the same.

 Is there a way to fix that please?

 Thanks for your help!


 System : Windows 7 Starter SP1, 32 bits
 Tor version : up to date with firefox included

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

Re: [tor-bugs] #21952 [Webpages]: .Onion everywhere?: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: .Onion everywhere?: increasing the use of onion services through 
automatic
redirects and aliasing
--+--
 Reporter:  linda |  Owner:  linda
 Type:  project   | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:49 cypherpunks]:
 > https://addons.mozilla.org/en-US/firefox/addon/heal
 > thyonions/
 >
 > (found it here:
 https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor )


 v1.0.7.1718 added this experimental project.

 > (and please, feel free to read the code(unzip) if you're paranoid like
 me)

 {{{
 1. Configure your server to send "Onion-Location" header with appropriate
 value.
 e.g.
 add_header Onion-Location "http://grrmailb3fxpjbwm.onion;;

 a. You can write "Onion-Location" to "onION-LoCAtion". Case doesn't
 matter.
 b. The value must start with "http:" or "https:", and must ends with
 ".onion".

 2. Install the add-on and go to "Options" > "Advanced".

 3. Enable "#21952" and click Save.

 4. Open a new tab and try to open your clearnet website.

 5. Example result:

 if "website.owner.test"'s server sent
 "Onion-Location: http://xyz.x.onion; header

 https://website.owner.test/about.html
 --redir--> http://xyz.x.onion/about.html
 }}}

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