Re: [tor-bugs] #33880 [Core Tor/Tor]: Confusing "Your relay has a very large number of connections to other relays" relay message

[Tor Bug Tracker & Wiki]

#33880: Confusing "Your relay has a very large number of connections to other
relays" relay message
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 rany: did your relay have an open ipv6 orport at the time?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33900 [Core Tor/Tor]: Check for invalid zero IPv4 addresses and ports in extend cells

[Tor Bug Tracker & Wiki]

#33900: Check for invalid zero IPv4 addresses and ports in extend cells
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal |   Keywords:  ipv6, prop311, technical-debt
Actual Points: |  Parent ID:  #33817
   Points:  0  |   Reviewer:
  Sponsor: |
  Sponsor55-must   |
---+---
 When we send and parse extend cells, we check that their IPv4 address
 field is not AF_UNSPEC.

 But we should also check for zero IPv4 addresses and zero ports. (Which
 are both invalid.)

 Code and points in #33817, I just needed a separate bug number.

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

Re: [tor-bugs] #33900 [Core Tor/Tor]: Check for invalid zero IPv4 addresses and ports in extend cells

[Tor Bug Tracker & Wiki]

#33900: Check for invalid zero IPv4 addresses and ports in extend cells
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.4.8-alpha
 Severity:  Normal | Resolution:  fixed
 Keywords:  ipv6, prop311, technical-debt  |  Actual Points:
Parent ID:  #33817 | Points:  0
 Reviewer: |Sponsor:
   |  Sponsor55-must
---+---
Changes (by teor):

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


Comment:

 See #33817.

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

Re: [tor-bugs] #33676 [Core Tor/Chutney]: Stop waiting a set time for microdescriptors

[Tor Bug Tracker & Wiki]

#33676: Stop waiting a set time for microdescriptors
---+---
 Reporter:  teor   |  Owner:  anuradha1904
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Chutney   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311, outreachy-ipv6  |  Actual Points:
Parent ID:  #33428 | Points:  0.5
 Reviewer:  teor   |Sponsor:  Sponsor55-can
---+---
Changes (by anuradha1904):

 * 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] #33817 [Core Tor/Tor]: Perform all IPv4 and IPv6 extend checks in one place

[Tor Bug Tracker & Wiki]

#33817: Perform all IPv4 and IPv6 extend checks in one place
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, prop311, technical-debt-   |  Actual Points:
  partial|
Parent ID:  #33220   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor55-must
-+-

Old description:

> Currently, tor checks that extend cells have IPv4 addresses in:
> [ ] some functions in circuitbuild_relay.c (a new file introduced by
> #33633)
> [ ] check_extend_cell() in onion.c
> [ ] extend_cell_from_extend2_cell_body() in onion.c
>   * (note that all relays that support IPv6 extends should be using
> extend2 cells, but we want to modify this code for consistency)
> [ ] channel_get_for_extend(), where only channels with IPv4 addresses are
> searched,
> [ ] and possibly other functions.
>
> We also want to fix a missing IPv6 check in:
> [x] connection_or_check_canonicity(), where only IPv4 addresses are
> considered canonical,
>   * (note that channel_tls_process_netinfo_cell() already handles IPv6
> canonicity correctly)
> Unlike the other changes, this change is a bug fix, and should not depend
> on the relay's configuration.
>
> We want to perform all these checks in the same place, so we can modify
> tor's behaviour based on:
> * tor's configuration
>   * including consensus parameters
> * the reachability of a relay's own IPv6 ORPort, and
> * any other relevant factors.

New description:

 Currently, tor checks that extend cells have IPv4 addresses in:
 [ ] some functions in circuitbuild_relay.c (a new file introduced by
 #33633)
 [ ] check_extend_cell() in onion.c
 [ ] extend_cell_from_extend2_cell_body() in onion.c
 [ ] and possibly other functions.

 We also want to fix a missing IPv6 check in:
 [x] connection_or_check_canonicity(), where only IPv4 addresses are
 considered canonical,
   * (note that channel_tls_process_netinfo_cell() already handles IPv6
 canonicity correctly)

 The canonical fix also fixes:
 [x] channel_get_for_extend(), where only channels with IPv4 addresses are
 searched.

 Unlike the other changes, this change is a bug fix, and should not depend
 on the relay's configuration.

 We want to perform all these checks in the same place, so we can modify
 tor's behaviour based on:
 * tor's configuration
   * including consensus parameters
 * the reachability of a relay's own IPv6 ORPort, and
 * any other relevant factors.

--

Comment (by teor):

 Note that channel_get_for_extend() is fixed by the canonical fix.

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

Re: [tor-bugs] #33896 [Metrics/Consensus Health]: Depictor: stop claiming so many digits of precision for clock skew

[Tor Bug Tracker & Wiki]

#33896: Depictor: stop claiming so many digits of precision for clock skew
--+-
 Reporter:  arma  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by tom):

 ACKing. This is trivial, but I don't expect I'll get to it until the
 quarantine is lifted.

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

Re: [tor-bugs] #33880 [Core Tor/Tor]: Confusing "Your relay has a very large number of connections to other relays" relay message

[Tor Bug Tracker & Wiki]

#33880: Confusing "Your relay has a very large number of connections to other
relays" relay message
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 See #24841 for what I believe is the same bug.

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

Re: [tor-bugs] #24841 [Core Tor/Tor]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?

[Tor Bug Tracker & Wiki]

#24841: Your relay has a very large number of connections to other relays. Is 
your
outbound address the same as your relay address?
-+-
 Reporter:  tyng |  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  043-backport-maybe, 042-backport-|  Actual Points:
  maybe, 033-triage-20180320,|
  033-removed-20180320, 035-deferred-20190115,   |
  041-proposed   |
Parent ID:  #33048   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor55-can
-+-

Comment (by arma):

 Ah ha! I had forgotten this ticket. I believe it is fully explained by
 #33880 -- these are reachability tests by directory authorities, and in
 0.3.1.1-alpha (ticket #17592, commit d5a151a0) we changed the timeout
 parameters such that it is quite likely that you will still have an old
 connection open from a directory authority when the next reachability test
 connection arrives. The numbers from the log message here line up
 perfectly with the numbers from the log message in that newer ticket.

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

Re: [tor-bugs] #33817 [Core Tor/Tor]: Perform all IPv4 and IPv6 extend checks in one place

[Tor Bug Tracker & Wiki]

#33817: Perform all IPv4 and IPv6 extend checks in one place
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, prop311, technical-debt-   |  Actual Points:
  partial|
Parent ID:  #33220   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor55-must
-+-

Old description:

> Currently, tor checks that extend cells have IPv4 addresses in:
> * some functions in circuitbuild_relay.c (a new file introduced by
> #33633)
> * check_extend_cell() in onion.c
> * extend_cell_from_extend2_cell_body() in onion.c
>   * (note that all relays that support IPv6 extends should be using
> extend2 cells, but we want to modify this code for consistency)
> * channel_get_for_extend(), where only channels with IPv4 addresses are
> searched,
> * and possibly other functions.
>
> We also want to fix a missing IPv6 check in:
> * connection_or_check_canonicity(), where only IPv4 addresses are
> considered canonical,
>   * (note that channel_tls_process_netinfo_cell() already handles IPv6
> canonicity correctly)
> Unlike the other changes, this change is a bug fix, and should not depend
> on the relay's configuration.
>
> We want to perform all these checks in the same place, so we can modify
> tor's behaviour based on:
> * tor's configuration
>   * including consensus parameters
> * the reachability of a relay's own IPv6 ORPort, and
> * any other relevant factors.

New description:

 Currently, tor checks that extend cells have IPv4 addresses in:
 [ ] some functions in circuitbuild_relay.c (a new file introduced by
 #33633)
 [ ] check_extend_cell() in onion.c
 [ ] extend_cell_from_extend2_cell_body() in onion.c
   * (note that all relays that support IPv6 extends should be using
 extend2 cells, but we want to modify this code for consistency)
 [ ] channel_get_for_extend(), where only channels with IPv4 addresses are
 searched,
 [ ] and possibly other functions.

 We also want to fix a missing IPv6 check in:
 [x] connection_or_check_canonicity(), where only IPv4 addresses are
 considered canonical,
   * (note that channel_tls_process_netinfo_cell() already handles IPv6
 canonicity correctly)
 Unlike the other changes, this change is a bug fix, and should not depend
 on the relay's configuration.

 We want to perform all these checks in the same place, so we can modify
 tor's behaviour based on:
 * tor's configuration
   * including consensus parameters
 * the reachability of a relay's own IPv6 ORPort, and
 * any other relevant factors.

--

Comment (by teor):

 Replying to [ticket:33817 teor]:
 > We also want to fix a missing IPv6 check in:
 > * connection_or_check_canonicity(), where only IPv4 addresses are
 considered canonical,
 >   * (note that channel_tls_process_netinfo_cell() already handles IPv6
 canonicity correctly)
 > Unlike the other changes, this change is a bug fix, and should not
 depend on the relay's configuration.

 I did this fix in #33899.

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

Re: [tor-bugs] #33899 [Core Tor/Tor]: Allow IPv6 addresses to be canonical

[Tor Bug Tracker & Wiki]

#33899: Allow IPv6 addresses to be canonical
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, prop311, network-team- |  Actual Points:  0.3
  roadmap-2020Q2 |
Parent ID:  #33220   | Points:  0.5
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-must
-+-
Changes (by teor):

 * status:  assigned => needs_review
 * reviewer:   => nickm
 * actualpoints:   => 0.3


Comment:

 See my PR:
 * master: https://github.com/torproject/tor/pull/1862

 I don't think we should backport this change.

 I don't think we should write unit tests for the logging here, because
 that will change in #33898. But I'm happy to write unit tests for the
 set_canonical() part of this fix.

 I'll let CI run first, and get an initial review. (The review isn't
 urgent, it's a bit of a side issue to #33817.)

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

Re: [tor-bugs] #33898 [Core Tor/Tor]: Stop modifying addr on connections, and delete real_addr

[Tor Bug Tracker & Wiki]

#33898: Stop modifying addr on connections, and delete real_addr
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, technical-debt, prop311  |  Actual Points:
Parent ID:  #33048 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-can
---+---

Comment (by teor):

 #33899 contains a tweak to the existing code, to consider IPv6 connections
 canonical. It also replaces the addr with the canonical IPv6 address,
 rather than an IPv4 address.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33899 [Core Tor/Tor]: Allow IPv6 addresses to be canonical

[Tor Bug Tracker & Wiki]

#33899: Allow IPv6 addresses to be canonical
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.4.4.x-final
Component:  Core |Version:  Tor: 0.3.1.1-alpha
  Tor/Tor|   Keywords:  ipv6, prop311, network-team-
 Severity:  Normal   |  roadmap-2020Q2
Actual Points:   |  Parent ID:  #33220
   Points:  0.5  |   Reviewer:
  Sponsor:   |
  Sponsor55-must |
-+-
 In #17604, we allowed IPv6 connections to set is_canonical_to_peer. But we
 did not let them set is_canonical.

 So channel_tls_process_netinfo_cell() handles IPv6 addresses, but
 connection_or_check_canonicity() does not.

 This inconsistency could be one cause of the logging issues in #24841.

 We should allow IPv6 connections to be canonical. We should also do some
 cleanup of the related connection address logging in #33898.

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

Re: [tor-bugs] #24841 [Core Tor/Tor]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?

[Tor Bug Tracker & Wiki]

#24841: Your relay has a very large number of connections to other relays. Is 
your
outbound address the same as your relay address?
-+-
 Reporter:  tyng |  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  043-backport-maybe, 042-backport-|  Actual Points:
  maybe, 033-triage-20180320,|
  033-removed-20180320, 035-deferred-20190115,   |
  041-proposed   |
Parent ID:  #33048   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor55-can
-+-
Changes (by teor):

 * keywords:
 033-triage-20180320, 033-removed-20180320, 035-deferred-20190115,
 041-proposed
 =>
 043-backport-maybe, 042-backport-maybe, 033-triage-20180320,
 033-removed-20180320, 035-deferred-20190115, 041-proposed
 * version:  Tor: 0.3.2.8-rc => Tor: 0.3.1.1-alpha


Comment:

 This log message was originally introduced in 0.3.1.1-alpha.

 Do you think we should backport this change?
 How far?

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

Re: [tor-bugs] #33898 [Core Tor/Tor]: Stop modifying addr on connections, and delete real_addr

[Tor Bug Tracker & Wiki]

#33898: Stop modifying addr on connections, and delete real_addr
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, technical-debt, prop311  |  Actual Points:
Parent ID:  #33048 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-can
---+---

Comment (by teor):

 Of all the tickets I've assigned to you so far, this is the most urgent
 and important one. It could save us all a lot of confusion (and debugging
 time) in future.

 It would be really useful to have it done in the next few weeks, before we
 ask relay operators to test IPv6 reachability self-checks.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33898 [Core Tor/Tor]: Stop modifying addr on connections, and delete real_addr

[Tor Bug Tracker & Wiki]

#33898: Stop modifying addr on connections, and delete real_addr
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  ipv6, technical-debt, prop311
Actual Points: |  Parent ID:  #33048
   Points:  1  |   Reviewer:
  Sponsor:  Sponsor55-can  |
---+---
 In connection_or_check_canonicity(), we overwrite conn.addr with the
 canonical address of the relay in the consensus. That makes accurate
 logging impossible.

 And so we also need channel.real_addr, to store the actual address of the
 remote peer. And for some reason, we also have conn.address, a string copy
 of the peer's canonical address and port.

 This is... a mess.

 Here's the high-level interface I'd like to see:
 * use a function to format a connection or channel addresses for loogging
 * use exactly as many address and port variables as needed in connection
 and channel (no extras!)
 * qualify each address and port variable's name with its purpose

 For example, here's one possible design:
 * delete addr, port, address, and real_addr
 * add remote_ap, a tor_addr_port_t that is the remote address and port of
 the TCP connection to the remote peer
 * implement connection_describe(), which:
   * formats remote_ap,
   * formats is_canonical (and any other useful info), and
   * calls node_describe() to format the canonical IPv4 and IPv6 addresses
 and ports of the remote peer.

 If we need separate variables or functions for channels, we can use a
 similar design. (But ideally, re-using as many functions and variables as
 possible.)

 This is important for Sponsor 55: getting accurate connection information
 will make diagnosing bugs much easier.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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):

 Thanks for your feedback!

 Replying to [comment:5 cohosh]:
 > I'm mostly thinking about this from a bridge enumeration standpoint at
 the moment, since this opens up another vector for attack. I guess my
 first question here, is what are we most interested in learning from this?
 Is it whether specific bridges have been blocked in specific places, or
 that countries X, Y, and Z are very effective at blocking bridges of type
 A?
 [[br]]
 It's the former. We want censorship measurement platforms to tell us if a
 given bridge is reachable in country X. BridgeDB already has code that
 takes into account where a bridge is blocked and where a user is from. The
 goal is to optimise bridge distribution, so users end up with bridges that
 are (most likely) unblocked in their country.
 [[br]]
 > If we do want to know when and where each specific bridge is blocked,
 then we should make sure we know how useful this information is to us and
 what we're going to do with it. If it's not useful, perhaps we should re-
 evaluate whether it's worth the exposure. Or if there's a less risky (more
 passive) way to get this information.
 [[br]]
 I suggest we start with low-risk bridges like our default bridges (which
 are already public anyway) and bridges in our HTTPS/Proxy bucket. We lose
 little to nothing if these bridges get into our adversaries' hands.
 [[br]]
 > > * Arturo mentioned that OONI probes may not talk to wolpertinger
 directly, but rather proxy their requests over OONI's infrastructure. In
 this case, we don't need to worry about making wolpertinger resistant to
 censorship, but we may still want to make it available over domain
 fronting so we are prepared for a future in which censorship measurement
 probes (which are unlikely to be able to talk to *.torproject.org) connect
 directly.
 >
 > Another question for the OONI side of things: are all OONI clients
 testing each bridge? Or just a subset of them? A subset will again limit
 exposure and make it difficult for a censor to be able to enumerate
 bridges just by running an OONI client.
 [[br]]
 That's a great question and I don't have satisfying answers yet. But I
 agree that we should start with a small set of bridges and iterate as we
 gain experience. We should at least build this system in a way that it
 doesn't make it easier for an adversary to collect bridges.
 [[br]]
 > I like this design for now where OONI gets the bridge information and
 distributes it to probes as opposed to probes asking for it directly. This
 is much easier for us to secure and I'm not sure we'd ever want to the
 latter situation because of the potential for enumeration.
 [[br]]
 Yes, agreed.
 [[br]]
 > >- When requesting a bridge to test, a censorship measurement probe
 should tell us the country it's  in. We may also want to know its
 autonomous system. What else do we want to know?
 > A timestamp for sure. I think it would be useful for the same probe to
 try multiple times within some time frame (4x/day for 2-3 days).
 [[br]]
 I don't follow: do you mean an OONI probe should embed a timestamp when
 requesting a bridge to test? Why do we want a probe to request bridges
 multiple times per time frame?

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

Re: [tor-bugs] #24841 [Core Tor/Tor]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?

[Tor Bug Tracker & Wiki]

#24841: Your relay has a very large number of connections to other relays. Is 
your
outbound address the same as your relay address?
-+-
 Reporter:  tyng |  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.8-rc
 Severity:  Normal   | Resolution:
 Keywords:  033-triage-20180320, |  Actual Points:
  033-removed-20180320, 035-deferred-20190115,   |
  041-proposed   |
Parent ID:  #33048   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor55-can
-+-
Changes (by teor):

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


Comment:

 Replying to [comment:16 teor]:
 > Replying to [comment:15 timkuijsten]:
 > > Since I've been starting a couple of new relays as a new relay
 operator, this message occurs now and then in the first couple of days and
 it made me wonder[0]. If we should ignore these numbers as long as they
 are below 60, then why show the message before having connected to at
 least 60 relays? I would propose to crank MIN_RELAY_CONNECTIONS_TO_WARN
 from 5 to 60 (but I'm completely new :)).
 > >
 > > [0] https://lists.torproject.org/pipermail/tor-
 relays/2018-August/016037.html
 >
 > Thanks for this patch!
 >
 > I think this is a good fix, but we could make it better by:
 > * counting the number of relays in the consensus, and using 1% of that
 as a minimum
 > * if the limit is less than 5, use 5 as the minimum
 > * if there is no consensus, use 5 relays as the minimum
 >
 > You can find the number of relays in the consensus by doing something
 like:
 > {{{
 > const networkstatus_t *consensus =
 networkstatus_get_reasonably_live_consensus(now, usable_flavour());
 > int n_relays = consensus ? smatlist_len(consensus->routerstatus_list) :
 0;
 > }}}
 >

 nickm, would you like to update the attached patch?

 I think my patch in #33817 will fix one possible source of this issue. But
 we won't see the impact until 0.4.4 or later are deployed to most of the
 network. (And there may be other causes.)

 So it's a good time to adjust the thresholds for this warning.

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

Re: [tor-bugs] #24841 [Core Tor/Tor]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?

[Tor Bug Tracker & Wiki]

#24841: Your relay has a very large number of connections to other relays. Is 
your
outbound address the same as your relay address?
-+-
 Reporter:  tyng |  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.8-rc
 Severity:  Normal   | Resolution:
 Keywords:  033-triage-20180320, |  Actual Points:
  033-removed-20180320, 035-deferred-20190115,   |
  041-proposed   |
Parent ID:  #33048   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor55-can
-+-

Comment (by teor):

 (This is not urgent at all - it would be nice to have this change in
 0.4.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] #24841 [Core Tor/Tor]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?

[Tor Bug Tracker & Wiki]

#24841: Your relay has a very large number of connections to other relays. Is 
your
outbound address the same as your relay address?
-+-
 Reporter:  tyng |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.8-rc
 Severity:  Normal   | Resolution:
 Keywords:  033-triage-20180320, |  Actual Points:
  033-removed-20180320, 035-deferred-20190115,   |
  041-proposed   |
Parent ID:  #33048   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor55-can
-+-
Changes (by teor):

 * points:   => 0.5
 * sponsor:   => Sponsor55-can
 * parent:   => #33048


Comment:

 This ticket might be fixed by #33817: connection_is_canonical_to_peer
 checks IPv6, but connection_is_canonical does not.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33897 [Circumvention/Snowflake]: Remove buffering from WebRTCPeer

[Tor Bug Tracker & Wiki]

#33897: Remove buffering from WebRTCPeer
-+-
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:  turbotunnel
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 `WebRTCPeer` has a `buffer` that is used to hold bytes until the data
 channel is connected. We should remove it after the turbotunnel changes
 are merged (#33745). What ends up happening is the reliability layer ends
 up retransmitting packets as they sit in the buffer, and when the data
 channel is finally established, all those old useless packets get sent in
 a mass. It's better to just drop those packets on the floor before the
 data channel exists.

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

Re: [tor-bugs] #26366 [Core Tor/Tor]: Possible duplicated logic in connection_edge_finished_connecting() and connection_exit_connect()

[Tor Bug Tracker & Wiki]

#26366: Possible duplicated logic in connection_edge_finished_connecting() and
connection_exit_connect()
--+---
 Reporter:  ahf   |  Owner:  neel
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+---
Changes (by catalyst):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:2 neel]:
 > PR: https://github.com/torproject/tor/pull/1781
 Thanks for the patch!

 There are a few things I would like to know more about the existing code.
 Maybe ahf knows?
 * There's an asymmetry between `connection_edge_finished_connecting()` and
 `connection_exit_connect()` in terms of how they call
 `connection_watch_events()`. `connection_edge_finished_connecting()` sets
 `READ_EVENT`, then separately calls `connection_start_writing()` if
 there's queued data, while `connection_exit_connect()` checks for queued
 data first, then picks `READ_EVENT|WRITE_EVENT` or `READ_EVENT` as
 appropriate. Maybe this difference is insignificant in practice?
 * For exit connections, is it even possible for
 `connected_cell_format_payload()` to return `-1`? It looks like it could
 if the address family is neither `AF_INET` nor `AF_INET6`, but how can
 this happen? Shouldn't previously-run code already have enforced? If so,
 why can't we use an assertion here?

 I made additional suggestions on the pull request.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33896 [Metrics/Consensus Health]: Depictor: stop claiming so many digits of precision for clock skew

[Tor Bug Tracker & Wiki]

#33896: Depictor: stop claiming so many digits of precision for clock skew
--+-
 Reporter:  arma  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 In
 https://consensus-health.torproject.org/#authorityclocks
 we state clock skew numbers like "-0.386114 seconds".

 There's no way that 114 part is at all accurate, since this figure is
 influence by (for example) network latency, Tor processing latency, etc.

 We list only 1 or 2 or 3 digits after the decimal point. I'm thinking two
 digits would be a nice balance.

 Motivated by the discussion on tor-relays@:
 https://lists.torproject.org/pipermail/tor-relays/2020-April/018372.html

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33895 [Circumvention/Pluggable transport]: Mirror personal git repos used for Pluggable Transports

[Tor Bug Tracker & Wiki]

#33895: Mirror personal git repos used for Pluggable Transports
---+
 Reporter:  sysrqb |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Some of the projects our software depends on is hosted in personal repos
 which are scattered across the web. We should probably mirror some of
 these on either git.tpo or gitlab.tpo (whichever makes more sense, but I'm
 leaning toward git.tpo right now) in case they disappear in the future.

 I'm not sure how we should define the policy for when we self-host verses
 when we use the official repo. For example, the `gocompress` project for
 Tor Browser is cloned from a personal github repo. Is that worth
 mirroring?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33894 [Core Tor/Tor]: make (retroactive) proposal for DoS subsystem

[Tor Bug Tracker & Wiki]

#33894: make (retroactive) proposal for DoS subsystem
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In #24902, dgoulet speaks of a ddos-design.txt document.

 But there is no actual proposal for the overall DoS subsystem.

 If we have the document around, and we just never published it, this is a
 great chance to notice, clean it up a bit, and call it proposal three-
 hundred-and-something. (And then maybe turn some of it into one of the
 spec files if that makes sense, but, one step at a time here. :)

 Motivated by this month's tor-dev thread where all we have to show for the
 DoS subsystem design is a trac ticket number and a changelog entry.

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

Re: [tor-bugs] #33837 [Core Tor/Tor]: Tor.framework Unknown type name 'dispatch_queue_t'

[Tor Bug Tracker & Wiki]

#33837: Tor.framework Unknown type name 'dispatch_queue_t'
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  043-should, 043-backport,|  Actual Points:
  042-backport, 041-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tla):

 So sorry. My account didn't have an e-mail address, so I wasn't notified.
 D'oh!

 Here's more info:
 https://github.com/iCepa/Tor.framework/issues/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] #33301 [Applications/Tor Browser]: It takes too a long time for Tor Browser to close and be ready for a next start

[Tor Bug Tracker & Wiki]

#33301: It takes too a long time for Tor Browser to close and be ready for a 
next
start
+--
 Reporter:  JKLjkl  |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  processes Firefox and -childID  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by JKLjkl):

 Replying to [comment:12 arma]:
 > Was there a Tor Browser version that didn't have this behavior for you?
 As far as i can remember now, the versions prior to 9.0.4 or older

 Replying to [comment:12 arma]:
 > Have you tried deleting your Tor Browser tree and installing a fresh
 one?
 Yes.

 Replying to [comment:12 arma]:
 > You're downloading it from torproject.org's download page, right, not
 some other launcher?
 Yes.

 Replying to [comment:12 arma]:
 > Have you tried installing it on a different computer running Ubuntu
 18.04?
 Not yet.

 Replying to [comment:12 arma]:
 > Have you tried reinstalling Ubuntu 18.04 on this computer?
 Not yet.

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

Re: [tor-bugs] #33884 [Circumvention/Snowflake]: Meek-Azure and SnowFlake are still broken

[Tor Bug Tracker & Wiki]

#33884: Meek-Azure and SnowFlake are still broken
-+---
 Reporter:  z1z  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  meek snowflake   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by z1z):

 I think meek-azure worked briefly in the last alpha version, but not
 snowflake, never been able to get it to connect.

 The snowflake links you posted to the same alpha version I'm using:
 9.5a11 (based on Mozilla Firefox 68.7.0esr) (64-bit)

 Does not connect via snowflake.(Waited over 5mins to connect, many times)

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

Re: [tor-bugs] #33877 [Applications/Tor Browser]: Disable Samples and Regression tests For Libevent Build

[Tor Bug Tracker & Wiki]

#33877: Disable Samples and Regression tests For Libevent Build
+--
 Reporter:  sisbell |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam202004R  |  Actual Points:
Parent ID:  #28704  | Points:  .1
 Reviewer:  gk, boklm   |Sponsor:
+--

Comment (by sisbell):

 Moved 'configure_opt' from linux-x86_64 var to linux var

 https://github.com/sisbell/tor-browser-build/commits/bug-33877a

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

Re: [tor-bugs] #33877 [Applications/Tor Browser]: Disable Samples and Regression tests For Libevent Build

[Tor Bug Tracker & Wiki]

#33877: Disable Samples and Regression tests For Libevent Build
+--
 Reporter:  sisbell |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam202004R  |  Actual Points:
Parent ID:  #28704  | Points:  .1
 Reviewer:  gk, boklm   |Sponsor:
+--
Changes (by sysrqb):

 * reviewer:   => gk, boklm


Comment:

 For Linux, does it make sense to move this:
 {{{
linux-x86_64: 1
osname: linux-x86_64
 +  configure_opt: '[% c("var/configure_opt_project") %]'
# We only support RLBox on the nightly channel and x86_64 for now
rlbox: '[% c("var/nightly") %]'
 }}}

 from `linux-x86_64`, and declare `configure_opt` under `linux` such that
 it is inherited by `linux-x86_64` and any new Linux arch we add?

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

Re: [tor-bugs] #32912 [Applications/GetTor]: Clean up gettor scripts

[Tor Bug Tracker & Wiki]

#32912: Clean up gettor scripts
+--
 Reporter:  hiro|  Owner:  cohosh
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/GetTor |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--
Changes (by cohosh):

 * status:  assigned => needs_review


Comment:

 This PR removes a bunch of old code:
 https://gitlab.torproject.org/torproject/anti-censorship/gettor-
 project/gettor/-/merge_requests/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] #33889 [Core Tor/Tor]: Functions with char* arguments are dangerous when used with casting

[Tor Bug Tracker & Wiki]

#33889: Functions with char* arguments are dangerous when used with casting
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security memory-safety  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+

Comment (by nickm):

 I'm +1 on this general idea.  I'm against using void* here though; we
 should be using uint8_t or unsigned char.

 If we're going to have two functions, let's have e.g. `fast_mem_is_zero()`
 take the unsigned pointer, and define a `fast_mem_is_zero_char()` version
 for legacy usage.

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

Re: [tor-bugs] #17548 [Circumvention/BridgeDB]: https://bridges.torproject.org/keys shows outdated keys

[Tor Bug Tracker & Wiki]

#17548: https://bridges.torproject.org/keys shows outdated keys
+---
 Reporter:  gk  |  Owner:  phw
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ex-sponsor-19   |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  cohosh  |Sponsor:  Sponsor30-can
+---
Changes (by cohosh):

 * status:  assigned => merge_ready


Comment:

 This looks good. Just a two comments:

 - there's still a test with a gpg key request in it
 
[https://github.com/NullHypothesis/bridgedb/blob/0859c23c97c28037ea08b3a835f0d5f38d7a4a77/bridgedb/test/test_email_request.py#L31
 here]

 - the README should be updated as well:
 https://github.com/NullHypothesis/bridgedb/tree/defect/17548#gnupg-email-
 signing

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

Re: [tor-bugs] #33729 [Applications/Tor Browser]: forestii IP address change planned for Ganeti migration

[Tor Bug Tracker & Wiki]

#33729: forestii IP address change planned for Ganeti migration
--+--
 Reporter:  anarcat   |  Owner:  tbb-team
 Type:  project   | Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:  tpa-roadmap-march |  Actual Points:
Parent ID:  #33082| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Gun+-123):

 Said a subscription

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

Re: [tor-bugs] #33745 [Circumvention/Snowflake]: Merge a turbotunnel branch

[Tor Bug Tracker & Wiki]

#33745: Merge a turbotunnel branch
-+
 Reporter:  dcf  |  Owner:  dcf
 Type:  task | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  turbotunnel  |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:  cohosh   |Sponsor:
-+
Changes (by cohosh):

 * status:  needs_review => needs_revision


Comment:

 Okay, these changes look good to me. Some things I noticed while going
 through to code again:

 - there's something up with the go.sum file you generated that's causing
 security errors for me. Specifically the hash for `github.com/tjfoc/gmsm`
 seemed wrong. I fixed this by removing go.sum and then regenerating it.
 Can you take a look at your end and see if you're having the same issues?

 - for the changes in
 [https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h
 =turbotunnel-merge=43f540e23d49af6ea75389ddc8808fdb1d482d5e this
 commit], it looks like we can still end up with a blocking goroutine
 waiting to read from a KCP stream once the SOCKS connection closes.

  In fact, since the KCP stream is kept alive, will this stay open
 indefinitely (or until Tor Browser restarts/closes)?

 - this is a nitpick, but the comments and variable names in `Handler` and
 `copyLoop` still assume this is a WebRTC session and not a KCP stream
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/tree/client/lib/snowflake.go?h
 =turbotunnel-merge=619802d12707baf5aee7091a7f1c02c3dbcaa30c#n166 here].

 I'll put it in needs_revision to hear back about these points but I
 generally think it's 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] #11698 [Applications/Tor Browser]: Decide how to incorporate Tor Browser Manual pages into Tor Browser

[Tor Bug Tracker & Wiki]

#11698: Decide how to incorporate Tor Browser Manual pages into Tor Browser
-+-
 Reporter:  mttp |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-manual, ux-team, |  Actual Points:
  TorBrowserTeam202010   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor30
-+-
Changes (by pili):

 * keywords:  tbb-manual, ux-team => tbb-manual, ux-team,
   TorBrowserTeam202010


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

Re: [tor-bugs] #11698 [Applications/Tor Browser]: Decide how to incorporate Tor Browser Manual pages into Tor Browser

[Tor Bug Tracker & Wiki]

#11698: Decide how to incorporate Tor Browser Manual pages into Tor Browser
--+---
 Reporter:  mttp  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-manual, ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor30
--+---
Changes (by antonela):

 * keywords:  tbb-manual, SponsorO, ux-team => tbb-manual, ux-team
 * sponsor:   => Sponsor30


Comment:

 Putting under S30 radar

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

Re: [tor-bugs] #33545 [Core Tor/Tor]: assertion failure when "all zero" client auth key provided

[Tor Bug Tracker & Wiki]

#33545: assertion failure when "all zero" client auth key provided
-+-
 Reporter:  mcs  |  Owner:  asn
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.4.0-alpha-
 |  dev
 Severity:  Normal   | Resolution:  implemented
 Keywords:  043-must security|  Actual Points:  0.2
  extra-review   |
Parent ID:   | Points:
 Reviewer:  dgoulet, nickm   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Squashed and merged!

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

Re: [tor-bugs] #33534 [Applications/Tor Browser]: Review FF release notes from FF69 to latest (FF75)

[Tor Bug Tracker & Wiki]

#33534: Review FF release notes from FF69 to latest (FF75)
--+
 Reporter:  pospeselr |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  20
Parent ID:  #33661| Points:
 Reviewer:|Sponsor:  Sponsor58-must
--+
Changes (by pospeselr):

 * actualpoints:  12 => 20


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

Re: [tor-bugs] #33534 [Applications/Tor Browser]: Review FF release notes from FF69 to latest (FF75) (was: Review FF release notes from FF69 to latest (FF73))

[Tor Bug Tracker & Wiki]

#33534: Review FF release notes from FF69 to latest (FF75)
--+
 Reporter:  pospeselr |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  12
Parent ID:  #33661| Points:
 Reviewer:|Sponsor:  Sponsor58-must
--+
Description changed by pospeselr:

Old description:

> Release Notes: https://www.mozilla.org/en-US/firefox/releases/
> Developer release notes: https://developer.mozilla.org/en-
> US/docs/Mozilla/Firefox/Releases
>
> Also, diff prefs.js between latest and esr 68.
>
> Also look at the bugs from 69 to 73 (update target_milestone param for
> each version)
>
> Mozilla fixed:
> ​https://bugzilla.mozilla.org/buglist.cgi?product=Core_format=advanced=FIXED_milestone=mozilla69=priority%2Cbug_severity=0
>
> Mozilla reponed:
> https://bugzilla.mozilla.org/buglist.cgi?resolution=---_format=advanced=Core_milestone=mozilla69
>
> Firefox fixed:
> ​https://bugzilla.mozilla.org/buglist.cgi?product=Firefox_format=advanced=FIXED_milestone=Firefox%2069=priority%2Cbug_severity=0

New description:

 Release Notes: https://www.mozilla.org/en-US/firefox/releases/
 Developer release notes: https://developer.mozilla.org/en-
 US/docs/Mozilla/Firefox/Releases

 Also, diff prefs.js between latest and esr 68.

 Also look at the bugs from 69 to 75 (update target_milestone param for
 each version)

 Mozilla fixed:
 
​https://bugzilla.mozilla.org/buglist.cgi?product=Core_format=advanced=FIXED_milestone=mozilla69=priority%2Cbug_severity=0

 Mozilla reponed:
 
https://bugzilla.mozilla.org/buglist.cgi?resolution=---_format=advanced=Core_milestone=mozilla69

 Firefox fixed:
 
​https://bugzilla.mozilla.org/buglist.cgi?product=Firefox_format=advanced=FIXED_milestone=Firefox%2069=priority%2Cbug_severity=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] #17548 [Circumvention/BridgeDB]: https://bridges.torproject.org/keys shows outdated keys

[Tor Bug Tracker & Wiki]

#17548: https://bridges.torproject.org/keys shows outdated keys
+---
 Reporter:  gk  |  Owner:  cohosh
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ex-sponsor-19   |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  Sponsor30-can
+---
Changes (by cohosh):

 * owner:  phw => cohosh


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

Re: [tor-bugs] #17548 [Circumvention/BridgeDB]: https://bridges.torproject.org/keys shows outdated keys

[Tor Bug Tracker & Wiki]

#17548: https://bridges.torproject.org/keys shows outdated keys
+---
 Reporter:  gk  |  Owner:  phw
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ex-sponsor-19   |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  cohosh  |Sponsor:  Sponsor30-can
+---
Changes (by cohosh):

 * owner:  cohosh => phw
 * reviewer:   => cohosh


Comment:

 oops

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

Re: [tor-bugs] #33545 [Core Tor/Tor]: assertion failure when "all zero" client auth key provided

[Tor Bug Tracker & Wiki]

#33545: assertion failure when "all zero" client auth key provided
-+-
 Reporter:  mcs  |  Owner:  asn
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.4.0-alpha-
 |  dev
 Severity:  Normal   | Resolution:
 Keywords:  043-must security|  Actual Points:  0.2
  extra-review   |
Parent ID:   | Points:
 Reviewer:  dgoulet, nickm   |Sponsor:
-+-

Comment (by asn):

 I think we are good to merge this today given that dgoulet is away and a
 release is pending.

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

Re: [tor-bugs] #33613 [Applications/Tor Browser]: Javascript Execution with NoScript Bypass (was: 811786)

[Tor Bug Tracker & Wiki]

#33613: Javascript Execution with NoScript Bypass
--+---
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Old description:

> Placeholder.

New description:

 The bug is upstream in Firefox 68esr. It is tracked by
 [https://bugzilla.mozilla.org/1621996 Bug 1621996].

--

Comment (by sysrqb):

 The patches above disabled javascript execution, as a safe guard. The
 original NoScript migration for this Firefox bug was incomplete. We
 believe the current mitigation in NoScript successfully avoids the bug,
 but I want to give enough time for more people to poke at it before
 thinking about relying on NoScript completely for blocking javascript
 execution on the Safest security level.

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

Re: [tor-bugs] #33545 [Core Tor/Tor]: assertion failure when "all zero" client auth key provided

[Tor Bug Tracker & Wiki]

#33545: assertion failure when "all zero" client auth key provided
-+-
 Reporter:  mcs  |  Owner:  asn
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.4.0-alpha-
 |  dev
 Severity:  Normal   | Resolution:
 Keywords:  043-must security|  Actual Points:  0.2
  extra-review   |
Parent ID:   | Points:
 Reviewer:  dgoulet, nickm   |Sponsor:
-+-

Comment (by nickm):

 I don't think there is an actual difference before and after the fixup.
 Try this demo:
 {{{
 #include 

 int
 main(int c, char**v)
 {
   struct foo { char array[10]; };

   struct foo x;

   printf("%p\n", x.array);
   printf("%p\n", );
   return 0;
 }
 }}}

 Note that both pointers are the same.

 I'm happy to merge this now, or wait for dgoulet.

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

Re: [tor-bugs] #33886 [Circumvention/BridgeDB]: brid...@torproject.org Don't respond to gmail

[Tor Bug Tracker & Wiki]

#33886: brid...@torproject.org Don't respond to gmail
+--
 Reporter:  mh828   |  Owner:  phw
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  bridgedb-reportbug  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by phw):

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


Comment:

 Thanks for your bug report! This may be caused by the following exception
 that BridgeDB occasionally raises:
 {{{
 Unhandled Error
 Traceback (most recent call last):
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/python/log.py", line 103, in callWithLogger
 return callWithContext({"system": lp}, func, *args, **kw)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/python/log.py", line 86, in callWithContext
 return context.call({ILogContext: newCtx}, func, *args, **kw)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/python/context.py", line 122, in callWithContext
 return self.currentContext().callWithContext(ctx, func, *args, **kw)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/python/context.py", line 85, in callWithContext
 return func(*args,**kw)
 ---  ---
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/internet/posixbase.py", line 614, in _doReadOrWrite
 why = selectable.doRead()
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/internet/tcp.py", line 243, in doRead
 return self._dataReceived(data)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/internet/tcp.py", line 249, in _dataReceived
 rval = self.protocol.dataReceived(data)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/protocols/basic.py", line 454, in dataReceived
 self.lineReceived(line)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/mail/smtp.py", line 445, in lineReceived
 return getattr(self, 'state_' + self.mode)(line)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/mail/smtp.py", line 705, in dataLineReceived
 m.eomReceived() for m in self.__messages
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/mail/smtp.py", line 705, in 
 m.eomReceived() for m in self.__messages
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/bridgedb-0.10.0+9.g208b49cd.dirty-
 py3.7.egg/bridgedb/distributors/email/server.py", line 240, in eomReceived
 self.responder.reply()
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/bridgedb-0.10.0+9.g208b49cd.dirty-
 py3.7.egg/bridgedb/distributors/email/autoresponder.py", line 603, in
 reply
 response = self.getMailData()
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/bridgedb-0.10.0+9.g208b49cd.dirty-
 py3.7.egg/bridgedb/distributors/email/autoresponder.py", line 420, in
 getMailData
 client, lang)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/bridgedb-0.10.0+9.g208b49cd.dirty-
 py3.7.egg/bridgedb/distributors/email/autoresponder.py", line 102, in
 createResponseBody
 bridges = context.distributor.getBridges(bridgeRequest, interval)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/bridgedb-0.10.0+9.g208b49cd.dirty-
 py3.7.egg/bridgedb/distributors/email/distributor.py", line 149, in
 getBridges
 with bridgedb.Storage.getDB() as db:
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/bridgedb-0.10.0+9.g208b49cd.dirty-py3.7.egg/bridgedb/Storage.py",
 line 352, in __enter__
 return next(self.gen)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/bridgedb-0.10.0+9.g208b49cd.dirty-py3.7.egg/bridgedb/Storage.py",
 line 472, in getDB
 assert _REFCOUNT == 0
 builtins.AssertionError:
 }}}

 Hmm, I wonder if our recent port to Python 3 broke our context manager.
 Email distribution did work in the recent past, so the issue is probably a
 bit more nuanced.

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

Re: [tor-bugs] #32873 [Core Tor/Tor]: 'GETINFO status/fresh-relay-descs' error message unhelpful

[Tor Bug Tracker & Wiki]

#32873: 'GETINFO status/fresh-relay-descs' error message unhelpful
--+--
 Reporter:  atagar|  Owner:  neel
 Type:  enhancement   | Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+--
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #33883 [Core Tor/Tor]: Fix typo in router_build_fresh_unsigned_routerinfo() comment

[Tor Bug Tracker & Wiki]

#33883: Fix typo in router_build_fresh_unsigned_routerinfo() comment
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+--
Changes (by asn):

 * reviewer:   => dgoulet


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

Re: [tor-bugs] #33788 [Core Tor/Tor]: Check the return value of tor_inet_ntop() and tor_inet_ntoa()

[Tor Bug Tracker & Wiki]

#33788: Check the return value of tor_inet_ntop() and tor_inet_ntoa()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  044-should, security-low,|  Actual Points:
  035-backport, 041-backport, 042-backport,  |
  043-backport, outreachy-ipv6, ipv6 |
Parent ID:  #33768   | Points:  1
 Reviewer:  teor |Sponsor:
 |  Sponsor55-must
-+-
Changes (by asn):

 * reviewer:   => teor


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

Re: [tor-bugs] #33630 [Applications/Tor Browser]: Retire noisebridge01 default bridge

[Tor Bug Tracker & Wiki]

#33630: Retire noisebridge01 default bridge
-+-
 Reporter:  phw  |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-bridges, TorBrowserTeam202004R,  |  Actual Points:  0.5
  tbb-9.5a12 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * keywords:  tbb-bridges, TorBrowserTeam202004R => tbb-bridges,
 TorBrowserTeam202004R, tbb-9.5a12
 * status:  reopened => merge_ready
 * cc: tbb-team (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] #33630 [Applications/Tor Browser]: Retire noisebridge01 default bridge

[Tor Bug Tracker & Wiki]

#33630: Retire noisebridge01 default bridge
+--
 Reporter:  phw |  Owner:  tbb-team
 Type:  task| Status:  reopened
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-bridges, TorBrowserTeam202004R  |  Actual Points:  0.5
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by sysrqb):

 Replying to [comment:8 phw]:
 > Replying to [comment:7 dcf]:
 > > I was surprised to see that commit
 [https://gitweb.torproject.org/builders/tor-browser-
 build.git/commit/?id=ac8641d245dadc64f0057231f9e593379e9701fc
 ac8641d245dadc64f0057231f9e593379e9701fc] on the
 [https://gitweb.torproject.org/builders/tor-browser-
 build.git/tag/?h=tbb-9.5a11-build1 tbb-9.5a11-build1] tag puts back the
 noisebridge01 bridge. What's the reason for it?
 > [[br]]
 > Right around the time we removed noisebridge01, we finally got in touch
 with a potential maintainer at noisebridge. I asked sysrqb if it was
 possible to revert the patch, and he did so for the alpha.
 >
 > It then turned out that our new maintainer would be setting up a new
 bridge behind a different IP address, so noisebridge01 needs to go after
 all. I may not have communicated this to sysrqb clearly enough. I'm sorry
 for the mess.

 Yeah, we had some confusion, but that's okay. I'll delete noisebridge01
 from the alpha (nightly) and we can add the new bridge info when that is
 available.

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

Re: [tor-bugs] #33891 [Applications/Tor Browser]: Consider switching to ungoogled-chromium as a base

[Tor Bug Tracker & Wiki]

#33891: Consider switching to ungoogled-chromium as a base
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

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


Comment:

 It's not that simple. Chromium doesn't provide a consistent browser
 platform on all operating systems.

 See also: #31671, #30410

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

Re: [tor-bugs] #33862 [Applications/Tor Browser]: Fix usages of createTransport API

[Tor Bug Tracker & Wiki]

#33862: Fix usages of createTransport API
--+--
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004R |  Actual Points:
Parent ID:  #33533| Points:
 Reviewer:|Sponsor:  Sponsor58
--+--
Changes (by acat):

 * keywords:  TorBrowserTeam202004 => TorBrowserTeam202004R
 * status:  new => needs_review


Comment:

 torbutton patch:
 
​https://github.com/acatarineu/torbutton/commit/35f17253b43c074dc176beef8980a10f14bb1ca1

 tor-launcher patch: ​https://github.com/acatarineu/tor-
 launcher/commit/c6a2801b87b0d04fc58f0d47005ce71971b6d41f

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

Re: [tor-bugs] #32174 [Applications/Tor Launcher]: replace XUL with

[Tor Bug Tracker & Wiki]

#32174: replace XUL  with 
-+-
 Reporter:  mcs  |  Owner:  brade
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
  ff78-esr,BugSmashFund,TorBrowserTeam202004R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by acat):

 * keywords:  ff78-esr,BugSmashFund =>
 ff78-esr,BugSmashFund,TorBrowserTeam202004R
 * status:  new => needs_review


Comment:

 tor-launcher patch: ​https://github.com/acatarineu/tor-
 launcher/commit/f85556836b5cbda80e1f9bc5fff49da0e7d5a980

 For Tor Browser patches, this is already done in #33533, so perhaps this
 can be reviewed there.

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

Re: [tor-bugs] #33892 [Applications/Tor Browser]: Add brandProductName to torbutton brand localization files

[Tor Bug Tracker & Wiki]

#33892: Add brandProductName to torbutton brand localization files
--+--
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004R |  Actual Points:
Parent ID:  #33533| Points:
 Reviewer:|Sponsor:
--+--
Changes (by acat):

 * keywords:  TorBrowserTeam202004 => TorBrowserTeam202004R
 * status:  new => needs_review


Comment:

 Patch in
 
https://github.com/acatarineu/torbutton/commit/8205657aaa54fb438553ab715d6ea067e3668f3c

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

Re: [tor-bugs] #33890 [Applications/Tor Browser]: Rename .xul to .xhtml

[Tor Bug Tracker & Wiki]

#33890: Rename .xul to .xhtml
--+--
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004R |  Actual Points:
Parent ID:  #33533| Points:
 Reviewer:|Sponsor:
--+--
Changes (by acat):

 * keywords:  TorBrowserTeam202004 => TorBrowserTeam202004R
 * status:  new => needs_review


Comment:

 torbutton patch:
 
https://github.com/acatarineu/torbutton/commit/782cc4b27d580c43d3db78690f9ab0803eb854af

 tor-launcher patch: https://github.com/acatarineu/tor-
 launcher/commit/0bd09322f4af1b36e9ee60411a9fae608132d92a

 For Tor Browser patches, this is already done in #33533, so perhaps this
 can be reviewed there.

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

[tor-bugs] #33893 [Applications/GetTor]: Track down old GetTor mirrors and decide what to do with them

[Tor Bug Tracker & Wiki]

#33893: Track down old GetTor mirrors and decide what to do with them
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Just talked to alwayslivid on IRC and found out that there's a list of
 mirrors in `config/tor-mirrors.json`. Some of these are serving very old
 versions of Tor Browser. We should find them and reach out to the
 operators and figure out what we want to do about mirrors going forward.

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

Re: [tor-bugs] #33878 [Applications/Tor Browser]: Make URL DuckDuckGo search use POST method

[Tor Bug Tracker & Wiki]

#33878: Make URL DuckDuckGo search use POST method
--+--
 Reporter:  kromek|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * version:  Tor: unspecified =>


Comment:

 Hmm, I can't reproduce this. If I search something using the URL bar, then
 the URL becomes `https://duckduckgo.com/?ia=news`, so the query is sent by
 POST. However if I use the search box inside the ddg page, then the query
 is part of the URL.

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

Re: [tor-bugs] #33881 [Applications/Tor Browser]: Unable to change default directory location in Parrot OS

[Tor Bug Tracker & Wiki]

#33881: Unable to change default directory location in Parrot OS
--+---
 Reporter:  nagarajtg5|  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:
--+---
Changes (by boklm):

 * status:  new => needs_information


Comment:

 How did you install Tor Browser, and what do you mean exactly by "change
 the default directory"?

 Where do you get the error message? Is it the output from the `./start-
 tor-browser.desktop` script?

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

Re: [tor-bugs] #32912 [Applications/GetTor]: Clean up gettor scripts

[Tor Bug Tracker & Wiki]

#32912: Clean up gettor scripts
+--
 Reporter:  hiro|  Owner:  cohosh
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/GetTor |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--
Changes (by cohosh):

 * owner:  (none) => cohosh
 * 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] #33702 [Core Tor/Tor]: RSA_get0_d could not be located in the dynamic link library tor.exe

[Tor Bug Tracker & Wiki]

#33702: RSA_get0_d could not be located in the dynamic link library tor.exe
--+--
 Reporter:  ner0  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by ner0):

 Replying to [comment:36 cypherpunks]:
 > @ner0
 > "an app folder" != "a current folder"
 >
 > and '''if''' "the app folder" == "the current folder" then windows_10
 exclude "an app folder" ("a current folder" is last one)
 I don't really see the distinction here; by "a current folder" I meant the
 working directory, which I assume is the directory from which the process
 was run and also assume it is "an app folder". As for the second part of
 your comment I am not completely sure where you derive that information
 from. Although that exclusion is precisely the problem, why would running
 as Administrator changes that? Is it because as administrator the current
 folder/workingdir is System32 and thus relegated to last?

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

Re: [tor-bugs] #32088 [Core Tor/Tor]: Proposal 310 - choose guards in sampled order

[Tor Bug Tracker & Wiki]

#32088: Proposal 310 - choose guards in sampled order
--+
 Reporter:  Jaym  |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec prop271 prop310  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by Jaym):

 * 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

[tor-bugs] #33892 [Applications/Tor Browser]: Add brandProductName to torbutton brand localization files

[Tor Bug Tracker & Wiki]

#33892: Add brandProductName to torbutton brand localization files
--+
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam202004
Actual Points:|  Parent ID:  #33533
   Points:|   Reviewer:
  Sponsor:|
--+
 `brandProductName` was already present in ESR68, but we did not update
 torbutton `brand.dtd` or `brand.properties` files. For 68, this does not
 break the browser, since `brandProductName` is not used as an xml entity
 (DTD), and the `.properties` usage is in a path we probably do not
 [https://searchfox.org/mozilla-
 
esr68/rev/c6e395f8a8512bec0dea4d3526831a3dbbae90e4/toolkit/profile/content/profileSelection.js#86
 hit].

 Currently, this is string is used in several additional places, and
 starting Firefox 70 it's used as a [https://searchfox.org/mozilla-
 central/rev/b7f3977978922d44c7d92ae01c0d4cc2baca7bc2/browser/locales/en-
 US/chrome/browser/browser.dtd#68 DTD entity], which prevents the browser
 from starting if it's not defined.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33891 [Applications/Tor Browser]: Consider switching to ungoogled-chromium as a base

[Tor Bug Tracker & Wiki]

#33891: Consider switching to ungoogled-chromium as a base
-+--
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Applications/Tor Browser
  Version:   |   Severity:  Major
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Recent news:

 https://news.slashdot.org/story/20/04/11/1724209/mozilla-installs-
 scheduled-telemetry-task-on-windows-with-firefox-75

 Considering the continuous invasive "privacy respecting" of Mozilla
 corporation and its ties with Google and other companies, it is time to
 consider moving away from Firefox and switching to a truly privacy
 respecting one.

 Unlike Firefox ungoogled-chromium makes ZERO background and ZERO
 unsolicited connections. It is also very easy to set up a tor proxy and
 use it with ungoogled-chromium. The only thing it lacks is the reset-
 identity functionality and the use of separate Tor circuits/IPs for
 different sites.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33890 [Applications/Tor Browser]: Rename .xul to .xhtml

[Tor Bug Tracker & Wiki]

#33890: Rename .xul to .xhtml
--+
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam202004
Actual Points:|  Parent ID:  #33533
   Points:|   Reviewer:
  Sponsor:|
--+
 Firefox did a mass rename of all .xul files to .xhtml in
 https://bugzilla.mozilla.org/show_bug.cgi?id=1579952. We need to do the
 same in torbutton and tor-launcher, as well as in several Tor Browser
 patches that involve UI.

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

Re: [tor-bugs] #33545 [Core Tor/Tor]: assertion failure when "all zero" client auth key provided

[Tor Bug Tracker & Wiki]

#33545: assertion failure when "all zero" client auth key provided
-+-
 Reporter:  mcs  |  Owner:  asn
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.4.0-alpha-
 |  dev
 Severity:  Normal   | Resolution:
 Keywords:  043-must security|  Actual Points:  0.2
  extra-review   |
Parent ID:   | Points:
 Reviewer:  dgoulet, nickm   |Sponsor:
-+-
Changes (by asn):

 * status:  needs_revision => needs_review


Comment:

 Great find!

 Pushed fixup in both branches. Also opened #33889 to track the general
 class of issues 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] #33889 [Core Tor/Tor]: Functions with char* arguments are dangerous when used with casting

[Tor Bug Tracker & Wiki]

#33889: Functions with char* arguments are dangerous when used with casting
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security memory-safety  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+
Description changed by asn:

Old description:

> There are various functions in our codebase which receive char* arguments
> when they actually receive a byte array. That's I guess because of the
> old C standard when uint8_t didn't really exist, so we had to use char*
> for everything.
>
> Still, these days we use uint8_t* and this means that we need to cast it
> to char* when we use those functions. This can cause security issues
> because this casting is silencing type-safety warnings (as an example see
> https://github.com/torproject/tor/pull/1843#discussion_r406191281).
>
> For example, see how `fast_mem_is_zero()` is used 75% of the time with
> casting its first argument. Instead of doing this, we could make a new
> `fast_mem_is_zero_uint8t()` function that takes uint8_t as argument. Or
> even make a `fast_mem_is_zero_char()` function that takes char*.
>
> In other functions, it might be possible to replace the `char*` with
> `void*` but in the case of `fast_mem_is_zero()` that's not possible
> because of the implementation of the function.
>
> Other potential problem functions: `base64_encode()` `hex_str()`
> `crypto_rand()` `crypto_digest()`.

New description:

 There are various functions in our codebase which receive char* arguments
 when they actually receive a byte array. That's I guess because of the old
 C standard when uint8_t didn't really exist, so we had to use char* for
 everything.

 Still, these days we use uint8_t* and this means that we need to cast it
 to char* when we use those functions. This can cause security issues
 because this casting is silencing type-safety warnings (as an example see
 https://github.com/torproject/tor/pull/1843#discussion_r406191281 from
 #33545).

 For example, see how `fast_mem_is_zero()` is used 75% of the time with
 casting its first argument. Instead of doing this, we could make a new
 `fast_mem_is_zero_uint8t()` function that takes uint8_t as argument. Or
 even make a `fast_mem_is_zero_char()` function that takes char*.

 In other functions, it might be possible to replace the `char*` with
 `void*` but in the case of `fast_mem_is_zero()` that's not possible
 because of the implementation of the function.

 Other potential problem functions: `base64_encode()` `hex_str()`
 `crypto_rand()` `crypto_digest()`.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33889 [Core Tor/Tor]: Functions with char* arguments are dangerous when used with casting

[Tor Bug Tracker & Wiki]

#33889: Functions with char* arguments are dangerous when used with casting
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  security memory-safety
Actual Points:|  Parent ID:
   Points:  3 |   Reviewer:
  Sponsor:|
--+
 There are various functions in our codebase which receive char* arguments
 when they actually receive a byte array. That's I guess because of the old
 C standard when uint8_t didn't really exist, so we had to use char* for
 everything.

 Still, these days we use uint8_t* and this means that we need to cast it
 to char* when we use those functions. This can cause security issues
 because this casting is silencing type-safety warnings (as an example see
 https://github.com/torproject/tor/pull/1843#discussion_r406191281).

 For example, see how `fast_mem_is_zero()` is used 75% of the time with
 casting its first argument. Instead of doing this, we could make a new
 `fast_mem_is_zero_uint8t()` function that takes uint8_t as argument. Or
 even make a `fast_mem_is_zero_char()` function that takes char*.

 In other functions, it might be possible to replace the `char*` with
 `void*` but in the case of `fast_mem_is_zero()` that's not possible
 because of the implementation of the function.

 Other potential problem functions: `base64_encode()` `hex_str()`
 `crypto_rand()` `crypto_digest()`.

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

Re: [tor-bugs] #33888 [Metrics/ExoneraTor]: Release ExoneraTor 4.4.0

[Tor Bug Tracker & Wiki]

#33888: Release ExoneraTor 4.4.0
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

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


Comment:

 Release: https://dist.torproject.org/exonerator/4.4.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] #33887 [Metrics/Library]: Release metrics-lib 2.11.0

[Tor Bug Tracker & Wiki]

#33887: Release metrics-lib 2.11.0
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Release: https://dist.torproject.org/metrics-lib/2.11.0/

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

[tor-bugs] #33888 [Metrics/ExoneraTor]: Release ExoneraTor 4.4.0

[Tor Bug Tracker & Wiki]

#33888: Release ExoneraTor 4.4.0
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 I'm going to put out a new ExoneraTor release today.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33887 [Metrics/Library]: Release metrics-lib 2.11.0

[Tor Bug Tracker & Wiki]

#33887: Release metrics-lib 2.11.0
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 I'm going to put out a new metrics-lib release 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] #33872 [Internal Services/Service - nextcloud]: Create a Nextcloud account for acat

[Tor Bug Tracker & Wiki]

#33872: Create a Nextcloud account for acat
-+-
 Reporter:  acat |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | 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 acat):

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


Comment:

 It seems the account was created.

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

Re: [tor-bugs] #30260 [Metrics/ExoneraTor]: Default date picker to latest available date

[Tor Bug Tracker & Wiki]

#30260: Default date picker to latest available date
+--
 Reporter:  cypherpunks |  Owner:  metrics-team
 Type:  enhancement | Status:  closed
 Priority:  Low |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  irl |Sponsor:
+--
Changes (by karsten):

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


Comment:

 On second thought, this patch is so trivial that it doesn't really need a
 review. I'd like to put out a release today, so I rebased and merged this
 patch to master as
 
[https://gitweb.torproject.org/exonerator.git/commit/?id=66d1c8189c54d9a608b0b0cdacc110a1a0c59249
 commit 66d1c81]. Closing.

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

Re: [tor-bugs] #33884 [Circumvention/Snowflake]: Meek-Azure and SnowFlake are still broken

[Tor Bug Tracker & Wiki]

#33884: Meek-Azure and SnowFlake are still broken
-+---
 Reporter:  z1z  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  meek snowflake   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by dcf):

 * version:  Tor: unspecified =>
 * component:  Circumvention => Circumvention/Snowflake


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

Re: [tor-bugs] #33884 [Circumvention]: Meek-Azure and SnowFlake are still broken

[Tor Bug Tracker & Wiki]

#33884: Meek-Azure and SnowFlake are still broken
+---
 Reporter:  z1z |  Owner:  (none)
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:
Component:  Circumvention   |Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  meek snowflake  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by dcf):

 * status:  new => needs_information
 * severity:  Critical => Normal
 * component:  Core Tor => Circumvention
 * priority:  Immediate => Medium
 * points:  Meek-Azure SnowFlake Broken =>
 * actualpoints:  Meek-Azure SnowFlake Broken =>
 * keywords:  Meek-Azure SnowFlake Broken Not Working => meek snowflake


Comment:

 Did meek and Snowflake ever work for you? How long ago?

 For Snowflake, please try the experimental packages at
 https://people.torproject.org/~dcf/pt-bundle/tor-browser-snowflake-
 turbotunnel-9.5a11-20200410/. See comment:7:ticket:33745.

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

Re: [tor-bugs] #33876 [Applications/Tor Browser]: Back Button on Tor Browser Android Closes App When Log is Open

[Tor Bug Tracker & Wiki]

#33876: Back Button on Tor Browser Android Closes App When Log is Open
--+--
 Reporter:  bim   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  android, ux-team => tbb-mobile, ux-team


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

Re: [tor-bugs] #33876 [Applications/Tor Browser]: Back Button on Tor Browser Android Closes App When Log is Open

[Tor Bug Tracker & Wiki]

#33876: Back Button on Tor Browser Android Closes App When Log is Open
--+--
 Reporter:  bim   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  android, ux-team  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pili):

 * cc: antonela (added)
 * keywords:  android => android, ux-team
 * component:  - Select a component => Applications/Tor Browser
 * owner:  (none) => tbb-team


Comment:

 Thanks for reporting. We will review this and get back 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

Re: [tor-bugs] #33874 [Applications/Tor Browser]: YouTube player interface broken

[Tor Bug Tracker & Wiki]

#33874: YouTube player interface broken
--+
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pili):

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


Comment:

 thanks for updating us

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

Re: [tor-bugs] #33883 [Core Tor/Tor]: Fix typo in router_build_fresh_unsigned_routerinfo() comment

[Tor Bug Tracker & Wiki]

#33883: Fix typo in router_build_fresh_unsigned_routerinfo() comment
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pili):

 * component:  - Select a component => Core Tor/Tor


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

Re: [tor-bugs] #33753 [Applications/Tor Browser]: The Tor is broken (v9.0.7)

[Tor Bug Tracker & Wiki]

#33753: The Tor is broken (v9.0.7)
--+
 Reporter:  oniox |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pili):

 * status:  needs_information => closed
 * resolution:   => worksforme


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

Re: [tor-bugs] #33885 [Community/Tor Support]: Tor Browser & VPN

[Tor Bug Tracker & Wiki]

#33885: Tor Browser & VPN
---+--
 Reporter:  oniox  |  Owner:  ggus
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by pili):

 * owner:  (none) => ggus
 * component:  - Select a component => Community/Tor Support


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

Re: [tor-bugs] #22011 [Applications/GetTor]: Implement telegram bot for gettor

[Tor Bug Tracker & Wiki]

#22011: Implement telegram bot for gettor
-+-
 Reporter:  hellais  |  Owner:  alwayslivid
 Type:  enhancement  | Status:  assigned
 Priority:  Low  |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #28231   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by alwayslivid):

 I spent a while studying the source code of gettor, and after attempting
 to build a bot directly on top of gettor would seem difficult, due to the
 fact that certain functions that the whole program depends on (e.g.
 `get_new()`) would simply not fit together with the design of an
 interactive bot that responds immediately to all queries.

 So, I'm moving on with the idea of creating another bot and then making
 use of snippets that are mostly in the upload folder, in order to handle
 uploading in a way that could also be more easily backported to the
 upstream version of gettor in the long term (... in case that does
 happen).

 Here's the issue I'm currently dealing with; I initially used the GNU GPL
 v3 license for my own code, but since I wanted to adapt certain pieces of
 source code from gettor, I think that changing the license to one that's
 more similar to the one that gettor has should be enough. I tried to reach
 out and ask about that in the IRC and got no response, so I'm just leaving
 this here in the case that any issues could potentially arise from the
 decision that I made.

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