date:20200501

Re: [tor-bugs] #33222 [Core Tor/Tor]: Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests

2020-05-01 Thread Tor Bug Tracker & Wiki

#33222: Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:  1.1
Parent ID:  #33221 | Points:  6
 Reviewer:  nickm  |Sponsor:  Sponsor55-must
---+

Old description:

> 4.2. Checking IPv6 ORPort Reachability
>
> We propose that testing relays (and bridges) select some IPv6 extend-
> capable
> relays for their reachability circuits, and include their own IPv4 and
> IPv6
> ORPorts in the final extend cells on those circuits.
>
> The final extending relay will extend to the testing relay:
>   * using an existing authenticated connection to the testing relay
> (which may be over IPv4 or IPv6), or
>   * over a new connection via the IPv4 or IPv6 ORPort in the extend cell.
>
> The testing relay will confirm that test circuits can extend to both its
> IPv4 and IPv6 ORPorts.
>
> 4.2.1. Selecting the Final Extending Relay
>
> IPv6 ORPort reachability checks require an IPv6 extend-capable relay as
> the second-last hop of reachability circuits. (The testing relay is the
> last hop.)
>
> IPv6-extend capable relays must have:
>   * Relay subprotocol version 3 (or later), and
>   * an IPv6 ORPort.
> (See section 5.1 for the definition of Relay subprotocol version 3.)
>
> The other relays in the path do not require any particular protocol
> versions.
>
> 4.2.2. Extending from the Second-Last Hop
>
> IPv6 ORPort reachability circuits should put the IPv4 and IPv6 ORPorts in
> the extend cell for the final extend in reachability circuits.
>
> Supplying both ORPorts makes these extend cells indistinguishable from
> future client extend cells.
>
> If reachability succeeds, the testing relay (or bridge) will accept the
> final extend on one of its ORPorts, selected at random by the extending
> relay (see section 3.2.1).
>
> 4.2.3. Separate IPv4 and IPv6 Reachability Flags
>
> Testing relays (and bridges) will record reachability separately for IPv4
> and IPv6 ORPorts, based on the ORPort that the test circuit was received
> on.
>
> Here is a reliable way to do reachability self-tests for each ORPort:
>
> 1. Check for create cells on inbound ORPort connections
>
> Check for a cell on any IPv4 and any IPv6 ORPort. (We can't know which
> listener(s) correspond to the advertised ORPorts, particularly when using
> NAT.) Make sure the cell was received on an inbound OR connection.
>
> 2. Check for created cells from testing circuits on outbound OR
> connections
>
> Check for a returned created cell on our IPv4 and IPv6 self-test
> circuits. Make sure those circuits were on outbound OR connections.
>
> By combining these tests, we confirm that we can:
> * reach our own ORPorts with testing circuits
> * send and receive cells via inbound OR connections to our own ORPorts
> * send and receive cells via outbound OR connections to other relays'
> ORPorts
>
> From proposal 311, section 4.2:
> https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-
> ipv6-reachability.txt#n283

New description:

 4.2. Checking IPv6 ORPort Reachability

 We propose that testing relays (and bridges) select some IPv6 extend-
 capable
 relays for their reachability circuits, and include their own IPv4 and
 IPv6
 ORPorts in the final extend cells on those circuits.

 The final extending relay will extend to the testing relay:
   * using an existing authenticated connection to the testing relay
 (which may be over IPv4 or IPv6), or
   * over a new connection via the IPv4 or IPv6 ORPort in the extend cell.

 The testing relay will confirm that test circuits can extend to both its
 IPv4 and IPv6 ORPorts.

 4.2.1. Selecting the Final Extending Relay

 IPv6 ORPort reachability checks require an IPv6 extend-capable relay as
 the second-last hop of reachability circuits. (The testing relay is the
 last hop.)

 IPv6-extend capable relays must have:
   * Relay subprotocol version 3 (or later), and
   * an IPv6 ORPort.
 (See section 5.1 for the definition of Relay subprotocol version 3.)

 The other relays in the path do not require any particular protocol
 versions.

 4.2.2. Extending from the Second-Last Hop

 IPv6 ORPort reachability circuits should put the IPv4 and IPv6 ORPorts in
 the extend cell for the final extend in reachability circuits.

 Supplying both ORPorts makes these extend cells indistinguishable from
 future client extend cells.

 If reachability succeeds, the testing relay (or bridge) will accept the
 final extend on one of its ORPorts, selected at random by the extending
 relay (see section 3.2.1).

 4.2.3. Separate IPv4 and IPv6 Reachability Flags

 Testing relays (a

Re: [tor-bugs] #33222 [Core Tor/Tor]: Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests

2020-05-01 Thread Tor Bug Tracker & Wiki

#33222: Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:  1.1
Parent ID:  #33221 | Points:  6
 Reviewer:  nickm  |Sponsor:  Sponsor55-must
---+

Old description:

> 4.2. Checking IPv6 ORPort Reachability
>
> We propose that testing relays (and bridges) select some IPv6 extend-
> capable
> relays for their reachability circuits, and include their own IPv4 and
> IPv6
> ORPorts in the final extend cells on those circuits.
>
> The final extending relay will extend to the testing relay:
>   * using an existing authenticated connection to the testing relay
> (which may be over IPv4 or IPv6), or
>   * over a new connection via the IPv4 or IPv6 ORPort in the extend cell.
>
> The testing relay will confirm that test circuits can extend to both its
> IPv4 and IPv6 ORPorts.
>
> 4.2.1. Selecting the Final Extending Relay
>
> IPv6 ORPort reachability checks require an IPv6 extend-capable relay as
> the second-last hop of reachability circuits. (The testing relay is the
> last hop.)
>
> IPv6-extend capable relays must have:
>   * Relay subprotocol version 3 (or later), and
>   * an IPv6 ORPort.
> (See section 5.1 for the definition of Relay subprotocol version 3.)
>
> The other relays in the path do not require any particular protocol
> versions.
>
> 4.2.2. Extending from the Second-Last Hop
>
> IPv6 ORPort reachability circuits should put the IPv4 and IPv6 ORPorts in
> the extend cell for the final extend in reachability circuits.
>
> Supplying both ORPorts makes these extend cells indistinguishable from
> future client extend cells.
>
> If reachability succeeds, the testing relay (or bridge) will accept the
> final extend on one of its ORPorts, selected at random by the extending
> relay (see section 3.2.1).
>
> 4.2.3. Separate IPv4 and IPv6 Reachability Flags
>
> Testing relays (and bridges) will record reachability separately for IPv4
> and IPv6 ORPorts, based on the ORPort that the test circuit was received
> on.
>
> Here is a reliable way to do reachability self-tests for each ORPort:
>
> 1. Check for create cells on inbound ORPort connections
>
> Check for a cell on any IPv4 and any IPv6 ORPort. (We can't know which
> listener(s) correspond to the advertised ORPorts, particularly when using
> NAT.) Make sure the cell was received on an inbound OR connection.
>
> 2. Check for created cells from testing circuits on outbound OR
> connections
>
> Check for a returned created cell on our IPv4 and IPv6 self-test
> circuits. Make sure those circuits were on outbound OR connections.
>
> By combining these tests, we confirm that we can:
> * reach our own ORPorts with testing circuits
> * send and receive cells via inbound OR connections to our own ORPorts
> * send and receive cells via outbound OR connections to other relays'
> ORPorts
>
> This isn't a perfect test, there are a few false positives:
> * relays with multiple IPv4 or IPv6 ORPorts, where only some ports are
> reachable:
>   * (this configuration is uncommon, but multiple ORPorts are supported)
>   * the final extend cell contains the advertised IPv6 address of the
> self-testing relay
>   * if the extending relay already has a connection to an old but working
> ORPort, it may use that connection instead
>   * so these tests can pass, even when the advertised ORPort is
> unreachable
> * relays whose keys have been copied from another relay in the consensus,
> for similar reasons
>   * this configuration is rare and unsupported
>
> From proposal 311, section 4.2:
> https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-
> ipv6-reachability.txt#n283

New description:

 4.2. Checking IPv6 ORPort Reachability

 We propose that testing relays (and bridges) select some IPv6 extend-
 capable
 relays for their reachability circuits, and include their own IPv4 and
 IPv6
 ORPorts in the final extend cells on those circuits.

 The final extending relay will extend to the testing relay:
   * using an existing authenticated connection to the testing relay
 (which may be over IPv4 or IPv6), or
   * over a new connection via the IPv4 or IPv6 ORPort in the extend cell.

 The testing relay will confirm that test circuits can extend to both its
 IPv4 and IPv6 ORPorts.

 4.2.1. Selecting the Final Extending Relay

 IPv6 ORPort reachability checks require an IPv6 extend-capable relay as
 the second-last hop of reachability circuits. (The testing relay is the
 last hop.)

 IPv6-extend capable relays must have:
   * Relay subprotocol version 3 (or later), and
   * an IPv6 ORPort.
 (See section 5.

Re: [tor-bugs] #33222 [Core Tor/Tor]: Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests

2020-05-01 Thread Tor Bug Tracker & Wiki

#33222: Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:  1.1
Parent ID:  #33221 | Points:  6
 Reviewer:  nickm  |Sponsor:  Sponsor55-must
---+

Comment (by teor):

 Thanks for the review!

 I might be a bit busy next week with non-work tasks, but I'll try to do at
 least one revision.

 Replying to [comment:7 teor]:
 > It sends IPv4-only and IPv6-only extends on reachability circuits, to
 any third hop.
 >
 > Here's what we need to do before we merge:
 > * 4.2.1 Selecting the Final Extending Relay (this ticket)
 >   * 5. Declare Support for Subprotocol Version "Relay=3" (#33226)
 > * unit tests
 > * changes files
 >
 > Then we can iterate on the remaining work.

 My next priority is to:
 * Separate tor's IPv4 and IPv6 reachability flags (#34067)

 So we know that we're actually getting IPv6 connections. (I'm pretty sure
 we are now, but we don't want to accidentally break 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] #34077 [Core Tor/Tor]: Fix compilation with GCC 10

2020-05-01 Thread Tor Bug Tracker & Wiki

#34077: Fix compilation with GCC 10
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:  teor  |Sponsor:
--+
Changes (by teor):

 * status:  needs_review => merge_ready
 * reviewer:   => teor


Comment:

 Both of these look fine.

 I'll let you decide how you want to 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] #32579 [Core Tor/Tor]: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case statements

2020-05-01 Thread Tor Bug Tracker & Wiki

#32579: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case
statements
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  reopened
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  code-correctness  |  Actual Points:
Parent ID:  #34078| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * parent:   => #34078


Comment:

 See also #34078.

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

Re: [tor-bugs] #34078 [Core Tor/Tor]: Fix compilation warnings with clang 10.0.0

2020-05-01 Thread Tor Bug Tracker & Wiki

#34078: Fix compilation warnings with clang 10.0.0
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:1 nickm]:
 > I'm not sure whether we should clean all of the switch-statement fall-
 through warnings or not.  There are a whole bunch of them.  (See
 attachment.)

 See #32579 for the last time we talked about `clang -Wimplicit-
 fallthrough`.

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

Re: [tor-bugs] #34015 [Applications/Tor Browser]: geckoview is not built reproducible

2020-05-01 Thread Tor Bug Tracker & Wiki

#34015: geckoview is not built reproducible
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam202004   |
Parent ID:  #33659   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * parent:  #33626 => #33659


Comment:

 I think this might actually be
 https://bugzilla.mozilla.org/show_bug.cgi?id=1626188 for which a fix
 landed on mozilla-central recently. We'll pick that up after the next
 rebase and can re-check things then.

 (It seems Trac can't handle parent<->child relation ships deeper than 5
 levels, so re-parenting to be able to comment at all)

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

Re: [tor-bugs] #31239 [Internal Services/Tor Sysadmin Team]: automate installs

2020-05-01 Thread Tor Bug Tracker & Wiki

#31239: automate installs
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-april|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 we might have a problem with automated installs using debootstrap, as it
 sets up usrmerge by default, which seems to cause significant problems:

 https://wiki.debian.org/Teams/Dpkg/MergedUsr

 we might want to switch to mmdebstrap for performance if not reliability
 anyways.

 this will at least need research and testing to confirm this is a problem.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34080 [Circumvention/Snowflake]: Avoid double delays from ReconnectTimeout

2020-05-01 Thread Tor Bug Tracker & Wiki

#34080: Avoid double delays from ReconnectTimeout
-+
 Reporter:  dcf  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 [https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/client/lib/snowflake.go?id=72cfb96edeb7c9a3c93d38539bc31a51e30dbe8d#n18
 ReconnectTimeout] is used in 2 places:
  * In [https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/client/lib/webrtc.go?id=72cfb96edeb7c9a3c93d38539bc31a51e30dbe8d#n223
 exchangeSDP], where it is a delay inserted between calls to
 `broker.Negotiate` until one of them succeeds.
{{{
 Failed to retrieve answer. Retrying in 10s
}}}
  * In the main [https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/client/snowflake.go?id=72cfb96edeb7c9a3c93d38539bc31a51e30dbe8d#n27
 ConnectLoop], where it is a delay inserted between every check for getting
 a new snowflake.
{{{
 WebRTC:   Retrying in 10s...
}}}

 The broker itself also terminates requests after 10s when the chosen proxy
 doesn't respond: `BrokerChannel Response: 504 Gateway Timeout`.

 This situation sometimes results in double delays. Here are two cases I've
 identified.
  * The client requests a proxy, the broker responds immediately with an
 answer, but the proxy doesn't work. After waiting the `DataChannelTimeout`
 to decide that the proxy doesn't work, the client waits an ''additional''
 `ReconnectTimeout` in `ConnectLoop`.
Here, I've set `DataChannelTimeout` to 10s. Notice that between
 `DataChannel created` and `Collecting a new Snowflake` there are 20s
 (which is `DataChannelTimeout` + `ReconnectTimeout`), when it really
 should only be 10s.
{{{
 2020/04/30 22:38:29 Received Answer.
 2020/04/30 22:38:29 WebRTC: DataChannel created.
 2020/04/30 22:38:39 establishDataChannel: timeout waiting for
 DataChannel.OnOpen
 2020/04/30 22:38:39 WebRTC: closing PeerConnection
 2020/04/30 22:38:39 WebRTC: Closing
 2020/04/30 22:38:39 WebRTC: WebRTC: Could not establish DataChannel
 Retrying in 10s...
 2020/04/30 22:38:49 WebRTC: Collecting a new Snowflake. Currently at [0/1]
 }}}
  * The client requests a proxy, and the broker waits for 10s to respond
 with a 504 Gateway Timeout (indicating that the chosen proxy did not
 return an answer to the broker in time). The client waits 10s for the
 broker to respond, then waits another `ReconnectTimeout` in exchangeSDP
 before trying the broker again.
{{{
 2020/04/30 22:39:30 Negotiating via BrokerChannel...
 2020/04/30 22:39:41 BrokerChannel Response: 504 Gateway Timeout
 2020/04/30 22:39:41 BrokerChannel Error: Unexpected error, no answer.
 2020/04/30 22:39:41 Failed to retrieve answer. Retrying in 10s
 2020/04/30 22:39:51 Negotiating via BrokerChannel...
}}}

 Both these cases can probably be fixed by running the timer in parallel
 with the periodic operation they are rate limiting. That is, instead of
 {{{
 for {
 operation()
 <-time.After(ReconnectTimeout)
 }
 }}}
 it can be
 {{{
 for {
 timer := time.After(ReconnectTimeout)
 operation()
 <-timer
 }
 }}}
 That way, if the operation itself takes more than 10s, `ReconnectTimeout`
 doesn't impose any additional delay.

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

Re: [tor-bugs] #34042 [Circumvention/Snowflake]: Reduce DataChannelTimeout

2020-05-01 Thread Tor Bug Tracker & Wiki

#34042: Reduce DataChannelTimeout
-+
 Reporter:  dcf  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dcf):

 * Attachment "0001-Reduce-DataChannelTimeout-from-30s-to-10s.patch" 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] #34042 [Circumvention/Snowflake]: Reduce DataChannelTimeout

2020-05-01 Thread Tor Bug Tracker & Wiki

#34042: Reduce DataChannelTimeout
-+--
 Reporter:  dcf  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * status:  new => needs_review


Comment:

 Thanks for testing on the VPS. Here is a patch to lower the timeout to 10
 s.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34081 [Internal Services/Tor Sysadmin Team]: Undo giving@ to RT, redirect to grants team

2020-05-01 Thread Tor Bug Tracker & Wiki

#34081: Undo giving@ to RT, redirect to grants team
-+-
 Reporter:  ggus |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Hi,

 Grants asked me to undo the email redirection to RT.

 Please redirect giving@tpo alias to these folks:

 isabela@tpo, bekeela@tpo, smith@tpo, sue@tpo

 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] #33973 [Applications/Tor Browser]: Create fat .aar for geckoview

2020-05-01 Thread Tor Bug Tracker & Wiki

#33973: Create fat .aar for geckoview
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam202004, GeorgKoppen202004|
Parent ID:  #33184   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * parent:  #33626 => #33184


Comment:

 Okay, for those of you sitting at home and watching along, I finally got
 this going (thanks for boklm for the invaluable help). A fat .aar file
 should be buildable with `bug_33973_v2`
 (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_33973_v2&id=31d4d5b5c57c45603958295aa92aafe51e6c29d8).

 (Reparenting as well as Trac does not like a depth > 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

[tor-bugs] #34082 [Core Tor/Tor]: Master ticket for client side rendezvous circuit related bugs that cause reachability problems in HSv3 land

2020-05-01 Thread Tor Bug Tracker & Wiki

#34082: Master ticket for client side rendezvous circuit related bugs that cause
reachability problems in HSv3 land
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This is the master ticket for some reachability issues I discovered while
 stress testing my onionbalance v3 setup. They all occurred while handling
 HSv3 services.

 At least two of them always occur together, but handling them as separate
 tickets for now and keeping this master ticket to glue them together,
 since they all mention different stack traces.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34083 [Core Tor/Tor]: Client rendezvous circuit is no longer in circuit_wait but in pending_entry_connections

2020-05-01 Thread Tor Bug Tracker & Wiki

#34083: Client rendezvous circuit is no longer in circuit_wait but in
pending_entry_connections
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:  #34082
   Points:|   Reviewer:
  Sponsor:|
--+
 When you are creating many rendezvous client circuits with a reasonable
 concurrency, you get tons of messages in the log file marked as bug like
 this:

 {{{
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d877d94940 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d8789c16c0 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d875eef5a0 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d876063640 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d877b92960 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d8764ae550 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d878a83f00 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d877854530 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d878cac3a0 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d875b8d290 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d8788a4d70 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d878144a30 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug:
 0x55d877a2dc30 is no longer in circuit_wait. Its current state is waiting
 for rendezvous desc. Why is it on pending_entry_connections? (on Tor
 0.4.4.0-alpha-dev )
 }}}

 No sense to send more lines since they are all the same, but just with
 different circuit ID. The number of such messages exceeds 1000 in a total
 say at least 100.000 built rendezvous circuits.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34084 [Core Tor/Tor]: HSv3: Bug at setup_intro_circ_auth_key at ../src/feature/hs/hs_client.c:739

2020-05-01 Thread Tor Bug Tracker & Wiki

#34084: HSv3: Bug at setup_intro_circ_auth_key at 
../src/feature/hs/hs_client.c:739
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:  #34082
   Points:|   Reviewer:
  Sponsor:|
--+
 Client side HSv3 non fatal bug. It occurs like between ~80-120 times in a
 total of 100.000 built rendezvous circuits:

 {{{
 Mar 31 18:44:17.000 [warn] tor_bug_occurred_(): Bug:
 ../src/feature/hs/hs_client.c:739: setup_intro_circ_auth_key: This line
 should not have been reached. (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Line unexpectedly
 reached at setup_intro_circ_auth_key at ../src/feature/hs/hs_client.c:739.
 Stack trace: (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(log_backtrace_impl+0x56)
 [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(tor_bug_occurred_+0x16c)
 [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug:
 tor(hs_client_circuit_has_opened+0x342) [0x55d8749ceb22] (on Tor 0.4.4.0
 -alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug:
 tor(circuit_send_next_onion_skin+0x2b8) [0x55d874930d38] (on Tor 0.4.4.0
 -alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(+0xbe4ba) [0x55d8749664ba] (on Tor
 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor
 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4)
 [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(command_process_cell+0x2c8)
 [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb)
 [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor
 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(connection_handle_read+0xa92)
 [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor
 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev
 )
 Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor
 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(do_main_loop+0xff)
 [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(tor_run_main+0x10b5)
 [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca]
 (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on
 Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0
 -alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on
 Tor 0.4.4.0-alpha-dev )
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34085 [Core Tor/Tor]: HSv3: Bug Non-fatal assertion in hs_client.c:518: intro_circ_is_ok

2020-05-01 Thread Tor Bug Tracker & Wiki

#34085: HSv3: Bug Non-fatal assertion in hs_client.c:518: intro_circ_is_ok
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:  #34082
   Points:|   Reviewer:
  Sponsor:|
--+
 Client side HSv3 non fatal bug. It occurs like between ~80-120 times in a
 total of 100.000 built rendezvous circuits:

 {{{
 Mar 31 18:44:17.000 [warn] tor_bug_occurred_(): Bug:
 ../src/feature/hs/hs_client.c:518: intro_circ_is_ok: Non-fatal assertion
 !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (on Tor 0.4.4.0
 -alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion
 !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in
 intro_circ_is_ok at ../src/feature/hs/hs_client.c:518. Stack trace: (on
 Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(log_backtrace_impl+0x56)
 [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(tor_bug_occurred_+0x16c)
 [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(hs_client_send_introduce1+0x271)
 [0x55d8749ce5e1] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug:
 tor(connection_ap_handshake_attach_circuit+0x3bd) [0x55d874949d5d] (on Tor
 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug:
 tor(connection_ap_attach_pending+0x178) [0x55d87494e108] (on Tor 0.4.4.0
 -alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug:
 tor(circuit_send_next_onion_skin+0x2b8) [0x55d874930d38] (on Tor 0.4.4.0
 -alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(+0xbe4ba) [0x55d8749664ba] (on Tor
 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor
 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4)
 [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(command_process_cell+0x2c8)
 [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb)
 [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor
 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(connection_handle_read+0xa92)
 [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor
 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev
 )
 Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor
 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(do_main_loop+0xff)
 [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(tor_run_main+0x10b5)
 [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca]
 (on Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on
 Tor 0.4.4.0-alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0
 -alpha-dev )
 Mar 31 18:44:17.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on
 Tor 0.4.4.0-alpha-dev )
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34086 [Core Tor/Tor]: HSv3: Bug Non-fatal assertion in hs_client.c:776: client_rendezvous_circ_has_opened

2020-05-01 Thread Tor Bug Tracker & Wiki

#34086: HSv3: Bug Non-fatal assertion in hs_client.c:776:
client_rendezvous_circ_has_opened
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:  #34082
   Points:|   Reviewer:
  Sponsor:|
--+
 Client side HSv3 non fatal bug. It occurs like between ~50 - 70 times in a
 total of 100.000 built rendezvous circuits:

 {{{
 Apr 03 14:53:04.000 [warn] tor_bug_occurred_(): Bug:
 ../src/feature/hs/hs_client.c:776: client_rendezvous_circ_has_opened: Non-
 fatal assertion !(!node_supports_v3_rendezvous_point(rp_node)) failed. (on
 Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion
 !(!node_supports_v3_rendezvous_point(rp_node)) failed in
 client_rendezvous_circ_has_opened at ../src/feature/hs/hs_client.c:776.
 Stack trace: (on Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(log_backtrace_impl+0x56)
 [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(tor_bug_occurred_+0x16c)
 [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(circuit_has_opened+0x80)
 [0x55d874947810] (on Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug:
 tor(circuit_send_next_onion_skin+0x2b8) [0x55d874930d38] (on Tor 0.4.4.0
 -alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(+0xbe4ba) [0x55d8749664ba] (on Tor
 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor
 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4)
 [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(command_process_cell+0x2c8)
 [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb)
 [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor
 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(connection_handle_read+0xa92)
 [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor
 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev
 )
 Apr 03 14:53:04.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor
 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(do_main_loop+0xff)
 [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(tor_run_main+0x10b5)
 [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca]
 (on Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on
 Tor 0.4.4.0-alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0
 -alpha-dev )
 Apr 03 14:53:04.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on
 Tor 0.4.4.0-alpha-dev )
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34087 [Core Tor/Tor]: HSv3: Bug: Non-fatal assertion in hs_client.c:981: close_or_reextend_intro_circ

2020-05-01 Thread Tor Bug Tracker & Wiki

#34087: HSv3: Bug: Non-fatal assertion in hs_client.c:981:
close_or_reextend_intro_circ
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:  #34082
   Points:|   Reviewer:
  Sponsor:|
--+
 Client side HSv3 non fatal bug. It occurs like between ~20 - 30 times in a
 total of 100.000 built rendezvous circuits:

 {{{
 Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug:
 ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_circ: Non-fatal
 assertion !(desc == NULL) failed. (on Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion
 !(desc == NULL) failed in close_or_reextend_intro_circ at
 ../src/feature/hs/hs_client.c:981. Stack trace: (on Tor 0.4.4.0-alpha-dev
 )
 Apr 11 08:58:25.000 [warn] Bug: tor(log_backtrace_impl+0x56)
 [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(tor_bug_occurred_+0x16c)
 [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug:
 tor(hs_client_receive_introduce_ack+0x2f5) [0x55d8749cfe95] (on Tor
 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(rend_process_relay_cell+0x226)
 [0x55d874a1e796] (on Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(+0xbe368) [0x55d874966368] (on Tor
 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor
 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4)
 [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(command_process_cell+0x2c8)
 [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb)
 [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor
 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(connection_handle_read+0xa92)
 [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor
 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev
 )
 Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor
 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(do_main_loop+0xff)
 [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(tor_run_main+0x10b5)
 [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca]
 (on Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on
 Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0
 -alpha-dev )
 Apr 11 08:58:25.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on
 Tor 0.4.4.0-alpha-dev )
 Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug:
 ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_circ: Non-fatal
 assertion !(desc == NULL) failed. (on Tor 0.4.4.0-alpha-dev )
 }}}

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

Re: [tor-bugs] #34082 [Core Tor/Tor]: Master ticket for client side rendezvous circuit related bugs that cause reachability problems in HSv3 land

2020-05-01 Thread Tor Bug Tracker & Wiki

#34082: Master ticket for client side rendezvous circuit related bugs that cause
reachability problems in HSv3 land
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by s7r):

 #34084 and #34085 are always one after each other (in this order, #34084
 first and #34085 second) and they are the ones that occur mostly.

 #34086 is the second one and #34087 the rarest.

 All connect happen while trying to connect to an onionbalance v3 frontend
 that has backends running same Tor version with no special setup or
 anything different (there is no possibility of misconfigured HS service or
 backend instance).

 If needed I can run on this setup different branches maybe with
 different/more log messages or patches to find out more if the stack trace
 is not sufficient.

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

Re: [tor-bugs] #33931 [Applications/Tor Browser]: obfs4 bridges are used instead of meek if meek is selected in Tor Browser for Android alpha

2020-05-01 Thread Tor Bug Tracker & Wiki

#33931: obfs4 bridges are used instead of meek if meek is selected in Tor 
Browser
for Android alpha
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-parity, tbb- |  Actual Points:
  regression, TorBrowserTeam202004   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:8 gk]:
 > Replying to [comment:7 sysrqb]:
 > > Replying to [comment:6 acat]:
 > > > I guess there are no other values that could make `bridgeType=0`
 other than the empty string? If we know all the possible values of
 `userDefinedBridgeList` (when `bridgeType == 0`), would it make sense to
 have cases for all of them, and then have a default that throws an error
 (similar to the switch in https://gitweb.torproject.org/user/sysrqb/tor-
 browser-
 build.git/commit/?h=bug33931_00&id=91e6aec4f60783fc0008d4d3c60c29ddecafac0d)?
 > >
 > > The defined cases in this patch are the only pluggable transports we
 currently use (`obfs4` and `meek(_lite)`). In the past, we had `obfs3`. I
 don't think we should expand this list, but (after thinking about this a
 little more) we should fail safe if the type is not recognized instead of
 "all bridges" being the default. I'll add that in a fixup commit. Thanks!
 >
 > I am not exactly sure if that's what you meant but I think the case
 where `bridgeType` for whatever reason is still `0` at the end of
 `openBridgeSream()` should be treated in `addBridgesFromResources()` in
 the `throw` block. That is, there should not be a `case 0` check anymore.
 Keeping that smells just like trouble we are currently dealing with. We
 start to be explicit with your patches in this bug. so let's avoid
 ambiguity here where we can.

 I think I was imagining that we would `throw` at the end of
 `openBridgeStream()`, but letting`addBridgesFromResources()` handle this
 error case seems okay to me, in this case, as well.

 I pushed a fixup commit onto my tor-android-service `bug33931_00` branch,
 and I pushed a new tor-browser-build branch `bug33931_01` containing an
 updated TOPL patch.

 https://gitweb.torproject.org/user/sysrqb/tor-android-
 service.git/commit/?h=bug33931_00&id=42d2cdb46542ff488ce0ed4bf9e5b41b3a8356a7

 https://gitweb.torproject.org/user/sysrqb/tor-browser-
 build.git/commit/?h=bug33931_01&id=04da65342a76f74b3d4a58601f326ded457dc97a

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34088 [Core Tor/Tor]: circuit_build_times_update_alpha(): Bug: Could not determine largest build time

2020-05-01 Thread Tor Bug Tracker & Wiki

#34088: circuit_build_times_update_alpha(): Bug: Could not determine largest 
build
time
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #34082
   Points:|   Reviewer:
  Sponsor:|
--+
 I don't think this is HSv3 ONLY related, but I can only make it happen
 while building large amounts of rendezvous circuits with reasonable
 concurrency (over 50). I am not assigning the tor-hs keyword for this
 reason, but sticking it to same master parent ticket.

 All lines are the same. It is seen for like 130-160 times during the build
 of little over 100.000 rendezvous circuits.

 {{{
 Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 20025ms and we've abandoned 0
 out of 136 circuits. (on Tor 0.4.4.0-alpha-dev )
 Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 20025ms and we've abandoned 0
 out of 137 circuits. (on Tor 0.4.4.0-alpha-dev )
 Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 20025ms and we've abandoned 0
 out of 138 circuits. (on Tor 0.4.4.0-alpha-dev )
 Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 20025ms and we've abandoned 0
 out of 139 circuits. (on Tor 0.4.4.0-alpha-dev )
 Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 20025ms and we've abandoned 0
 out of 140 circuits. (on Tor 0.4.4.0-alpha-dev )
 }}}

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

Re: [tor-bugs] #34088 [Core Tor/Tor]: circuit_build_times_update_alpha(): Bug: Could not determine largest build time

2020-05-01 Thread Tor Bug Tracker & Wiki

#34088: circuit_build_times_update_alpha(): Bug: Could not determine largest 
build
time
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #34082| Points:
 Reviewer:|Sponsor:
--+
Description changed by s7r:

Old description:

> I don't think this is HSv3 ONLY related, but I can only make it happen
> while building large amounts of rendezvous circuits with reasonable
> concurrency (over 50). I am not assigning the tor-hs keyword for this
> reason, but sticking it to same master parent ticket.
>
> All lines are the same. It is seen for like 130-160 times during the
> build of little over 100.000 rendezvous circuits.
>
> {{{
> Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
> not determine largest build time (0). Xm is 20025ms and we've abandoned 0
> out of 136 circuits. (on Tor 0.4.4.0-alpha-dev )
> Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
> not determine largest build time (0). Xm is 20025ms and we've abandoned 0
> out of 137 circuits. (on Tor 0.4.4.0-alpha-dev )
> Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
> not determine largest build time (0). Xm is 20025ms and we've abandoned 0
> out of 138 circuits. (on Tor 0.4.4.0-alpha-dev )
> Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
> not determine largest build time (0). Xm is 20025ms and we've abandoned 0
> out of 139 circuits. (on Tor 0.4.4.0-alpha-dev )
> Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
> not determine largest build time (0). Xm is 20025ms and we've abandoned 0
> out of 140 circuits. (on Tor 0.4.4.0-alpha-dev )
> }}}

New description:

 I don't think this is HSv3 ONLY related, but I can only make it happen
 while building large amounts of rendezvous circuits with reasonable
 concurrency (over 50). I am not assigning the tor-hs keyword for this
 reason, but sticking it to same master parent ticket.

 All lines are the same. It is seen for like 130-160 times during the build
 of little over 100.000 rendezvous circuits.

 {{{
 Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 20025ms and we've abandoned 0
 out of 136 circuits. (on Tor 0.4.4.0-alpha-dev )
 Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 20025ms and we've abandoned 0
 out of 137 circuits. (on Tor 0.4.4.0-alpha-dev )
 Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 20025ms and we've abandoned 0
 out of 138 circuits. (on Tor 0.4.4.0-alpha-dev )
 Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 20025ms and we've abandoned 0
 out of 139 circuits. (on Tor 0.4.4.0-alpha-dev )
 Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 20025ms and we've abandoned 0
 out of 140 circuits. (on Tor 0.4.4.0-alpha-dev )
 }}}

 EDIT: All lines are the same except it always abandons 0 out of N circuits
 and N is always different of course, increasing with +1 most of the times
 until the Bug warn disappears.

--

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

Re: [tor-bugs] #34081 [Internal Services/Tor Sysadmin Team]: Undo giving@ to RT, redirect to grants team

2020-05-01 Thread Tor Bug Tracker & Wiki

#34081: Undo giving@ to RT, redirect to grants team
-+
 Reporter:  ggus |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by arma):

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


Comment:

 It is done. (It will take effect in 0-4 hours.)

 Let us know when to revert the revert. :)

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

Re: [tor-bugs] #30812 [Applications/Tor Browser]: cant modify browser default background color - about:blank, about:newtab

2020-05-01 Thread Tor Bug Tracker & Wiki

#30812: cant modify browser default background color - about:blank, about:newtab
--+---
 Reporter:  kingfitz  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Thorin):

 upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1634602

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

Re: [tor-bugs] #33931 [Applications/Tor Browser]: obfs4 bridges are used instead of meek if meek is selected in Tor Browser for Android alpha

2020-05-01 Thread Tor Bug Tracker & Wiki

#33931: obfs4 bridges are used instead of meek if meek is selected in Tor 
Browser
for Android alpha
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile, tbb-parity, tbb- |  Actual Points:
  regression, TorBrowserTeam202004   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Replying to [comment:10 sysrqb]:
 > Replying to [comment:8 gk]:
 > > Replying to [comment:7 sysrqb]:
 > > > Replying to [comment:6 acat]:
 > > > > I guess there are no other values that could make `bridgeType=0`
 other than the empty string? If we know all the possible values of
 `userDefinedBridgeList` (when `bridgeType == 0`), would it make sense to
 have cases for all of them, and then have a default that throws an error
 (similar to the switch in https://gitweb.torproject.org/user/sysrqb/tor-
 browser-
 build.git/commit/?h=bug33931_00&id=91e6aec4f60783fc0008d4d3c60c29ddecafac0d)?
 > > >
 > > > The defined cases in this patch are the only pluggable transports we
 currently use (`obfs4` and `meek(_lite)`). In the past, we had `obfs3`. I
 don't think we should expand this list, but (after thinking about this a
 little more) we should fail safe if the type is not recognized instead of
 "all bridges" being the default. I'll add that in a fixup commit. Thanks!
 > >
 > > I am not exactly sure if that's what you meant but I think the case
 where `bridgeType` for whatever reason is still `0` at the end of
 `openBridgeSream()` should be treated in `addBridgesFromResources()` in
 the `throw` block. That is, there should not be a `case 0` check anymore.
 Keeping that smells just like trouble we are currently dealing with. We
 start to be explicit with your patches in this bug. so let's avoid
 ambiguity here where we can.
 >
 > I think I was imagining that we would `throw` at the end of
 `openBridgeStream()`, but letting`addBridgesFromResources()` handle this
 error case seems okay to me, in this case, as well.
 >
 > I pushed a fixup commit onto my tor-android-service `bug33931_00`
 branch, and I pushed a new tor-browser-build branch `bug33931_01`
 containing an updated TOPL patch.
 >
 > https://gitweb.torproject.org/user/sysrqb/tor-android-
 service.git/commit/?h=bug33931_00&id=42d2cdb46542ff488ce0ed4bf9e5b41b3a8356a7
 >
 > https://gitweb.torproject.org/user/sysrqb/tor-browser-
 build.git/commit/?h=bug33931_01&id=04da65342a76f74b3d4a58601f326ded457dc97a

 Looks good to me. Squashed and merged to `tor-android-service`'s `master`
 (commit ed2e1479eeddede01b1d510ef79dc5ec798b39c0) and merged to `tor-
 browser-build`'s `master` + a commit to pick the `tor-android-service`
 changes up (commits 04da65342a76f74b3d4a58601f326ded457dc97a and
 b858dca8745b583afd2660389ccd5a96630154a0).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34089 [Internal Services/Services Admin Team]: Add Apache ProxyPass directive on polyanthum to expose wolpertinger

2020-05-01 Thread Tor Bug Tracker & Wiki

#34089: Add Apache ProxyPass directive on polyanthum to expose wolpertinger
-+-
 Reporter:  phw  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services   |Version:
  Admin Team |
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #32740
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Over at #32740, we are developing a new service that will expose a REST
 API on polyanthum. OONI (and possibly other censorship measurement tools)
 will query this API to obtain bridges to test.

 Please add the following ProxyPass directive to polyanthum's Apache
 config:

 {{{
 ProxyPass /wolpertinger/ http://127.0.0.1:5000/
 }}}

 (For what it's worth, we've done this before in #30703, where anarcat
 documented how he went about implementing this.)

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

Re: [tor-bugs] #32740 [Circumvention/BridgeDB]: Implement a feedback loop between BridgeDB and OONI

2020-05-01 Thread Tor Bug Tracker & Wiki

#32740: Implement a feedback loop between BridgeDB and OONI
-+-
 Reporter:  phw  |  Owner:  phw
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s30-o23a2, anti-censorship-roadmap-  |  Actual Points:
  2020Q1 |
Parent ID:  #31280   | Points:  10
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-

Comment (by phw):

 FYI, I filed #34089 to expose wolpertinger's REST API on polyanthum.

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

Re: [tor-bugs] #34081 [Internal Services/Tor Sysadmin Team]: Undo giving@ to RT, redirect to grants team

2020-05-01 Thread Tor Bug Tracker & Wiki

#34081: Undo giving@ to RT, redirect to grants team
-+
 Reporter:  ggus |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by anarcat):

 should we destroy the queue as well or will that stay put?

 because people can still write to giv...@rt.torproject.org, will someone
 look at that queue at all?

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

[tor-bugs] #34090 [Applications]: qbittorrent

2020-05-01 Thread Tor Bug Tracker & Wiki

#34090: qbittorrent
+--
 Reporter:  rococo  |  Owner:  (none)
 Type:  task| Status:  new
 Priority:  High|  Component:  Applications
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 I am completely baffled on how to use BitTorrent for TPB downloads.
 Anyone with some help, please.  Thank you in advance.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34091 [Webpages]: "torrc" error message plus

2020-05-01 Thread Tor Bug Tracker & Wiki

#34091: "torrc" error message  plus
--+--
 Reporter:  mopzop|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Webpages
  Version:  Tor: unspecified  |   Severity:  Major
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I, am doing my best to learn what I can about using Tor, but it is causing
 problems that knows, now, what ignorant feels like. I, no longer can
 connect to the Internet with a regular browser, and is necessary for day
 to day usage utilizing bookmarks, and saved passwords for certain
 accounts. I, do not run Tor when using other browsers, nor do I, want, or
 can I, use Tor to access sites used on a daily basis. Neither, Chrome,
 Mozilla Firefox, or Google for that matter will allow me to do
 ''anything'' saying I, am not connected to the Internet, when most
 definitely, am connected.
 I, receive different messages about the DNS, router, or unable to diagnose
 the problem. The browser opens, but that is as far I, can get. I, cannot
 even log into my Google account, of which my problems began, meaning when
 I, logged out of Google everything stopped. Tor was doing the same,
 opening to the home page, and allowing me to access the blog, and email,
 only, but using DuckDuckGo returned one message:
 "Error 1016 Ray ID: 58cbdadddaeebb46 • 2020-05-01 19:19:35 UTC
 Origin DNS error"
 and one saying "torrc error." I, cannot recall each error message
 received, sorry. Apparently, Tor grants me access, now, but when my
 computer completely shut down, because of an "At Risk" message never, ever
 seen in my life popped up disabling use, and froze, forcing me to shut my
 device off. I, realized feeling more vulnerable, now to a virus, malware,
 etc.
 What is going on?

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

Re: [tor-bugs] #32740 [Circumvention/BridgeDB]: Implement a feedback loop between BridgeDB and OONI

2020-05-01 Thread Tor Bug Tracker & Wiki

#32740: Implement a feedback loop between BridgeDB and OONI
-+-
 Reporter:  phw  |  Owner:  phw
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s30-o23a2, anti-censorship-roadmap-  |  Actual Points:
  2020Q1 |
Parent ID:  #31280   | Points:  10
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-

Comment (by phw):

 I pushed work-in-progress code to the new
 [https://gitlab.torproject.org/torproject/anti-censorship/wolpertinger
 wolpertinger repository].

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

Re: [tor-bugs] #31528 [Circumvention/BridgeDB]: Get rid of BridgeDB's "chatspeak"

2020-05-01 Thread Tor Bug Tracker & Wiki

#31528: Get rid of BridgeDB's "chatspeak"
+
 Reporter:  phw |  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by phw):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:6 agix]:
 > There you go:
 >
 >
 
[https://github.com/agiix/bridgedb/commit/7d421714bb79733712da7d0ca704c2209d1d2e12]
 [[br]]
 The patch looks great, thanks! I left a few minor comments in the commit.
 Do you mind addressing them? After that, it's ready to merge.

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

[tor-bugs] #34092 [Circumvention/Snowflake]: Snowflake no longer working on Google Chrome

2020-05-01 Thread Tor Bug Tracker & Wiki

#34092: Snowflake no longer working on Google Chrome
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Circumvention/Snowflake
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 Extension icon disappeared and cannot enable Snowflake in Google Chrome.

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

Re: [tor-bugs] #34081 [Internal Services/Tor Sysadmin Team]: Undo giving@ to RT, redirect to grants team

2020-05-01 Thread Tor Bug Tracker & Wiki

#34081: Undo giving@ to RT, redirect to grants team
-+
 Reporter:  ggus |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 I think we should leave the rt queue intact. Next week ggus and others
 will do an rt training for new rt users, and having the giving queue there
 will let people look at, and practice handling, the mails that came in
 already.

 Part of the challenge, it turns out, is that in the past some folks used
 giving@tpo as the email address for external Tor accounts, so it's where
 password reset urls go. The better idea is to shift all of those external
 accounts so they use something else, like finance-admin@tpo, and then
 giving@ can be what it is designed for, which is humans trying to reach
 humans.

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

Re: [tor-bugs] #33222 [Core Tor/Tor]: Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests

Re: [tor-bugs] #33222 [Core Tor/Tor]: Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests

Re: [tor-bugs] #33222 [Core Tor/Tor]: Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests

Re: [tor-bugs] #34077 [Core Tor/Tor]: Fix compilation with GCC 10

Re: [tor-bugs] #32579 [Core Tor/Tor]: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case statements

Re: [tor-bugs] #34078 [Core Tor/Tor]: Fix compilation warnings with clang 10.0.0

Re: [tor-bugs] #34015 [Applications/Tor Browser]: geckoview is not built reproducible

Re: [tor-bugs] #31239 [Internal Services/Tor Sysadmin Team]: automate installs

[tor-bugs] #34080 [Circumvention/Snowflake]: Avoid double delays from ReconnectTimeout

Re: [tor-bugs] #34042 [Circumvention/Snowflake]: Reduce DataChannelTimeout

Re: [tor-bugs] #34042 [Circumvention/Snowflake]: Reduce DataChannelTimeout

[tor-bugs] #34081 [Internal Services/Tor Sysadmin Team]: Undo giving@ to RT, redirect to grants team

Re: [tor-bugs] #33973 [Applications/Tor Browser]: Create fat .aar for geckoview

[tor-bugs] #34082 [Core Tor/Tor]: Master ticket for client side rendezvous circuit related bugs that cause reachability problems in HSv3 land

[tor-bugs] #34083 [Core Tor/Tor]: Client rendezvous circuit is no longer in circuit_wait but in pending_entry_connections

[tor-bugs] #34084 [Core Tor/Tor]: HSv3: Bug at setup_intro_circ_auth_key at ../src/feature/hs/hs_client.c:739

[tor-bugs] #34085 [Core Tor/Tor]: HSv3: Bug Non-fatal assertion in hs_client.c:518: intro_circ_is_ok

[tor-bugs] #34086 [Core Tor/Tor]: HSv3: Bug Non-fatal assertion in hs_client.c:776: client_rendezvous_circ_has_opened

[tor-bugs] #34087 [Core Tor/Tor]: HSv3: Bug: Non-fatal assertion in hs_client.c:981: close_or_reextend_intro_circ

Re: [tor-bugs] #34082 [Core Tor/Tor]: Master ticket for client side rendezvous circuit related bugs that cause reachability problems in HSv3 land

Re: [tor-bugs] #33931 [Applications/Tor Browser]: obfs4 bridges are used instead of meek if meek is selected in Tor Browser for Android alpha

[tor-bugs] #34088 [Core Tor/Tor]: circuit_build_times_update_alpha(): Bug: Could not determine largest build time

Re: [tor-bugs] #34088 [Core Tor/Tor]: circuit_build_times_update_alpha(): Bug: Could not determine largest build time

Re: [tor-bugs] #34081 [Internal Services/Tor Sysadmin Team]: Undo giving@ to RT, redirect to grants team

Re: [tor-bugs] #30812 [Applications/Tor Browser]: cant modify browser default background color - about:blank, about:newtab

Re: [tor-bugs] #33931 [Applications/Tor Browser]: obfs4 bridges are used instead of meek if meek is selected in Tor Browser for Android alpha

[tor-bugs] #34089 [Internal Services/Services Admin Team]: Add Apache ProxyPass directive on polyanthum to expose wolpertinger

Re: [tor-bugs] #32740 [Circumvention/BridgeDB]: Implement a feedback loop between BridgeDB and OONI

Re: [tor-bugs] #34081 [Internal Services/Tor Sysadmin Team]: Undo giving@ to RT, redirect to grants team

[tor-bugs] #34090 [Applications]: qbittorrent

[tor-bugs] #34091 [Webpages]: "torrc" error message plus

Re: [tor-bugs] #32740 [Circumvention/BridgeDB]: Implement a feedback loop between BridgeDB and OONI

Re: [tor-bugs] #31528 [Circumvention/BridgeDB]: Get rid of BridgeDB's "chatspeak"

[tor-bugs] #34092 [Circumvention/Snowflake]: Snowflake no longer working on Google Chrome

Re: [tor-bugs] #34081 [Internal Services/Tor Sysadmin Team]: Undo giving@ to RT, redirect to grants team

35 matches

Site Navigation

Mail list logo

Footer information