[tor-bugs] #27807 [Applications]: Add link backup feature in Tor Browser

[Tor Bug Tracker & Wiki]

#27807: Add link backup feature in Tor Browser
---+--
 Reporter:  Prince360  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Applications
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 **Please add Link backup feature in "Tor Browser for Android"**

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27201 [Core Tor/Tor]: rust/protover doesn't forbid version zero

[Tor Bug Tracker & Wiki]

#27201: rust/protover doesn't forbid version zero
+--
 Reporter:  cyberpunks  |  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.5.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.3.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  rust,033-backport,034-backport  |  Actual Points:
Parent ID:  #27198  | Points:
 Reviewer:  teor|Sponsor:
+--

Comment (by teor):

 CI is here:
 https://travis-ci.org/teor2345/tor/builds/431332945

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27197 [Core Tor/Tor]: rust protover accepts excess commas in version strings

[Tor Bug Tracker & Wiki]

#27197: rust protover accepts excess commas in version strings
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, security-low, 033-backport,|  Actual Points:
  034-backport   |
Parent ID:  #27194   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 CI is here:
 https://travis-ci.org/teor2345/tor/builds/431333010

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27316 [Core Tor/Tor]: protover.c accepts arbitrary bytes in protocol names

[Tor Bug Tracker & Wiki]

#27316: protover.c accepts arbitrary bytes in protocol names
-+-
 Reporter:  cyberpunks   |  Owner:
 |  cyberpunks
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  protover, 029-backport,  |  Actual Points:
  032-backport, 033-backport, 034-backport   |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 This looks fine to me, and the CI passed at:
 https://github.com/torproject/tor/pull/332

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27490 [Core Tor/Tor]: When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at random

[Tor Bug Tracker & Wiki]

#27490: When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen 
for
a directory or orport connection, prefer IPv4 or IPv6 at random
--+
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #17835| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 I am very confused by this branch, and I'm not sure if I can review it
 properly.

 It seems to have:
 * one commit that makes most of the changes
 * three commits that make some log and comment changes
 * the same three commits that make some log and comment changes. Please
 don't add duplicate commits to a branch.
 * a merge
 * a bunch of extra commits that choose IP addresses randomly, but in
 different places all through the code
 * a commit that fixes the unit tests

 Some of this is my fault, because I asked you to add ClientAutoIPv6ORPort,
 but then I talked about ClientPreferIPv6ORPort in the rest of my feedback.

 Here's what this patch needs to do:
 * ClientPreferIPv6ORPort is an existing option, this patch must not change
 what it does
 * ClientAutoIPv6ORPort is a new option, it can do new things

 Here's how we can move forward:
 * please open a new pull request like commit 1a98526, but using
 ClientAutoIPv6ORPort, rather than changing ClientPreferIPv6ORPort
 * please add the logging changes from commit 2311a42
 * please add new unit tests for ClientAutoIPv6ORPort (if the unit tests
 for ClientPreferIPv6ORPort fail, then you have changed how
 ClientPreferIPv6ORPort works)

 Adding all those extra comments isn't as helpful as I thought it would be.
 Let's just change the function comment on
 fascist_firewall_prefer_ipv6_orport().

 I am not sure why the 4 "assign it a random preference" commits are
 needed.
 I think it is enough for fascist_firewall_prefer_ipv6_orport() to return a
 random value when ClientAutoIPv6ORPort is 1.
 Why do we need to choose at random in these places as well?

 But we might need to change rewrite_node_address_for_bridge() so that we
 choose a random address when ClientAutoIPv6ORPort is 1.
 But that is a simple change, because the code already calls
 fascist_firewall_prefer_ipv6_orport().

 All we need to do it change:
 "if (options->ClientPreferIPv6ORPort == -1) {"
 to
 "if (options->ClientPreferIPv6ORPort == -1 &&
 options->ClientAutoIPv6ORPort == 0) {"
 Then, when ClientAutoIPv6ORPort is 1, the code will choose at random.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17835 [Core Tor/Tor]: Make ClientPreferIPv6ORPort smarter

[Tor Bug Tracker & Wiki]

#17835: Make ClientPreferIPv6ORPort smarter
-+
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client ipv6  |  Actual Points:
Parent ID:  #17811   | Points:  medium/large
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * milestone:  Tor: unspecified => Tor: 0.3.6.x-final


Comment:

 Let's look at this for merge in 0.3.6, if enough of the child tickets have
 been completed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26940 [Core Tor/Tor]: Privcount blinding and encryption: doc fixes

[Tor Bug Tracker & Wiki]

#26940: Privcount blinding and encryption: doc fixes
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 035-roadmap-master, 035   |  Actual Points:
  -triaged-in-20180711, rust |
Parent ID:  #25669   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorV
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Looks good to me. The new documentation is helpful for understanding the
 code.

 See my comments on the pull request, I found a few typos.

 After they're fixed, let's merge,

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26943 [Core Tor/Tor]: Privcount blinding and encryption: Safety fixes

[Tor Bug Tracker & Wiki]

#26943: Privcount blinding and encryption: Safety fixes
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 035-roadmap-master, 035   |  Actual Points:
  -triaged-in-20180711, rust |
Parent ID:  #25669   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorV
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Commits 3-5 look good.

 The CI is here:
 https://github.com/teor2345/privcount_shamir/pull/5

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26939 [Core Tor/Tor]: Privcount blinding and encryption: type fixes

[Tor Bug Tracker & Wiki]

#26939: Privcount blinding and encryption: type fixes
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 035-roadmap-master, 035   |  Actual Points:
  -triaged-in-20180711, rust |
Parent ID:  #25669   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorV
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 The first two commits in this branch look fine.

 I opened a pull request to get CI:
 https://github.com/teor2345/privcount_shamir/pull/5

 Can you configure Travis CI on your privcount_shamir?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23521 [Core Tor/Tor]: detect if clock skew is probably really time zone misconfiguration

[Tor Bug Tracker & Wiki]

#23521: detect if clock skew is probably really time zone misconfiguration
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew, ux,   |  Actual Points:
  s8-errors, 034-triage-20180328,|
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by traumschule):

 Marked #27806 as a duplicate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27806 [- Select a component]: cannot establish connection to tor

[Tor Bug Tracker & Wiki]

#27806: cannot establish connection to tor
--+---
 Reporter:  NerxXm8   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  s8-errors |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by traumschule):

 * keywords:   => s8-errors
 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Thanks for filing this. Tor disabled the network because
 > It seems that our clock is ahead by 1 days, 23 hours, 59 minutes, or
 that theirs is behind. Tor requires an accurate clock to work: please
 check your time, timezone, and date settings.
 Marking this as duplicate of #23521, also see #27351.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27794 [Core Tor/Tor]: Apparmor profile whitelist /etc/torrc.d/ and /usr/local/etc/torrc.d/

[Tor Bug Tracker & Wiki]

#27794: Apparmor profile whitelist /etc/torrc.d/ and /usr/local/etc/torrc.d/
--+-
 Reporter:  adrelanos |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  apparmor  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by traumschule):

 * keywords:   => apparmor


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27804 [Core Tor/Tor]: rust protover_all_supported() NULL pointer dereference

[Tor Bug Tracker & Wiki]

#27804: rust protover_all_supported() NULL pointer dereference
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, memory-safety,   |  Actual Points:
  035-must, fast-fix, 033-backport,  |
  034-backport   |
Parent ID:  #27740   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cyberpunks):

 Fortunately the only callers that pass NULL are
 
[https://gitweb.torproject.org/tor.git/tree/src/feature/dirauth/dirvote.c?id=bd6007d8986d851bb9e76fc2d9a72143a03f04ac#n4590
 these asserts] so this null deref (currently) can't happen.

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

[tor-bugs] #27806 [- Select a component]: cannot establish connection to tor

[Tor Bug Tracker & Wiki]

#27806: cannot establish connection to tor
-+--
 Reporter:  NerxXm8  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  - Select a component
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 9/23/18, 00:32:39.128 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 9/23/18, 00:32:39.128 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 9/23/18, 00:32:39.129 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 9/23/18, 00:32:39.129 [NOTICE] Opening Socks listener on 127.0.0.1:9150
 9/23/18, 00:32:39.775 [NOTICE] Bootstrapped 5%: Connecting to directory
 server
 9/23/18, 00:32:39.850 [NOTICE] Bootstrapped 10%: Finishing handshake with
 directory server
 9/23/18, 00:32:45.951 [WARN] Received NETINFO cell with skewed time
 (OR:199.58.81.140:443): It seems that our clock is ahead by 1 days, 23
 hours, 59 minutes, or that theirs is behind. Tor requires an accurate
 clock to work: please check your time, timezone, and date settings.
 9/23/18, 00:32:45.952 [WARN] Problem bootstrapping. Stuck at 10%:
 Finishing handshake with directory server. (Clock skew 172799 in NETINFO
 cell from OR; CLOCK_SKEW; count 4; recommendation warn; host
 74A910646BCEEFBCD2E874FC1DC997430F968145 at 199.58.81.140:443)
 9/23/18, 00:32:45.952 [WARN] 3 connections have failed:
 9/23/18, 00:32:45.952 [WARN]  2 connections died in state handshaking
 (Tor, v3 handshake) with SSL state SSL negotiation finished successfully
 in OPEN
 9/23/18, 00:32:45.952 [WARN]  1 connections died in state connect()ing
 with SSL state (No SSL object)
 9/23/18, 00:32:45.962 [NOTICE] Bootstrapped 15%: Establishing an encrypted
 directory connection
 9/23/18, 00:32:45.966 [NOTICE] Closing no-longer-configured Socks listener
 on 127.0.0.1:9150
 9/23/18, 00:32:45.967 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 9/23/18, 00:32:45.967 [NOTICE] Closing old Socks listener on
 127.0.0.1:9150
 9/23/18, 00:32:46.518 [NOTICE] Delaying directory fetches: DisableNetwork
 is 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] #27740 [Core Tor/Tor]: rust protover_all_supported() returns rust-allocated string in *missing_out

[Tor Bug Tracker & Wiki]

#27740: rust protover_all_supported() returns rust-allocated string in 
*missing_out
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, memory-safety,   |  Actual Points:
  035-must, fast-fix, 033-backport,  |
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:6 cyberpunks]:
 > Rust uses jemalloc to allocate memory by default. No CI has been failing
 even though `test_protover_all_supported` calls `tor_free()` on this
 jemalloc-allocated pointer though. Is it missing hardening that could
 catch similar issues in the future?

 ASAN would probably help, but it doesn't work with jemalloc, see #27272.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27805 [Core Tor/Tor]: Update CodingStandardsRust.md with allocate_and_copy_string()

[Tor Bug Tracker & Wiki]

#27805: Update CodingStandardsRust.md with allocate_and_copy_string()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:  Tor: 0.3.3.1-alpha
  Tor/Tor|   Keywords:  rust, protover, memory-safety,
 Severity:  Normal   |  035-must, fast-fix, 033-backport, 034-backport
Actual Points:   |  Parent ID:  #27740
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We have allocate_and_copy_string() in Rust, which uses tor_malloc():
 
​https://github.com/torproject/tor/blob/master/src/rust/tor_allocate/tor_allocate.rs#L30

 We need to update our rust coding standards to mention
 allocate_and_copy_string():
 
​https://gitweb.torproject.org/tor.git/tree/doc/HACKING/CodingStandardsRust.md#n374

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27740 [Core Tor/Tor]: rust protover_all_supported() returns rust-allocated string in *missing_out

[Tor Bug Tracker & Wiki]

#27740: rust protover_all_supported() returns rust-allocated string in 
*missing_out
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, memory-safety,   |  Actual Points:
  035-must, fast-fix, 033-backport,  |
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cyberpunks):

 Rust uses jemalloc to allocate memory by default. No CI has been failing
 even though `test_protover_all_supported` calls `tor_free()` on this
 jemalloc-allocated pointer though. Is it missing hardening that could
 catch similar issues in the future?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27740 [Core Tor/Tor]: rust protover_all_supported() returns rust-allocated string in *missing_out

[Tor Bug Tracker & Wiki]

#27740: rust protover_all_supported() returns rust-allocated string in 
*missing_out
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, memory-safety,   |  Actual Points:
  035-must, fast-fix, 033-backport,  |
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:5 cyberpunks]:
 > Replying to [comment:3 teor]:
 > > As far as I understand it, it may be ok to allocate in Rust and
 deallocate in C, as long as they use the same allocator.
 > Oh right. Of course currently, they don't.

 We have allocate_and_copy_string() in Rust, which uses tor_malloc():
 
https://github.com/torproject/tor/blob/master/src/rust/tor_allocate/tor_allocate.rs#L30

 We need to update our RustCodingStandards.md to mention
 allocate_and_copy_string():
 
https://gitweb.torproject.org/tor.git/tree/doc/HACKING/CodingStandardsRust.md#n374

 I'll open another ticket.

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

Re: [tor-bugs] #27803 [Core Tor/Tor]: rust protover_all_supported() double-free of *missing_out

[Tor Bug Tracker & Wiki]

#27803: rust protover_all_supported() double-free of *missing_out
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:  not a
 Keywords:  rust, protover, memory-safety,   |  bug
  035-must, fast-fix, 033-backport,  |  Actual Points:
  034-backport   |
Parent ID:  #27740   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => closed
 * resolution:   => not a bug


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

Re: [tor-bugs] #27740 [Core Tor/Tor]: rust protover_all_supported() returns rust-allocated string in *missing_out

[Tor Bug Tracker & Wiki]

#27740: rust protover_all_supported() returns rust-allocated string in 
*missing_out
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, memory-safety,   |  Actual Points:
  035-must, fast-fix, 033-backport,  |
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cyberpunks):

 Replying to [comment:3 teor]:
 > As far as I understand it, it may be ok to allocate in Rust and
 deallocate in C, as long as they use the same allocator.
 Right, and currently, they don't.


 > deallocated in Rust (when the function returns),
 It actually isn't.

 > * when missing_out is NULL, Rust still assigns to it
 Nice catch!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27801 [Core Tor/Tor]: tor_api: CreateConnection() interface

[Tor Bug Tracker & Wiki]

#27801: tor_api: CreateConnection() interface
--+
 Reporter:  sysrqb|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25510| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: unspecified => Tor: 0.3.6.x-final


Comment:

 adding for consideration to 0.3.6

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

Re: [tor-bugs] #26464 [Core Tor/Tor]: Static cross-compiling for Windows is broken

[Tor Bug Tracker & Wiki]

#26464: Static cross-compiling for Windows is broken
-+
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-triaged-in-20180711  |  Actual Points:
Parent ID:  #6623| Points:
 Reviewer:  nickm|Sponsor:
-+
Changes (by teor):

 * parent:   => #6623


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27802 [Core Tor/Tor]: OpenSSL 1.1.0 issue during static link

[Tor Bug Tracker & Wiki]

#27802: OpenSSL 1.1.0 issue during static link
-+-
 Reporter:  cretz|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  static, 029-backport, 032-backport,  |  Actual Points:
  033-backport, 034-backport |
Parent ID:  #6623| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:   => static, 029-backport, 032-backport, 033-backport,
 034-backport
 * parent:   => #6623
 * milestone:   => Tor: 0.3.5.x-final


Comment:

 I am not sure whether to put this fix in 0.3.5 or 0.3.6, but it would be
 nice to have a working static binary in our LTS release.
 It might also be good to backport these fixes, if they aren't too big.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27484 [Applications/Tor Browser]: Onboarding: unintuitive not-navigation buttons, starting with "Circuit Display" / "See My Path"

[Tor Bug Tracker & Wiki]

#27484: Onboarding: unintuitive not-navigation buttons, starting with "Circuit
Display" / "See My Path"
-+-
 Reporter:  dmr  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-onboarding, ux-  |  Actual Points:
  team   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by traumschule):

 Replying to [comment:1 arma]:
 > Right. I was going through the onboarding, everything was cool, I
 clicked "See my path" and now I have a tab open to duckduckgo. What does
 that have to do with seeing my path?

 had the same. is this fixed in the coming alpha?

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

Re: [tor-bugs] #27803 [Core Tor/Tor]: rust protover_all_supported() double-free of *missing_out

[Tor Bug Tracker & Wiki]

#27803: rust protover_all_supported() double-free of *missing_out
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, memory-safety,   |  Actual Points:
  035-must, fast-fix, 033-backport,  |
  034-backport   |
Parent ID:  #27740   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cyberpunks):

 That's not true. The code calls [https://doc.rust-
 lang.org/std/ffi/struct.CString.html#method.into_raw CString::into_raw()]
 to prevent a double-free.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27804 [Core Tor/Tor]: rust protover_all_supported() NULL pointer dereference

[Tor Bug Tracker & Wiki]

#27804: rust protover_all_supported() NULL pointer dereference
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:  Tor: 0.3.3.1-alpha
  Tor/Tor|   Keywords:  rust, protover, memory-safety,
 Severity:  Normal   |  035-must, fast-fix, 033-backport, 034-backport
Actual Points:   |  Parent ID:  #27740
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 When missing_out is NULL, Rust still assigns to *missing_out

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27803 [Core Tor/Tor]: rust protover_all_supported() double-free of *missing_out

[Tor Bug Tracker & Wiki]

#27803: rust protover_all_supported() double-free of *missing_out
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:  Tor: 0.3.3.1-alpha
  Tor/Tor|   Keywords:  rust, protover, memory-safety,
 Severity:  Normal   |  035-must, fast-fix, 033-backport, 034-backport
Actual Points:   |  Parent ID:  #27740
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 `*missing_out` is allocated in Rust, deallocated in Rust (when the
 function returns), used in C, and then freed in C

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27740 [Core Tor/Tor]: rust protover_all_supported() returns rust-allocated string in *missing_out

[Tor Bug Tracker & Wiki]

#27740: rust protover_all_supported() returns rust-allocated string in 
*missing_out
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, memory-safety,   |  Actual Points:
  035-must, fast-fix, 033-backport,  |
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  rust, protover, memory-safety, 035-must, fast-fix =>
 rust, protover, memory-safety, 035-must, fast-fix, 033-backport,
 034-backport


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27740 [Core Tor/Tor]: rust protover_all_supported() returns rust-allocated string in *missing_out

[Tor Bug Tracker & Wiki]

#27740: rust protover_all_supported() returns rust-allocated string in 
*missing_out
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, memory-safety,   |  Actual Points:
  035-must, fast-fix |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:   => rust, protover, memory-safety, 035-must, fast-fix
 * milestone:  Tor: unspecified => Tor: 0.3.5.x-final


Comment:

 Thanks for this bug report.

 As far as I understand it, it may be ok to allocate in Rust and deallocate
 in C, as long as they use the same allocator. But, this behaviour is not
 guaranteed to be safe in future Rust releases:
 
https://gitweb.torproject.org/tor.git/tree/doc/HACKING/CodingStandardsRust.md#n365

 But even if allocating in Rust and freeing in C was safe, this function is
 also memory unsafe because:
 * *missing_out is allocated in Rust, deallocated in Rust (when the
 function returns), used in C, and then freed in C
 * when missing_out is NULL, Rust still assigns to it

 I'll open child tickets for these issues.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27802 [Core Tor/Tor]: OpenSSL 1.1.0 issue during static link

[Tor Bug Tracker & Wiki]

#27802: OpenSSL 1.1.0 issue during static link
+--
 Reporter:  cretz   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Core Tor/Tor
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 Here's my configure call (using Tor 0.3.5.1-alpha in my case):

 {{{
 sh ./configure --prefix=/home/cretz/work/bine/gopath/src/github.com/cretz
 /tor-static/tor/dist --disable-gcc-hardening --disable-system-torrc
 --disable-asciidoc --enable-static-libevent --with-libevent-
 dir=/home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../libevent/dist --enable-static-openssl --with-openssl-
 dir=/home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist --enable-static-zlib --with-zlib-
 dir=/home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist --enable-static-tor
 }}}

 Note, this all works fine with OpenSSL 1.0.x. Running gets:

 {{{
 configure: Now, we'll look for OpenSSL >= 1.0.1
 checking for openssl directory... configure: WARNING: Could not find a
 linkable openssl.  If you have it installed somewhere unusual, you can
 specify an explicit path using --with-openssl-dir
 configure: WARNING: On Debian, you can install openssl using "apt-get
 install libssl-dev"
 configure: error: Missing libraries; unable to proceed.
 }}}

 Looking in config.log where it's checking OpenSSL:

 {{{
 configure:9656: Now, we'll look for OpenSSL >= 1.0.1
 configure:9677: checking for openssl directory
 configure:9732: gcc -o conftest -g -O2 -static
 -I/home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/include
 -L/home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib  conftest.c -lpthread -ldl  -lssl -lcrypto
 >&5
 /home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib/libcrypto.a(b_addr.o): In function
 `BIO_lookup':
 b_addr.c:(.text+0xc9c): warning: Using 'getaddrinfo' in statically linked
 applications requires at runtime the shared libraries from the glibc
 version used for linking
 /home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib/libcrypto.a(b_sock.o): In function
 `BIO_gethostbyname':
 b_sock.c:(.text+0x71): warning: Using 'gethostbyname' in statically linked
 applications requires at runtime the shared libraries from the glibc
 version used for linking
 /home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function
 `CRYPTO_THREAD_lock_new':
 threads_pthread.c:(.text+0x25): undefined reference to
 `pthread_rwlock_init'
 /home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function
 `CRYPTO_THREAD_read_lock':
 threads_pthread.c:(.text+0x65): undefined reference to
 `pthread_rwlock_rdlock'
 /home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function
 `CRYPTO_THREAD_write_lock':
 threads_pthread.c:(.text+0x85): undefined reference to
 `pthread_rwlock_wrlock'
 /home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function
 `CRYPTO_THREAD_unlock':
 threads_pthread.c:(.text+0xa5): undefined reference to
 `pthread_rwlock_unlock'
 /home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function
 `CRYPTO_THREAD_lock_free':
 threads_pthread.c:(.text+0xca): undefined reference to
 `pthread_rwlock_destroy'
 /home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function
 `CRYPTO_THREAD_run_once':
 threads_pthread.c:(.text+0xf5): undefined reference to `pthread_once'
 /home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function
 `CRYPTO_THREAD_init_local':
 threads_pthread.c:(.text+0x115): undefined reference to
 `pthread_key_create'
 /home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function
 `CRYPTO_THREAD_set_local':
 threads_pthread.c:(.text+0x147): undefined reference to
 `pthread_setspecific'
 /home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function
 `CRYPTO_THREAD_cleanup_local':
 threads_pthread.c:(.text+0x167): undefined reference to
 `pthread_key_delete'
 /home/cretz/work/bine/gopath/src/github.com/cretz/tor-
 static/tor/../openssl/dist/lib/libcrypto.a(threads_pthread.o): In function
 `CRYPTO_THREAD_get_local':
 threads_pthread.c:(.text+0x133): undefined reference to
 

Re: [tor-bugs] #27794 [Core Tor/Tor]: Apparmor profile whitelist /etc/torrc.d/ and /usr/local/etc/torrc.d/

[Tor Bug Tracker & Wiki]

#27794: Apparmor profile whitelist /etc/torrc.d/ and /usr/local/etc/torrc.d/
--+-
 Reporter:  adrelanos |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by teor):

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


Comment:

 Hi,

 Thanks for this bug report.

 I don't think it is a bug in upstream Tor - I can't find an apparmor
 profile in upstream Tor:
 https://gitweb.torproject.org/tor.git/tree/contrib/dist

 It looks like a bug in the Debian package:
 https://gitweb.torproject.org/debian/tor.git/tree/debian/tor.apparmor-
 profile.abstraction

 Please log Debian package bugs on the Debian bug tracker at:
 https://bugs.debian.org

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27739 [Core Tor/Tor]: rust protover_all_supported() accepts too-long protocol names

[Tor Bug Tracker & Wiki]

#27739: rust protover_all_supported() accepts too-long protocol names
+
 Reporter:  cyberpunks  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.3.6
 Severity:  Normal  | Resolution:
 Keywords:  rust, protover  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * keywords:  035-must, protover, memory-safety, 033-backport, 034-backport
 => rust, protover
 * milestone:  Tor: 0.3.5.x-final => Tor: 0.3.6.x-final


Comment:

 Replying to [comment:4 cyberpunks]:
 > This isn't a memory-safety issue is it? And this is missing the rust
 tag.

 You're right, the memory safety issue is fixed by #27741.
 But it would still be good to remove all the redundant Unvalidated rust
 code due to the #27741 fix.
 We probably don't need to backport a refactor like 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

Re: [tor-bugs] #27194 [Core Tor/Tor]: handling extra commas in protover

[Tor Bug Tracker & Wiki]

#27194: handling extra commas in protover
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, security-low, 029-backport,|  Actual Points:
  032-backport, 033-backport, 034-backport   |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 See protocommas1 at https://gitgud.io/onionk/tor.git for the original
 patch and a fixup.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25510 [Core Tor/Tor]: Collect feedback on mobile embedding API; resolve issues.

[Tor Bug Tracker & Wiki]

#25510: Collect feedback on mobile embedding API; resolve issues.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, 035-roadmap-master, |  Actual Points:
  034-triage-20180328, 034-included-20180328,|
  035-triaged-in-20180711|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-must
-+-

Comment (by sysrqb):

 I finally took a look at the API. I really like it. I created some example
 programs while I was looking at it and thinking about whether anything was
 missing. I documented some of that on #26653. They're in my public tor
 repo on branch `testing_26653`.

 #24204 was a big win.

 I think the API can use a little more documentation, and I created #27801
 as a maybe-this-will-be-useful-for-someone.

 Overall, I don't think we need anything else for TBA. Thanks!

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

[tor-bugs] #27801 [Core Tor/Tor]: tor_api: CreateConnection() interface

[Tor Bug Tracker & Wiki]

#27801: tor_api: CreateConnection() interface
--+--
 Reporter:  sysrqb|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #25510
   Points:|   Reviewer:
  Sponsor:|
--+--
 In ticket:26653#comment:8 I mentioned it may be nice if there was an
 easier way of requesting a new connection other than via a SOCKS
 connection. Adding an interface for creating a connection when roughly the
 same parameters Tor receives from the SOCKS handshake. In fact, I wonder
 if providing this as a wrapper around a default SOCKS client
 implementation may be an easy way of doing this.

 Something like:

 {{{
 /**
  * Tells Tor to open a socket for a client connection to the requested
  * destination.  Return the socket.
  */
 SOCKS_SOCKET tor_main_create_connection(tor_main_configuration_t *cfg,
 const char * hostname,
 uint16_t port,
 const char * stream_isolation);
 }}}

 Note, we don't need this for Tor Browser for Android. This is simply a
 more general 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] #26653 [Applications/Tor Browser]: Evaluate Tor's Embedding API when integrating Tor Launcher

[Tor Bug Tracker & Wiki]

#26653: Evaluate Tor's Embedding API when integrating Tor Launcher
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  TorBrowserTeam201809   |
Parent ID:  #24856   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

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


Comment:

 Okay. I have an example Java client called `jverify_config` (doing the
 same thing as the `threaded_verify_config` example). It's in the same
 branch as above.

 I don't think we need anything else here.

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

Re: [tor-bugs] #27130 [Core Tor/Tor]: rust dependency updating instructions don't work

[Tor Bug Tracker & Wiki]

#27130: rust dependency updating instructions don't work
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.9
 Severity:  Normal   | Resolution:
 Keywords:  rust, doc, 033-backport, |  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by cyberpunks):

 Changed the instructions around so that changes to `Cargo.lock` are always
 done one way, using `cargo update`, instead of sometimes with cargo update
 and sometimes with this script, depending.

 Also it turns out `cargo update` doesn't even work unless you remove
 `.cargo/config` first, since the settings there leave cargo only able to
 access the vendored sources and not the real registry. And there's no way
 to override source-replacements like that with environment variables.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27797 [Core Tor/Tor]: node: Make node_supports_v3_rendezvous_point() also check for the onion_pk

[Tor Bug Tracker & Wiki]

#27797: node: Make node_supports_v3_rendezvous_point() also check for the 
onion_pk
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-relay, 033-backport, |  Actual Points:
  034-backport   |
Parent ID:  #27774   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 032 branch: `ticket27797_032_01`
 The 035 branch merges without conflict on 033 and onward:
 `ticket27797_035_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] #27797 [Core Tor/Tor]: node: Make node_supports_v3_rendezvous_point() also check for the onion_pk

[Tor Bug Tracker & Wiki]

#27797: node: Make node_supports_v3_rendezvous_point() also check for the 
onion_pk
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-relay, 033-backport, |  Actual Points:
  034-backport   |
Parent ID:  #27774   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Backport candidate? if so, please make a branch based on 0.3.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] #27410 [Core Tor/Tor]: Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/or/hs_client.c:268

[Tor Bug Tracker & Wiki]

#27410: Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed 
in
retry_all_socks_conn_waiting_for_desc at ../src/or/hs_client.c:268
-+-
 Reporter:  cstest   |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.9
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, hs-v3, 032-backport, |  Actual Points:
  033-backport, 034-backport |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Okay -- i've merged both branches to master; marking the 0.3.2 one for
 possible backport.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27800 [Core Tor/Tor]: Non-fatal assertion !(old) failed in node_add_to_ed25519_map (was: assertion failed in nodelist.c)

[Tor Bug Tracker & Wiki]

#27800: Non-fatal assertion !(old) failed in node_add_to_ed25519_map
--+
 Reporter:  stefani   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * component:  Core Tor => Core Tor/Tor
 * priority:  Medium => High
 * milestone:   => Tor: 0.3.5.x-final
 * keywords:   => regression


Old description:

> this error showed up in my logs today:
>
> [warn] tor_bug_occurred_(): Bug: ../src/or/nodelist.c:297:
> node_add_to_ed25519_map: Non-fatal assertion !(old) failed. (on Tor
> 0.3.4.8 )
>  [warn] Bug: Non-fatal assertion !(old) failed in node_add_to_ed25519_map
> at ../src/or/nodelist.c:297. Stack trace: (on Tor 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(log_backtrace+0x44) [0x560fb19f0354] (on
> Tor 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x560fb1a0b2f9]
> (on Tor 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(+0x648b1) [0x560fb18cc8b1] (on Tor 0.3.4.8
> )
>  [warn] Bug: /usr/bin/tor(nodelist_set_routerinfo+0x13f)
> [0x560fb18ce9ef] (on Tor 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(+0x9d7ec) [0x560fb19057ec] (on Tor 0.3.4.8
> )
>  [warn] Bug: /usr/bin/tor(router_add_to_routerlist+0x814)
> [0x560fb190bb94] (on Tor 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(dirserv_add_descriptor+0x228)
> [0x560fb19aefa8] (on Tor 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(dirserv_add_multiple_descriptors+0x154)
> [0x560fb19af294] (on Tor 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(connection_dir_process_inbuf+0xabc)
> [0x560fb19a494c] (on Tor 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(connection_handle_read+0xa27)
> [0x560fb197d717] (on Tor 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(+0x53afe) [0x560fb18bbafe] (on Tor 0.3.4.8
> )
>  [warn] Bug: /usr/lib/x86_64-linux-
> gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fefd7df25a0] (on Tor
> 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(do_main_loop+0x265) [0x560fb18bde95] (on
> Tor 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(tor_run_main+0x1175) [0x560fb18c0685] (on
> Tor 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x560fb18b84ba] (on Tor
> 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(main+0x19) [0x560fb18b8229] (on Tor 0.3.4.8
> )
>  [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)
> [0x7fefd664e2e1] (on Tor 0.3.4.8 )
>  [warn] Bug: /usr/bin/tor(_start+0x2a) [0x560fb18b827a] (on Tor
> 0.3.4.8 )

New description:

 this error showed up in my logs today:

 (happened on the directory authority `bastet`)

 {{{
 [warn] tor_bug_occurred_(): Bug: ../src/or/nodelist.c:297:
 node_add_to_ed25519_map: Non-fatal assertion !(old) failed. (on Tor
 0.3.4.8 )
  [warn] Bug: Non-fatal assertion !(old) failed in node_add_to_ed25519_map
 at ../src/or/nodelist.c:297. Stack trace: (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(log_backtrace+0x44) [0x560fb19f0354] (on Tor
 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x560fb1a0b2f9] (on
 Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(+0x648b1) [0x560fb18cc8b1] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(nodelist_set_routerinfo+0x13f)
 [0x560fb18ce9ef] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(+0x9d7ec) [0x560fb19057ec] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(router_add_to_routerlist+0x814)
 [0x560fb190bb94] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(dirserv_add_descriptor+0x228)
 [0x560fb19aefa8] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(dirserv_add_multiple_descriptors+0x154)
 [0x560fb19af294] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(connection_dir_process_inbuf+0xabc)
 [0x560fb19a494c] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(connection_handle_read+0xa27)
 [0x560fb197d717] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(+0x53afe) [0x560fb18bbafe] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fefd7df25a0] (on Tor
 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(do_main_loop+0x265) [0x560fb18bde95] (on Tor
 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(tor_run_main+0x1175) [0x560fb18c0685] (on
 Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x560fb18b84ba] (on Tor
 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(main+0x19) [0x560fb18b8229] (on Tor 0.3.4.8
 )
  [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)
 [0x7fefd664e2e1] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(_start+0x2a) [0x560fb18b827a] (on Tor
 0.3.4.8 )
 }}}

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor 

[tor-bugs] #27800 [Core Tor]: assertion failed in nodelist.c

[Tor Bug Tracker & Wiki]

#27800: assertion failed in nodelist.c
--+--
 Reporter:  stefani   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor
  Version:  Tor: 0.3.4.8  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 this error showed up in my logs today:

 [warn] tor_bug_occurred_(): Bug: ../src/or/nodelist.c:297:
 node_add_to_ed25519_map: Non-fatal assertion !(old) failed. (on Tor
 0.3.4.8 )
  [warn] Bug: Non-fatal assertion !(old) failed in node_add_to_ed25519_map
 at ../src/or/nodelist.c:297. Stack trace: (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(log_backtrace+0x44) [0x560fb19f0354] (on Tor
 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x560fb1a0b2f9] (on
 Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(+0x648b1) [0x560fb18cc8b1] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(nodelist_set_routerinfo+0x13f)
 [0x560fb18ce9ef] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(+0x9d7ec) [0x560fb19057ec] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(router_add_to_routerlist+0x814)
 [0x560fb190bb94] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(dirserv_add_descriptor+0x228)
 [0x560fb19aefa8] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(dirserv_add_multiple_descriptors+0x154)
 [0x560fb19af294] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(connection_dir_process_inbuf+0xabc)
 [0x560fb19a494c] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(connection_handle_read+0xa27)
 [0x560fb197d717] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(+0x53afe) [0x560fb18bbafe] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fefd7df25a0] (on Tor
 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(do_main_loop+0x265) [0x560fb18bde95] (on Tor
 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(tor_run_main+0x1175) [0x560fb18c0685] (on
 Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x560fb18b84ba] (on Tor
 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(main+0x19) [0x560fb18b8229] (on Tor 0.3.4.8
 )
  [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)
 [0x7fefd664e2e1] (on Tor 0.3.4.8 )
  [warn] Bug: /usr/bin/tor(_start+0x2a) [0x560fb18b827a] (on Tor
 0.3.4.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] #27130 [Core Tor/Tor]: rust dependency updating instructions don't work

[Tor Bug Tracker & Wiki]

#27130: rust dependency updating instructions don't work
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.9
 Severity:  Normal   | Resolution:
 Keywords:  rust, doc, 033-backport, |  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by catalyst):

 Replying to [comment:12 cyberpunks]:
 > Replying to [comment:11 catalyst]:
 > > I just tried it.  It looks like I have to run `cargo update` to update
 `Cargo.lock` to a newer version of `libc`, and `cargo vendor` doesn't try
 to change it.
 >
 > Did you make any crate actually require a newer version of libc? That's
 in the instructions as the first step.
 Thanks, that seems to have helped.
 >
 > > To add/remove/update dependencies, first add your dependencies into
 the appropriate *crate-level* `Cargo.toml`
 >
 > If dependencies are being updated, it would be because there's a reason
 for it and you now require a new minimum version, right?
 As [comment:8 teor mentioned above], what if an older version of a
 dependency had bugs or security vulnerabilities?  Then we might want the
 newest compatible version without explicitly bumping the minimum version
 in `Cargo.toml`.
 > Pushed a commit to maybe make the instructions a bit clearer.
 Thanks.  Could you please also explain why someone might want to manually
 edit versions in `Cargo.toml` versus running `cargo update`?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24805 [Core Tor/Fallback Scripts]: Update fallback whitelist in late 2018

[Tor Bug Tracker & Wiki]

#24805: Update fallback whitelist in late 2018
-+-
 Reporter:  teor |  Owner:  phoul
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Fallback Scripts|Version:
 Severity:  Normal   | Resolution:
 Keywords:  fallback, 034-triage-20180328,   |  Actual Points:
  034-removed-20180328, 035-removed-20180711,|
  035-roadmap|
Parent ID:  #24786   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by phoul):

 Added new fallback dir at
 https://github.com/Phoul/tor/commit/bc68e80e0a801d498ce215de4a689c09927181df

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23512 [Core Tor/Tor]: Bandwidth stats info leak upon close of circuits with queued cells

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats info leak upon close of circuits with queued cells
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorQ
-+-

Comment (by nickm):

 bug23512-v4-029-fixes fixes some compilation errors that we ran into on
 master.

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

Re: [tor-bugs] #27740 [Core Tor/Tor]: rust protover_all_supported() returns rust-allocated string in *missing_out

[Tor Bug Tracker & Wiki]

#27740: rust protover_all_supported() returns rust-allocated string in 
*missing_out
--+
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cyberpunks):

 This needs the keywords `rust, protover, memory-safety`. You can't
 `tor_free()` a string allocated by rust code, which is what the C code
 will immediately try to do.

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

Re: [tor-bugs] #27782 [Core Tor/Tor]: nss: tor_tls_release_socket() won't catch invalid socket value

[Tor Bug Tracker & Wiki]

#27782: nss: tor_tls_release_socket() won't catch invalid socket value
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-nss   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged 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] #27795 [Core Tor/Tor]: Possible fd leak on 0.3.5.1-alpha

[Tor Bug Tracker & Wiki]

#27795: Possible fd leak on 0.3.5.1-alpha
---+
 Reporter:  dgoulet|  Owner:  nickm
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  regression, tor-relay  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * status:  needs_review => needs_information


Comment:

 fixed that and merged to master. Let's close this ticket if toralf and
 arma report that the error want away.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27739 [Core Tor/Tor]: rust protover_all_supported() accepts too-long protocol names

[Tor Bug Tracker & Wiki]

#27739: rust protover_all_supported() accepts too-long protocol names
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.6
 Severity:  Normal   | Resolution:
 Keywords:  035-must, protover, memory-safety,   |  Actual Points:
  033-backport, 034-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cyberpunks):

 This isn't a memory-safety issue is it? And this is missing the rust tag.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27194 [Core Tor/Tor]: handling extra commas in protover

[Tor Bug Tracker & Wiki]

#27194: handling extra commas in protover
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, security-low, 029-backport,|  Actual Points:
  032-backport, 033-backport, 034-backport   |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by cyberpunks):

 What revision is needed here now?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27795 [Core Tor/Tor]: Possible fd leak on 0.3.5.1-alpha

[Tor Bug Tracker & Wiki]

#27795: Possible fd leak on 0.3.5.1-alpha
---+
 Reporter:  dgoulet|  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  regression, tor-relay  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dgoulet):

 This lgtm except one thing (unrelated to the main issue at hands):

 * `tor_tls_release_socket()` for NSS, seems to have a possible fd leak if
 `PR_GetIdentitiesLayer()` fails that is we `BUG()` and immediately return
 but I think we should close the `sock`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27782 [Core Tor/Tor]: nss: tor_tls_release_socket() won't catch invalid socket value

[Tor Bug Tracker & Wiki]

#27782: nss: tor_tls_release_socket() won't catch invalid socket value
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-nss   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review


Comment:

 Fix in branch `bug27795_27782`; pull request at
 https://github.com/torproject/tor/pull/364 .  It also has a fix for
 #27795.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27795 [Core Tor/Tor]: Possible fd leak on 0.3.5.1-alpha

[Tor Bug Tracker & Wiki]

#27795: Possible fd leak on 0.3.5.1-alpha
---+
 Reporter:  dgoulet|  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  regression, tor-relay  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 Fix in branch `bug27795_27782`; pull request at
 https://github.com/torproject/tor/pull/364 .  It also has a fix for
 #27782.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27795 [Core Tor/Tor]: Possible fd leak on 0.3.5.1-alpha

[Tor Bug Tracker & Wiki]

#27795: Possible fd leak on 0.3.5.1-alpha
---+
 Reporter:  dgoulet|  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  High   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  regression, tor-relay  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * status:  new => accepted
 * owner:  (none) => nickm


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27795 [Core Tor/Tor]: Possible fd leak on 0.3.5.1-alpha

[Tor Bug Tracker & Wiki]

#27795: Possible fd leak on 0.3.5.1-alpha
---+
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  regression, tor-relay  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 moria1 is at 100% cpu too it turns out.

 I like nickm's theory above. We're all just going on the log message. My
 tor has nowhere near that many fd's open now. Everything seems to come
 apart once Tor hits that limit -- or once Tor thinks it hits that limit.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27795 [Core Tor/Tor]: Possible fd leak on 0.3.5.1-alpha

[Tor Bug Tracker & Wiki]

#27795: Possible fd leak on 0.3.5.1-alpha
---+
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  regression, tor-relay  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by toralf):

 * Attachment "warn.log.gz" added.

 kill -10 output of an exit relay (port 80/443) having usually ~ 4,000 OR
 connections and warning when it is reached 49967 connections

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

Re: [tor-bugs] #27795 [Core Tor/Tor]: Possible fd leak on 0.3.5.1-alpha

[Tor Bug Tracker & Wiki]

#27795: Possible fd leak on 0.3.5.1-alpha
---+
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  regression, tor-relay  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 wait. WHY do we think that this is leaking fds?  Is it because the OS says
 we're out of fds, or is it because of some log message?

 Because I think the problem might be that my fix for #24751 does not
 interact correctly with our socket accounting code in socket.c.  In that
 case, the sockets actually are getting closed, but Tor is not counting
 them as 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] #27325 [Core Tor/Tor]: Rework NETINFO cell parsing and generation with trunnel

[Tor Bug Tracker & Wiki]

#27325: Rework NETINFO cell parsing and generation with trunnel
-+-
 Reporter:  rl1987   |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  trunnel wireformat heartbleed-   |  Actual Points:
  safety security parsing|
Parent ID:  #27143   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by rl1987):

 * status:  new => accepted
 * owner:  (none) => rl1987


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27798 [Applications/Tor Browser]: example A B C circuit view

[Tor Bug Tracker & Wiki]

#27798: example A B C circuit view
--+--
 Reporter:  throwawsept2018   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by rl1987):

 * owner:  (none) => tbb-team
 * component:  - Select a component => Applications/Tor Browser


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

Re: [tor-bugs] #27740 [Core Tor/Tor]: rust protover_all_supported() returns rust-allocated string in *missing_out

[Tor Bug Tracker & Wiki]

#27740: rust protover_all_supported() returns rust-allocated string in 
*missing_out
--+
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * milestone:   => Tor: unspecified


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27797 [Core Tor/Tor]: node: Make node_supports_v3_rendezvous_point() also check for the onion_pk

[Tor Bug Tracker & Wiki]

#27797: node: Make node_supports_v3_rendezvous_point() also check for the 
onion_pk
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-relay, 033-backport, |  Actual Points:
  034-backport   |
Parent ID:  #27774   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * 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] #27410 [Core Tor/Tor]: Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/or/hs_client.c:268

[Tor Bug Tracker & Wiki]

#27410: Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed 
in
retry_all_socks_conn_waiting_for_desc at ../src/or/hs_client.c:268
-+-
 Reporter:  cstest   |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.9
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, hs-v3, 032-backport, |  Actual Points:
  033-backport, 034-backport |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by dgoulet):

 * keywords:  tor-hs, hs-v3 => tor-hs, hs-v3, 032-backport, 033-backport,
 034-backport


Comment:

 Replying to [comment:7 nickm]:
 > The changes file says it's a bugfix on 0.3.2.  Does this need a
 backport, or is it okay to fix it in 0.3.5 only and leave it broken for
 earlier releases?

 Oh good point! ...

 Here is the 032 branch: `ticket27410_032_01`. I haven't backported the
 unit test as that was a complicated thing to do! Many helper function went
 in since 032 and would take me a while to figure it out in 032.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27799 [Core Tor/Tor]: Split routerlist.c and dirserv.c into smaller modules

[Tor Bug Tracker & Wiki]

#27799: Split routerlist.c and dirserv.c into smaller modules
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 Made requested changes and 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] #27799 [Core Tor/Tor]: Split routerlist.c and dirserv.c into smaller modules

[Tor Bug Tracker & Wiki]

#27799: Split routerlist.c and dirserv.c into smaller modules
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 I think this is great. Some questions:

 I would be consistent on a file name that have `_fmt` for which it should
 be either at the start or end, doesn't matter, just that we have the same
 standard for all files.

 {{{
 fmt_serverstatus.c
 routerstatus_fmt.c
 }}}

 The other thing that confuses me is:

 {{{
   * recv_descs.c handles fingerprint files and processing incoming
 routerinfos that relays upload to us
 }}}

 The `recv_descs.c` file name seems to suggest to me that it is about
 receiving descriptors, not "handling" them per se. I would suggest using
 something around the lines of `handle_desc.c` or using the term "decision"
 somehow to show that the code in that file is about decision making of
 descriptors, not parsing, not I/O, not storing or "receiving".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27139 [Core Tor/Tor]: macOS i386 fails time unit tests

[Tor Bug Tracker & Wiki]

#27139: macOS i386 fails time unit tests
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  regression, macos, i386, |  Actual Points:
  034-backport, arm32, 32-bit|
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Okay, merged to 0.3.4 and forward!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27410 [Core Tor/Tor]: Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/or/hs_client.c:268

[Tor Bug Tracker & Wiki]

#27410: Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed 
in
retry_all_socks_conn_waiting_for_desc at ../src/or/hs_client.c:268
---+
 Reporter:  cstest |  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.3.9
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, hs-v3  |  Actual Points:
Parent ID: | Points:
 Reviewer:  asn|Sponsor:
---+

Comment (by nickm):

 The changes file says it's a bugfix on 0.3.2.  Does this need a backport,
 or is it okay to fix it in 0.3.5 only and leave it broken for earlier
 releases?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27799 [Core Tor/Tor]: Split routerlist.c and dirserv.c into smaller modules

[Tor Bug Tracker & Wiki]

#27799: Split routerlist.c and dirserv.c into smaller modules
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:  dgoulet
  Sponsor:|
--+
 These are a couple of the biggest modules in Tor, and they have a bunch of
 responsibilities each.

 Per discussion, we're going to try to put more code movement into 0.3.5,
 to reduce the number of code-movement releases we need to merge across.

 See branch `split_routerlist_dirserv` with PR at
 https://github.com/torproject/tor/pull/363 .

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27799 [Core Tor/Tor]: Split routerlist.c and dirserv.c into smaller modules

[Tor Bug Tracker & Wiki]

#27799: Split routerlist.c and dirserv.c into smaller modules
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

 * status:  assigned => 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] #27130 [Core Tor/Tor]: rust dependency updating instructions don't work

[Tor Bug Tracker & Wiki]

#27130: rust dependency updating instructions don't work
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.9
 Severity:  Normal   | Resolution:
 Keywords:  rust, doc, 033-backport, |  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by cyberpunks):

 Replying to [comment:11 catalyst]:
 > I just tried it.  It looks like I have to run `cargo update` to update
 `Cargo.lock` to a newer version of `libc`, and `cargo vendor` doesn't try
 to change it.

 Did you make any crate actually require a newer version of libc? That's in
 the instructions as the first step.

 > To add/remove/update dependencies, first add your dependencies into the
 appropriate *crate-level* `Cargo.toml`

 If dependencies are being updated, it would be because there's a reason
 for it and you now require a new minimum version, right?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27750 [Core Tor/Tor]: conn_close_if_marked: Non-fatal assertion !(connection_is_writing(conn))

[Tor Bug Tracker & Wiki]

#27750: conn_close_if_marked: Non-fatal assertion !(connection_is_writing(conn))
+
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.4.8
 Severity:  Normal  | Resolution:
 Keywords:  regression, assert  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by udo):

 I closed all open ports to see if that 'fixes' the issue (makes it not
 appear anymore).
 I.e.: relay-only for now.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27798 [- Select a component]: example A B C circuit view

[Tor Bug Tracker & Wiki]

#27798: example A B C circuit view
-+--
 Reporter:  throwawsept2018  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  - Select a component
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 I copy tor browser 8.0 to ram disk. There are no disk leaks on ram disk.

 Circuit view is broken after copy. Example A, B, C.
 I set extensions.torbutton.loglevel 1. I get this log:

 Torbutton INFO: This is not a Tor Browser: TypeError: m_tb_prefs is
 undefined
 TypeError: m_tb_prefs is undefined[Learn More]  torbutton.js:348:1
 torbutton_init chrome://torbutton/content/torbutton.js:348:1

 I start tor browser again. circuit view works. Please fix first time
 broken circuit view.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27774 [Core Tor/Tor]: hs-v3: Assertion onion_pk failed in introduce1_set_encrypted_onion_key

[Tor Bug Tracker & Wiki]

#27774: hs-v3: Assertion onion_pk failed in introduce1_set_encrypted_onion_key
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.9
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Branch: `ticket27774_035_02`
 PR: https://github.com/torproject/tor/pull/362

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27797 [Core Tor/Tor]: node: Make node_supports_v3_rendezvous_point() also check for the onion_pk

[Tor Bug Tracker & Wiki]

#27797: node: Make node_supports_v3_rendezvous_point() also check for the 
onion_pk
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-relay, 033-backport, |  Actual Points:
  034-backport   |
Parent ID:  #27774   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  new => needs_review
 * cc: asn (added)


Comment:

 Branch: `ticket27797_035_01`
 PR: https://github.com/torproject/tor/pull/361

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27662 [Core Tor/Tor]: refactor networkstatus_parse_vote_from_string()

[Tor Bug Tracker & Wiki]

#27662: refactor networkstatus_parse_vote_from_string()
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, refactor, long-  |  Actual Points:
  functions, cthulhucode |
Parent ID:  #22408   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cyberpunks):

 What revision is needed 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] #27797 [Core Tor/Tor]: node: Make node_supports_v3_rendezvous_point() also check for the onion_pk

[Tor Bug Tracker & Wiki]

#27797: node: Make node_supports_v3_rendezvous_point() also check for the 
onion_pk
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-hs, tor-relay, 033-backport,
 Severity:  Normal   |  034-backport
Actual Points:   |  Parent ID:  #27774
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Turns out that we think this is related to #27774.

 A client selects a v3 RP by only looking at the protover but it is
 possible that at that time we simply don't have the descriptor yet thus
 missing the `onion_pk` which led to a failure when sending the INTRODUCE1
 cell.

 Like `node_supports_ed25519_link_authentication()` does, we should simply
 check for the `onion_pk` as an extra step to the protover.

 Flagging this for backport.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27795 [Core Tor/Tor]: Possible fd leak on 0.3.5.1-alpha

[Tor Bug Tracker & Wiki]

#27795: Possible fd leak on 0.3.5.1-alpha
---+
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  regression, tor-relay  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 The leading theory from yesterday is that something went wrong with my
 code for #24751, which affects how we close OR connections. But we
 couldn't find the bug.

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

[tor-bugs] #27796 [Applications/Tor Browser]: removed style does not work

[Tor Bug Tracker & Wiki]

#27796: removed style does not work
--+--
 Reporter:  cypherpunks3  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Applications/Tor Browser
  Version:|   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Exception that sometime it works OK but it depends on the website if it
 works the first time it works always but other webstie is breaken!
 version 7 is correct function

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27795 [Core Tor/Tor]: Possible fd leak on 0.3.5.1-alpha

[Tor Bug Tracker & Wiki]

#27795: Possible fd leak on 0.3.5.1-alpha
---+
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  regression, tor-relay  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27795 [Core Tor/Tor]: Possible fd leak on 0.3.5.1-alpha

[Tor Bug Tracker & Wiki]

#27795: Possible fd leak on 0.3.5.1-alpha
--+---
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  regression, tor-relay
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 It has been reported by toralf and moria1 so far that their relay ran out
 of file descriptor.

 toralf's relay ended up in 100% CPU situation whereas I believe moria1
 stopped working properly as a dirauth.

 The DoS status was normal so the winning theory so far is a FD leak in
 035.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27410 [Core Tor/Tor]: Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/or/hs_client.c:268

[Tor Bug Tracker & Wiki]

#27410: Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed 
in
retry_all_socks_conn_waiting_for_desc at ../src/or/hs_client.c:268
---+
 Reporter:  cstest |  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.3.9
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, hs-v3  |  Actual Points:
Parent ID: | Points:
 Reviewer:  asn|Sponsor:
---+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Great stuff. LGTM!

 FWIW, I made PR about this because it's easy and I wanted CI and coveralls
 to run:
 https://github.com/torproject/tor/pull/360

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27794 [Core Tor/Tor]: Apparmor profile whitelist /etc/torrc.d/ and /usr/local/etc/torrc.d/

[Tor Bug Tracker & Wiki]

#27794: Apparmor profile whitelist /etc/torrc.d/ and /usr/local/etc/torrc.d/
---+--
 Reporter:  adrelanos  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Core Tor/Tor
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 > [warn] Could not open "/etc/torrc.d/40_tor_control_panel.conf":
 Permission denied

 Please allow in apparmor profile by default:

 * /etc/torrc.d/ r,
 * /usr/local/etc/torrc.d/ r,

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27784 [Core Tor/Chutney]: chutney/tools/test-network.sh works fine but failing transmission!

[Tor Bug Tracker & Wiki]

#27784: chutney/tools/test-network.sh works fine but failing transmission!
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sreenivassadhu@…):

 * Attachment "nodes.1537347299.rar" added.

 log

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27783 [Core Tor/Chutney]: Chutney: Authorities are getting created but relays are not getting configured!

[Tor Bug Tracker & Wiki]

#27783: Chutney: Authorities are getting created but relays are not getting
configured!
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sreenivassadhu@…):

 Thanks for the response!

 (I don't think there is anything wrong with your resolv.conf file. That
 message is for your information. It is not an error or a warning.)

 Because of this, relays are not getting configured! Authorities and nodes
 are getting created! Relay DNS is the local host and its mentioned in
 resolve.conf file.
 Why its using  '/etc/resolv.conf' file? We have got resolve.conf in
 Chutney itself!

 I will try with minimal nos i.e 2,5,8 respectively!

 Pls help

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27784 [Core Tor/Chutney]: chutney/tools/test-network.sh works fine but failing transmission!

[Tor Bug Tracker & Wiki]

#27784: chutney/tools/test-network.sh works fine but failing transmission!
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 > Can you attach a compressed tar archive of
 /home/aakanksha/chutney/tools/./../net/nodes.1537347299 to this ticket?
 > It has all the detailed logs.

 I need to see the detailed logs to help 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] #25687 [Core Tor/Tor]: over-report of observed / self-measure bandwidth on fast hardware -- important to torflow / peerflow

[Tor Bug Tracker & Wiki]

#25687: over-report of observed / self-measure bandwidth  on fast hardware --
important to torflow / peerflow
-+-
 Reporter:  starlight|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, needs-research, needs-   |  Actual Points:
  proposal?  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * Attachment "20180920_060844_sbws_2nd sbws.png" 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] #27783 [Core Tor/Chutney]: Chutney: Authorities are getting created but relays are not getting configured!

[Tor Bug Tracker & Wiki]

#27783: Chutney: Authorities are getting created but relays are not getting
configured!
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 > what configuration else is required in resolv.conf file? other than
 provided in the Chutney!?

 I don't think there is anything wrong with your resolv.conf file. That
 message is for your information. It is not an error or a warning.

 When you configure chutney, all the keys are created, and then the script
 exits successfully.

 > NODES = Authority.getN(10) + ExitRelay.getN(50) + Client.getN(100)

 To run 160 nodes, you will need at least 2*160*160 = 51200 file
 descriptors on your machine, 10s of gigabytes of RAM, and tens or hundreds
 of CPU cores.

 Depending on your machine, you might be able to run 10 or 20 nodes using
 chutney.

 If you need to run a network with hundreds of tor instances, try shadow at
 https://shadow.github.io

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25687 [Core Tor/Tor]: over-report of observed / self-measure bandwidth on fast hardware -- important to torflow / peerflow

[Tor Bug Tracker & Wiki]

#25687: over-report of observed / self-measure bandwidth  on fast hardware --
important to torflow / peerflow
-+-
 Reporter:  starlight|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, needs-research, needs-   |  Actual Points:
  proposal?  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 Replying to [comment:16 teor]:
 > Replying to [comment:15 starlight]:

 > > Of course.  Mentioned this because the SBWS patch candidates I read
 implement the behavior, though perhaps this has changed since I looked.
 If the logic is present suggest having a consensus parameter to determine
 whether or not the behavior is in force.  Best of luck!
 >
 > Oh right, maybe I'm wrong then.
 >
 > Juga, does sbws implement torflow's "filtered"option?

 yes, i did [0], since we wanted sbws to be able to behave like torflow
 (and it does [1]) to later decide which scaling algorithm we should have.
 The filtered option doesn't change much, since torflow is taking the
 maximum between that and the stream bandwidth. See the attached graph.
 The point i was trying to make in #comment:11 is:
 - we need to come out with a better algorithm that takes into account
 differently observed bandwidth and measured bandwidth. Measured bandwidth
 has little value in Torflow.
 - we (/i) might need to review how observed bandwidth is obtained
 I think i'll be able to explain this better in a week, since these
 comments get messy across tickets (my fault)

 [0]
 https://github.com/torproject/sbws/blob/master/sbws/lib/v3bwfile.py#L762
 [1]
 
https://trac.torproject.org/projects/tor/attachment/ticket/27338/20180905_092840_torflow_sbws.png

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #6623 [Core Tor/Tor]: --enable-static-tor cannot succeed

[Tor Bug Tracker & Wiki]

#6623: --enable-static-tor cannot succeed
-+-
 Reporter:  tmpname0901  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.20-rc
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay autotools build link   |  Actual Points:
  static 029-backport 032-backport 033-backport  |
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  tor-relay autotools build link static =>
 tor-relay autotools build link static 029-backport 032-backport
 033-backport 034-backport
 * milestone:  Tor: unspecified => Tor: 0.3.5.x-final


Comment:

 I am not sure whether to put this fix in 0.3.5 or 0.3.6, but it would be
 nice to have a working static binary in our LTS release.

 It might also be good to backport these fixes, if they aren't too big,

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