Re: [tor-bugs] #31510 [Core Tor/Stem]: Stem install test errors: cached_tor_manual and arm.* image

[Tor Bug Tracker & Wiki]

#31510: Stem install test errors: cached_tor_manual and arm.* image
---+---
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Maybe these files are left over from old builds, and the clean step is
 broken?
 I will check when I am back at my build machine.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31458 [Applications/Tor Browser]: Facilitate getting the widl fixes from wine into mingw and update the mingw-w64 project in tor-browser-build once they are in

[Tor Bug Tracker & Wiki]

#31458: Facilitate getting the widl fixes from wine into mingw and update the
mingw-w64 project in tor-browser-build once they are in
-+-
 Reporter:  pospeselr|  Owner:
 |  pospeselr
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201908R, tbb-9.0   |  Actual Points:
  -must-alpha|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good, thanks! I cherry-picked your patch to `master` (commit
 89e6eed8ce459dfeae17ce886f35df209760965c) and adapted the commit message a
 bit.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31545 [Core Tor/Tor]: CID 1452819: nul-terminated string handling, possibly spurious

[Tor Bug Tracker & Wiki]

#31545: CID 1452819: nul-terminated string handling, possibly spurious
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core |Version:  Tor: unspecified
  Tor/Tor|   Keywords:  042-must, memory-safety?, easy,
 Severity:  Normal   |  intro, ipv6, logging, fast-fix
Actual Points:   |  Parent ID:
   Points:  0.1  |   Reviewer:
  Sponsor:   |
  Sponsor27-must |
-+-
 Bug introduced by #21003, copying sponsors and tags.

 {{{
 /src/feature/nodelist/describe.c: 77 in format_node_description()
 71   }
 72   if (addr32h && has_addr) {
 73 memcpy(cp, " and ", 5);
 74 cp += 5;
 75   }
 76   if (has_addr) {
CID 1452819:(STRING_NULL)
Passing unterminated string "cp" to "tor_addr_to_str", which expects a
 null-terminated string.
 77 tor_addr_to_str(cp, addr, TOR_ADDR_BUF_LEN, 1);
 78   }
 79
 80   return buf;
 81 }
 82
 /src/feature/nodelist/describe.c: 70 in format_node_description()
 64 cp += 4;
 65   }
 66   if (addr32h) {
 67 struct in_addr in;
 68 in.s_addr = htonl(addr32h);
 69 tor_inet_ntoa(&in, cp, INET_NTOA_BUF_LEN);
CID 1452819:(STRING_NULL)
Passing unterminated string "cp" to "strlen", which expects a null-
 terminated string.
 70 cp += strlen(cp);
 71   }
 72   if (addr32h && has_addr) {
 73 memcpy(cp, " and ", 5);
 74 cp += 5;
 75   }
 }}}

 I think the best fix for this issue is using strncpy() rather than
 memcpy().

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31078 [Core Tor/Tor]: improve docs for config var abstraction

[Tor Bug Tracker & Wiki]

#31078: improve docs for config var abstraction
--+
 Reporter:  catalyst  |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29211| Points:  2
 Reviewer:|Sponsor:  Sponsor31-can
--+
Changes (by teor):

 * owner:  (none) => nickm
 * status:  new => assigned
 * milestone:  Tor: unspecified => Tor: 0.4.2.x-final


Comment:

 These changes need to be done (or at least triaged) before we continue
 work on #29211.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31532 [Core Tor/Tor]: Use ptrdiff_t for struct_member_t.offset, etc

[Tor Bug Tracker & Wiki]

#31532: Use ptrdiff_t for struct_member_t.offset, etc
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:
Parent ID:  #29211   | Points:
 Reviewer:   |Sponsor:  Sponsor31-can
-+-
Changes (by teor):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31542 [Core Tor/Tor]: Cannot connect to IPv6 addresses using Tor SOCKS

[Tor Bug Tracker & Wiki]

#31542: Cannot connect to IPv6 addresses using Tor SOCKS
--+
 Reporter:  sega01|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  042-should, ipv6  |  Actual Points:
Parent ID:  #26664| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_information => new
 * parent:   => #26664


Comment:

 Yeah, there's definitely some bug here, see the children of #26664 for
 similar bugs.

 I've put #26664 on our IPv6 roadmap.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #11625 [Core Tor/Tor]: Tor DNSPORT returns NXDOMAIN for AAAA records?

[Tor Bug Tracker & Wiki]

#11625: Tor DNSPORT returns NXDOMAIN for  records?
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.5.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, dns, exit-node-choice,   |  Actual Points:
  ipv6   |
Parent ID:  #26664   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #26664


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:
 |  cypherpunks
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:  1000
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 = Hey folks let’s use Cloudflare! =
 = https://www.cloudflare.com/ =

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

Re: [tor-bugs] #31543 [Core Tor/Tor]: Add unit tests or chutney tests for IPv6Traffic

[Tor Bug Tracker & Wiki]

#31543: Add unit tests or chutney tests for IPv6Traffic
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  042-should, ipv6  |  Actual Points:
Parent ID:  #26664| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:  #31542 => #26664


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30182 [Core Tor/Chutney]: IPv6 Exits succeed on Travis Linux, but Travis Linux doesn't support IPv6

[Tor Bug Tracker & Wiki]

#30182: IPv6 Exits succeed on Travis Linux, but Travis Linux doesn't support 
IPv6
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  chutney-ci, ipv6  |  Actual Points:
Parent ID:  #26664| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:  #30208 => #26664


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26664 [Core Tor/Tor]: When an exit tells a client about an IPv6-only hostname, the client should choose another IPv6 exit

[Tor Bug Tracker & Wiki]

#26664: When an exit tells a client about an IPv6-only hostname, the client 
should
choose another IPv6 exit
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6 tor-client tor-exit  |  Actual Points:
Parent ID:  #17011| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * parent:  #17811 => #17011


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24833 [Core Tor/Tor]: DNS not reliably returning AAAA records

[Tor Bug Tracker & Wiki]

#24833: DNS not reliably returning  records
-+-
 Reporter:  Zakhar   |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.14
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-client, tor-exit, tor- |  Actual Points:
  dns, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:  #26664   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #26664


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31494 [Core Tor/Tor]: config refactoring: follow-ups from merged commits

[Tor Bug Tracker & Wiki]

#31494: config refactoring: follow-ups from merged commits
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  task | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:
Parent ID:  #29211   | Points:
 Reviewer:   |Sponsor:  Sponsor31-must
-+-

Comment (by teor):

 https://trac.torproject.org/projects/tor/ticket/30935#comment:7

 Do we have tests that read in whole torrc, state, and SR files, then write
 them out again, and make sure they are unchanged?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31516 [Core Tor/Tor]: config refactor: every function table entry should be documented and unit tested (was: config refactor: every function table entry should be unit tested)

[Tor Bug Tracker & Wiki]

#31516: config refactor: every function table entry should be documented and 
unit
tested
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:
Parent ID:  #29211   | Points:
 Reviewer:   |Sponsor:  Sponsor31-must
-+-
Description changed by teor:

Old description:

> We've added a lot of function tables, but some of their entries are all
> NULL, everywhere in the code.
>
> So even if it looks like we have 100% coverage, we're not testing these
> code paths.
>
> Ideally, we should have non-trivial functions, which do the thing that
> the function table entry is mean to do.

New description:

 We've added a lot of function tables, but some of their entries are all
 NULL, everywhere in the code.

 So even if it looks like we have 100% coverage, we're not testing these
 code paths.

 Ideally, we should have non-trivial functions, which do the thing that the
 function table entry is mean to do.

 Edited to add:

 Also, function table types should be documented with the same level of
 detail as regular functions. Each argument should have a type, name?, and
 description.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31240 [Core Tor/Tor]: Make confparse able to handle multiple config_format_t objects at once

[Tor Bug Tracker & Wiki]

#31240: Make confparse able to handle multiple config_format_t objects at once
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:  3
Parent ID:  #29211   | Points:  3
 Reviewer:  teor |Sponsor:  Sponsor31-can
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 This commit message typo blocks merging this branch:
 https://github.com/nmathewson/tor/pull/3#discussion_r317549159

 {{{
 commit 94bfbf7859
 Author: Nick Mathewson 
 Date:   Tue Jul 23 10:41:57 2019 -0400

 Use special magic to enforce manager/object connection.

 Every time we finalize a config manager, we now generate a new magic
 number for it, so that we'll get an assertion failure if we ever two
 to use an object with a different configuration manager than the one
 that generated it.
 }}}

 I have tried to guess the commits that fix these issues, but I'd like you
 to confirm on the PR:

 Please add runtime magic generation uniqueness tests:
 https://github.com/nmathewson/tor/pull/3#discussion_r317550341

 Please add subconfig tests:
 https://github.com/nmathewson/tor/pull/3#discussion_r317552964

 Do we need unit tests that have non-managed fields?
 https://github.com/nmathewson/tor/pull/3#discussion_r317553659

 There aren't any tests that use a clear callback. Please add some.
 https://github.com/nmathewson/tor/pull/3#discussion_r317554429

 This CI build hung:

 https://ci.appveyor.com/project/nmathewson/tor/builds/26996434
 Let's check both torproject and nmathewson CI again after the fixes listed
 above.

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

Re: [tor-bugs] #31542 [Core Tor/Tor]: Cannot connect to IPv6 addresses using Tor SOCKS

[Tor Bug Tracker & Wiki]

#31542: Cannot connect to IPv6 addresses using Tor SOCKS
--+
 Reporter:  sega01|  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  042-should, ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by sega01):

 There were a ton of logs going on even without trying to generate
 activity, maybe from other connections (although I didn't think I had
 anything using it). I think most of those logs had nothing to do with this
 issue (and it was also connecting over Tor already, so that may be partly
 why).

 The issue with part-time IPv6 working (one in 20%) is with DNS. With the
 TransPort/iptables setup, IPv6 basically works 100% of the time for me.
 But I get maybe 20% of DNS to IPv6 only requests to go through.

 I did about 10 with PreferIPv6 and IPv6Traffic on. None of them worked.

 If I hit an IPv6 only hostname, it will work maybe 20% of the time. So
 IPv6 isn't totally broken, even over SOCKS.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31544 [Core Tor/Tor]: sr: Check why some sr_disk_state fields need to be cleared

[Tor Bug Tracker & Wiki]

#31544: sr: Check why some sr_disk_state fields need to be cleared
--+-
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  network-team-roadmap-august
Actual Points:|  Parent ID:  #29211
   Points:|   Reviewer:
  Sponsor:|
--+-
 Split off #31240:

 teor: When we add fields, how will we make sure we remember to clear them
 all?

 nickm: We don't need to do so in general, the manager will take care of it
 for us. This is only necessary for derived fields, and fields for which
 the unit tests are expecting an unusual behavior, IIRC.

 nickm: (I can dig deeper here; I forget the exact reason why this function
 is clearing these, but I think it is because of legacy cruft.)

 teor: Yeah let's double-check what's going on here.



 https://github.com/nmathewson/tor/pull/3#discussion_r317548828

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31542 [Core Tor/Tor]: Cannot connect to IPv6 addresses using Tor SOCKS

[Tor Bug Tracker & Wiki]

#31542: Cannot connect to IPv6 addresses using Tor SOCKS
--+
 Reporter:  sega01|  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  042-should, ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I can't see anything obvious, but the exit does seem to be closing the
 connection.

 Try connecting to the same IPv6 address a few times.
 Only 20% of the exits support IPv6, and Tor will try 3 exits.
 So raw IPv6 will fail about half the time.

 Also try setting PreferIPv6 on your SOCKSPort:

  IPv6Traffic

 Tell exits to allow IPv6 addresses in response to SOCKS requests on
 this connection, so long as SOCKS5 is in use. (SOCKS4 can’t handle IPv6.)

 PreferIPv6

 Tells exits that, if a host has both an IPv4 and an IPv6 address, we
 would prefer to connect to it via IPv6. (IPv4 is the default.)

 https://2019.www.torproject.org/docs/tor-manual.html.en

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31542 [Core Tor/Tor]: Cannot connect to IPv6 addresses using Tor SOCKS

[Tor Bug Tracker & Wiki]

#31542: Cannot connect to IPv6 addresses using Tor SOCKS
--+
 Reporter:  sega01|  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  042-should, ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by sega01):

 At the top of my ticket I have my complete configuration.

 If I add "Log notice stderr", I get nothing extra when I try to connect.

 If I add "Log info stderr", I get this.

 {{{
 Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info]
 connection_handle_listener_read(): New SOCKS connection opened from [::1].
 Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info]
 add_predicted_port(): New port prediction added. Will continue predictive
 circ building for 2619 more seconds.
 Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info]
 connection_edge_process_inbuf(): data from edge while in 'waiting for
 circuit' state. Leaving it on buffer.
 Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info]
 exit circ (length 3): $AF9E103026FBCB20179233D293C4982665D2A01C(open)
 $4E98AA295B7171996D18DD1F6A19F64AB4036B4A(open)
 $96E095D5CDBFC3988DEB708EC155346472402C32(open)
 Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info]
 link_apconn_to_circ(): Looks like completed circuit to [scrubbed] does
 allow optimistic data for connection to [scrubbed]
 Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info]
 connection_ap_handshake_send_begin(): Sending relay cell 0 on circ
 3481194959 to begin stream 48431.
 Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info]
 connection_ap_handshake_send_begin(): Address/port sent, ap socket 16,
 n_circ_id 3481194959
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 circuit_predict_and_launch_new(): Have 7 clean circs need another
 buildtime test circ.
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 choose_good_exit_server_general(): Found 992 servers that might support
 0/0 pending connections.
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 compute_weighted_bandwidths(): Empty routerlist passed in to consensus
 weight node selection for rule weight as exit
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 choose_good_exit_server_general(): Chose exit server
 '$6FB41ED1D68FCC399DCE81600CE30360DCFFE263~Unnamed at 62.210.37.82'
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 extend_info_from_node(): Including Ed25519 ID for
 $6FB41ED1D68FCC399DCE81600CE30360DCFFE263~Unnamed at 62.210.37.82
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 select_primary_guard_for_circuit(): Selected primary guard zwiuhel
 ($AF9E103026FBCB20179233D293C4982665D2A01C) for circuit.
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 extend_info_from_node(): Including Ed25519 ID for
 $AF9E103026FBCB20179233D293C4982665D2A01C~zwiuhel at 95.216.203.16
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 extend_info_from_node(): Including Ed25519 ID for
 $E6C04728E9339DF22F331B7017D4A7AA3F252F0B~malekalcom at 149.202.208.203
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 circuit_send_first_onion_skin(): First hop: finished sending CREATE cell
 to '$AF9E103026FBCB20179233D293C4982665D2A01C~zwiuhel at 95.216.203.16'
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 command_process_relay_cell(): circuit_receive_relay_cell (backward)
 failed. Closing.
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 circuit_mark_for_close_(): Circuit 3481194959 (id: 12) marked for close at
 ../src/core/or/command.c:582 (orig reason: 1, new reason: 0)
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 connection_edge_destroy(): CircID 0: At an edge. Marking connection for
 close.
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 circuit_free_(): Circuit 0 (id: 12) has been freed.
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 circuit_finish_handshake(): Finished building circuit hop:
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 exit circ (length 3, last hop Unnamed):
 $AF9E103026FBCB20179233D293C4982665D2A01C(open)
 $E6C04728E9339DF22F331B7017D4A7AA3F252F0B(closed)
 $6FB41ED1D68FCC399DCE81600CE30360DCFFE263(closed)
 Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info]
 circuit_send_intermediate_onion_ski

[tor-bugs] #31543 [Core Tor/Tor]: Add unit tests or chutney tests for IPv6Traffic

[Tor Bug Tracker & Wiki]

#31543: Add unit tests or chutney tests for IPv6Traffic
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Normal|   Keywords:  042-should, ipv6
Actual Points:|  Parent ID:  #31542
   Points:|   Reviewer:
  Sponsor:|
--+
 In #31542 we broke IPv6Traffic. Let's add tests to make sure we don't
 break it again.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31542 [Core Tor/Tor]: Cannot connect to IPv6 addresses using Tor SOCKS

[Tor Bug Tracker & Wiki]

#31542: Cannot connect to IPv6 addresses using Tor SOCKS
--+
 Reporter:  sega01|  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  042-should, ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  042-should, 041-regression?, ipv6 => 042-should, ipv6


Comment:

 What are your log configuration lines?

 There should be notice level logs for connection failures.
 But some logs are at info level.
 Can you copy and paste info-level logs from these failures?

 Do 0.3.5 or 0.2.9 have this bug?

 I'll open a child ticket, so we add tests to make sure 5is issue doesn't
 happen again.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30665 [Applications/Tor Browser]: Get Firefox 68 ESR Working with latest android toolchain

[Tor Bug Tracker & Wiki]

#30665: Get Firefox 68 ESR Working with latest android toolchain
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by sisbell):

 I have branch esr68_0827. This is based off of 9.0-3 branch.

 Branch esr68_0827-patched is based off of
 https://git.torproject.org/user/sysrqb/tor-browser.git :
 2dbb7aefeaeb0499ac69c67df470e2ed6df8cb71.

 Overall it looks very good. The patched branch builds and I tested the
 armv7 apk on Android Q. Tor starts and I'm able to access an external
 site.

 Note the following:
 * I provided the android-jsocks.patch which removes the jsocks.aar
 dependency. This is only used for VPN support, which we don't need. I
 broke out the tor-android-service VPN code into its own module, which we
 now exclude from browser builds. This patch can be removed once a similar
 change is made in firefox code.
 * --disable-tor-browser-update does not work in this build so I removed it
 from mozconfig until support is added.
 * network is enabled for the container but I added --offline flag to
 gradle so its can only use our maven cache. I confirmed that nothing
 gradle-related is downloading in the current build.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31542 [Core Tor/Tor]: Cannot connect to IPv6 addresses using Tor SOCKS

[Tor Bug Tracker & Wiki]

#31542: Cannot connect to IPv6 addresses using Tor SOCKS
---+---
 Reporter:  sega01 |  Owner:  (none)
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.4.1.5
 Severity:  Normal | Resolution:
 Keywords:  042-should, 041-regression?, ipv6  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by sega01):

 Thanks for getting back to me!

 There were no notice logs generated (mind you, with my configuration but I
 think I normally get those) from the Tor client.

 I am not sure which one worked last. That said, I know 4.0.5 has the same
 issue. And 4.0.5 and 4.1.5 both work fine with IPv6 using TransPort.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31542 [Core Tor/Tor]: Cannot connect to IPv6 addresses using Tor SOCKS

[Tor Bug Tracker & Wiki]

#31542: Cannot connect to IPv6 addresses using Tor SOCKS
---+---
 Reporter:  sega01 |  Owner:  (none)
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.4.1.5
 Severity:  Normal | Resolution:
 Keywords:  042-should, 041-regression?, ipv6  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  new => needs_information
 * keywords:   => 042-should, 041-regression?, ipv6
 * milestone:   => Tor: 0.4.2.x-final


Comment:

 Can you copy and paste your notice level Tor logs for the IPv6 failures?

 What is the last tor version that worked with IPv6?
 0.4.0, 0.3.5, or 0.2.9?

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

Re: [tor-bugs] #31455 [Circumvention/meek]: Redeploy meek-server instances using Go 1.11.13+ / 1.12.8+

[Tor Bug Tracker & Wiki]

#31455: Redeploy meek-server instances using Go 1.11.13+ / 1.12.8+
+--
 Reporter:  dcf |  Owner:  inf0
 Type:  defect  | Status:  assigned
 Priority:  High|  Milestone:
Component:  Circumvention/meek  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by dcf):

 * owner:  phw => inf0


Old description:

> These versions fix a denial-of-service vulnerability in the HTTP/2 server
> code.
>
> https://groups.google.com/d/msg/golang-announce/65QixT3tcmg/DrFiG6vvCwAJ
> > We have just released Go 1.12.8 and Go 1.11.13 to address recently
> reported security issues. We recommend that all users update to one of
> these releases (if you’re not sure which, choose Go 1.12.8).
> > * net/http: Denial of Service vulnerabilities in the HTTP/2
> implementation
> >
> >   net/http and golang.org/x/net/http2 servers that accept direct
> connections from untrusted clients could be remotely made to allocate an
> unlimited amount of memory, until the program crashes. Servers will now
> close connections if the send queue accumulates too many control
> messages.
> >
> >   The issues are CVE-2019-9512 and CVE-2019-9514, and Go issue
> [https://golang.org/issue/33606 golang.org/issue/33606].
> >
> >   This is also fixed in version v0.0.0-20190813141303-74dc4d7220e7 of
> golang.org/x/net/http2.
> >
> > * net/url: parsing validation issue
> >
> >   url.Parse would accept URLs with malformed hosts, such that the Host
> field could have arbitrary suffixes that would appear in neither
> Hostname() nor Port(), allowing authorization bypasses in certain
> applications. Note that URLs with invalid, not numeric ports will now
> return an error from url.Parse.
> >
> >   The issue is CVE-2019-14809 and Go issue
> [https://golang.org/issue/29098 golang.org/issue/29098].
>
> We need to redeploy the following servers:
>  * cymrubridge02 (backend for meek-azure, run by inf0)
>  * BridgeDB Moat (run by sysrqb, phw)
>  * ~~starman (throttled meek.bamsoftware.com, run by dcf)~~
>  * ~~maenad (unthrottled meek.bamsoftware.com, run by dcf)~~
>  * ~~GAEuploader (gaeuploader.meek.bamsoftware.com, run by dcf)~~

New description:

 These versions fix a denial-of-service vulnerability in the HTTP/2 server
 code.

 https://groups.google.com/d/msg/golang-announce/65QixT3tcmg/DrFiG6vvCwAJ
 > We have just released Go 1.12.8 and Go 1.11.13 to address recently
 reported security issues. We recommend that all users update to one of
 these releases (if you’re not sure which, choose Go 1.12.8).
 > * net/http: Denial of Service vulnerabilities in the HTTP/2
 implementation
 >
 >   net/http and golang.org/x/net/http2 servers that accept direct
 connections from untrusted clients could be remotely made to allocate an
 unlimited amount of memory, until the program crashes. Servers will now
 close connections if the send queue accumulates too many control messages.
 >
 >   The issues are CVE-2019-9512 and CVE-2019-9514, and Go issue
 [https://golang.org/issue/33606 golang.org/issue/33606].
 >
 >   This is also fixed in version v0.0.0-20190813141303-74dc4d7220e7 of
 golang.org/x/net/http2.
 >
 > * net/url: parsing validation issue
 >
 >   url.Parse would accept URLs with malformed hosts, such that the Host
 field could have arbitrary suffixes that would appear in neither
 Hostname() nor Port(), allowing authorization bypasses in certain
 applications. Note that URLs with invalid, not numeric ports will now
 return an error from url.Parse.
 >
 >   The issue is CVE-2019-14809 and Go issue
 [https://golang.org/issue/29098 golang.org/issue/29098].

 We need to redeploy the following servers:
  * cymrubridge02 (backend for meek-azure, run by inf0)
  * ~~BridgeDB Moat (run by sysrqb, phw)~~
  * ~~starman (throttled meek.bamsoftware.com, run by dcf)~~
  * ~~maenad (unthrottled meek.bamsoftware.com, run by dcf)~~
  * ~~GAEuploader (gaeuploader.meek.bamsoftware.com, run by dcf)~~

--

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

Re: [tor-bugs] #31542 [Core Tor/Tor]: Cannot connect to IPv6 addresses using Tor SOCKS

[Tor Bug Tracker & Wiki]

#31542: Cannot connect to IPv6 addresses using Tor SOCKS
--+--
 Reporter:  sega01|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sega01):

 I am also seeing this behavior with Tor Browser 8.5.4.

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:
 |  cypherpunks
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:  1000
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 ok found better one
 https://trac.torproject.org/projects/tor/ticket/24351#comment:107

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:
 |  cypherpunks
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:  1000
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 found email

 https://social.privacytools.io/@cloudflarelink

 > supp...@cloudflare.com

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:
 |  cypherpunks
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:  1000
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Anyone who have access??

 https://codeberg.org/crimeflare

 >> just checkout commit

 Sorry for being a n00b but how can I do it? I don't use git or github.

 https://codeberg.org...search?q=a1d9ae2327

 return 0 result.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27502 [Applications/Tor Browser]: Prioritize .onion hosts in AltSvc?

[Tor Bug Tracker & Wiki]

#27502: Prioritize .onion hosts in AltSvc?
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #30024| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+

Comment (by redshiftzero):

 Similarly, it would also be nice to prioritize v3 onions over v2 onions.
 For context, for SecureDrop we want to add Alt-Srv headers on our v2
 onions to direct traffic to v3 onions.

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

[tor-bugs] #31542 [Core Tor/Tor]: Cannot connect to IPv6 addresses using Tor SOCKS

[Tor Bug Tracker & Wiki]

#31542: Cannot connect to IPv6 addresses using Tor SOCKS
--+--
 Reporter:  sega01|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor/Tor
  Version:  Tor: 0.4.1.5  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Here is my Tor configuration:

 {{{
 SocksPort 127.0.0.1:9050 IPv6Traffic
 SocksPort [::1]:9050 IPv6Traffic
 DataDirectory /run/tor_client
 ControlPort unix:/run/tor_client/control
 ClientUseIPv6 1
 }}}

 I'm using 0.4.1.5 on Debian 9.

 IPv4 direct addresses are fine:
 {{{
 $ curl -s -x socks5h://127.0.0.1:9050 -v 157.230.170.226
 * Rebuilt URL to: 157.230.170.226/
 *   Trying 127.0.0.1...
 * TCP_NODELAY set
 * SOCKS5 communication to 157.230.170.226:80
 * SOCKS5 request granted.
 * Connected to (nil) (127.0.0.1) port 9050 (#0)
 > GET / HTTP/1.1
 > Host: 157.230.170.226
 > User-Agent: curl/7.52.1
 > Accept: */*
 >
 < HTTP/1.1 301 Moved Permanently
 < Server: nginx
 < Date: Tue, 27 Aug 2019 20:54:51 GMT
 < Content-Type: text/html
 < Content-Length: 178
 < Connection: keep-alive
 < Location: https://157.230.170.226/
 <
 
 301 Moved Permanently
 
 301 Moved Permanently
 nginx
 
 
 * Curl_http_done: called premature == 0
 * Connection #0 to host 157.230.170.226 left intact
 $ curl -s -x socks5h://[::1]:9050 -v 157.230.170.226
 * Rebuilt URL to: 157.230.170.226/
 *   Trying ::1...
 * TCP_NODELAY set
 * SOCKS5 communication to 157.230.170.226:80
 * SOCKS5 request granted.
 * Connected to (nil) (::1) port 9050 (#0)
 > GET / HTTP/1.1
 > Host: 157.230.170.226
 > User-Agent: curl/7.52.1
 > Accept: */*
 >
 < HTTP/1.1 301 Moved Permanently
 < Server: nginx
 < Date: Tue, 27 Aug 2019 20:55:03 GMT
 < Content-Type: text/html
 < Content-Length: 178
 < Connection: keep-alive
 < Location: https://157.230.170.226/
 <
 
 301 Moved Permanently
 
 301 Moved Permanently
 nginx
 
 
 * Curl_http_done: called premature == 0
 * Connection #0 to host 157.230.170.226 left intact
 }}}

 IPv6 direct addresses do not work:

 {{{
 $ curl -s -x socks5h://[::1]:9050 -v [2604:a880:cad:d0::684e:f001]
 * Rebuilt URL to: [2604:a880:cad:d0::684e:f001]/
 *   Trying ::1...
 * TCP_NODELAY set
 * SOCKS5 communication to 2604:a880:cad:d0::684e:f001:80
 * Can't complete SOCKS5 connection to
 ::::::::0. (1)
 * Closing connection 0
 $ curl -s -x socks5h://127.0.0.1:9050 -v [2604:a880:cad:d0::684e:f001]
 * Rebuilt URL to: [2604:a880:cad:d0::684e:f001]/
 *   Trying 127.0.0.1...
 * TCP_NODELAY set
 * SOCKS5 communication to 2604:a880:cad:d0::684e:f001:80
 * Can't complete SOCKS5 connection to 0.0.0.0:0. (1)
 * Closing connection 0
 }}}

 What should I test from here?

 Thanks!

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

Re: [tor-bugs] #31541 [Core Tor/Tor]: hs-v3: Client can re-pick bad intro points

[Tor Bug Tracker & Wiki]

#31541: hs-v3: Client can re-pick bad intro points
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs tor-client 035-backport,  |  Actual Points:
  040-backport, 041-backport |
Parent ID:  #30200   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by nickm):

 I don't understand the bug.  `smartlist_del` will remove `ip` from the
 smartlist, but `ip` is not invalidated by `smartlist_del`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31541 [Core Tor/Tor]: hs-v3: Client can re-pick bad intro points

[Tor Bug Tracker & Wiki]

#31541: hs-v3: Client can re-pick bad intro points
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs tor-client 035-backport,  |  Actual Points:
  040-backport, 041-backport |
Parent ID:  #30200   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by nickm):

 * severity:  Normal => Major


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

Re: [tor-bugs] #30126 [Applications/Tor Browser]: Make Tor Browser on macOS compatible with Apple's notarization

[Tor Bug Tracker & Wiki]

#30126: Make Tor Browser on macOS compatible with Apple's notarization
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201908  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Replying to [comment:42 mcs]:
 > Replying to [comment:34 gk]:
 > * A macOS computer running 10.13.6 or later (required for the `xcrun`
 notarization commands that are part of Xcode 10.1 and later). I do not
 know enough about the Tor Browser signing and release process to know what
 kind of computer to recommend. If we plan to buy a new computer and
 portability is needed, maybe a MacBook Air. If portability is less of a
 concern, maybe a Mac Mini (still somewhat portable but you need to add a
 keyboard, mouse, and display).

 New macs will come with the latest macOS.

 > * A copy of Xcode 10.1 or later (note that 10.3 is the highest stable
 release, but 10.2 and up require macOS 10.14.3 or later).

 Downloadable from the App Store, requires an App Store account for every
 download and update.

 > * Connectivity to the Internet (at least to reach Apple's timestamping
 and notarization servers).

 > > Another thought I had: can we buy us some time if we pretend we have
 signed our stuff _before_ June 2019? IIRC the notarization requirement is
 only a requirement for binaries signed _after_ that threshold.
 >
 > This is an interesting idea, but it seems like a loophole that Apple
 would have closed by now. But maybe it would work. I don't have any
 experience with running a timestamping server; can we easily set one up
 that uses a time prior to June 2019?

 Apple has banned apps for evading rules like this. Might not be the best
 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] #31458 [Applications/Tor Browser]: Facilitate getting the widl fixes from wine into mingw and update the mingw-w64 project in tor-browser-build once they are in

[Tor Bug Tracker & Wiki]

#31458: Facilitate getting the widl fixes from wine into mingw and update the
mingw-w64 project in tor-browser-build once they are in
-+-
 Reporter:  pospeselr|  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201908R, tbb-9.0   |  Actual Points:
  -must-alpha|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * keywords:  TorBrowserTeam201908, tbb-9.0-must-alpha =>
 TorBrowserTeam201908R, tbb-9.0-must-alpha
 * 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] #31458 [Applications/Tor Browser]: Facilitate getting the widl fixes from wine into mingw and update the mingw-w64 project in tor-browser-build once they are in

[Tor Bug Tracker & Wiki]

#31458: Facilitate getting the widl fixes from wine into mingw and update the
mingw-w64 project in tor-browser-build once they are in
-+-
 Reporter:  pospeselr|  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201908, tbb-9.0-must-  |  Actual Points:
  alpha  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Commit to remove the mingw-w64 widl pre-build patch:

 tor-browser-build: https://gitweb.torproject.org/user/richard/tor-browser-
 build.git/commit/?h=bug_31458

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25957 [Core Tor/Tor]: Tor 0.3.3.5-rc died: Caught signal 11

[Tor Bug Tracker & Wiki]

#25957: Tor 0.3.3.5-rc died: Caught signal 11
+---
 Reporter:  Pine64ARMv8 |  Owner:  (none)
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: 0.3.3.5-rc
 Severity:  Normal  | Resolution:
 Keywords:  crash, openssl  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by teor):

 We are still waiting for this information on this ticket:

 Replying to [comment:1 teor]:
 > Hi, can you tell us what version of OpenSSL tor was compiled with, and
 what version you have installed?
 > When Tor starts up, it logs a message containing this information, if
 the versions are different.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30041 [Core Tor/Tor]: OOB access with huge buffers (src/lib/buf/buffers.c)

[Tor Bug Tracker & Wiki]

#30041: OOB access with huge buffers (src/lib/buf/buffers.c)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:  fixed
 Keywords:  security-low, hackerone, bug-|  Actual Points:
  bounty, 029-backport, 035-backport,|
  040-backport, consider-backport-after-0405 |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 Replying to [comment:13 cypherpunks]:
 > i believe my issue is related. will this limit fix my bugs or should i
 open new ticket?
 >
 >
 > {{{
 > [warn] {BUG} Bug: Non-fatal assertion !(buf->datalen >= INT_MAX -
 at_most) failed in buf_read_from_tls at buffers_tls.c:73. (Stack trace not
 available) (on Tor 0.4.0.5 )
 > }}}

 Looks like #25957, I will add your logs there.
 If you can answer the questions on that ticket, we might be able to make
 progress,

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25957 [Core Tor/Tor]: Tor 0.3.3.5-rc died: Caught signal 11

[Tor Bug Tracker & Wiki]

#25957: Tor 0.3.3.5-rc died: Caught signal 11
+---
 Reporter:  Pine64ARMv8 |  Owner:  (none)
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: 0.3.3.5-rc
 Severity:  Normal  | Resolution:
 Keywords:  crash, openssl  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by teor):

 From https://trac.torproject.org/projects/tor/ticket/30041#comment:13
 > i believe my issue is related. will this limit fix my bugs or should i
 open new ticket?
 >
 >
 > {{{
 > [warn] {BUG} Bug: Non-fatal assertion !(buf->datalen >= INT_MAX -
 at_most) failed in buf_read_from_tls at buffers_tls.c:73. (Stack trace not
 available) (on Tor 0.4.0.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] #31458 [Applications/Tor Browser]: Facilitate getting the widl fixes from wine into mingw and update the mingw-w64 project in tor-browser-build once they are in

[Tor Bug Tracker & Wiki]

#31458: Facilitate getting the widl fixes from wine into mingw and update the
mingw-w64 project in tor-browser-build once they are in
-+-
 Reporter:  pospeselr|  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201908, tbb-9.0-must-  |  Actual Points:
  alpha  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 And verified 32-bit Tor Browser is working with NVDA on 64-bit Windows 7.

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

Re: [tor-bugs] #29430 [Applications/Tor Browser]: Use uTLS for meek TLS camouflage in Tor Browser

[Tor Bug Tracker & Wiki]

#29430: Use uTLS for meek TLS camouflage in Tor Browser
-+-
 Reporter:  dcf  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  meek, utls, ff68-esr, tbb-9.0-must-  |  Actual Points:
  nightly, TorBrowserTeam201908R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by mcs):

 * status:  needs_revision => needs_review
 * keywords:  meek, utls, ff68-esr, tbb-9.0-must-nightly,
 TorBrowserTeam201908 => meek, utls, ff68-esr, tbb-9.0-must-nightly,
 TorBrowserTeam201908R


Comment:

 Replying to [comment:31 gk]:
 > Alright, this looks mostly good to me. However, it seems selecting
 `meek` breaks the circuit display now:
 > {{{
 > nodeData[i].ip is undefined tor-circuit-display.js:298
 > ...

 Thanks for catching that bug. It turns out that we also need a small patch
 to Torbutton:
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug29430-01&id=844693481ce92bb34536113a318211cbaedde4bd

 This will fix the immediate problem. In the long run, the control port
 response parser and circuit display code should be more robust and not
 completely fail when it sees a bridge type that it does not recognize.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30279 [Core Tor/Chutney]: Test IPv6-only v3 onion services in Chutney's CI, once homebrew tor stable supports them

[Tor Bug Tracker & Wiki]

#30279: Test IPv6-only v3 onion services in Chutney's CI, once homebrew tor 
stable
supports them
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Low  |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  merge-after-041-stable-in-homebrew,  |  Actual Points:  0.2
  tor-hs, ipv6, single-onion, fast-fix,  |
  chutney-ci, network-team-roadmap-2019-Q1Q2,|
  041-deferred-20190530  |
Parent ID:   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  Sponsor19-can
-+-

Comment (by teor):

 (Alternately, we could add a macOS chutney job to Tor's CI, and that would
 test Tor master. We should probably do both.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30279 [Core Tor/Chutney]: Test IPv6-only v3 onion services in Chutney's CI, once homebrew tor stable supports them

[Tor Bug Tracker & Wiki]

#30279: Test IPv6-only v3 onion services in Chutney's CI, once homebrew tor 
stable
supports them
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Low  |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  merge-after-041-stable-in-homebrew,  |  Actual Points:  0.2
  tor-hs, ipv6, single-onion, fast-fix,  |
  chutney-ci, network-team-roadmap-2019-Q1Q2,|
  041-deferred-20190530  |
Parent ID:   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  Sponsor19-can
-+-
Changes (by teor):

 * status:  merge_ready => needs_revision


Comment:

 The version of Tor in the homebrew cache in the Travis image is 0.3.3.7:
 {{{
 $ tor --version
 Tor version 0.3.3.7 (git-035a35178c92da94).
 }}}

 We don't have any integration tests for this code right now, so it's
 probably worth refreshing the homebrew cache just for this job.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31539 [Applications/Tor Browser]: FAQ page (esp connection troubleshoooting) should be available offline in TB

[Tor Bug Tracker & Wiki]

#31539: FAQ page (esp connection troubleshoooting) should be available offline 
in
TB
--+--
 Reporter:  mrphs |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  censorship, support,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mrphs):

 And the reason I mentioned FAQ page instead of https://tb-
 manual.torproject.org/bridges/ was because when you go to `Tor Network
 Settings...`, it says `For assistance, visit
 support.torproject.org/#connectingtotor` which is the FAQ page. I don't
 know how or why it was decided to show which URL where, but I do believe
 that whatever we do, we need to be consistent.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31541 [Core Tor/Tor]: hs-v3: Client can re-pick bad intro points

[Tor Bug Tracker & Wiki]

#31541: hs-v3: Client can re-pick bad intro points
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs tor-client 035-backport,  |  Actual Points:
  040-backport, 041-backport |
Parent ID:  #30200   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by dgoulet):

 * keywords:  tor-hs tor-client => tor-hs tor-client 035-backport,
 040-backport, 041-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] #25882 [Core Tor/Tor]: clients not detecting stale onion service introduction points

[Tor Bug Tracker & Wiki]

#25882: clients not detecting stale onion service introduction points
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, reachability, network-team-  |  Actual Points:
  roadmap-september  |
Parent ID:  #30200   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by dgoulet):

 #31541 is probably a big start to fixing this.

 I'm still investigating the circuit timeout issues so there might be more
 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] #31541 [Core Tor/Tor]: hs-v3: Client can re-pick bad intro points

[Tor Bug Tracker & Wiki]

#31541: hs-v3: Client can re-pick bad intro points
+
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:  tor-hs tor-client
Actual Points:  |  Parent ID:  #30200
   Points:  1   |   Reviewer:  asn
  Sponsor:  Sponsor27-must  |
+
 Ok this one took me a while to figure out!

 This is sorta related to #25882 as it is a bug that makes the client retry
 constantly the same intro point even though it was flagged as having an
 error.

 Problem lies in `client_get_random_intro()` which randomly selects an
 intro point from the descriptor. Sparing the detail, this is where it goes
 wrong:

 {{{
 ip = smartlist_get(usable_ips, idx);
 smartlist_del(usable_ips, idx);
 }}}

 ... and then we use `ip` to check if usable and if yes, we connect to it.

 We can't `del()` the value from the list until we are done with the `ip`
 object. The `smartlist_get()` returns a pointer to location *in the list*
 so if we change the list order right after acquiring the reference, we are
 accessing bad things, possibly junk.

 So basically, junk can be used, the wrong IP can be used even though it
 would not pass the `intro_point_is_usable()` if it was correct pointer.

 I was able to find this using a pathological case where the HS pins its
 intro point to 3 specific nodes. So, even upon a restart or desc rotation,
 the same IPs are re-used but with different auth key.

 If a client had already connected to that service and thus had those IPs
 in its failure cache, it will fail to eternity to connect to the service
 because it basically never realize it needs to refetch a new descriptor.

 Even though there is a catch all with
 `hs_client_any_intro_points_usable()` before extending to an intro point,
 the problem lies with the above which can make the code NEVER pick a
 certain intro point so the catch all always validate to true since there
 is one intro point in the list that was never tried.

 This is very bad for reachability, network load, but also simple "code
 safety". I strongly recommend backport to our maintained version >= 032.

 Fortunately for us, the fix is trivial, we should only `del()` when done
 with the IP object.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31458 [Applications/Tor Browser]: Facilitate getting the widl fixes from wine into mingw and update the mingw-w64 project in tor-browser-build once they are in

[Tor Bug Tracker & Wiki]

#31458: Facilitate getting the widl fixes from wine into mingw and update the
mingw-w64 project in tor-browser-build once they are in
-+-
 Reporter:  pospeselr|  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201908, tbb-9.0-must-  |  Actual Points:
  alpha  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Verified the above build working correctly on 32-bit Windows 7, now
 setting up 64-bit Windows 7 WoW.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30360 [Internal Services/Service - nextcloud]: Please make the Deck API available

[Tor Bug Tracker & Wiki]

#30360: Please make the Deck API available
-+-
 Reporter:  ln5  |  Owner:
 |  nextcloud-admin@…
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ln5):

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


Comment:

 Sounds like we're going to aim for getting kanban like functionality from
 gitlab. Closing this one, please reopen if I'm misinformed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31540 [Internal Services/Tor Sysadmin Team]: Do we want to run a NextCloud instance?

[Tor Bug Tracker & Wiki]

#31540: Do we want to run a NextCloud instance?
+-
 Reporter:  ln5 |  Owner:  tpa
 Type:  task| Status:  new
 Priority:  Medium  |  Component:  Internal Services/Tor Sysadmin Team
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
 Today's meeting on NextCloud as a replacement for Storm and SVN decided we
 should go ahead using NextCloud.

 Should Tor run an instance or should we rather have someone do it for us?
 Riseup has offered to run it for us, in a separate instance for Tor only
 if we want that. They've also offered to help us running one on our own
 infrastructure if that's what we want.

 What do we want?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30126 [Applications/Tor Browser]: Make Tor Browser on macOS compatible with Apple's notarization

[Tor Bug Tracker & Wiki]

#30126: Make Tor Browser on macOS compatible with Apple's notarization
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201908  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by mcs):

 Replying to [comment:34 gk]:
 > mcs/brade: could you assemble a list of minimal requirements we have to
 have to get the notarization going, with the focus on what we'd need for
 our signing machine (plus a script or something you used).

 The only scripts we used were very simple ones that only saved us typing
 the commands I mentioned in comment:11 and comment:20 (`codesign`, `xcrun
 altool`, and `xcrun stapler` commands). I don't know exactly how the
 notarization steps will fit into the overall Tor Browser build process,
 but ideally someone would write a script to automate things and especially
 to allow the submission/wait for a reply from Apple part to be done in
 parallel for our .dmg files. Maybe that is something boklm could do?

 Now that we have solved (most of) the build-related requirements, here are
 the remaining things we need:
 * An Apple Developer ID key and certificate (I think we already have this
 for the existing Gatekeeper signing).
 * An entitlements file. So far we have always used the one from Firefox,
 e.g., https://searchfox.org/mozilla-
 esr68/source/security/mac/hardenedruntime/production.entitlements.xml
 * A macOS computer running 10.13.6 or later (required for the `xcrun`
 notarization commands that are part of Xcode 10.1 and later). I do not
 know enough about the Tor Browser signing and release process to know what
 kind of computer to recommend. If we plan to buy a new computer and
 portability is needed, maybe a MacBook Air. If portability is less of a
 concern, maybe a Mac Mini (still somewhat portable but you need to add a
 keyboard, mouse, and display).
 * A copy of Xcode 10.1 or later (note that 10.3 is the highest stable
 release, but 10.2 and up require macOS 10.14.3 or later).
 * Connectivity to the Internet (at least to reach Apple's timestamping and
 notarization servers).
 * A script or set of scripts to automated things some, especially for the
 part where we have to wait for Apple to respond to the a notarization
 request. This and the network connectivity requirement are the most
 annoying parts of the entire process.

 > Another thought I had: can we buy us some time if we pretend we have
 signed our stuff _before_ June 2019? IIRC the notarization requirement is
 only a requirement for binaries signed _after_ that threshold.

 This is an interesting idea, but it seems like a loophole that Apple would
 have closed by now. But maybe it would work. I don't have any experience
 with running a timestamping server; can we easily set one up that uses a
 time prior to June 2019?

 Kathy and I would like to install the macOS 10.15 beta and see what the
 behavior is if someone tries to run an app that has not been notarized
 (and also to see how difficult it is for people to work around a lack of
 notarization). But other ESR68 work seems more important given the fact
 that items such as the updater and meek affect all platforms/all OS
 versions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29415 [Internal Services/Service - nextcloud]: Evaluating NextCloud as replacement for Sandstorm and SVN

[Tor Bug Tracker & Wiki]

#29415: Evaluating NextCloud as replacement for Sandstorm and SVN
-+-
 Reporter:  ln5  |  Owner:  (none)
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ln5):

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


Comment:

 Todays evaluation meeting, held in #tor-internal, decided that we should
 go ahead and replace storm with NextCloud. SVN not clear yet which repos,
 but NextCloud is to be used irregardless.

 New ticket(s) will be created for next steps.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30869 [Internal Services/Service - nextcloud]: [Nextcloud] Feedback re: collaborative document editing

[Tor Bug Tracker & Wiki]

#30869: [Nextcloud] Feedback re: collaborative document editing
-+-
 Reporter:  alsmith  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  | Resolution:  not a
 Severity:  Normal   |  bug
 Keywords:  nextcloud, migration |  Actual Points:
Parent ID:  #29415   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ln5):

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


Comment:

 Thanks for all the useful feedback. Closing this 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] #31036 [Core Tor/Tor]: Logfile grow upto 2GB tor fails and refuse to start

[Tor Bug Tracker & Wiki]

#31036: Logfile grow upto 2GB tor fails and refuse to start
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-backport 040-backport|  Actual Points:
  041-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Sorry, can be platform specific. but i could have this again reproduced
 and it just happened randomly again.
 warning log file filled over 7GB within one hour.
 all messages are the same:


 {{{
 Aug 26 09:47:20.000 [warn] {BUG} tor_bug_occurred_(): Bug:
 buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >=
 INT_MAX - at_most) failed. (on Tor 0.4.0.5 )
 }}}
 tor process does not start afterwards. without setting

 {{{
 TruncateLogFile 1
 }}}

 error:

 {{{
 Aug 27 07:03:46.000 [warn] Couldn't open file for 'Log warn file
 C:\tools\msys64\home\tor\var\log\tor\warn.log': Invalid argument
 Aug 27 07:03:46.000 [warn] Failed to parse/validate config: Failed to init
 Log options. See logs for details.
 Aug 27 07:03:46.000 [err] Reading config failed--see warnings above.
 }}}

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

Re: [tor-bugs] #31539 [Applications/Tor Browser]: FAQ page (esp connection troubleshoooting) should be available offline in TB

[Tor Bug Tracker & Wiki]

#31539: FAQ page (esp connection troubleshoooting) should be available offline 
in
TB
--+--
 Reporter:  mrphs |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  censorship, support,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mrphs):

 * type:  defect => enhancement


Old description:

> Tor has been once again blocked as of few hours ago in Iran. And as per
> usual my DMs and Email have been flooded with questions from censored
> users not knowing how to get back on the network. This means people still
> don't know they can use a bridge or that there are default bridges
> provided to the user or that they can perform bridge discovery inside the
> Tor Browser.
>
> One of the things I've always admired Tails for, is that all of their
> documentation is available offline inside Tails. We used to do a similar
> thing. In the old days, there was a short Tor Browser manual. A one page
> simple html that was served when someone would request TB via GetTor.
>
> I think it wont hurt to load an offline HTML page in case connection
> fails, and users are confused on what to do next. In my experience, most
> users don't even know that there are other ways to connect to the Tor
> network when the direct connection fails.
>
> Additionally, we should consider a scenario that I haven't seen covered
> by any of the help documents I've read so far and that is when a user has
> already been connecting to the Tor network directly, but after some time
> it fails and now they need a bridge.
>
> I'm not sure which component would be the right one for this, considering
> it involves censorship circumvention, tor browser and tor support. Feel
> free to move it to the right bucket.

New description:

 Tor has been once again blocked as of few hours ago in Iran. And as per
 usual my DMs and Email have been flooded with questions from censored
 users not knowing how to get back on the network. This means people still
 don't know they can use a bridge, or that there are default bridges
 provided, or that they can perform bridge discovery inside the Tor
 Browser.

 One of the things I've always admired Tails for, is that all of their
 documentation is available offline inside Tails. We used to do a similar
 thing. In the old days, there was a short Tor Browser manual. A one page
 simple html that was served when someone would request TB via GetTor.

 I think it wont hurt to load an offline HTML page in case connection
 fails, and users are confused on what to do next. In my experience, most
 users don't even know that there are other ways to connect to the Tor
 network when the direct connection fails.

 Additionally, we should consider a scenario that I haven't seen covered by
 any of the help documents I've read so far and that is when a user has
 already been connecting to the Tor network directly, but after some time
 it fails and now they need a bridge.

 I'm not sure which component would be the right one for this, considering
 it involves censorship circumvention, tor browser and tor support. Feel
 free to move it to the right bucket.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27284 [Core Tor/Tor]: Check IPv6 exit policies on microdescs

[Tor Bug Tracker & Wiki]

#27284: Check IPv6 exit policies on microdescs
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-after-042-stable,  |  Actual Points:
  029-backport, 035-backport, 040-backport,  |
  041-backport, 042-backport, ipv6,  |
  040-deferred-20190220, teor-   |
  unreached-2019-03-08   |
Parent ID:  #27248   | Points:
 Reviewer:  nickm|Sponsor:
-+-

Comment (by neel):

 I made the boolean back into a bitfield and moved it to the other
 bitfields in a fixup commit.

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

[tor-bugs] #31539 [Applications/Tor Browser]: FAQ page (esp connection troubleshoooting) should be available offline in TB

[Tor Bug Tracker & Wiki]

#31539: FAQ page (esp connection troubleshoooting) should be available offline 
in
TB
--+
 Reporter:  mrphs |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  censorship,
  |  support,
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Tor has been once again blocked as of few hours ago in Iran. And as per
 usual my DMs and Email have been flooded with questions from censored
 users not knowing how to get back on the network. This means people still
 don't know they can use a bridge or that there are default bridges
 provided to the user or that they can perform bridge discovery inside the
 Tor Browser.

 One of the things I've always admired Tails for, is that all of their
 documentation is available offline inside Tails. We used to do a similar
 thing. In the old days, there was a short Tor Browser manual. A one page
 simple html that was served when someone would request TB via GetTor.

 I think it wont hurt to load an offline HTML page in case connection
 fails, and users are confused on what to do next. In my experience, most
 users don't even know that there are other ways to connect to the Tor
 network when the direct connection fails.

 Additionally, we should consider a scenario that I haven't seen covered by
 any of the help documents I've read so far and that is when a user has
 already been connecting to the Tor network directly, but after some time
 it fails and now they need a bridge.

 I'm not sure which component would be the right one for this, considering
 it involves censorship circumvention, tor browser and tor support. Feel
 free to move it to the right bucket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30041 [Core Tor/Tor]: OOB access with huge buffers (src/lib/buf/buffers.c)

[Tor Bug Tracker & Wiki]

#30041: OOB access with huge buffers (src/lib/buf/buffers.c)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:  fixed
 Keywords:  security-low, hackerone, bug-|  Actual Points:
  bounty, 029-backport, 035-backport,|
  040-backport, consider-backport-after-0405 |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-

Comment (by cypherpunks):

 i believe my issue is related. will this limit fix my bugs or should i
 open new ticket?


 {{{
 [warn] {BUG} Bug: Non-fatal assertion !(buf->datalen >= INT_MAX - at_most)
 failed in buf_read_from_tls at buffers_tls.c:73. (Stack trace not
 available) (on Tor 0.4.0.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] #20212 [Core Tor/Tor]: Tor can be forced to open too many circuits by embedding .onion resources

[Tor Bug Tracker & Wiki]

#20212: Tor can be forced to open too many circuits by embedding .onion 
resources
-+-
 Reporter:  gacar|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery, |  Actual Points:
  TorBrowserTeam201803, 034-roadmap-proposed,|
  security, tor-hs   |
Parent ID:  #29995   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by cypherpunks):

 things got even worse. since DDOSmitigating. a client opening to many
 circuit in short time period will trigger this and get punished by guard.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31240 [Core Tor/Tor]: Make confparse able to handle multiple config_format_t objects at once

[Tor Bug Tracker & Wiki]

#31240: Make confparse able to handle multiple config_format_t objects at once
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:  3
Parent ID:  #29211   | Points:  3
 Reviewer:  teor |Sponsor:  Sponsor31-can
-+-
Changes (by nickm):

 * status:  needs_revision => 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:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.3.9
 Severity:  Normal | Resolution:
 Keywords:  rust, doc, 033-unreached-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer:  nickm  |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 Trying to pick this up again.

 Looking at the branch, I see several changes.
   1. It makes the `updateRustDependencies.sh` script exit on error.
   2. It changes the crate dependency versions listed in our Cargo.toml
 files to be no longer pinned, under the theory that Cargo.lock is the
 correct mechanism for pinning versions.
   3. It updates the instructions for updating versions so that:
* they no longer recommend version pinning with Cargo.toml
* they give more information about the correct sequence of action
 in git.

 I agree with 1 and 3; we should discuss 2 as a team.

 When I try to use this script, I see two problems:

 First, cargo now includes "cargo vendor", but it has been updated to no
 longer support the `--explicit-version` flag.  We should investigate why,
 and what to do about it.

 Second, I get: "./scripts/maint/updateRustDependencies.sh: line 51: test:
 too many arguments".  This is an easy fix.

 My next step here is to read up on why --explicit-version is no longer
 supported here, and to start a discussion on what we actually want to do
 about versions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31010 [Applications/Tor Browser]: Rebase Tor Browser mobile/ patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

#31010: Rebase Tor Browser mobile/ patches for Firefox ESR 68
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:  #30429   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:15 sysrqb]:
 > The new branch for review is: `acat30429+5_tor-
 browser_android_68esr_54`.

 whoops, that should be `acat30429+5_tor-browser_android_68esr_53`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake

[Tor Bug Tracker & Wiki]

#29206: New design for client -- server protocol for Snowflake
---+---
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Circumvention/Snowflake|Version:
 Severity:  Normal | Resolution:
 Keywords:  anti-censorship-roadmap-september  |  Actual Points:
Parent ID: | Points:  6
 Reviewer:  dcf|Sponsor:
   |  Sponsor28-must
---+---
Changes (by cohosh):

 * status:  needs_revision => needs_review


Comment:

 This is finally ready for another review. Here's a rebased branch:
 https://github.com/cohosh/snowflake/compare/sequencing The main
 improvements from the last version are:
 - Each end of a SnowflakeConn will send empty acknowledgement packets
 (consisting of just the Snowflake header) upon the receipt of new data
 - Each write method spins up a goroutine that will wait for some specified
 time until checking to see if the acknowledgement packet for that data has
 been received. If not, it closes the underlying connection causing future
 reads and writes to fail.
 - On each call to SnowflakeConn's write method, data is saved in an
 internal buffer until it has been acknowledged
 - SnowflakeConn now has a new method to set and reset the underlying
 connection. If there is buffered data, SnowflakeConn will resend that data
 under the same session ID whenever a new underlying connection has been
 specified

 My reasoning for implementing it this way is that the client and server
 shouldn't have to worry about buffering data after a call to Write(). This
 makes
 [https://github.com/cohosh/snowflake/blob/sequencing/client/lib/webrtc.go#L34
 the buffer in `client/webrtc.go`] redundant, but I'll remove it later when
 finishing up tying together the client and server interactions.

 The next step of course is to allow for resetting the underlying
 connection in SnowflakeConn and using the sessionID to correlate new
 connections with old ones. There's going to have to be some tricky
 refactoring here. Right now when the webrtc connection times out (due to
 staleness), both the webrtc connection and the socks connection are closed
 and the client waits for a new socks connection to open. The SnowflakeConn
 should be persistent across snowflakes (and the way it is currently set up
 perhaps also across SOCKS connections (??)), so the question is where
 SnowflakeConn should "live".

 I'm thinking of adding a new method to SnowflakeCollector that will set
 (and reset) the underlying connection, and then modifying the
 
[https://github.com/cohosh/snowflake/blob/sequencing/client/lib/snowflake.go#L24
 Handler function] to redefine the snowflake rather than closing the SOCKS
 connection and waiting for a new one. This doesn't fit perfectly with what
 I'd assume a SnowflakeCollector does by name, but then again maybe it
 does. This would make the SnowflakeCollector responsible for both getting
 new snowflakes and also deciding which snowflake(s) to send traffic
 through.

 Any feedback on decisions up to this point and on future plans is welcome
 :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31521 [Metrics/Analysis]: Investigate 10-second delay in TTFB

[Tor Bug Tracker & Wiki]

#31521: Investigate 10-second delay in TTFB
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Analysis |Version:
 Severity:  Normal   | Resolution:
 Keywords:  scalability performance  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by mikeperry):

 * cc: arthuredelstein (added)


Comment:

 This sounds about the rate of bad exit connectivity that arthuredelstein
 noticed during his scans a year or so ago. IIRC he noticed it for DNS
 timeouts though. In this case DNS appears not to be involved/at fault.

 There are three ways to deal with this:

 0. Continue exit scanning constantly and hassle Exits to help diagnose/fix
 this.
 1. Test that pre-built Exit circuits can resolve a test domain like
 example.com (may not handle this case).
 2. Implement an Adaptive Stream Timeout (similar to/based on Circuit Build
 Timeout) rather than the fixed 10s value.

 Option 3 is the only sure shot. There is a trac ticket where we
 investigated doing adaptive stream timeouts in addition/instead of CBT as
 part of a Google Summer of Code + Research project. It did not help the
 general case, but it would help this long tail. I can't find the ticket at
 the moment, but it is in the performance R&D kanban under the "Develop"
 column.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27284 [Core Tor/Tor]: Check IPv6 exit policies on microdescs

[Tor Bug Tracker & Wiki]

#27284: Check IPv6 exit policies on microdescs
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-after-042-stable,  |  Actual Points:
  029-backport, 035-backport, 040-backport,  |
  041-backport, 042-backport, ipv6,  |
  040-deferred-20190220, teor-   |
  unreached-2019-03-08   |
Parent ID:  #27248   | Points:
 Reviewer:  nickm|Sponsor:
-+-

Comment (by nickm):

 This looks better to me.  I'd like to turn the boolean back into a
 bitfield, but move it to be next to the other bitfields, in order to save
 memory.

 Teor, do you think we will want to backport this?  If so I want to rebase
 it before merging--but I am not sure how necessary a backport is, or how
 difficult it would be.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31538 [Applications/Tor Browser]: Windows bundles based on ESR 68 are not built reproducibly

[Tor Bug Tracker & Wiki]

#31538: Windows bundles based on ESR 68 are not built reproducibly
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908, |
  GeorgKoppen201908  |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 The diff is surprisingly large (see the example attached for the `plugin-
 hang-ui.exe`).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31538 [Applications/Tor Browser]: Windows bundles based on ESR 68 are not built reproducibly

[Tor Bug Tracker & Wiki]

#31538: Windows bundles based on ESR 68 are not built reproducibly
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908, |
  GeorgKoppen201908  |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * Attachment "plugin_hang_ui_diff.bz2" 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] #31288 [Circumvention/Snowflake]: Add an option to be able to run the Snowflake WebExt as a background app in Chrome

[Tor Bug Tracker & Wiki]

#31288: Add an option to be able to run the Snowflake WebExt as a background 
app in
Chrome
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arlolra):

 Seems to be the "background" permission,
 https://developer.chrome.com/extensions/declare_permissions#background

 We could maybe declare it as an optional permission and then conditionally
 request it at runtime with the permissions api,
 https://developer.chrome.com/extensions/permissions

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31538 [Applications/Tor Browser]: Windows bundles based on ESR 68 are not built reproducibly

[Tor Bug Tracker & Wiki]

#31538: Windows bundles based on ESR 68 are not built reproducibly
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm, ff68-esr,
 Severity:  Major|  tbb-9.0-must-nightly,
 |  TorBrowserTeam201908,
 |  GeorgKoppen201908
Actual Points:   |  Parent ID:  #30322
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 As mentioned in comment:20:ticket:28238 we have files that are not built
 reproducibly with the new `mingw-w64-clang` toolchain. It affects not all
 binaries, though, only firefox.exe, libGLESv2.dll, mozglue.dll, plugin-
 container.exe, plugin-hang-ui.exe, and xul.dll.

 This is still an issue after switching to clang, lld etc. 8.0.0.

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

Re: [tor-bugs] #30279 [Core Tor/Chutney]: Test IPv6-only v3 onion services in Chutney's CI, once homebrew tor stable supports them

[Tor Bug Tracker & Wiki]

#30279: Test IPv6-only v3 onion services in Chutney's CI, once homebrew tor 
stable
supports them
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  merge-after-041-stable-in-homebrew,  |  Actual Points:  0.2
  tor-hs, ipv6, single-onion, fast-fix,  |
  chutney-ci, network-team-roadmap-2019-Q1Q2,|
  041-deferred-20190530  |
Parent ID:   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  Sponsor19-can
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 Homebrew now includes 0.4.1.5 -- I've restarted travis on the PR.  Let's
 merge it if it passes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31537 [Circumvention/Snowflake]: snowflake.tp.o could use a favicon

[Tor Bug Tracker & Wiki]

#31537: snowflake.tp.o could use a favicon
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Circumvention/Snowflake
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31240 [Core Tor/Tor]: Make confparse able to handle multiple config_format_t objects at once

[Tor Bug Tracker & Wiki]

#31240: Make confparse able to handle multiple config_format_t objects at once
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:  3
Parent ID:  #29211   | Points:  3
 Reviewer:  teor |Sponsor:  Sponsor31-can
-+-

Comment (by nickm):

 I've pushed the requested tests, plus a few more to increase the test
 coverage on confparse.c.  I'll put this back in needs_review if CI
 approves.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25066 [Core Tor/Tor]: Rendezvous points should return signed proof of the established rend point

[Tor Bug Tracker & Wiki]

#25066: Rendezvous points should return signed proof of the established rend 
point
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor27-can
-+-
Changes (by asn):

 * parent:  #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] #31164 [Circumvention]: Set up default bridge at Karlstad University

[Tor Bug Tracker & Wiki]

#31164: Set up default bridge at Karlstad University
---+--
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-bridges|  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+--

Comment (by pulls):

 Progress made, three bridges up and running with the following torrc:

 {{{
 SocksPort auto
 RunAsDaemon 1
 ExtORPort auto
 ExitPolicy reject *:*

 # memory
 MaxMemInQueues 2 GB

 # more useful statistics
 EntryStatistics 1
 ExtraInfoStatistics 1
 HeartbeatPeriod 1 hour

 # obfs4 and parameters
 ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
 ServerTransportOptions obfs4 iatMode=0

 # announce bridges
 BridgeRelay 1
 BridgeDistribution none

 # These ports must be externally reachable.  Avoid port 9001.
 ServerTransportListenAddr obfs4 0.0.0.0:27015
 ORPort 27018

 # identity
 Nickname KauBridgePale
 ContactInfo abuse-...@lists.kau.se
 }}}

 Bridgelines here:

 {{{
 Bridge obfs4 193.11.166.194:27015 2D82C2E354D531A68469ADF7F878FA6060C6BACA
 cert=4TLQPJrTSaDffMK7Nbao6LC7G9OW/NHkUwIdjLSS3KYf0Nv4/nQiiI8dY2TcsQx01NniOg
 iat-mode=0
 Bridge obfs4 193.11.166.194:27020 86AC7B8D430DAC4117E9F42C9EAED18133863AAF
 cert=0LDeJH4JzMDtkJJrFphJCiPqKx7loozKN7VNfuukMGfHO0Z8OGdzHVkhVAOfo1mUdv9cMg
 iat-mode=0
 Bridge obfs4 193.11.166.194:27025 1AE2C08904527FEA90C4C4F8C1083EA59FBC6FAF
 cert=ItvYZzW5tn6v3G4UnQa6Qz04Npro6e81AP70YujmK/KXwDFPTs3aHXcHp4n8Vt6w/bv8cA
 iat-mode=0
 }}}

 Anything you want me to change in the torrc or we good to go?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-9.0-must-nightly,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 Replying to [comment:47 gk]:
 > Replying to [comment:46 tom]:
 > > > >  - fxc2 requires the winpthread dll to be in its bin directly
 IIRC; but I don't see where you're copying that. (I might have missed it.
 If you're not getting errors on fxc2 it must be working.)
 > > >
 > > > I think we don't need it when building with `mingw-w64-clang`. At
 least the build passes and I'd suspect compile time issues if that were a
 problem.
 > > >
 > >
 > > No, from my recollection it will compile fine but won't run if the dll
 is missing from the directory.  (However if firefox builds, then fxc2
 didn't error and it worked...)
 >
 > Another thought here: how are you compiling `fxc2`? I recall that I
 needed to resort to the .dll when compiling `fxc2` with `mingw-w64-gcc`,
 which was my main motivation to use `mingw-w64-clang` when building `fxc2`
 as well.

 No, you're right - I completely misremembered; I'm sorry. When I cut fxc2
 over to mingw-clang I got rid of needing winpthread (which makes sense now
 that I think more deeply about it.)  https://hg.mozilla.org/mozilla-
 central/rev/918d2aeb31eb7d18603be0c5f6ae9b27c12b6fc2

 Sorry!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:
 |  cypherpunks
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:  1000
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 hi, here you can find a backup of browser addons and everything before
 some cloudflare employee defaced that for the to spying MitM company
 hostile repository.

 just checkout commit
 {{{
 a1d9ae2327
 }}}
 there you find everything related to issue topic.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-9.0-must-nightly,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:46 tom]:
 > > >  - fxc2 requires the winpthread dll to be in its bin directly IIRC;
 but I don't see where you're copying that. (I might have missed it. If
 you're not getting errors on fxc2 it must be working.)
 > >
 > > I think we don't need it when building with `mingw-w64-clang`. At
 least the build passes and I'd suspect compile time issues if that were a
 problem.
 > >
 >
 > No, from my recollection it will compile fine but won't run if the dll
 is missing from the directory.  (However if firefox builds, then fxc2
 didn't error and it worked...)

 Another thought here: how are you compiling `fxc2`? I recall that I needed
 to resort to the .dll when compiling `fxc2` with `mingw-w64-gcc`, which
 was my main motivation to use `mingw-w64-clang` when building `fxc2` as
 well.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29461 [Metrics/CollecTor]: Add a Snowflake module

[Tor Bug Tracker & Wiki]

#29461: Add a Snowflake module
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-august, anti-|  Actual Points:
  censorship-roadmap-september   |
Parent ID:   | Points:  8
 Reviewer:  irl  |Sponsor:
 |  Sponsor28
-+-

Comment (by karsten):

 Commented on #31493.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31493 [Circumvention/Snowflake]: Add a version to the metrics output

[Tor Bug Tracker & Wiki]

#31493: Add a version to the metrics output
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+--

Comment (by karsten):

 In dir-spec, lines starting with `@` are treated as annotations that
 ''precede'' a descriptor and that can be stripped off without changing the
 descriptor. Including such a line inside a descriptor might be
 problematic.

 But after reading this ticket and #29461, I wonder if my suggestion to add
 a version number was bad advice. After all, we already have `snowflake-
 stats-end` in the first line as unique identifier of this descriptor type.
 And if something in the data format changes, there will be a specification
 update introducing new lines anyway. It's probably not worth the effort to
 update existing specification, implementation, and data to add something
 that we probably won't need. Can I take this suggestion back and we leave
 the format unchanged? (Sorry!!)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26768 [Core Tor/Tor]: Support onionbalance in HSv3

[Tor Bug Tracker & Wiki]

#26768: Support onionbalance in HSv3
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs scaling onionbalance  |  Actual Points:
  network-team-roadmap-september tor-spec|
Parent ID:  #29998   | Points:  8
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * points:  15 => 8


Comment:

 Reducing the amount of points, since I also assigned points to child
 ticket #31369.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29461 [Metrics/CollecTor]: Add a Snowflake module

[Tor Bug Tracker & Wiki]

#29461: Add a Snowflake module
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-august, anti-|  Actual Points:
  censorship-roadmap-september   |
Parent ID:   | Points:  8
 Reviewer:  irl  |Sponsor:
 |  Sponsor28
-+-

Comment (by cohosh):

 Okay I've updated #31493 to use the following spec:
 {{{
 We export metrics in the following (version 1.0) format:

 "snowflake-stats-end" -MM-DD HH:MM:SS (NSEC s) NL
 [At start, exactly once.]

 -MM-DD HH:MM:SS defines the end of the included measurement
 interval of length NSEC seconds (86400 seconds by default).

 "@type snowflake-stats 1.0"
 [Exactly once.]

 Defines the version of snowflake stats output being used
 (currently 1.0)

 "snowflake-ips" CC=NUM,CC=NUM,... NL
 [At most once.]

 List of mappings from two-letter country codes to the number of
 unique IP addresses of snowflake proxies that have polled.

 [rest omitted for brevity]
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31369 [Core Tor/Stem]: HSv3 descriptor support in stem

[Tor Bug Tracker & Wiki]

#31369: HSv3 descriptor support in stem
-+
 Reporter:  asn  |  Owner:  atagar
 Type:  defect   | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs onionbalance scaling  |  Actual Points:
Parent ID:  #26768   | Points:  9
 Reviewer:   |Sponsor:  Sponsor27-must
-+
Changes (by asn):

 * points:   => 9
 * sponsor:  Sponsor27-can => Sponsor27-must


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31493 [Circumvention/Snowflake]: Add a version to the metrics output

[Tor Bug Tracker & Wiki]

#31493: Add a version to the metrics output
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+--

Comment (by cohosh):

 I updated https://github.com/cohosh/snowflake/compare/bug31493 to use the
 following spec:

 {{{
 We export metrics in the following (version 1.0) format:

 "snowflake-stats-end" -MM-DD HH:MM:SS (NSEC s) NL
 [At start, exactly once.]

 -MM-DD HH:MM:SS defines the end of the included measurement
 interval of length NSEC seconds (86400 seconds by default).

 "@type snowflake-stats 1.0"
 [Exactly once.]

 Defines the version of snowflake stats output being used
 (currently 1.0)

 "snowflake-ips" CC=NUM,CC=NUM,... NL
 [At most once.]

 List of mappings from two-letter country codes to the number of
 unique IP addresses of snowflake proxies that have polled.

 "snowflake-ips-total" NUM NL
 [At most once.]

 A count of the total number of unique IP addresses of snowflake
 proxies that have polled.

 "snowflake-idle-count" NUM NL
 [At most once.]

 A count of the number of times a proxy has polled but received
 no client offer, rounded up to the nearest multiple of 8.

 "client-denied-count" NUM NL
 [At most once.]

 A count of the number of times a client has requested a proxy
 from the broker but no proxies were available, rounded up to
 the nearest multiple of 8.

 "client-snowflake-match-count" NUM NL
 [At most once.]

 A count of the number of times a client successfully received a
 proxy from the broker, rounded up to the nearest multiple of 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] #30259 [Webpages/Website]: Improve verify signature flow for Tor Browser

[Tor Bug Tracker & Wiki]

#30259: Improve verify signature flow for Tor Browser
--+--
 Reporter:  antonela  |  Owner:  antonela
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by antonela):

 * component:  UX => Webpages/Website


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31518 [Core Tor/Tor]: HAProxy implementation in TCPProxy option.

[Tor Bug Tracker & Wiki]

#31518: HAProxy implementation in TCPProxy option.
--+--
 Reporter:  haxxpop   |  Owner:  haxxpop
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  proxy tcp |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by haxxpop):

 If you would like you can also run the haproxy server by running
 {{{
 go install github.com/haxxpop/proxy-server
 proxy-server
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31460 [Circumvention/Snowflake]: Don't reveal proxy IDs in broker /debug

[Tor Bug Tracker & Wiki]

#31460: Don't reveal proxy IDs in broker /debug
-+
 Reporter:  phw  |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by cohosh):

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


Comment:

 Merged in `00eb4aadf5` and deployed as of `2019/08/27 14:06:07`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-9.0-must-nightly,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 > >  - fxc2 requires the winpthread dll to be in its bin directly IIRC;
 but I don't see where you're copying that. (I might have missed it. If
 you're not getting errors on fxc2 it must be working.)
 >
 > I think we don't need it when building with `mingw-w64-clang`. At least
 the build passes and I'd suspect compile time issues if that were a
 problem.
 >

 No, from my recollection it will compile fine but won't run if the dll is
 missing from the directory.  (However if firefox builds, then fxc2 didn't
 error and it worked...)


 > >  - I'm not sure what you do about PDBs; but it would be good to get a
 bug on file about generating/outputting them. (Perhaps in some
 configuration generating the static clang libraries with debug info also.)
 >
 > I agree. Right now don't generate them.

 I suspect you do generate them; but without setting MOZ_COPY_PDBs they are
 not winding up next to the outputed files so they're not winding up in the
 final tarball. You could stick that into the mozconfig and see if they
 show up though.

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

Re: [tor-bugs] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-9.0-must-nightly,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:44 tom]:
 >  - Have you confirmed you don't need the spec thing for
 https://bugzilla.mozilla.org/show_bug.cgi?id=1460801 ?  (If so, I can
 close that bug.)

 I think it worked for me back then a couple of months ago when I worked on
 the toolchain. I'll double-check with nightly builds once things landed
 but am optimistic.

 >  - fxc2 requires the winpthread dll to be in its bin directly IIRC; but
 I don't see where you're copying that. (I might have missed it. If you're
 not getting errors on fxc2 it must be working.)

 I think we don't need it when building with `mingw-w64-clang`. At least
 the build passes and I'd suspect compile time issues if that were a
 problem.

 >  - I see some flags in our mozconfig you don't have:
 >- https://searchfox.org/mozilla-
 
central/rev/325c1a707819602feff736f129cb36055ba6d94f/browser/config/mozconfigs/win32/mingwclang#53-54

 Yes, I am not sure why we don't need those but the build is not breaking,
 so we could leave that investigation for later.

 >  - I'm not sure what you do about PDBs; but it would be good to get a
 bug on file about generating/outputting them. (Perhaps in some
 configuration generating the static clang libraries with debug info also.)

 I agree. Right now don't generate them.

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

Re: [tor-bugs] #31536 [Applications/Tor Browser]: Allow using Kerberos ticket

[Tor Bug Tracker & Wiki]

#31536: Allow using Kerberos ticket
--+--
 Reporter:  mbocek|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


Comment:

 I'm not a Tor Browser Developer, but this sounds like an unsupported use
 case.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31369 [Core Tor/Stem]: HSv3 descriptor support in stem

[Tor Bug Tracker & Wiki]

#31369: HSv3 descriptor support in stem
-+---
 Reporter:  asn  |  Owner:  atagar
 Type:  defect   | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs onionbalance scaling  |  Actual Points:
Parent ID:  #26768   | Points:
 Reviewer:   |Sponsor:  Sponsor27-can
-+---
Changes (by asn):

 * parent:   => #26768


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26768 [Core Tor/Tor]: Support onionbalance in HSv3

[Tor Bug Tracker & Wiki]

#26768: Support onionbalance in HSv3
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs scaling onionbalance  |  Actual Points:
  network-team-roadmap-september tor-spec|
Parent ID:  #29998   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by asn):

 FWIW, I learned that Joe Landers started working on onionbalance v3 a few
 months ago and have some stem code and OB code that could be useful to us:
 
​https://github.com/joelanders/stem/commit/e8455584cf50d7a398f994a7ea761baf3c7d6c00
 
​https://github.com/joelanders/onionbalance/commit/1d30e6c5076ec2ee17e4b7a2a63ed72d0c32a670

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31369 [Core Tor/Stem]: HSv3 descriptor support in stem

[Tor Bug Tracker & Wiki]

#31369: HSv3 descriptor support in stem
-+---
 Reporter:  asn  |  Owner:  atagar
 Type:  defect   | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs onionbalance scaling  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor27-can
-+---

Comment (by asn):

 FWIW, I learned that Joe Landers started working on onionbalance v3 a few
 months ago and have some stem code and OB code that could be useful to us:
 
https://github.com/joelanders/stem/commit/e8455584cf50d7a398f994a7ea761baf3c7d6c00
 
https://github.com/joelanders/onionbalance/commit/1d30e6c5076ec2ee17e4b7a2a63ed72d0c32a670

 Damian, perhaps the stem code might be worth checking out in case you can
 steal stuff. Joe is more than happy for us to use his code.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-9.0-must-nightly,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 - Have you confirmed you don't need the spec thing for
 https://bugzilla.mozilla.org/show_bug.cgi?id=1460801 ?  (If so, I can
 close that bug.)
  - fxc2 requires the winpthread dll to be in its bin directly IIRC; but I
 don't see where you're copying that. (I might have missed it. If you're
 not getting errors on fxc2 it must be working.)
  - I see some flags in our mozconfig you don't have:
- https://searchfox.org/mozilla-
 
central/rev/325c1a707819602feff736f129cb36055ba6d94f/browser/config/mozconfigs/win32/mingwclang#53-54
  - I'm not sure what you do about PDBs; but it would be good to get a bug
 on file about generating/outputting them. (Perhaps in some configuration
 generating the static clang libraries with debug info also.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31385 [Circumvention/Snowflake]: Snowflake client fails after bootstrap

[Tor Bug Tracker & Wiki]

#31385: Snowflake client fails after bootstrap
-+
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Replying to [comment:25 amiableclarity2011]:
 > Hello, currently, in China, I still can't open any webpage in 9.0a4
 version Tor browser through snowflake bridge. I can connect to Tor network
 through snowflake bridge. I upload my torrc-defaults file, my torrc file,
 my state file, my cached-microdescs.new file and my cached-descriptors
 file.

 Hi amiableclarity2011,

 As cypherpunks said, we've pushed a fix out for this ticket and it will
 take a while for updates to propagate. Hopefully your connection will
 improve soon.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29211 [Core Tor/Tor]: Distribute config.c functionality across more modules

[Tor Bug Tracker & Wiki]

#29211: Distribute config.c functionality across more modules
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:
Parent ID:   | Points:  23
 Reviewer:   |Sponsor:  Sponsor31-can
-+-

Comment (by teor):

 Hi Nick,

 Here are my initial thoughts on the branches I reviewed.
 I want to think about them a bit more, and review and revise them before
 the sponsor 31 meeting on Thursday.
 I'd like a response at that meeting, rather than on this ticket.
 But I wanted to give you time to think through them before the meeting.

 The goal of sponsor 31 is to improve code quality.
 But I worry that this pull request series has not improved our code
 quality (yet!), team processes, or coding habits.

 I wanted more:
 * collaboration on the design,
 * summary and detailed design documentation,
 * opportunities to write code for large refactors myself,
 * function documentation and callback documentation,
 * code comments around tricky code (or less tricky code),
 * automated code transform scripts (sed or coccinelle),
 * unit tests,
 * tests for typical options used by Tor Browser, and possibly other
 significant uses of tor, (unit tests, chutney, or stem),
 * working stem tests in CI (rather than stem CI having allow failures due
 to #29437).

 I wanted less:
 * CI failures,
 * regressions (#31495, #31527),
 * technical debt,
 * missing changes files,
 * pull request merge conflicts / target branch mistakes (which make
 reviews difficult),
 * pull requests in the review backlog,
 * dependencies between commits and pull requests (which make fixes
 difficult),
 * exceptions to the normal review rules and review processes,
 * pressure to complete reviews by a deadline.

 Overall it seems that this process has been difficult for all of us.
 I would like us to pause for a while, and work through the tensions that
 this refactor has brought up.

 I have some ideas about the root causes here.

 But I would like to hear your ideas at the sponsor 31 meeting on Thursday.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19774 [Circumvention/BridgeDB]: bridges.torproject.org could use a favicon

[Tor Bug Tracker & Wiki]

#19774: bridges.torproject.org could use a favicon
-+
 Reporter:  isis |  Owner:  antonela
 Type:  enhancement  | Status:  assigned
 Priority:  Very Low |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Minor| Resolution:
 Keywords:  ux-team, easy, ex-sponsor19  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  Sponsor30-must
-+
Changes (by antonela):

 * keywords:  ux-team, easy, ex-sponsor19, Sponsor30-must => ux-team, easy,
 ex-sponsor19
 * sponsor:   => Sponsor30-must


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19774 [Circumvention/BridgeDB]: bridges.torproject.org could use a favicon

[Tor Bug Tracker & Wiki]

#19774: bridges.torproject.org could use a favicon
-+-
 Reporter:  isis |  Owner:
 |  antonela
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Very Low |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Minor| Resolution:
 Keywords:  ux-team, easy, ex-sponsor19, |  Actual Points:
  Sponsor30-must |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * keywords:  ux-team, easy, ex-sponsor19 => ux-team, easy, ex-sponsor19,
 Sponsor30-must


Comment:

 Adding s30 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] #31293 [Applications/Tor Browser]: tor-android-service gradle failure when probing network interfaces

[Tor Bug Tracker & Wiki]

#31293: tor-android-service gradle failure when probing network interfaces
---+--
 Reporter:  sysrqb |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201908  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 FWIW: I've now built new .apks on one of my build machines taking #31357
 into account and have not been running into any issues. So, it's not a
 problem of #25623 alone being fixed at least.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:
 |  cypherpunks
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:  1000
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 this -> with.

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:
 |  cypherpunks
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:  1000
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Hey punks, what's wrong this your github??

 https://codeberg.org/crimeflare/cloudflare-tor

 You've decided to switch side? Really what the fuck happened to 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