Re: [tor-bugs] #25512 [Core Tor/Tor]: Tor in-process restart fails to write auth cookie

[Tor Bug Tracker & Wiki]

#25512: Tor in-process restart fails to write auth cookie
-+-
 Reporter:  tla  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, auth cookie, restart,|  Actual Points:
  in-process, s8-api |
Parent ID:  #23684   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25612 [Core Tor/Tor]: Segfault when starting Tor Raspian Stretch Light 2018-03-13 Kernel 4.9

[Tor Bug Tracker & Wiki]

#25612: Segfault when starting Tor Raspian Stretch Light 2018-03-13 Kernel 4.9
-+-
 Reporter:  ConjugateThis|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.10
 Severity:  Normal   | Resolution:
 Keywords:  segmentation fault debian stretch|  Actual Points:
  raspian raspberry pi   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

 * severity:  Blocker => Normal


Comment:

 Did you build Tor yourself?

 Or did you use some package? If a package, are you super certain that you
 have a package that is designed for your system and architecture?

 Raspian is famous for not actually working with Debian debs, because of
 arch compatibility problems.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25612 [Core Tor/Tor]: Segfault when starting Tor Raspian Stretch Light 2018-03-13 Kernel 4.9

[Tor Bug Tracker & Wiki]

#25612: Segfault when starting Tor Raspian Stretch Light 2018-03-13 Kernel 4.9
-+-
 Reporter:   |  Owner:  (none)
  ConjugateThis  |
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Core |Version:  Tor: 0.3.2.10
  Tor/Tor|   Keywords:  segmentation fault debian stretch
 Severity:  Blocker  |  raspian raspberry pi
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 I just updated my raspberry pi to the latest Stretch Light, and tried
 installing and running Tor, and a segfault is generated. The app won't
 start in shell, or as a service.

 Tor Version  0.3.2.10-1~d90.stretch+1

 {{{
 GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git
 Copyright (C) 2016 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
 and "show warranty" for details.
 This GDB was configured as "arm-linux-gnueabihf".
 Type "show configuration" for configuration details.
 For bug reporting instructions, please see:
 .
 Find the GDB manual and other documentation resources online at:
 .
 For help, type "help".
 Type "apropos word" to search for commands related to "word"...
 Reading symbols from tor...(no debugging symbols found)...done.
 (gdb) run
 Starting program: /usr/sbin/tor
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library "/lib/arm-linux-
 gnueabihf/libthread_db.so.1".

 Program received signal SIGSEGV, Segmentation fault.
 0x004896be in ?? ()
 (gdb) bt
 #0  0x004896be in ?? ()
 #1  0xbefffeac in ?? ()
 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25611 [Core Tor/Stem]: Integ test for MAPADDRESS

[Tor Bug Tracker & Wiki]

#25611: Integ test for MAPADDRESS
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Stem had an integration test for tor's MAPADDRESS command...

 
https://gitweb.torproject.org/stem.git/tree/test/integ/control/controller.py#n1120

 However, it doesn't work...

 {{{
 ==
 FAIL: test_mapaddress
 --
 Traceback (most recent call last):
   File "/home/atagar/Desktop/stem/test/require.py", line 58, in wrapped
 return func(self, *args, **kwargs)
   File "/home/atagar/Desktop/stem/test/require.py", line 58, in wrapped
 return func(self, *args, **kwargs)
   File "/home/atagar/Desktop/stem/test/integ/control/controller.py", line
 1154, in test_mapaddress
 
self.assertTrue(stem.util.connection.is_valid_ipv4_address(stem.util.str_tools._to_unicode(ip_addr)),
 "'%s' isn't an address" % ip_addr)
 AssertionError: '
 
 403 Forbidden
 
 Forbidden
 You don't have permission to access /ip
 on this server.
 ' isn't an address
 }}}

 After several hours of fiddling with it I'm disabling the failing test for
 now. Things I checked were...

 * Tested with both the current stem codebase and last release tag (1.6.0)
 to rule out a recent regression in stem.

 * Tested with both the current tor git codebase and an older version
 (0.2.7.6) to rule out a regression in tor.

 * Through tor browser visited the site this test retrieves
 (http://ifconfig.me/ip) in case they're blocking tor. No dice.

 Open questions are 'why did this test start failing?' and get integ
 coverage for MAPADDRESS. Happy to outright replace this test with
 something else that exercises it.

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

Re: [tor-bugs] #21835 [Community/Tor Support]: Add information about hostingcompany that offers Tor Relays / Exit node hosting

[Tor Bug Tracker & Wiki]

#21835: Add information about hostingcompany that offers Tor Relays / Exit node
hosting
---+---
 Reporter:  sweg   |  Owner:  phoul
 Type:  enhancement| Status:  needs_information
 Priority:  Low|  Milestone:
Component:  Community/Tor Support  |Version:  Tor: unspecified
 Severity:  Trivial| Resolution:
 Keywords:  Hosting|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by ahf):

 We have https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs if
 that is what you are looking for?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20833 [Community/Tor Support]: Using a VPN with Tor

[Tor Bug Tracker & Wiki]

#20833: Using a VPN with Tor
---+--
 Reporter:  DepressedExplorer  |  Owner:  phoul
 Type:  project| Status:  closed
 Priority:  Low|  Milestone:
Component:  Community/Tor Support  |Version:  Tor: unspecified
 Severity:  Trivial| Resolution:  invalid
 Keywords:  vpn|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by Jaruga):

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


Comment:

 The Tor Project quite largely discourages using a VPN with Tor, this is
 something repeated time and time again. To ask any suggestions about the
 topic past that discouraging is sort of counterproductive.

 Closed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21835 [Community/Tor Support]: Add information about hostingcompany that offers Tor Relays / Exit node hosting

[Tor Bug Tracker & Wiki]

#21835: Add information about hostingcompany that offers Tor Relays / Exit node
hosting
---+---
 Reporter:  sweg   |  Owner:  phoul
 Type:  enhancement| Status:  needs_information
 Priority:  Low|  Milestone:
Component:  Community/Tor Support  |Version:  Tor: unspecified
 Severity:  Trivial| Resolution:
 Keywords:  Hosting|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by Jaruga):

 * status:  new => needs_information


Comment:

 I'm not really sure what exactly this ticket is for - are you suggesting
 that a wiki page be made outlining hosts that are exit friendly, or are
 you just here to make a plug for Cockbox?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25413 [Community/Tor Support]: Concept: Secure Mail Server / Mail Network

[Tor Bug Tracker & Wiki]

#25413: Concept: Secure Mail Server / Mail Network
---+-
 Reporter:  bkapur |  Owner:  phoul
 Type:  project| Status:  closed
 Priority:  Low|  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  invalid
 Keywords:  email, secure mail system  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by Jaruga):

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


Comment:

 See https://trac.torproject.org/projects/tor/wiki/torbirdy

 Closed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24872 [Community/Tor Support]: remove outdated tor relay security recommendations and update these wiki pages

[Tor Bug Tracker & Wiki]

#24872: remove outdated tor relay security recommendations and update these wiki
pages
---+--
 Reporter:  cypherpunks|  Owner:  Jaruga
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by Jaruga):

 * status:  assigned => accepted


Comment:

 Accepting.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24872 [Community/Tor Support]: remove outdated tor relay security recommendations and update these wiki pages

[Tor Bug Tracker & Wiki]

#24872: remove outdated tor relay security recommendations and update these wiki
pages
---+--
 Reporter:  cypherpunks|  Owner:  Jaruga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by Jaruga):

 * owner:  phoul => Jaruga
 * status:  new => assigned


Comment:

 I'll get to this on the weekend.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23964 [Community/Outreach]: Rebecca have learning.

[Tor Bug Tracker & Wiki]

#23964: Rebecca have learning.
+-
 Reporter:  Rebecca |  Owner:  mrphs, alison
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Vidalia: 0.3.x
Component:  Community/Outreach  |Version:  Tor: 0.3.0.4-rc
 Severity:  Normal  | Resolution:  invalid
 Keywords:  Rebecca_need_help   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  SponsorU-can
+-
Changes (by Jaruga):

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


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

Re: [tor-bugs] #25483 [Obfuscation/Snowflake]: Windows reproducible build of snowflake

[Tor Bug Tracker & Wiki]

#25483: Windows reproducible build of snowflake
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #19001 | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 Firefox parent bug for issues with building under MinGW

 [https://bugzilla.mozilla.org/show_bug.cgi?id=1393901 #139301 --enable-
 webrtc does not build under MinGW]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23344 [Applications/Tor Browser]: Show country of temporary bridge used in snowflake just like with the obfs4 PT in the Torbutton

[Tor Bug Tracker & Wiki]

#23344: Show country of temporary bridge used in snowflake just like with the 
obfs4
PT in the Torbutton
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 If it worked, it wouldn't really look like this:
  * Bridge: snowflake (Italy)
  * Russia (xx.xx.xx.xx)
  * Panama (xx.xx.xx.xx)
  * Internet
 The snowflake proxy is an extra hop before the bridge. The bridge itself
 doesn't move (that's why it can have a static fingerprint). So let's say
 the bridge is in Mexico, then it would look like this:
  * Pre-bridge proxy: snowflake (Italy)
  * Bridge: snowflake (Mexico)
  * Russia (xx.xx.xx.xx)
  * Panama (xx.xx.xx.xx)
  * Internet
 It would be an interesting thing to visualize. Though like yawning said,
 the PT architecture doesn't support anything like this. tor treats the
 transport plugin as an opaque pipe, and the transport plugin doesn't even
 have a way to report ancillary information like this.

 Going further, the question of "what snowflake proxy am I using?" isn't
 well defined. For example, the transport plugin could be using two
 snowflake proxies simultaneously, and multiplexing traffic for the same
 circuit across both of them. (We don't support that now, but nothing
 precludes it.)

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

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

[Tor Bug Tracker & Wiki]

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

 * priority:  Medium => High


Comment:

 This ticket is the root of a tree of dependencies for other tickets.

 A stable proxy URL means that we can start asking people to put a proxy
 badge on their pages (#20813).

 Hosting that we can actually write to will allow us to point the proxy to
 the standalone broker (#22874) instead of the App Engine one. A standalone
 broker that's independent of App Engine means we can use alternate domain
 fronts (#22782).

 A stable proxy URL means that a browser extension (#23888) will be able to
 reference code that is being maintained.

 [[Image(snowflake-deps.20180323.png)]]

 That doesn't mean we can't make progress on the other tickets. #22874 is
 99% done, and you can write most of #23888 and plug in a proxy URL at the
 end. We could switch clients to the standalone broker immediately. It's
 just that none of these changes will have an effect, because the in-the-
 wild proxies (not that there are many of them) are still using the
 keroserene.net proxy, which isn't being updated and still points to the
 App Engine broker.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23947#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

 * Attachment "snowflake-deps.20180323.png" added.


--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23947>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
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] #25610 [Core Tor/Tor]: module: Modularized directory authority subsystem

[Tor Bug Tracker & Wiki]

#25610: module: Modularized directory authority subsystem
-+-
 Reporter:  dgoulet  |  Owner:  ahf
 Type:   | Status:  assigned
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  modularization, 034-roadmap-
 Severity:  Normal   |  subtask, tor-dirauth
Actual Points:   |  Parent ID:  #25494
   Points:   |   Reviewer:
  Sponsor:   |
  Sponsor8   |
-+-
 Make the directory subsystem a module that is enabled at configure time.

 This is part of our initial modularization effort.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25495 [Core Tor/Tor]: module: Identify a list of tor module

[Tor Bug Tracker & Wiki]

#25495: module: Identify a list of tor module
+
 Reporter:  dgoulet |  Owner:  (none)
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  modularization  |  Actual Points:
Parent ID:  #25494  | Points:
 Reviewer:  |Sponsor:  Sponsor8
+
Changes (by dgoulet):

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


Comment:

 I've created this document https://pad.riseup.net/p/tor_modularization

 The idea of the document is to have "Roles" which are high level entities.
 We list what is *only* used by them. The "Common" section contains what is
 shared between 2 or more Roles.

 It makes it easier to isolate modules just by looking at the Roles. We
 could then maybe go towards a model where we have libraries from the
 "Common" section for which we can then link those only for specific roles.

 (Be advised, at this time, it exists and will be improved but it will go
 away at some point. We'll most likely replace it with a Wiki page to be
 more permanent).

 Closing this as it was a sub-tasks. The document will still evolve over
 time. I'll update the ticket once we have a Wiki page or something more
 permanent.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21315 [Obfuscation/Snowflake]: publish some realtime stats from the broker?

[Tor Bug Tracker & Wiki]

#21315: publish some realtime stats from the broker?
---+
 Reporter:  arma   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 There's an undocumented /debug URL path that shows the currently connected
 snowflakes.
   https://snowflake-reg.appspot.com/debug (App Engine broker that we plan
 to move away from)
   https://snowflake-broker.bamsoftware.com/debug (standalone broker from
 #22874)
 I'm not sure it's a good idea to publish this information in this form,
 but for what it's worth, that's how it works now.

 There should be at least 3 snowflakes on each broker at all times, because
 we're specifically running some fallback proxy-go instances. Obviously
 these are no good from a circumvention point of view, because they're on a
 static IP address--they're mainly there so that curious people who try the
 snowflake option in the alpha browser aren't immediately discouraged.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25590 [Internal Services/Tor Sysadmin Team]: Add a configuration line to the consensus-health Apache config

[Tor Bug Tracker & Wiki]

#25590: Add a configuration line to the consensus-health Apache config
-+-
 Reporter:  tom  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25588   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 Replying to [comment:1 weasel]:
 > Should the applications that make these requests say they don't want
 compression if they really don't want compression?
 >
 > Hmm.

 No, unfortunately you can't specify in an AJAX request from the browser
 whether or not you want compression enabled.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25590 [Internal Services/Tor Sysadmin Team]: Add a configuration line to the consensus-health Apache config

[Tor Bug Tracker & Wiki]

#25590: Add a configuration line to the consensus-health Apache config
-+-
 Reporter:  tom  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25588   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 I'm not (yet) convinced this is sane.

 Having this application specific case handling in the apache config seems
 unsmart and certainly like it can't possibly scale.

 Should the applications that make these requests say they don't want
 compression if they really don't want compression?

 Hmm.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20212 [Core Tor/Tor]: Tor can be forced to open too many circuits by embedding .onion resources

[Tor Bug Tracker & Wiki]

#20212: Tor can be forced to open too many circuits by embedding .onion 
resources
-+-
 Reporter:  gacar|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery, |  Actual Points:
  TorBrowserTeam201803   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * 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] #25609 [Core Tor/Tor]: Investigate Tor client retry behavior on failing onions

[Tor Bug Tracker & Wiki]

#25609: Investigate Tor client retry behavior on failing onions
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery  |  Actual Points:
Parent ID:  #20212   | Points:  2
 Reviewer:   |Sponsor:
-+
Changes (by asn):

 * keywords:  guard-discovery, TorBrowserTeam201803 => guard-discovery


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20212 [Applications/Tor Browser]: Tor can be forced to open too many circuits by embedding .onion resources

[Tor Bug Tracker & Wiki]

#20212: Tor can be forced to open too many circuits by embedding .onion 
resources
-+-
 Reporter:  gacar|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery, |  Actual Points:
  TorBrowserTeam201803   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:10 cypherpunks]:
 > Replying to [comment:9 cypherpunks]:
 > > Why limit the number of onion addresses that can be embedded instead
 of limiting the number of circuits that can be created for onions in a
 single origin?
 >
 > The former should be relatively easy to implement in Tor Browser, while
 the latter would presumably be much more difficult and error prone (if
 implemented by monitoring circuit events on the control port). The simple
 approach of limiting the number of onions seems like it would indirectly
 limit the number of circuits, but reading the above question I'm suddenly
 having doubts. (How quickly can Tor Browser cause more circuits to be made
 by continually retrying just one onion that is failing to rendezvous?)

 I opened #25609 to investigate the issue presented in the last parenthesis
 of this post. It's important because if an attacker can cause Tor to make
 many circuits by continuously retrying a broken onion, this can bypass any
 sort of origin rate-limiting defense.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25609 [Core Tor/Tor]: Investigate Tor client retry behavior on failing onions

[Tor Bug Tracker & Wiki]

#25609: Investigate Tor client retry behavior on failing onions
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery, |  Actual Points:
  TorBrowserTeam201803   |
Parent ID:  #20212   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Some furhter input from arma:
 {{{
 18:25 <@armadev> i mean, the old behavior was:
 18:26 <@armadev> fetch the onion descriptor, try each of the intro points,
 if they're all down, fetch a new version of the descriptor in case it
 changed, if it didn't
  change, fail.
 18:26 <@armadev> and i guess on further attempts, either "keep failing"
 for a while, or "fetch a new descriptor, oh it's the same as the one we
 already have that
  failed, ok fail"
 18:26 <@armadev> is the new behavior different?
 }}}
 {{{
 18:52 <@armadev> i guess it's also related to the weird behavior where if
 you have five socks streams for the onion, you'll have five descriptor
 fetches or something
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25609 [Core Tor/Tor]: Investigate Tor client retry behavior on failing onions

[Tor Bug Tracker & Wiki]

#25609: Investigate Tor client retry behavior on failing onions
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  guard-discovery,
 Severity:  Normal   |  TorBrowserTeam201803
Actual Points:   |  Parent ID:  #20212
   Points:  2|   Reviewer:
  Sponsor:   |
-+-
 An attacker can cause a Tor client to create many circuits by continuously
 serving a broken/failing onion over and over again.

 We should investigate how many circuits a Tor client is willing to setup
 for an onion with a non-existent descriptor, or an onion that is unwilling
 to rendezvous, and see if this is a security 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] #20212 [Applications/Tor Browser]: Tor can be forced to open too many circuits by embedding .onion resources

[Tor Bug Tracker & Wiki]

#20212: Tor can be forced to open too many circuits by embedding .onion 
resources
-+-
 Reporter:  gacar|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery, |  Actual Points:
  TorBrowserTeam201803   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Here is another attack from IRC arma: An attacker could also setup an
 onion address that redirects you to another onion address which redirects
 you to another onion address ad infinitum. This allows the attacker to
 cause `n` onion loads in series, and if each page has `k` onions, this
 allows attacker to cause `n*k` onion loads. That's both an optimization
 but is also meant to work around any defences that try to restrict onion
 address loads per origin.

 Furthermore, depending on how stream isolation works, the above attack
 could also work with IPs/domain addresses and not just onions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #16849 [Core Tor/Tor]: clear_status_flags_on_sybil might want to clear more flags

[Tor Bug Tracker & Wiki]

#16849: clear_status_flags_on_sybil might want to clear more flags
-+-
 Reporter:  teor |  Owner:
 |  ffmancera
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, SponsorS-deferred, technical-  |  Actual Points:
  debt, tor-dirauth, pending-disaster, review-   |
  group-32, review-group-34  |
Parent ID:   | Points:  small
 Reviewer:  nickm|Sponsor:
-+-

Comment (by ffmancera):

 Okay, let me fix these bugs and thanks for this review :-)

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

Re: [tor-bugs] #25520 [Metrics/Statistics]: Adapt webstats to read CollecTor provided logs

[Tor Bug Tracker & Wiki]

#25520: Adapt webstats to read CollecTor provided logs
+-
 Reporter:  iwakeh  |  Owner:  karsten
 Type:  enhancement | Status:  merge_ready
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+-
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Looks fine and can be just one commit.

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

Re: [tor-bugs] #13703 [Community]: Adding doc/HARDENING

[Tor Bug Tracker & Wiki]

#13703: Adding doc/HARDENING
-+-
 Reporter:  mmcc |  Owner:  Jaruga
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Community|Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  hardening, security, opsec, docs,|  Actual Points:
  lorax, tor-relay, tor-doc  |
Parent ID:   | Points:
 Reviewer:  isis |Sponsor:
-+-
Changes (by Jaruga):

 * owner:  (none) => Jaruga
 * status:  new => accepted
 * component:  Core Tor/Tor => Community


Comment:

 This is long overdue but seems like a good idea - I can create a hardening
 doc for the wiki and forward it on for possible inclusion elsewhere.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25608 [Webpages/Blog]: create blog username for kushal

[Tor Bug Tracker & Wiki]

#25608: create blog username for kushal
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 username: kushal
 email: mail AT kushaldas.in

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

Re: [tor-bugs] #25512 [Core Tor/Tor]: Tor in-process restart fails to write auth cookie

[Tor Bug Tracker & Wiki]

#25512: Tor in-process restart fails to write auth cookie
-+-
 Reporter:  tla  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, auth cookie, restart,|  Actual Points:
  in-process, s8-api |
Parent ID:  #23684   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-
Changes (by asn):

 * reviewer:   => ahf


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

Re: [tor-bugs] #23846 [Core Tor/Tor]: Use libtool for building shared library

[Tor Bug Tracker & Wiki]

#23846: Use libtool for building shared library
+
 Reporter:  hellais |  Owner:  sbs
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-mobile, s8-api  |  Actual Points:
Parent ID:  #23684  | Points:
 Reviewer:  ahf |Sponsor:  Sponsor8
+
Changes (by asn):

 * reviewer:   => ahf


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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #24904, #24031, #21394

[Tor Bug Tracker & Wiki]

Batch modification to #24904, #24031, #21394 by dgoulet:
reviewer to nickm

Comment:
Assign Reviewer to nickm for the 26/03/18 week.

--
Tickets URL: 

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

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

[Tor Bug Tracker & Wiki]

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

 * keywords:  surveillance, cloudflare, captcha, censorship, mitm =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25559 [Applications/Tor Browser]: Miscellaneous security- and privacy-related prefs for Tor Browser

[Tor Bug Tracker & Wiki]

#25559: Miscellaneous security- and privacy-related prefs for Tor Browser
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security, ff60-esr|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by fmarier):

 * cc: francois@… (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] #25580 [Applications/Tor Browser]: Torbutton should trigger Tor Browser auto update when it starts and it knows it's out of date (was: Should Tor Browser auto update for me when it star

[Tor Bug Tracker & Wiki]

#25580: Torbutton should trigger Tor Browser auto update when it starts and it
knows it's out of date
--+--
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Indeed, the schedule of automatic checks for updates doesn't guarantee
 that Tor Browser starts to check for updates immediately at startup. But
 Torbutton can "force" it to do so when it's clear that Tor Browser is out
 of 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] #12377 [Core Tor/Tor]: get_interface_address6() behaviour iff all interface addresses are internal

[Tor Bug Tracker & Wiki]

#12377: get_interface_address6() behaviour iff all interface addresses are 
internal
-+-
 Reporter:  rl1987   |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, address-detection,|  Actual Points:
  review-group-34|
Parent ID:   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 I got this branch to merge in latest master. I modified several things to
 make it merge and also to our coding standards. Make check is happy now.

 I'm happy with this branch. Linux only and I'm also curious to see it pass
 on Jenkins with BSD/OS X/Windows of this world.

 @nickm, I think it would be nice if you go over it at least in terms of
 code structure/compat layer, if it is satisfying to you.

 Branch: `ticket12377_034_01`
 PR: https://github.com/torproject/tor/pull/28

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25607 [Core Tor/Tor]: On restart-in-process, do the right thing with thread-local storage

[Tor Bug Tracker & Wiki]

#25607: On restart-in-process, do the right thing with thread-local storage
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  s8-api
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 We use thread-local storage in one or two places; we should make sure that
 when tor shuts down, it's dropped, and when tor starts up again in the
 same process, it's created as an independent key.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25512 [Core Tor/Tor]: Tor in-process restart fails to write auth cookie

[Tor Bug Tracker & Wiki]

#25512: Tor in-process restart fails to write auth cookie
-+-
 Reporter:  tla  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, auth cookie, restart,|  Actual Points:
  in-process, s8-api |
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 Possible fix in branch `bug25512`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25512 [Core Tor/Tor]: Tor in-process restart fails to write auth cookie

[Tor Bug Tracker & Wiki]

#25512: Tor in-process restart fails to write auth cookie
-+-
 Reporter:  tla  |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, auth cookie, restart,|  Actual Points:
  in-process, s8-api |
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * owner:  ahf => nickm
 * status:  assigned => accepted


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

Re: [tor-bugs] #25512 [Core Tor/Tor]: Tor in-process restart fails to write auth cookie

[Tor Bug Tracker & Wiki]

#25512: Tor in-process restart fails to write auth cookie
-+-
 Reporter:  tla  |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, auth cookie, restart,|  Actual Points:
  in-process, s8-api |
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by nickm):

 ahf: this fix is probably as simple as making sure we clear
 authentication_cookie_is_set and authentication_cookie on
 control_free_all()

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24740 [Core Tor/Tor]: Tor launches two requests for authority certificates on first bootstrap

[Tor Bug Tracker & Wiki]

#24740: Tor launches two requests for authority certificates on first bootstrap
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-bootstrap, tor-bandwidth, easy,  |  Actual Points:
  intro, review-group-34 |
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

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


Comment:

 okay; let's give it a try!  Merging to master

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

Re: [tor-bugs] #25560 [Core Tor/Tor]: test all rust crates for realsies

[Tor Bug Tracker & Wiki]

#25560: test all rust crates for realsies
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-testing, rust, 033-must  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:  nickm|Sponsor:  SponsorM-can
-+-
Changes (by nickm):

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


Comment:

 rebased and squashed on 0.3.3, merged forward!

 Please let me know if I messed anything up

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

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

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
-+-
 Reporter:  ioerror  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  surveillance, cloudflare, captcha,   |  Actual Points:
  censorship, mitm   |
Parent ID:   | Points:  1000
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * keywords:   => surveillance, cloudflare, captcha, censorship, mitm


Comment:

 @jgrahamc: Are you here? The rate of denial of Tor users by CF's captcha
 provider has (by my observations) risen way above 90%. In fact even
 websites having nothig to vandalize, like flightradar24, are practically
 unreachable. It is obvious that the "code evolution" only cuts the slice
 of accepted Tor users smaller and smaller.

 Two years ago you wrote
 https://trac.torproject.org/projects/tor/ticket/18361#comment:230:
 >We're actively looking into two things: fewer CAPTCHAs and a better
 CAPTCHA solution. The latter is >pretty hard because we need something
 that scales to our size, works internationally, actually does >what it
 says on the tin. We have made changes (with the help on Google) to reduce
 the complexity of >CAPTCHAs being seen by Tor users and continue to work
 on this."

 Today, we don't get any CAPTCHAs AT ALL. How is that any better? (for Tor
 users ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25602 [Core Tor/Tor]: Fix two comment typos in hs_cell.c

[Tor Bug Tracker & Wiki]

#25602: Fix two comment typos in hs_cell.c
--+
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Very Low  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Trivial   | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged!

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

Re: [tor-bugs] #25288 [Metrics/Consensus Health]: Atlas is now called Relay Search and it has a new URL

[Tor Bug Tracker & Wiki]

#25288: Atlas is now called Relay Search and it has a new URL
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25283| Points:
 Reviewer:  tom   |Sponsor:
--+--
Changes (by irl):

 * cc: tom (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] #24904 [Core Tor/Tor]: Make geoip use channel_is_client so it ignores flapping relays

[Tor Bug Tracker & Wiki]

#24904: Make geoip use channel_is_client so it ignores flapping relays
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, refactor, technical-|  Actual Points:
  debt, tor-stats, 033-must, |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #23423   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 Taken from part of arma's commit `f5ff9f23`

 See branch: `bug24904_033_01`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25520 [Metrics/Statistics]: Adapt webstats to read CollecTor provided logs

[Tor Bug Tracker & Wiki]

#25520: Adapt webstats to read CollecTor provided logs
+--
 Reporter:  iwakeh  |  Owner:  karsten
 Type:  enhancement | Status:  needs_review
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--
Changes (by karsten):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:6 iwakeh]:
 > The webstats/MainTest fails.  Maybe, remove or replace by other tests
 (it seems to test log line parsing, which is done in metrics-lib now).

 Hmm, you're right. Everything's tested in metrics-lib, so we can just
 remove this test.

 > Please take a look at [https://gitweb.torproject.org/user/iwakeh
 /metrics-web.git/commit/?h=task-25520 this patch].
 > I tweaked the use of streams a little.  Log line counts could be bigger
 than integer: use long in java and bigint in sql.  If you think that it
 suffices to use int (and don't want to alter the db table) please
 introduce a cast to int at before writing to the db.

 Looks good. I'll alter the database table as part of deployment.

 Please find my updated branch with your commit and with the removed test
 class. I think I'd like to squash all three commits into one, unless you
 think that's a bad 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] #24904 [Core Tor/Tor]: Make geoip use channel_is_client so it ignores flapping relays

[Tor Bug Tracker & Wiki]

#24904: Make geoip use channel_is_client so it ignores flapping relays
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, refactor, technical-|  Actual Points:
  debt, tor-stats, 033-must, |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #23423   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * owner:  (none) => dgoulet
 * status:  needs_revision => accepted


Comment:

 Taking over this one so we can get it in 033 asap.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25577 [Core Tor/Tor]: cmux: CircuitPriorityHalflife value is never taken from the consensus

[Tor Bug Tracker & Wiki]

#25577: cmux: CircuitPriorityHalflife value is never taken from the consensus
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 Woa, this is only in 034, my mistake.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over

[Tor Bug Tracker & Wiki]

#24767: All relays are constantly connecting to down relays and failing over and
over
-+-
 Reporter:  arma |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, performance, |  Actual Points:
  review-group-32, 033-must, review-group-34,|
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by dgoulet):

 >  Is it okay with you if I change the name anyway? The problem is that
 the "since" implies a continuous condition. If I say "I have been unable
 to eat broccoli since 1982", it does not mean only that in 1982 I failed
 to eat broccoli: it also means that at every time since 1982, I have also
 been unable to eat broccoli.

 Renamed `unable_connect_since_ts` in commit `0410a5e49c`.

 >  But the preferred address can change while Tor is running, I think,
 based on configuration options. That would make the value cached in the
 node become incorrect, and that's why I think we should maybe just not
 have this in the node_t at all.

 If a `node_t` preferred address changes, indeed we won't match the
 connection to a `node_t` anymore and thus we will fallback to using the
 cache for unknown nodes. And that object in the cache will be used until
 the `node_t` gets modified by I guess the new descriptor at some point. So
 all in all, we'll still be tracking connection failure correctly.

 The only reason why I'm still a bit hesitating on using the "unknown
 cache" for everything is maybe because of performance. If we would use
 that, at *every* connection, we would need to do a lookup where the hash
 function is a bit heavier with this addr + port + digest triplet than
 simply looking up the node list. Furthermore, every 60 seconds
 (`OR_CONNECT_FAILURE_CLEANUP_INTERVAL`), we cleanup that cache meaning we
 can iterate over thousands of objects in there (potentially more than the
 number of relays). I don't think it would be a significant cost but still
 important to keep in mind. Keeping it tiny can worth it.

 However, just using the cache (and not the node_t), would make things a
 bit more simpler in the code, we would just need to accept the additional
 memory and lookup/iteration price.

 My testing on a real relays shows that the majority of the times, we'll
 get our information out of the `node_t`.

 At this point, I can lean towards both sides, I might just need a second
 opinion?

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

[tor-bugs] #25606 [- Select a component]: Unable to change master password

[Tor Bug Tracker & Wiki]

#25606: Unable to change master password
--+-
 Reporter:  etienne   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  master password
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 My issue is the same as ticket
 [https://trac.torproject.org/projects/tor/ticket/13510 #13510]

 except I'm using Tor Browser last available version 7.5.2

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

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

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-test, 033-backport,|  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-
Changes (by Hello71):

 * status:  merge_ready => needs_review


Comment:

 squashed and rebased on master (addition of `--all-features` flag). I only
 applied it in `test_rust.sh`; do you think it should be applied in
 `cargo_test` script instead? I think probably not, since I was trying to
 make `cargo_test` do basically the same thing as `cargo test`.

 setting needs_review for that and a quick sanity check that I didn't break
 anything while squashing. no major changes in the overall diff though.

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

Re: [tor-bugs] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by antonela):

 * cc: antonela (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] #25577 [Core Tor/Tor]: cmux: CircuitPriorityHalflife value is never taken from the consensus

[Tor Bug Tracker & Wiki]

#25577: cmux: CircuitPriorityHalflife value is never taken from the consensus
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by sysrqb):

 Replying to [ticket:25577 dgoulet]:
 >  resulting in a warning at bootup

 This warning occurs after we download a new consensus, too.

 {{{
 Mar 23 07:26:20.000 [warn] CircuitPriorityHalflife is too small
 (-1.00). Adjusting to the smallest value allowed: 30.00.
 Mar 23 08:16:20.000 [warn] CircuitPriorityHalflife is too small
 (-1.00). Adjusting to the smallest value allowed: 30.00.
 Mar 23 09:01:20.000 [warn] CircuitPriorityHalflife is too small
 (-1.00). Adjusting to the smallest value allowed: 30.00.
 Mar 23 10:05:20.000 [warn] CircuitPriorityHalflife is too small
 (-1.00). Adjusting to the smallest value allowed: 30.00.
 Mar 23 11:08:20.000 [warn] CircuitPriorityHalflife is too small
 (-1.00). Adjusting to the smallest value allowed: 30.00.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25512 [Core Tor/Tor]: Tor in-process restart fails to write auth cookie

[Tor Bug Tracker & Wiki]

#25512: Tor in-process restart fails to write auth cookie
-+-
 Reporter:  tla  |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, auth cookie, restart,|  Actual Points:
  in-process, s8-api |
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by tla):

 Just checked usage with HashedControlPassword instead of cookie file:
 *that* works! So, great! We can work around this issue for now.
 Nevertheless - this should be fixed!

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

Re: [tor-bugs] #25520 [Metrics/Statistics]: Adapt webstats to read CollecTor provided logs

[Tor Bug Tracker & Wiki]

#25520: Adapt webstats to read CollecTor provided logs
+
 Reporter:  iwakeh  |  Owner:  karsten
 Type:  enhancement | Status:  needs_revision
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+
Changes (by iwakeh):

 * status:  needs_review => needs_revision


Comment:

 The webstats/MainTest fails.  Maybe, remove or replace by other tests (it
 seems to test log line parsing, which is done in metrics-lib now).

 Please take a look at [https://gitweb.torproject.org/user/iwakeh/metrics-
 web.git/commit/?h=task-25520 this patch].
 I tweaked the use of streams a little.  Log line counts could be bigger
 than integer: use long in java and bigint in sql.  If you think that it
 suffices to use int (and don't want to alter the db table) please
 introduce a cast to int at before writing to the db.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25566 [Applications/Tor Browser]: Include or add an option to close connection to Cloudflare.

[Tor Bug Tracker & Wiki]

#25566: Include or add an option to close connection to Cloudflare.
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  duplicate
  cloudflare,mozilla |  Actual Points:
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 Please don't create duplicates of ticket #24351

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25585 [Applications/Tor Browser]: Use https instead of http to fetch dependencies when possible

[Tor Bug Tracker & Wiki]

#25585: Use https instead of http to fetch dependencies when possible
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, boklm201803,|  Actual Points:
  TorBrowserTeam201803R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good and merged to `master` (commit
 cd059a825f61d6ae514cfe823b3075819485f704).

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