Re: [tor-bugs] #19992 [Applications/Tor Browser]: System details leakable via navigator.oscpu

[Tor Bug Tracker & Wiki]

#19992: System details leakable via navigator.oscpu
--+
 Reporter:  be11f157cd19c4a2ba1e9c70a38b1a74  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  worksforme
 Keywords:  tbb-fingerprinting|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * status:  new => closed
 * keywords:  oscpu leakage => tbb-fingerprinting
 * version:  Tor: unspecified =>
 * resolution:   => worksforme


Comment:

 That's not happening for me with a default 6.0.4 on a Linux system. I get
 back `OS CPU  Windows NT 6.1` when testing on browserleaks.com.

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

Re: [tor-bugs] #19992 [Applications/Tor Browser]: System details leakable via navigator.oscpu

[Tor Bug Tracker & Wiki]

#19992: System details leakable via navigator.oscpu
--+
 Reporter:  be11f157cd19c4a2ba1e9c70a38b1a74  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor:
  |  unspecified
 Severity:  Major | Resolution:
 Keywords:  oscpu leakage |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by be11f157cd19c4a2ba1e9c70a38b1a74):

 You may want to consider remove navigator.oscpu entirely to prevent the
 browser from being identified as Firefox.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19992 [Applications/Tor Browser]: System details leakable via navigator.oscpu

[Tor Bug Tracker & Wiki]

#19992: System details leakable via navigator.oscpu
-+-
 Reporter:   |  Owner:  tbb-team
  be11f157cd19c4a2ba1e9c70a38b1a74   |
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:  Tor:
 |  unspecified
 Severity:  Major|   Keywords:  oscpu
 |  leakage
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 navigator.oscpu returns the correct operating system. While this may not
 be a problem on windows, on my Linux machine it returns "Linux x86_64"

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

Re: [tor-bugs] #19989 [Core Tor/Tor]: Tor fails to bootstrap with an Exit as EntryNode

[Tor Bug Tracker & Wiki]

#19989: Tor fails to bootstrap with an Exit as EntryNode
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fallback  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 How strange!

 I wonder if this is an accidental side effect from our weighting
 algorithms, where we avoid using exits as directory mirrors when the ratio
 of bandwidth is a certain way in the network.

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

Re: [tor-bugs] #19989 [Core Tor/Tor]: Tor fails to bootstrap with an Exit as EntryNode

[Tor Bug Tracker & Wiki]

#19989: Tor fails to bootstrap with an Exit as EntryNode
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fallback  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Interestingly, it works if you supply two Exits for the EntryNodes, so
 that's strange behaviour.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19991 [Core Tor/Tor]: Tor client slow to bootstrap using ClientUseIPv6 0

[Tor Bug Tracker & Wiki]

#19991: Tor client slow to bootstrap using ClientUseIPv6 0
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal|   Keywords:  ipv6
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 When I run an IPv6-only Tor client using:
 {{{
 tor DataDirectory /tmp/tor.$$ SOCKSPort 0 ClientUseIPv4 0
 UseMicrodescriptors 0
 }}}
 It is sometimes very slow to bootstrap.

 I wonder if it's a poor quality IPv6 connection, and perhaps an
 interaction with the directory re-use feature?

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

Re: [tor-bugs] #19608 [Core Tor/Tor]: IPv6-only clients can't fetch microdescriptors on 0.2.8.5-rc

[Tor Bug Tracker & Wiki]

#19608: IPv6-only clients can't fetch microdescriptors on 0.2.8.5-rc
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.2-alpha
 Severity:  Major| Resolution:
 Keywords:  ipv6, microdesc, fallbacks,  |  Actual Points:  0.5
  regression |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  ipv6, microdesc, fallbacks => ipv6, microdesc, fallbacks,
 regression
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 I just tested 0.2.8.7 and master, and `ClientUseIPv4 0` only bootstraps
 with `UseMicrodescriptors 0`.

 I wonder what went wrong?

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

Re: [tor-bugs] #19610 [Core Tor/Tor]: IPv6-only clients fetch microdescriptors from 15/25 IPv6 fallbacks

[Tor Bug Tracker & Wiki]

#19610: IPv6-only clients fetch microdescriptors from 15/25 IPv6 fallbacks
+--
 Reporter:  teor|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.8.4-rc
 Severity:  Normal  | Resolution:
 Keywords:  ipv6, microdesc, fallbacks  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 #19989 makes this worse - tor clients won't fetch microdescriptors from
 Exits.

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

Re: [tor-bugs] #18828 [Core Tor/Tor]: Regenerate fallback list for 0.2.9

[Tor Bug Tracker & Wiki]

#18828: Regenerate fallback list for 0.2.9
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201608, 029-accepted  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  SponsorU-
 |  can
-+-

Comment (by teor):

 It's likely that #19989 applies to IPv6-only clients fetching
 microdescriptors from fallback directories (#19608). So we should make
 sure there are some non-Exit IPv6-capable relays in the set.

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

Re: [tor-bugs] #19989 [Core Tor/Tor]: Tor fails to bootstrap with an Exit as EntryNode (was: Tor fails to bootstrap with a single EntryNode)

[Tor Bug Tracker & Wiki]

#19989: Tor fails to bootstrap with an Exit as EntryNode
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fallback  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * keywords:  guard => fallback


Old description:

> When I try to run tor with EntryNodes x (where x is a single relay), it
> hangs at:
>
> {{{
> Aug 26 00:51:57.000 [notice] Bootstrapped 45%: Asking for relay
> descriptors
> Aug 26 00:51:57.000 [notice] I learned some more directory information,
> but not enough to build a circuit: We need more microdescriptors: we have
> 0/6973, and can only build 0% of likely paths. (We have 0% of guards bw,
> 0% of midpoint bw, and 0% of exit bw = 0% of path bw.)
> Aug 26 00:51:58.000 [notice] Bootstrapped 50%: Loading relay descriptors
> }}}
>
> This issue might prevent us from switching to one guard in future
> releases.
>
> I can reproduce this issue on 0.2.9.2-alpha-dev, 0.2.8.{6,7},
> maint-0.2.7, maint-0.2.6 using the following command:
> {{{
> src/or/tor DataDirectory /tmp/tor.$$ SOCKSPort 0 EntryNodes x
> }}}

New description:

 When I try to run tor with EntryNodes x (where x is a single Exit relay),
 it hangs at:

 {{{
 Aug 26 00:51:57.000 [notice] Bootstrapped 45%: Asking for relay
 descriptors
 Aug 26 00:51:57.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We need more microdescriptors: we have
 0/6973, and can only build 0% of likely paths. (We have 0% of guards bw,
 0% of midpoint bw, and 0% of exit bw = 0% of path bw.)
 Aug 26 00:51:58.000 [notice] Bootstrapped 50%: Loading relay descriptors
 }}}

 ~~This issue might prevent us from switching to one guard in future
 releases.~~
 This issue likely makes Exits useless as fallback directories for
 IPv6-only microdescriptor clients (#19608).

 I can reproduce this issue on 0.2.9.2-alpha-dev, 0.2.8.{6,7}, maint-0.2.7,
 maint-0.2.6 using the following command:
 {{{
 src/or/tor DataDirectory /tmp/tor.$$ SOCKSPort 0 EntryNodes x
 }}}

--

Comment:

 I chose an exit. It fails for me with any exit.
 I've updated the description and the title.

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

Re: [tor-bugs] #19989 [Core Tor/Tor]: Tor fails to bootstrap with a single EntryNode

[Tor Bug Tracker & Wiki]

#19989: Tor fails to bootstrap with a single EntryNode
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  guard |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Works for me? What 'x' did you choose? I just chose moria1 and it
 bootstrapped fine.

 Also, didn't we move to one guard like a year ago?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19990 [Core Tor/Tor]: EntryNodes is incompatible with IPv6-only bootstrap

[Tor Bug Tracker & Wiki]

#19990: EntryNodes is incompatible with IPv6-only bootstrap
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal|   Keywords:  ipv6
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:|
--+
 When UseMicrodescriptors is 1, tor clients which bootstrap over IPv6 have
 to get descriptors from the fallback directories, because there are no
 IPv6 addresses in the microdescriptor consensus.

 When EntryNodes is set, it excludes all the fallback directories, meaning
 that IPv6 clients can't bootstrap.

 This can be tested with:
 {{{
 src/or/tor DataDirectory /tmp/tor.$$ SOCKSPort 0 EntryNodes x
 ClientUseIPv4 0
 }}}

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

[tor-bugs] #19989 [Core Tor/Tor]: Tor fails to bootstrap with a single EntryNode

[Tor Bug Tracker & Wiki]

#19989: Tor fails to bootstrap with a single EntryNode
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  guard
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 When I try to run tor with EntryNodes x (where x is a single relay), it
 hangs at:

 {{{
 Aug 26 00:51:57.000 [notice] Bootstrapped 45%: Asking for relay
 descriptors
 Aug 26 00:51:57.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We need more microdescriptors: we have
 0/6973, and can only build 0% of likely paths. (We have 0% of guards bw,
 0% of midpoint bw, and 0% of exit bw = 0% of path bw.)
 Aug 26 00:51:58.000 [notice] Bootstrapped 50%: Loading relay descriptors
 }}}

 This issue might prevent us from switching to one guard in future
 releases.

 I can reproduce this issue on 0.2.9.2-alpha-dev, 0.2.8.{6,7}, maint-0.2.7,
 maint-0.2.6 using the following command:
 {{{
 src/or/tor DataDirectory /tmp/tor.$$ SOCKSPort 0 EntryNodes x
 }}}

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

Re: [tor-bugs] #13953 [Core Tor/Tor]: Self-test reachability test - Listen address from ORPort is ignored, it uses default address unless specified via Address argument

[Tor Bug Tracker & Wiki]

#13953: Self-test reachability test - Listen address from ORPort is ignored, it
uses default address unless specified via Address argument
---+---
 Reporter:  s7r|  Owner:  teor
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.5.10
 Severity:  Normal | Resolution:
   |  implemented
 Keywords:  review-group-7, TorCoreTeam201608  |  Actual Points:  1.0
Parent ID:  #17782 | Points:  3
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 I just logged #19988: Warn when Port addresses have no effect, as a
 follow-up to this ticket, in case we still see problems with these kinds
 of issues when operators switch to 0.2.9.

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

[tor-bugs] #19988 [Core Tor/Tor]: Warn when Port addresses have no effect

[Tor Bug Tracker & Wiki]

#19988: Warn when Port addresses have no effect
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 Following up #13953, we could also warn:
 "Setting Listen Address %s on the %sNoListen port %d has no effect. Tor
 uses Address for IPv4 and the first advertised port for IPv6.",
 address_string, ip_version == 6 ? "secondary " : "", port_number

 We would warn on every IPv4 NoListen port, and the second and subsequent
 IPv6 NoListen ports.

 I think this could be useful, but it could also be too verbose.

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

Re: [tor-bugs] #19987 [Core Tor/Tor]: Unit Test Middle, Exit, Intro, and Rend node choices

[Tor Bug Tracker & Wiki]

#19987: Unit Test Middle, Exit, Intro, and Rend node choices
-+--
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  path-selection, testing  |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+--

Old description:

> I'd like to unit test the #19973 fix to the 0.2.8.6 path selection issue
> by copying the code from test_choose_random_entry_no_guards,
> but running it on:
> * choose_good_middle_server
> * choose_good_exit_server_general
> * router_choose_random_node (used by rend_consider_services_intro_points)
> * pick_rendezvous_node
>
> The tests should make sure these functions return any node at random.
> In 0.2.8.6, these functions chose nodes using the direct connection
> reachability rules, which was wrong.
>
> We could make these tests simpler and more reliable by setting up a node
> list with a single node that 0.2.8.6 wouldn't choose, but 0.2.8.7 would.
> For example:
> * an IPv4-only node with ClientUseIPv4 0
> * a node on 9001/9030 with FascistFirewall 1
> * a node on 1.1.1.1 with ReachableAddresses 2.0.0.0/8

New description:

 We could unit test the #19973 fix to the 0.2.8.6 path selection issue by
 copying the code from test_choose_random_entry_no_guards,
 but running it on:
 * choose_good_middle_server
 * choose_good_exit_server_general
 * router_choose_random_node (used by rend_consider_services_intro_points)
 * pick_rendezvous_node

 The tests should make sure these functions return any node at random.
 In 0.2.8.6, these functions chose nodes using the direct connection
 reachability rules, which was wrong.

 We could make these tests simpler and more reliable by setting up a node
 list with a single node that 0.2.8.6 wouldn't choose, but 0.2.8.7 would.
 For example:
 * an IPv4-only node with ClientUseIPv4 0
 * a node on 9001/9030 with FascistFirewall 1
 * a node on 1.1.1.1 with ReachableAddresses 2.0.0.0/8

--

Comment (by teor):

 I'm not sure if I will get time to write this test, so I modified the
 description so it didn't look like I was volunteering.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19987 [Core Tor/Tor]: Unit Test Middle, Exit, Intro, and Rend node choices

[Tor Bug Tracker & Wiki]

#19987: Unit Test Middle, Exit, Intro, and Rend node choices
--+-
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  path-selection, testing
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:|
--+-
 I'd like to unit test the #19973 fix to the 0.2.8.6 path selection issue
 by copying the code from test_choose_random_entry_no_guards,
 but running it on:
 * choose_good_middle_server
 * choose_good_exit_server_general
 * router_choose_random_node (used by rend_consider_services_intro_points)
 * pick_rendezvous_node

 The tests should make sure these functions return any node at random.
 In 0.2.8.6, these functions chose nodes using the direct connection
 reachability rules, which was wrong.

 We could make these tests simpler and more reliable by setting up a node
 list with a single node that 0.2.8.6 wouldn't choose, but 0.2.8.7 would.
 For example:
 * an IPv4-only node with ClientUseIPv4 0
 * a node on 9001/9030 with FascistFirewall 1
 * a node on 1.1.1.1 with ReachableAddresses 2.0.0.0/8

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

Re: [tor-bugs] #18640 [Core Tor/Tor]: Use smarter algorithms to handle socket exhaustion

[Tor Bug Tracker & Wiki]

#18640: Use smarter algorithms to handle socket exhaustion
-+-
 Reporter:  nickm|  Owner:  andrea
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, TorCoreTeam201606, review-  |  Actual Points:  4
  group-5, review-group-7|
Parent ID:  #17293   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorU-can
-+-
Changes (by andrea):

 * status:  reopened => needs_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] #18640 [Core Tor/Tor]: Use smarter algorithms to handle socket exhaustion

[Tor Bug Tracker & Wiki]

#18640: Use smarter algorithms to handle socket exhaustion
-+-
 Reporter:  nickm|  Owner:  andrea
 Type:  enhancement  | Status:
 |  reopened
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, TorCoreTeam201606, review-  |  Actual Points:  4
  group-5, review-group-7|
Parent ID:  #17293   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorU-can
-+-
Changes (by andrea):

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


Comment:

 Test suite failures fixed in {{{oos-test-failures}}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19985 [- Select a component]: pathbias_mark_use_success

[Tor Bug Tracker & Wiki]

#19985: pathbias_mark_use_success
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 pathbias_mark_use_success: Bug: Used circuit 243 is in strange path state
 new. Circuit is a General-purpose client currently open. (on Tor
 0.2.9.1-alpha f6c7e131a1ceb178)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19986 [- Select a component]: pathbias_count_use_attempt

[Tor Bug Tracker & Wiki]

#19986: pathbias_count_use_attempt
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 pathbias_count_use_attempt: Bug: Used circuit is in strange path state
 new. Circuit is a General-purpose client currently open. (on Tor
 0.2.9.1-alpha f6c7e131a1ceb178)

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

Re: [tor-bugs] #19976 [HTTPS Everywhere/EFF-HTTPS Everywhere]: HTTPS Everywhere tries to load a library with an empty name

[Tor Bug Tracker & Wiki]

#19976: HTTPS Everywhere tries to load a library with an empty name
-+-
 Reporter:  boklm|  Owner:  jsha
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201608 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by legind):

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


Comment:

 A new release of HTTPS Everywhere has been made, v 5.2.3, which fixes this
 bug.  I've tested on Tor Browser, and it looks to be updating to the
 latest.  Thank you for reporting and for your patch.

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

Re: [tor-bugs] #19978 [Core Tor/Tor]: testsuite fails on hppa

[Tor Bug Tracker & Wiki]

#19978: testsuite fails on hppa
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 This is a duplicate of #19261 and #19465. The fix probably wasn't
 backported to 0.2.8 hence the issue still exists 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] #19976 [HTTPS Everywhere/EFF-HTTPS Everywhere]: HTTPS Everywhere tries to load a library with an empty name

[Tor Bug Tracker & Wiki]

#19976: HTTPS Everywhere tries to load a library with an empty name
-+-
 Reporter:  boklm|  Owner:  jsha
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201608 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:   => TorBrowserTeam201608


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

Re: [tor-bugs] #19976 [HTTPS Everywhere/EFF-HTTPS Everywhere]: HTTPS Everywhere tries to load a library with an empty name

[Tor Bug Tracker & Wiki]

#19976: HTTPS Everywhere tries to load a library with an empty name
-+-
 Reporter:  boklm|  Owner:  jsha
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: legind (added)
 * status:  new => needs_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] #15852 [Applications/Tor Browser]: Remove/synchronize Torbutton SOCKS pref logic

[Tor Bug Tracker & Wiki]

#15852: Remove/synchronize Torbutton SOCKS pref logic
-+-
 Reporter:  mikeperry|  Owner:  brade
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-4.5-regression, tbb-torbutton-   |  Actual Points:
  conversion, TorBrowserTeam201608R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by mcs):

 * status:  needs_revision => needs_review


Comment:

 Here is a squashed commit that includes the changes gk requested in
 comment:12:
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug15852-02=1b41636c9351b46bbcb2094a65c65a4407b60a37

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

Re: [tor-bugs] #18640 [Core Tor/Tor]: Use smarter algorithms to handle socket exhaustion

[Tor Bug Tracker & Wiki]

#18640: Use smarter algorithms to handle socket exhaustion
-+-
 Reporter:  nickm|  Owner:  andrea
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, TorCoreTeam201606, review-  |  implemented
  group-5, review-group-7|  Actual Points:  4
Parent ID:  #17293   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorU-can
-+-
Changes (by nickm):

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


Comment:

 merged; thank you!

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

Re: [tor-bugs] #18640 [Core Tor/Tor]: Use smarter algorithms to handle socket exhaustion

[Tor Bug Tracker & Wiki]

#18640: Use smarter algorithms to handle socket exhaustion
-+-
 Reporter:  nickm|  Owner:  andrea
 Type:  enhancement  | Status:
 |  reopened
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, TorCoreTeam201606, review-  |  Actual Points:  4
  group-5, review-group-7|
Parent ID:  #17293   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorU-can
-+-
Changes (by dgoulet):

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


Comment:

 This made current git upstream fail to build with two issues.

 Both fixed in `bug18640_029_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] #19976 [HTTPS Everywhere/EFF-HTTPS Everywhere]: HTTPS Everywhere tries to load a library with an empty name

[Tor Bug Tracker & Wiki]

#19976: HTTPS Everywhere tries to load a library with an empty name
---+--
 Reporter:  boklm  |  Owner:  jsha
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by mcs):

 * cc: mcs (added)


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

Re: [tor-bugs] #18640 [Core Tor/Tor]: Use smarter algorithms to handle socket exhaustion

[Tor Bug Tracker & Wiki]

#18640: Use smarter algorithms to handle socket exhaustion
-+-
 Reporter:  nickm|  Owner:  andrea
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, TorCoreTeam201606, review-  |  implemented
  group-5, review-group-7|  Actual Points:  4
Parent ID:  #17293   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorU-can
-+-
Changes (by nickm):

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


Comment:

 > Open a new ticket to make this code look at all edge/directory
 connections, and turn the check on by default.

 This is #19984, just opened.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19984 [Core Tor/Tor]: Use a better set of comparison/evaluation functions for deciding which connections to kill when OOS

[Tor Bug Tracker & Wiki]

#19984: Use a better set of comparison/evaluation functions for deciding which
connections to kill when OOS
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  dos,sockets
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 Our existing OOS code kills low-priority OR connections. But really, we
 need to look at all connections that an adversary might be able to create
 (especially dir and exit connections), or else an adversary will be able
 to open a bunch of those, and force us to kill as many OR connections as
 they want.

 This problem is the reason that DisableOOSCheck is now on-by-default.

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

Re: [tor-bugs] #18640 [Core Tor/Tor]: Use smarter algorithms to handle socket exhaustion

[Tor Bug Tracker & Wiki]

#18640: Use smarter algorithms to handle socket exhaustion
-+-
 Reporter:  nickm|  Owner:  andrea
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, TorCoreTeam201606, review-  |  Actual Points:  4
  group-5, review-group-7|
Parent ID:  #17293   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorU-can
-+-

Comment (by nickm):

 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] #17242 [Core Tor/Tor]: prop224: Implement client and service support (was: Implement client and service support for proposal 224)

[Tor Bug Tracker & Wiki]

#17242: prop224: Implement client and service support
--+
 Reporter:  dgoulet   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #12424| Points:  parent
 Reviewer:|Sponsor:  SponsorR-must
--+
Changes (by dgoulet):

 * points:  large => parent
 * sponsor:   => SponsorR-must
 * milestone:  Tor: 0.2.??? => Tor: 0.3.0.x-final


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

[tor-bugs] #19983 [Core Tor/Tor]: Is openssl 1.1.0's "secure heap" feature useful for us?

[Tor Bug Tracker & Wiki]

#19983: Is openssl 1.1.0's "secure heap" feature useful for us?
--+--
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  openssl110
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Found out about this in the 1.1.0 changelog. Maybe it could be something
 to take advantage of.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19982 [Core Tor/Tor]: Remove all openssl calls outside of crypto*.c, tortls*.c

[Tor Bug Tracker & Wiki]

#19982: Remove all openssl calls outside of crypto*.c, tortls*.c
--+--
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 It would be a fine thing to have all our openssl access mediated through
 these files.

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

Re: [tor-bugs] #19981 [Core Tor/Tor]: Make sure we build with OpenSSL 1.1.0 with all deprecated APIs removed

[Tor Bug Tracker & Wiki]

#19981: Make sure we build with OpenSSL 1.1.0 with all deprecated APIs removed
--+--
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  openssl110|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 The "OPENSSL_API_COMPAT" macro may help here.

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

[tor-bugs] #19981 [Core Tor/Tor]: Make sure we build with OpenSSL 1.1.0 with all deprecated APIs removed

[Tor Bug Tracker & Wiki]

#19981: Make sure we build with OpenSSL 1.1.0 with all deprecated APIs removed
--+--
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  openssl110
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 There's an option to build openssl 1.1.0 with all the deprecated APIs
 turned off. We should make sure that Tor still works without using any of
 those.

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

[tor-bugs] #19980 [Core Tor/Tor]: Use OpenSSL 1.1.0 X5519 in Tor when available (if it's good)

[Tor Bug Tracker & Wiki]

#19980: Use OpenSSL 1.1.0 X5519 in Tor when available (if it's good)
--+--
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  openssl110
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 OpenSSL 1.1.0 says it now has X5519 support.  If it's done well, we should
 consider using it in Tor when linking against OpenSSL 1.1.0.

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

[tor-bugs] #19979 [Core Tor/Tor]: Use OpenSSL 1.1.0 HKDF in Tor when available.

[Tor Bug Tracker & Wiki]

#19979: Use OpenSSL 1.1.0 HKDF in Tor when available.
--+-
 Reporter:  nickm |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  openssl110 easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 OpenSSL 1.1.0 now includes HKDF support. We should consider using their
 implementation instead of ours when it's available.

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

Re: [tor-bugs] #19972 [Core Tor/Tor]: prop224: Proposal fixes from implementation of HSDir support

[Tor Bug Tracker & Wiki]

#19972: prop224: Proposal fixes from implementation of HSDir support
--+
 Reporter:  dgoulet   |  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  proposal, tor-hs  |  Actual Points:  0.1
Parent ID:  #17238| Points:  0.5
 Reviewer:|Sponsor:  SponsorR-must
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 All good! Feel free to update the upstream! Thx!

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

Re: [tor-bugs] #17238 [Core Tor/Tor]: prop224: Implement HSDir support

[Tor Bug Tracker & Wiki]

#17238: prop224: Implement HSDir support
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201608,  |  Actual Points:
  review-group-7, actualreviewpoints=2   |
Parent ID:  #12424   | Points:  parent
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_information


Comment:

 I've merged all your things! _minor_ fixes here and there mostly to follow
 some syntax but that's it. I've integrated them in the current commit that
 exists. The `fetch` feature has its own commit as well as the unit test
 for it. Finally, the "make check-spaces happy" is also its own commit.

 On top of all this, I've added a commit for the consensus params
 (discussed in #19899). This is imo ready for a `merge_ready` state that is
 put it in nickm's court.

 @asn, can you confirm your happiness? :) Once you do, I'll create a merge
 request on Gitlab.

 Test code coverage:
 {{{
 src/or/hs_cache.c  - 100%
 src/or/hs_common.c - 82% /* Existing code refactored in there. *
 src/or/hs_descriptor.c - 90.7%
 }}}

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

Re: [tor-bugs] #19899 [Core Tor/Tor]: prop224: Add a consensus param to enable/disable next gen onion service

[Tor Bug Tracker & Wiki]

#19899: prop224: Add a consensus param to enable/disable next gen onion service
+--
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  enhancement | Status:  accepted
 Priority:  High|  Milestone:  Tor:
|  0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, tor-hs, TorCoreTeam201608  |  Actual Points:  0.1
Parent ID:  #17238  | Points:  1
 Reviewer:  |Sponsor:
|  SponsorR-must
+--
Changes (by dgoulet):

 * parent:  #12424 => #17238
 * actualpoints:   => 0.1


Comment:

 I've implemented this in branch `ticket17238_029_02` thus now part of the
 larger ticket #17238. `NextGenOnionServices` is the chosen option.

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

Re: [tor-bugs] #19978 [Core Tor/Tor]: testsuite fails on hppa

[Tor Bug Tracker & Wiki]

#19978: testsuite fails on hppa
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#19969: tor client does not immediately open new circuits after standby
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #19977 [Core Tor/Tor]: testsuite fails on mips, powerpc, s390x

[Tor Bug Tracker & Wiki]

#19977: testsuite fails on mips, powerpc, s390x
--+
 Reporter:  weasel|  Owner:  dgoulet
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Major | Resolution:
 Keywords:  tor-sr, test  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:  SponsorR-must
--+
Changes (by dgoulet):

 * keywords:   => tor-sr, test
 * owner:   => dgoulet
 * points:   => 0.2
 * status:  new => accepted
 * sponsor:   => SponsorR-must


Comment:

 By the look of it, this is probably an endianess issue (BE vs LE).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19978 [Core Tor/Tor]: testsuite fails on hppa

[Tor Bug Tracker & Wiki]

#19978: testsuite fails on hppa
--+--
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 According to https://buildd.debian.org/status/package.php?p=tor=sid,
 0.2.8.6 failed to build on hppa:

 {{{
 rend_cache/store_v2_desc_as_client:
   FAIL ../src/test/test_rendcache.c:201: assert(ret OP_EQ -1): 0 vs -1
   [store_v2_desc_as_client FAILED]
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19977 [Core Tor/Tor]: testsuite fails on mips, powerpc, s390x

[Tor Bug Tracker & Wiki]

#19977: testsuite fails on mips, powerpc, s390x
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 According to
 https://buildd.debian.org/status/package.php?p=tor=experimental, tor
 fails on several architectures.

 It might be a big-endian issue.

 {{{
 shared-random/encoding: [forking]
   FAIL ../src/test/test_shared_random.c:409: assert(hashed_rand OP_EQ
 parsed_commit.random_number):
 30920FF41C187DFCBE96E453A0885E3B956B9EEB18C3A15D2EE1D0858ECC3CDB vs
 24F71F644E3890594AA31F048010E74F01F09ABAB5E08CFCB5EF74B3623782DA
   [encoding FAILED]
 }}}

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

Re: [tor-bugs] #12736 [Applications/Tor Browser]: DLL hijacking vulnerability in TBB

[Tor Bug Tracker & Wiki]

#12736: DLL hijacking vulnerability in TBB
+--
 Reporter:  underdoge   |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201608  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by boklm):

 Vanilla firefox is also affected by this issue when HTTPS Everywhere is
 installed.

 I opened #19976 with a patch to fix the issue in HTTPS Everywhere.

 Whith this patch applied, firefox.exe is no longer trying to find a .DLL
 library.

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

Re: [tor-bugs] #19691 [Obfuscation/BridgeDB]: does not re-open logfiles properly

[Tor Bug Tracker & Wiki]

#19691: does not re-open logfiles properly
--+--
 Reporter:  weasel|  Owner:  isis
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridgedb-0.3.7|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by isis):

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


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

Re: [tor-bugs] #19976 [HTTPS Everywhere/EFF-HTTPS Everywhere]: HTTPS Everywhere tries to load a library with an empty name

[Tor Bug Tracker & Wiki]

#19976: HTTPS Everywhere tries to load a library with an empty name
---+--
 Reporter:  boklm  |  Owner:  jsha
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 I attached a patch that should fix this.

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

[tor-bugs] #19976 [HTTPS Everywhere/EFF-HTTPS Everywhere]: HTTPS Everywhere tries to load a library with an empty name

[Tor Bug Tracker & Wiki]

#19976: HTTPS Everywhere tries to load a library with an empty name
---+--
 Reporter:  boklm  |  Owner:  jsha
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 The `NSS.initialize` function, called from `src/components/ssl-
 observatory.js` with an empty argument, is trying to load a library with
 an empty name.

 This is possibly causing a DLL hijacking vulnerability in Tor Browser (see
 #12736).

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

Re: [tor-bugs] #19691 [Obfuscation/BridgeDB]: does not re-open logfiles properly

[Tor Bug Tracker & Wiki]

#19691: does not re-open logfiles properly
--+
 Reporter:  weasel|  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  bridgedb-0.3.7|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by isis):

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


Comment:

 SIGHUPs to flog are added in
 [https://gitweb.torproject.org/project/bridges/bridgedb-
 admin.git/commit/?id=a218b01ab0f0ce10c988c63bf8ba1243b64a55fd commit]
 `a218b01a`.

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

Re: [tor-bugs] #19972 [Core Tor/Tor]: prop224: Proposal fixes from implementation of HSDir support

[Tor Bug Tracker & Wiki]

#19972: prop224: Proposal fixes from implementation of HSDir support
--+
 Reporter:  dgoulet   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  proposal, tor-hs  |  Actual Points:  0.1
Parent ID:  #17238| Points:  0.5
 Reviewer:|Sponsor:  SponsorR-must
--+

Comment (by asn):

 Your changes look good to me David.

 I also pushed a commit myself to `ticket19972_01` in my repo, that
 addresses comment:2 .

 Let me know if you like it and I will push all this stuff upstream.

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

Re: [tor-bugs] #17238 [Core Tor/Tor]: prop224: Implement HSDir support

[Tor Bug Tracker & Wiki]

#17238: prop224: Implement HSDir support
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201608,  |  Actual Points:
  review-group-7, actualreviewpoints=2   |
Parent ID:  #12424   | Points:  parent
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-

Comment (by asn):

 Please see brach `ticket17238_029_11` in my repo.

 It features:
 - It adds support for fetching descs from HSDirs (using "/tor/hs/3/"
 path)
 - It adds high-level unittests for pushing/fetching descs from HSDirs.
 - It introduces a prefix for desc signatures.
 - It's rebased on latest git master.
 - It fixes a few bugs and improves some code.
 - Addresses check-spaces (although in its own commit).

 David another thing we should discuss is whether we should guard all this
 HSDir cache code with a consensus parameter, or we should just leave it
 there active but unused till we deploy the rest of the prop224 parts.

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

Re: [tor-bugs] #19972 [Core Tor/Tor]: prop224: Proposal fixes from implementation of HSDir support

[Tor Bug Tracker & Wiki]

#19972: prop224: Proposal fixes from implementation of HSDir support
--+
 Reporter:  dgoulet   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  proposal, tor-hs  |  Actual Points:  0.1
Parent ID:  #17238| Points:  0.5
 Reviewer:|Sponsor:  SponsorR-must
--+

Comment (by asn):

 We should also mention the prefixed descriptor signature here. Here is
 what I currently do:

 {{{
 /* Prefix required to compute/verify HS desc signatures */
 #define hs_desc_signature_prefix "Tor onion service descriptor sig v3"
 ...
 if (ed25519_sign_prefixed(,
   (const uint8_t *) encoded_str, encoded_len,
   hs_desc_signature_prefix,
   >plaintext_data.signing_kp) < 0) {
 }}}

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

Re: [tor-bugs] #19974 [Core Tor/Tor]: Test failure

[Tor Bug Tracker & Wiki]

#19974: Test failure
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 The machine is a "classic" i686 ; tor is used as a transparent proxy for
 other machines on the local network.

 Anyway the test did not fail again after restarting the process without
 modifying anything else ... maybe the machine is too old and starts to be
 prone to hardware errors.

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

Re: [tor-bugs] #17933 [Applications/Tor Browser]: Tor Browser does not isolate the pdf 'download' (via the download button) to URL bar domain (was: Recent Tor Browser isolates the pdf 'download' outco

[Tor Bug Tracker & Wiki]

#17933: Tor Browser does not isolate the pdf 'download' (via the download 
button)
to URL bar domain
+--
 Reporter:  arma|  Owner:  tbb-team
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-linkability, tbb-usability  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  needs_information => assigned
 * keywords:  tbb-linkability => tbb-linkability, tbb-usability


Comment:

 We probably have arma's issue as downloading with the Download button is
 going over the catch-all curcuit and is not isolated to the URL bar
 domain.

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

Re: [tor-bugs] #8168 [Applications/Tor Browser]: Replace deprecated getOriginatingURI() method used in Firefox patches

[Tor Bug Tracker & Wiki]

#8168: Replace deprecated getOriginatingURI() method used in Firefox patches
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-linkability, ff24-esr, tbb-  |  Actual Points:
  firefox-patch  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 This is long done in our patches.

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