[tor-bugs] #34065 [Core Tor/Tor]: Make routerset_contains_router() support IPv6

[Tor Bug Tracker & Wiki]

#34065: Make routerset_contains_router() support IPv6
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  ipv6, prop311, 044-should
Actual Points: |  Parent ID:  #33221
   Points:  0.5|   Reviewer:
  Sponsor:  Sponsor55-can  |
---+---
 In router_should_check_reachability(), we test to see if the current relay
 is in ExcludeNodes.

 But ExcludeNodes doesn't support IPv6, so if a user excludes our IPv6
 address, we'll just ignore that setting.

 This is not a required task.

 But we should probably be explicit about ignoring IPv6 in the man page.

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

 Part of the problem here is a naming issue. It's not clear what "real"
 means, particularly when the other address fields doesn't have any
 qualifiers.

 And it's even less clear when we should be using each address field.

 One quick win here, would be to give each of the existing fields a
 distinct, qualified name. The name should clearly describe its purpose or
 contents.

 > I agree that these rules start to get ugly once relays have multiple
 canonical addresses.

 I don't think it's as bad as you think.

 Here are some general principles:
 * Each connection is either IPv4 or IPv6. So any substitute address should
 be from the corresponding family.
 * Any logs should contain addresses from the relevant family, or ideally,
 all available addresses.
 * If an address is only intended for logging, it can be in any convenient
 format. For example, "IPv4:port and [IPv6]:port". If we use an unparseable
 format like this, it will be easier to see coding bugs that use the wrong
 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

Re: [tor-bugs] #33957 [Core Tor/Chutney]: Unexpected keyword argument 'bufsize' in subprocess.check_output()

[Tor Bug Tracker & Wiki]

#33957: Unexpected keyword argument 'bufsize' in subprocess.check_output()
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  prop311, prop312  |  Actual Points:
Parent ID:  #33050| Points:
 Reviewer:  nickm |Sponsor:  Sponsor55-can
--+---
Changes (by teor):

 * parent:   => #33050


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

Re: [tor-bugs] #33901 [Core Tor/Tor]: Allow IPv6 extend cells

[Tor Bug Tracker & Wiki]

#33901: Allow IPv6 extend cells
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  ipv6, prop311  |  Actual Points:  0.5
Parent ID:  #33048 | Points:  0.5
 Reviewer:  ahf|Sponsor:  Sponsor55-must
---+
Changes (by teor):

 * parent:  #33817 => #33048


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

Re: [tor-bugs] #33917 [Core Tor/Tor]: Make IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL

[Tor Bug Tracker & Wiki]

#33917: Make IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL
-+-
 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.9.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ipv6, prop311, prop312, technical-   |  Actual Points:  0.2
  debt   |
Parent ID:  #33048   | Points:  0.2
 Reviewer:  ahf  |Sponsor:
 |  Sponsor55-must
-+-
Changes (by teor):

 * parent:  #33817 => #33048


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  #33048 | Points:  0
 Reviewer: |Sponsor:
   |  Sponsor55-must
---+---
Changes (by teor):

 * parent:  #33817 => #33048


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  closed
 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- |  implemented
  roadmap-2020Q2 |  Actual Points:  0.3
Parent ID:  #33048   | Points:  0.5
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-must
-+-
Changes (by teor):

 * parent:  #33220 => #33048


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

[Tor Bug Tracker & Wiki]

#33817: Perform Basic Relay IPv6 Extends
---+
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  ipv6, prop311  |  Actual Points:  3.2
Parent ID:  #33048 | Points:  1
 Reviewer:  nickm  |Sponsor:  Sponsor55-must
---+
Changes (by teor):

 * parent:  #33220 => #33048


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

Re: [tor-bugs] #33633 [Core Tor/Tor]: Move extend and reachability code to the relay module

[Tor Bug Tracker & Wiki]

#33633: Move extend and reachability code to the relay module
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, prop311, technical-debt,   |  implemented
  network-team-roadmap-2020Q1|  Actual Points:  1.0
Parent ID:  #33048   | Points:  0.5
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-must
-+-
Changes (by teor):

 * parent:  #33220 => #33048


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

Re: [tor-bugs] #33596 [Core Tor/Chutney]: Fix or disable mixed+hs-v2 for Tor 0.3.5

[Tor Bug Tracker & Wiki]

#33596: Fix or disable mixed+hs-v2 for Tor 0.3.5
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ipv6, prop311, network-team- |  Actual Points:
  roadmap-2020Q1 |
Parent ID:  #33050   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor55-can
-+-
Changes (by teor):

 * parent:  #33379 => #33050


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

Re: [tor-bugs] #33271 [Core Tor/Chutney]: Prop 313: 8.2. Test IPv6 Statistics using Chutney

[Tor Bug Tracker & Wiki]

#33271: Prop 313: 8.2. Test IPv6 Statistics using Chutney
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  prop313, ipv6 |  Actual Points:
Parent ID:  #33272| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * sponsor:  Sponsor55-must =>


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

Re: [tor-bugs] #33407 [Core Tor/Tor]: Make chutney bridge authorities publish bridges in their networkstatus-bridges

[Tor Bug Tracker & Wiki]

#33407: Make chutney bridge authorities publish bridges in their networkstatus-
bridges
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, prop311, tor-bridge, chutney,  |  duplicate
  outreachy-ipv6 |  Actual Points:
Parent ID:  #33581   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * sponsor:  Sponsor55-can =>


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

Re: [tor-bugs] #33267 [Core Tor/Chutney]: Prop 313: 8.1. Test IPv6 Relay Consensus Counts using Chutney

[Tor Bug Tracker & Wiki]

#33267: Prop 313: 8.1. Test IPv6 Relay Consensus Counts using Chutney
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  prop313, ipv6 |  Actual Points:
Parent ID:  #33268| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * sponsor:  Sponsor55-must =>


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

Re: [tor-bugs] #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:  closed
 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-|  duplicate
  maybe, 033-triage-20180320,|  Actual Points:
  033-removed-20180320, 035-deferred-20190115,   |
  041-proposed   |
Parent ID:  #33880   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * sponsor:  Sponsor55-can =>


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

Re: [tor-bugs] #33263 [Core Tor/Tor]: Prop 313: 4. Collect IPv6 Bandwidth Stats on Relays and Bridges

[Tor Bug Tracker & Wiki]

#33263: Prop 313: 4. Collect IPv6 Bandwidth Stats on Relays and Bridges
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop313, ipv6  |  Actual Points:
Parent ID:  #33052 | Points:  3
 Reviewer: |Sponsor:  Sponsor55-must
---+
Changes (by teor):

 * points:  1 => 3


Comment:

 Since we've done the detailed design work on this task, I am revising the
 estimates up.

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

Re: [tor-bugs] #33264 [Core Tor/Tor]: Prop 313: 5. Collect IPv6 Connection Stats on Relays

[Tor Bug Tracker & Wiki]

#33264: Prop 313: 5. Collect IPv6 Connection Stats on Relays
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop313, ipv6  |  Actual Points:
Parent ID:  #33052 | Points:  5
 Reviewer: |Sponsor:  Sponsor55-must
---+
Changes (by teor):

 * points:  2 => 5


Comment:

 Since we've done the detailed design work on this task, I am revising the
 estimates up.

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

 Yeah, I can try to explain how we got here, and then folks can decide if
 they have a better place we can get to.

 When you receive a connection from a relay, it never comes from the
 relay's IP address and ORPort. At best, it comes from the relay's IP
 address and some high-numbered port. So if you rely on the address and
 port of the incoming connection to be able to learn which relay it is,
 there will at best be ambiguity in the cases where an IP address runs more
 than one relay ("which one is the one that connected to you?"), and at
 worst the connection came from a different IP address than is listed in
 the relay's descriptor, for example because the other side sets
 OutboundBindAddress, or because they *don't* set it but their default
 route goes out through a different IP address, or because you do some port
 forwarding thing on your side so it looks to you like connections come
 from your forwarder.

 Also there's the (hopefully less common) case where somebody is trying to
 do a person-in-the-middle attack where they ask the other side to extend
 to your identity but their address, and then they forward the connection
 to you. Or they ask you to connect to some remote relay but at a
 nonstandard address and port, and then they redirect that connection to
 the relay.

 Ok. Given that context, here are the rules we followed back when I wrote
 this part:

 * If the connection is to (or from) a known relay, then addr and port will
 tell you which relay it is.
 * Else (not to/from a known relay), addr and port will be whatever you
 tried to connect to, or whatever TCP told you for the incoming connection.

 * real_addr will always be whatever-you-tried-to-connect-to or whatever-
 TCP-told-you. In the case where we overwrote addr and port because it's a
 known relay, there is no concept of real_port, i.e. that information is
 discarded.
 * address will always be a string version of addr. We keep it entirely so
 we don't have to keep recreating it every time we want to write addr
 somewhere.

 For extra context, the above conventions predate the "canonical" flag, and
 also predate the DoS subsystem (which rightly looks at real_addr rather
 than addr).

 I agree that these rules start to get ugly once relays have multiple
 canonical addresses.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #33241, #33242, #33243, #33244, ...

[Tor Bug Tracker & Wiki]

Batch modification to #33241, #33242, #33243, #33244, #33249 by teor:
sponsor to Sponsor55-can

Comment:
I've made all the IPv6 directory fetch tasks optional, because they could take 
a lot of work, and they are high-risk.

When we finish the required tasks, we can prioritise the optional tasks.

--
Tickets URL: 

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

Re: [tor-bugs] #33239 [Core Tor/Tor]: Prop 312: 3.2.3 Limit Directory Authority Addresses to Address and ORPort

[Tor Bug Tracker & Wiki]

#33239: Prop 312: 3.2.3 Limit Directory Authority Addresses to Address and 
ORPort
+--
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop312, tor-dirauth, security-low  |  Actual Points:
Parent ID:  #33049  | Points:  1
 Reviewer:  |Sponsor:
|  Sponsor55-must
+--
Changes (by teor):

 * keywords:  prop312, tor-dirauth => prop312, tor-dirauth, security-low


Comment:

 I think we should do #33237 and #33239, but they aren't urgent, so we
 should leave them until the end of the project.

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

Re: [tor-bugs] #33237 [Core Tor/Tor]: Prop 312: 3.2.2. Stop Directory Authorities Resolving *Port Hostnames

[Tor Bug Tracker & Wiki]

#33237: Prop 312: 3.2.2. Stop Directory Authorities Resolving *Port Hostnames
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop312, tor-dirauth, security-low  |  Actual Points:
Parent ID:  #33049  | Points:  1
 Reviewer:  |Sponsor:
|  Sponsor55-must
+--
Changes (by teor):

 * sponsor:  Sponsor55-can => Sponsor55-must


Comment:

 I think we should do #33237 and #33239, but they aren't urgent, so we
 should leave them until the end of the project.

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

Re: [tor-bugs] #33224 [Core Tor/Tor]: Prop 311: 4.3.2. Add AssumeReachableIPv6 Option and Consensus Parameter

[Tor Bug Tracker & Wiki]

#33224: Prop 311: 4.3.2. Add AssumeReachableIPv6 Option and Consensus Parameter
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:
Parent ID:  #33221 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-must
---+

Comment (by teor):

 In the meeting today, we decided to do this ticket, because:
 * it won't take much work, and
 * it lets us react quickly to any bugs in the new reachability code.

 For similar reasons, we also want an AssumeReachable consensus parameter
 for IPv4 and IPv6, see #34064.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34064 [Core Tor/Tor]: Add an AssumeReachable consensus parameter

[Tor Bug Tracker & Wiki]

#34064: Add an AssumeReachable consensus parameter
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:  prop311
Actual Points:  |  Parent ID:  #33221
   Points:  0.5 |   Reviewer:
  Sponsor:  Sponsor55-must  |
+
 Like #33224, we want a network-wide consensus parameter that makes relays
 and bridges assume they are reachable.

 We'll be modifying the IPv4 and IPv6 reachability code, so we need to be
 able to respond quickly to IPv4 reachability bugs as well.

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

Re: [tor-bugs] #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
---+---

Old description:

> 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.
>
> We may also need separate fields for reverse proxied addresses, see the
> comment at:
> https://github.com/torproject/tor/blob/7517e1b5d31aada1f594c2594737a231d9d8e116/src/core/or/channeltls.c#L1339
>
> 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.

New description:

 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.

 See:
 
https://github.com/torproject/tor/blob/7f9eaec538b7d01e0d1b130dc4cf2ec634252d46/src/core/or/connection_or.c#L920

 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.

 We may also need separate fields for reverse proxied addresses, see the
 comment at:
 
https://github.com/torproject/tor/blob/7517e1b5d31aada1f594c2594737a231d9d8e116/src/core/or/channeltls.c#L1339

 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.

--

Comment (by teor):

 Add link to a comment that explains why we have real_addr:
 
https://github.com/torproject/tor/blob/7f9eaec538b7d01e0d1b130dc4cf2ec634252d46/src/core/or/connection_or.c#L920

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

Old description:

> 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.

New description:

 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.

 We may also need separate fields for reverse proxied addresses, see the
 comment at:
 
https://github.com/torproject/tor/blob/7517e1b5d31aada1f594c2594737a231d9d8e116/src/core/or/channeltls.c#L1339

 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.

--

Comment (by teor):

 We may also need separate fields for reverse proxied addresses, see the
 comment at:
 
https://github.com/torproject/tor/blob/7517e1b5d31aada1f594c2594737a231d9d8e116/src/core/or/channeltls.c#L1339

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

[Tor Bug Tracker & Wiki]

#33817: Perform Basic Relay IPv6 Extends
---+
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  ipv6, prop311  |  Actual Points:  3.2
Parent ID:  #33220 | Points:  1
 Reviewer:  nickm  |Sponsor:  Sponsor55-must
---+
Changes (by nickm):

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


Comment:

 LGTM now. Merging.

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

Re: [tor-bugs] #33835 [Circumvention/BridgeDB]: Gmail's quoted response confuses BridgeDB's email autoresponder

[Tor Bug Tracker & Wiki]

#33835: Gmail's quoted response confuses BridgeDB's email autoresponder
+
 Reporter:  phw |  Owner:  agix
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  s30-o22a2   |  Actual Points:
Parent ID:  #31279  | Points:  1
 Reviewer:  |Sponsor:  Sponsor30-can
+
Changes (by phw):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:11 agix]:
 > There you go:
 >
 
[https://github.com/agiix/bridgedb/commit/1fb531ed505352026223c298607554654116564e]
 >
 > Correction about comment:8
 > What I meant was that all but 4 unit tests (and a few commented out
 ones) pass :)
 [[br]]
 Thanks! I left a bunch of comments
 
[https://github.com/agiix/bridgedb/commit/1fb531ed505352026223c298607554654116564e
 here]. The overall approach seems reasonable but we should make a handful
 of small changes – I'm happy to elaborate on any of my comments, just let
 me know. I would also suggest to not worry about the unit tests for now.
 Let's make sure that we're happy with the overall design, and then we can
 make sure that everything is properly tested.

 Finally, please don't feel discouraged by my asking for revisions. Non-
 trivial patches (and this certainly is one) typically go through at least
 one round of revisions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34063 [Internal Services/Services Admin Team]: [RT-admin] Check if spam filter script is running

[Tor Bug Tracker & Wiki]

#34063: [RT-admin] Check if spam filter script is running
-+-
 Reporter:  ggus |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services   |Version:
  Admin Team |
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 According to RT service documentation[1], there are some maintenance
 actions happening like spam training in RT. Since we're receiving a lot of
 spam, we should verify if spam filter is actually running.


 {{{
 Spam training

 Every mail sent to RT is also sent to the rtmailarchive account. This is
 required to be able to train SpamAssassin as it can only learn from
 unaltered email messages.

 A three steps cronjob is run daily.

 ​Step 1: Every mail in Maildir/.help* is checked against the RT. For each
 message, we look up a matching ticket using the Message-Id header. If the
 ticket is in a help* queue and has status resolved, we move it to the ham
 training folder. If the ticket in in the spam queue and has status
 resolved, we move it to the spam training folder. If the file is more than
 100 days old, we delete it.

 Step 2: SpamAssassin is fed with the content of the ham and spam training
 folder. After the process, the message is moved to the corresponding
 learned folder.

 Step 3: Message in the learned folders are deleteed.
 }}}

 [1]
 
https://trac.torproject.org/projects/tor/wiki/org/operations/services/rt.torproject.org#Spamtraining

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

Re: [tor-bugs] #34036 [Internal Services/Services Admin Team]: audit access permissions in rt.torproject.org

[Tor Bug Tracker & Wiki]

#34036: audit access permissions in rt.torproject.org
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ggus):

 Based on the last membership review, I removed users who are no longer
 part of core contributors.

 We still need to audit permissions and queues.

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

Re: [tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

[Tor Bug Tracker & Wiki]

#33666: Investigate Snowflake proxy failures
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by phw):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:23 cohosh]:
 > Okay I just removed the one unused variable.
 >
 > I also realized I opened this PR for the wrong repo. Here's a new one:
 https://github.com/cohosh/snowflake-webext/pull/3
 [[br]]
 LGTM!

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

Re: [tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

[Tor Bug Tracker & Wiki]

#33666: Investigate Snowflake proxy failures
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * status:  needs_information => needs_review


Comment:

 Okay I just removed the one unused variable.

 I also realized I opened this PR for the wrong repo. Here's a new one:
 https://github.com/cohosh/snowflake-webext/pull/3

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

Re: [tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

[Tor Bug Tracker & Wiki]

#33666: Investigate Snowflake proxy failures
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_information
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by phw):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:20 cohosh]:
 > Alright here's a new PR that uses an additive adjustment to the poll
 interval: https://github.com/cohosh/snowflake/pull/27
 [[br]]
 I left two questions on the PR. Other than that, the code looks good!

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

[Tor Bug Tracker & Wiki]

#33817: Perform Basic Relay IPv6 Extends
---+
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:  3.2
Parent ID:  #33220 | Points:  1
 Reviewer:  nickm  |Sponsor:  Sponsor55-must
---+
Changes (by teor):

 * status:  needs_revision => needs_review
 * actualpoints:  3 => 3.2


Comment:

 Thanks for the review!

 I made the requested fixes, the code is a bit cleaner 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] #34055 [Applications/Tor Browser]: Use and document 'tbb-backport' in the release process

[Tor Bug Tracker & Wiki]

#34055: Use and document 'tbb-backport' in the release process
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 BTW, what's wrong with with the variant in the comment:description for
 you?
 `tbb-backport` doesn't seem to be documented in
 https://gitweb.torproject.org/tor-browser-
 spec.git/tree/processes/ReleaseProcess

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

Re: [tor-bugs] #29077 [Circumvention/meek]: uTLS for meek-client camouflage

[Tor Bug Tracker & Wiki]

#29077: uTLS for meek-client camouflage
+-
 Reporter:  dcf |  Owner:  dcf
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Circumvention/meek  |Version:
 Severity:  Normal  | Resolution:  implemented
 Keywords:  moat utls   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  ahf |Sponsor:
+-

Comment (by dcf):

 Replying to [comment:12 dcf]:
 > When creating the internal `http.Transport`, I think I'd like to make it
 have the same default settings as `http.DefaultTransport` with respect to
 timeouts, idle connections, etc. So I'm thinking of cloning the public
 fields of `http.DefaultTransport` using the reflection trick from
 comment:11:ticket:12208.

 Since go1.13 there is a [https://golang.org/pkg/net/http/#Transport.Clone
 Transport.Clone] function that can replace the use of reflection to copy a
 `Transport`. See https://github.com/golang/go/issues/26013. I made meek
 use the new function [https://gitweb.torproject.org/pluggable-
 transports/meek.git/commit/?id=bc887de694bc2d2381af099d5c38f0e9efd76c4b
 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] #25595 [Circumvention/Snowflake]: Test suite for Snowflake on various NAT topologies

[Tor Bug Tracker & Wiki]

#25595: Test suite for Snowflake on various NAT topologies
+--
 Reporter:  arlolra |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1  |  Actual Points:
Parent ID:  | Points:  5
 Reviewer:  |Sponsor:
|  Sponsor28-can
+--

Comment (by viatsk):

 The vnet NAT implementation appears to have the options necessary to
 configure the type of NAT, which they make use of in their
 [https://github.com/pion/transport/blob/master/vnet/nat_test.go tests]. I
 think the next step here is to spin up two NATs and try to get them to
 send binding requests to each other.

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

Re: [tor-bugs] #34062 [Applications/GetTor]: Gracefully shutdown services in GetTor

[Tor Bug Tracker & Wiki]

#34062: Gracefully shutdown services in GetTor
-+--
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Low  |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * status:  new => needs_review


Comment:

 https://gitlab.torproject.org/torproject/anti-censorship/gettor-
 project/gettor/-/merge_requests/8

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

Re: [tor-bugs] #34061 [Applications/GetTor]: Reduce amount of GetTor logging

[Tor Bug Tracker & Wiki]

#34061: Reduce amount of GetTor logging
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Low  |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, starter|  Actual Points:
Parent ID:   | Points:  .5
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 This assigns more appropriate levels to existing log messages and sets the
 default log level to "info": https://gitlab.torproject.org/torproject
 /anti-censorship/gettor-project/gettor/-/merge_requests/7

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

Re: [tor-bugs] #34061 [Applications/GetTor]: Reduce amount of GetTor logging

[Tor Bug Tracker & Wiki]

#34061: Reduce amount of GetTor logging
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Low  |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, starter|  Actual Points:
Parent ID:   | Points:  .5
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * 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] #34029 [Metrics/CollecTor]: Add more command-line arguments to the Nagios CollecTor check script

[Tor Bug Tracker & Wiki]

#34029: Add more command-line arguments to the Nagios CollecTor check script
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Looks good. Thank you!

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

Re: [tor-bugs] #31877 [Community/Outreach]: Promote workshops on how to set up a bridge at relay operator meetups

[Tor Bug Tracker & Wiki]

#31877: Promote workshops on how to set up a bridge at relay operator meetups
+
 Reporter:  phw |  Owner:  ggus
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  s30-o24a3   |  Actual Points:
Parent ID:  #31281  | Points:  3
 Reviewer:  |Sponsor:  Sponsor30-must
+
Changes (by ggus):

 * owner:  (none) => ggus
 * component:  Circumvention => Community/Outreach


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

Re: [tor-bugs] #34029 [Metrics/CollecTor]: Add more command-line arguments to the Nagios CollecTor check script

[Tor Bug Tracker & Wiki]

#34029: Add more command-line arguments to the Nagios CollecTor check script
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by anarcat):

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


Comment:

 Replying to [comment:5 karsten]:
 > Replying to [comment:4 anarcat]:
 > >  1. add the collector/collector2 hosts (and you lose the
 colchicifolium/corsicum reference)
 > >  2. add a collector2 service (and you still don't have the
 colchicifolium/corsicum reference)
 >
 > If this is just about the "global/collector" thing, I'm fine with having
 a "global/collector" and "global/collector2" without the host names.

 Done.

 > >  3. add the service to the colchicifolium/corsicum hosts, but then you
 need to fix the check to be able to bypass DNS, as I said
 >
 > I'm afraid this isn't trivial to do for me. If one of the variants above
 works, I'd like to avoid digging deeper into Python library stuff here.

 It's not exactly trivial, which is why I warned about this. :)

 I pushed the new checks now, let me know if it doesn't work as expected...

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

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_revision
 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, asn|Sponsor:
--+

Comment (by Jaym):

 Thanks! rebased on https://github.com/torproject/tor/pull/1873

 + tried to improve based on asn's comments

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

[Tor Bug Tracker & Wiki]

#33817: Perform Basic Relay IPv6 Extends
---+
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:  3
Parent ID:  #33220 | Points:  1
 Reviewer:  nickm  |Sponsor:  Sponsor55-must
---+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 I've left some small-ish comments on the PR; nothing major.  I think this
 should work.

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

Re: [tor-bugs] #34061 [Applications/GetTor]: Reduce amount of GetTor logging

[Tor Bug Tracker & Wiki]

#34061: Reduce amount of GetTor logging
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Low  |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, starter|  Actual Points:
Parent ID:   | Points:  .5
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

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


Comment:

 Getting moving on this will help us monitor the logs for critical errors
 more easily.

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

Re: [tor-bugs] #34029 [Metrics/CollecTor]: Add more command-line arguments to the Nagios CollecTor check script

[Tor Bug Tracker & Wiki]

#34029: Add more command-line arguments to the Nagios CollecTor check script
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Replying to [comment:4 anarcat]:
 >  1. add the collector/collector2 hosts (and you lose the
 colchicifolium/corsicum reference)
 >  2. add a collector2 service (and you still don't have the
 colchicifolium/corsicum reference)

 If this is just about the "global/collector" thing, I'm fine with having a
 "global/collector" and "global/collector2" without the host names.

 >  3. add the service to the colchicifolium/corsicum hosts, but then you
 need to fix the check to be able to bypass DNS, as I said

 I'm afraid this isn't trivial to do for me. If one of the variants above
 works, I'd like to avoid digging deeper into Python library stuff here.

 Thanks!

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

[tor-bugs] #34062 [Applications/GetTor]: Gracefully shutdown services in GetTor

[Tor Bug Tracker & Wiki]

#34062: Gracefully shutdown services in GetTor
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 I get these errors when I shutdown or restart GetTor. Seems like something
 we can easily implement:

 {{{
 2020-04-29T15:24:03+ [gettor#debug] SERVICE:: Calling shutdown on
 sendmail
 2020-04-29T15:24:03+ [twisted.internet.defer#critical] Unhandled error
 in Deferred:
 2020-04-29T15:24:03+ [twisted.internet.defer#critical]
 Traceback (most recent call last):
   File "/usr/lib/python3/dist-packages/twisted/internet/base.py",
 line 428, in fireEvent
 result = callable(*args, **kwargs)
   File "/usr/lib/python3/dist-
 packages/twisted/application/service.py", line 296, in stopServ
 ice
 l.append(defer.maybeDeferred(service.stopService))
   File "/usr/lib/python3/dist-packages/twisted/internet/defer.py",
 line 151, in maybeDeferred
 result = f(*args, **kw)
   File "/usr/lib/python3/dist-
 packages/twisted/application/service.py", line 296, in stopServ
 ice
 l.append(defer.maybeDeferred(service.stopService))
 ---  ---
   File "/usr/lib/python3/dist-packages/twisted/internet/defer.py",
 line 151, in maybeDeferred
 result = f(*args, **kw)
   File
 "/srv/gettor.torproject.org/home/gettor/gettor/services/__init__.py", line
 60, in stop
 Service
 self.instance.shutdown()
 builtins.AttributeError: 'Sendmail' object has no attribute
 'shutdown'
 }}}

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

Re: [tor-bugs] #33950 [Applications/Tor Browser]: Add instructions for rolling back already rolled out update in tor-browser-spec.git/processes/ReleaseProcess

[Tor Bug Tracker & Wiki]

#33950: Add instructions for rolling back already rolled out update in 
tor-browser-
spec.git/processes/ReleaseProcess
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam202004R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Looks good to me. Merged to `master` as commit
 c1a8d19ec385b815f54d26638f886588e1854294 (with a small typo fix committed
 as 99878a95e913e3286f6d756429129cd15ce94791).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34061 [Applications/GetTor]: Reduce amount of GetTor logging

[Tor Bug Tracker & Wiki]

#34061: Reduce amount of GetTor logging
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:  easy, starter
Actual Points:   |  Parent ID:
   Points:  .5   |   Reviewer:
  Sponsor:   |
-+---
 We're logging at a very high level (looks like at debug), and outputting
 frequent successes when we only really need to be logging errors.

 For example: a successfully processed email in `log/email_parser.log`
 outputs:
 {{{
 2020-04-27 23:18:53+ [-] Log opened.
 2020-04-27 23:18:53+ [process email] New email request received.
 2020-04-27 23:18:53+ [process email] Reading new email.
 2020-04-27 23:18:53+ [-] Database query executed successfully.
 2020-04-27 23:18:53+ [email parser] Building email message from
 string.
 2020-04-27 23:18:53+ [email parser] Normalizing and validating FROM
 email address.
 2020-04-27 23:18:53+ [email parser] Email address normalized and
 validated.
 2020-04-27 23:18:53+ [email parser] Request from [hid]
 2020-04-27 23:18:53+ [email parser] Found request for links.
 2020-04-27 23:18:53+ [-] Database query executed successfully.
 2020-04-27 23:18:53+ [-] Main loop terminated.
 2020-04-27 23:18:53+ [process email] Email request processed.
 }}}
 and in `log/gettor.log`:
 {{{
 2020-04-29T14:46:51+ [gettor#info] Getting links for windows is.
 2020-04-29T14:46:51+ [-] Database query executed successfully.
 2020-04-29T14:46:51+ [gettor#info] Sending links to [hid].
 2020-04-29T14:46:51+ [gettor#debug] Creating plain text email
 2020-04-29T14:46:51+ [gettor#debug] Calling asynchronous sendmail.
 2020-04-29T14:46:51+ [twisted.mail.smtp.ESMTPSenderFactory#info]
 Starting factory 
 2020-04-29T14:46:51+ [gettor#info] Email sent successfully.
 2020-04-29T14:46:51+ [twisted.mail.smtp.ESMTPSenderFactory#info]
 Stopping factory 
 2020-04-29T14:46:51+ [-] Database query executed successfully.
 2020-04-29T14:46:51+ [-] Database query executed successfully.
 }}}

 We could reduce this to one log message at most. Especially since this
 information *should* be captured in the stats database.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34060 [Applications/GetTor]: Errors thrown in Gettor if "To:" address field doesn't match gettor@tp.o

[Tor Bug Tracker & Wiki]

#34060: Errors thrown in Gettor if "To:" address field doesn't match gettor@tp.o
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:  1|   Reviewer:
  Sponsor:   |
-+
 I was checking the logs for errors and found a bunch of the following
 failures:

 {{{
 2020-04-29 07:57:51+ [email parser] Error while parsing email content:
 [Failure instance: Traceba
 ck: : 'command'
 /usr/lib/python3/dist-
 packages/twisted/internet/defer.py:311:addCallbacks
 /usr/lib/python3/dist-
 packages/twisted/internet/defer.py:654:_runCallbacks
 /usr/lib/python3/dist-
 packages/twisted/internet/defer.py:1613:unwindGenerator
 /usr/lib/python3/dist-
 packages/twisted/internet/defer.py:1529:_cancellableInlineCallbacks
 ---  ---
 /usr/lib/python3/dist-
 packages/twisted/internet/defer.py:1418:_inlineCallbacks
 /srv/gettor.torproject.org/home/gettor/gettor/parse/email.py:250:parse_callback
 ].
 }}}

 I noticed this is caused by `parse` returning an empty request
 [https://gitweb.torproject.org/gettor.git/tree/gettor/parse/email.py#n220
 here] which only happens if the `"To:"` address doesn't match
 `get...@torproject.org` exactly. After doing more looking, I found the
 following mismatched addresses:
 - "To:" address is just blank
 - gettor+[lang code]@torproject.org (e.g., gettor...@torproject.org).
 - [random user]@gmail.com
 - [user]@[random domain].[random tld]

 (where random = no known connection to gettor, not cryptographically
 random :))

 For the blank and random addresses, I wonder how this is happening.
 Perhaps we're relying on information that's not consistently configured
 correctly on user email clients?

 For addresses of the form gettor+[lang code]@torproject.org, it looks like
 gettor used to work by accepting emails of this form to determine
 localization (see https://twitter.com/get_tor/status/754126179506982912).
 Perhaps we shouldn't be throwing these out, even though we no longer do
 localization this way. We could use these language codes once we get
 around to localizing gettor messages as an optional step.

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

Re: [tor-bugs] #33952 [Applications/Tor Browser]: Document the process to update ssh keys and add/remove users from build-sunet-a.torproject.net

[Tor Bug Tracker & Wiki]

#33952: Document the process to update ssh keys and add/remove users from build-
sunet-a.torproject.net
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam202004R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Looks good now, thanks. I tried the removal of users (brade and mcs) and
 it worked, too. Merged to `master` with commit
 6768a86581b63bfa37279d3144e105faaa35e366.

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

Re: [tor-bugs] #34059 [Internal Services]: [RT-admin] Create new queues: giving@ and newsletter@

[Tor Bug Tracker & Wiki]

#34059: [RT-admin] Create new queues: giving@ and newsletter@
---+--
 Reporter:  ggus   |  Owner:  ggus
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Internal Services  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by ggus):

 I created newsletter and gave the same permission as 'press' group, and
 added this queue as a part of press permission group.

 I created giving and gave the same permission as 'donation' group, and
 added this queue as a part of donation permission group.

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

Re: [tor-bugs] #34035 [Applications/GetTor]: Dry out GetTor's sendmail function

[Tor Bug Tracker & Wiki]

#34035: Dry out GetTor's sendmail function
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  phw  |Sponsor:
-+
Changes (by cohosh):

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


Comment:

 Thanks! Merged and deployed :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34059 [Internal Services]: [RT-admin] Create new queues: giving@ and newsletter@

[Tor Bug Tracker & Wiki]

#34059: [RT-admin] Create new queues: giving@ and newsletter@
---+--
 Reporter:  ggus   |  Owner:  ggus
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Internal Services  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 - newsletter@rt: responses to the monthly newsletters

 - giving@rt: build relationship with donors

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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_revision
 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, asn|Sponsor:
--+
Changes (by asn):

 * status:  needs_review => needs_revision
 * reviewer:  nickm => nickm, asn


Comment:

 Hello, thanks for all the work here! I actually missed the proposal and
 the ticket so this caught me by surprise today. This seems really well
 thought all-in-all and a solid patch, and the test adjustments look good
 to.

 I added a few comments to the PR. It's mainly documentation requests to
 polish some parts that I didn't comprehend.

 Also, can the next revision come with a new PR, which contains the changes
 in the top commits? This can be done with a rebase. Isolating the changes
 of this PR was not easy for me because the relevant commits were scattered
 around the log.

 Thanks a lot!

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

Re: [tor-bugs] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

[Tor Bug Tracker & Wiki]

#33700: audio- and video-conferencing considerations
-+-
 Reporter:  anarcat  |  Owner:  gaba
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * owner:  hiro => gaba


Comment:

 gaba, the budget is ready in
 https://help.torproject.org/tsa/howto/conference/#Cost

 do not send to funders without a final review on my part please.

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

Re: [tor-bugs] #33992 [Applications/Tor Browser]: Treat securedrop.tor.onion as eTLD

[Tor Bug Tracker & Wiki]

#33992: Treat securedrop.tor.onion as eTLD
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:  acat, gk  |Sponsor:
--+--
Changes (by sysrqb):

 * status:  needs_revision => needs_review


Comment:

 I pushed two fixup commits to `bug33992_00`. I'll squash the three commits
 together before we merge them.

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

[tor-bugs] #34058 [Applications/GetTor]: Make sure gettor logs are scrubbed of personal info

[Tor Bug Tracker & Wiki]

#34058: Make sure gettor logs are scrubbed of personal info
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:  easy, starter
Actual Points:   |  Parent ID:
   Points:  1|   Reviewer:
  Sponsor:   |
-+---
 Some error messages in the gettor logs contain personal info from gettor
 queries. We should make sure we're not logging this information
 (particularly for email addresses in SMTP errors).

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

Re: [tor-bugs] #33992 [Applications/Tor Browser]: Treat securedrop.tor.onion as eTLD

[Tor Bug Tracker & Wiki]

#33992: Treat securedrop.tor.onion as eTLD
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:  acat, gk  |Sponsor:
--+

Comment (by sysrqb):

 Replying to [comment:6 gk]:
 > Overall, looks good. I feel though it might be worth moving the code
 blocks a bit around. Could you move
 > {{{
 > +  // Drop '.securedrop.tor.onion' suffix, and keep track of it for
 later
 > +  NS_NAMED_LITERAL_CSTRING(dotSDTO, ".securedrop.tor.onion");
 > +  const bool sdtoSuffix = StringEndsWith(aHostname, dotSDTO);
 > +  if (sdtoSuffix) aHostname.Truncate(aHostname.Length() -
 dotSDTO.Length());
 > +
 > }}}
 > after the edge case check. I feel both the one before and after your
 change should stay grouped together.

 Yes, that makes sense. I'll change that.

 >
 > Additionally, could we move the other two changes before the repsective
 `aBaseDomain.Append('.');` parts? We remove the `.` first and we should
 add them therefore last again.

 That's a nice bug. It's good you noticed it.

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

Re: [tor-bugs] #12802 [Circumvention/BridgeDB]: BridgeDB needs Nagios checks for the Email Distributor

[Tor Bug Tracker & Wiki]

#12802: BridgeDB needs Nagios checks for the Email Distributor
-+-
 Reporter:  isis |  Owner:  phw
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-email, nagios, anti-|  Actual Points:
  censorship-roadmap-2020Q1  |
Parent ID:  #30152   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-

Comment (by hiro):

 I understand now what is happening with this host. Sorry about the
 confusion. I will enable the check.

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

Re: [tor-bugs] #33992 [Applications/Tor Browser]: Treat securedrop.tor.onion as eTLD

[Tor Bug Tracker & Wiki]

#33992: Treat securedrop.tor.onion as eTLD
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:  acat, gk  |Sponsor:
--+

Comment (by acat):

 Replying to [comment:5 sysrqb]:
 > Adding gk as a reviewer, too.
 >
 > acat, I had another question for you, as well. I don't have a strong
 feeling about this, so we can leave it if you think it is helpful in
 another way.
 >
 > > if we use this, should we just delete `tor.onion` and
 `securedrop.tor.onion` from `effective_tld_names.dat`?
 Yeah, I think we can remove the `effective_tld_names.dat` changes, as your
 patch works better for what we have now in Tor Browser (the SecureDrop
 rulesets). I don't see cases where we would need the changes in
 `effective_tld_names.dat`, at least for now. We will probably have to
 revise this anyway if we have to support rules other than
 `*.securedrop.tor.onion`.

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

Re: [tor-bugs] #21549 [Applications/Tor Browser]: Investigate wasm for linkability/fingerprintability/disk avoidance issues

[Tor Bug Tracker & Wiki]

#21549: Investigate wasm for linkability/fingerprintability/disk avoidance 
issues
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff68-esr, tbb-9.0,   |  Actual Points:  1.5
  TorBrowserTeam201910R, BugSmashFund, tbb-  |
  backport   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff68-esr, tbb-9.0, TorBrowserTeam201910R, tbb-backport,
 BugSmashFund => ff68-esr, tbb-9.0, TorBrowserTeam201910R,
 BugSmashFund, tbb-backport


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

Re: [tor-bugs] #34055 [Applications/Tor Browser]: Use and document 'tbb-backport' in the release process

[Tor Bug Tracker & Wiki]

#34055: Use and document 'tbb-backport' in the release process
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > Yeah, I added a better link.
 So error-prone that #21549 is missed right now :(
 > It does not seem like we do this for the upcoming stable release and the
 next regular stable one is 9.5.
 Then it will be the first minor stable release you don't use to test your
 improvements (except version updates). That means you will lose the whole
 release cycle to receive feedback from the users :(

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

Re: [tor-bugs] #34029 [Metrics/CollecTor]: Add more command-line arguments to the Nagios CollecTor check script

[Tor Bug Tracker & Wiki]

#34029: Add more command-line arguments to the Nagios CollecTor check script
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by anarcat):

 * owner:  anarcat => metrics-team
 * status:  accepted => assigned


Comment:

 >  Regarding the host/address hack, I don't think we'll need that. We can
 simply put in the public DNS name, rather than the host name.
 >
 > anarcat, can you review these changes and deploy two checks for the two
 hosts, ideally labeled as "colchicifolium/collector" and
 "corsicum/collector", so that I can quickly notice which one I need to
 fix?

 well that's the thing: service checks are attached to hosts here, and
 right now the hostnames are colchicifolium and corsicum - the "collector"
 and "collector2" names do not exist in nagios. so we can either:

  1. add the collector/collector2 hosts (and you lose the
 colchicifolium/corsicum reference)
  2. add a collector2 service (and you still don't have the
 colchicifolium/corsicum reference)
  3. add the service to the colchicifolium/corsicum hosts, but then you
 need to fix the check to be able to bypass DNS, as I said

 Which one will it be? :)

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

Re: [tor-bugs] #33992 [Applications/Tor Browser]: Treat securedrop.tor.onion as eTLD

[Tor Bug Tracker & Wiki]

#33992: Treat securedrop.tor.onion as eTLD
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:  acat, gk  |Sponsor:
--+
Changes (by gk):

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


Comment:

 Overall, looks good. I feel though it might be worth moving the code
 blocks a bit around. Could you move
 {{{
 +  // Drop '.securedrop.tor.onion' suffix, and keep track of it for later
 +  NS_NAMED_LITERAL_CSTRING(dotSDTO, ".securedrop.tor.onion");
 +  const bool sdtoSuffix = StringEndsWith(aHostname, dotSDTO);
 +  if (sdtoSuffix) aHostname.Truncate(aHostname.Length() -
 dotSDTO.Length());
 +
 }}}
 after the edge case check. I feel both the one before and after your
 change should stay grouped together.

 Additionally, could we move the other two changes before the repsective
 `aBaseDomain.Append('.');` parts? We remove the `.` first and we should
 add them therefore last again.

 I still need to test the changes.

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

Re: [tor-bugs] #34029 [Metrics/CollecTor]: Add more command-line arguments to the Nagios CollecTor check script

[Tor Bug Tracker & Wiki]

#34029: Add more command-line arguments to the Nagios CollecTor check script
---+--
 Reporter:  karsten|  Owner:  anarcat
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by anarcat):

 * owner:  metrics-team => anarcat
 * status:  new => accepted


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

Re: [tor-bugs] #33576 [Applications/Tor Browser]: Update pion-webrtc version to 2.2.3

[Tor Bug Tracker & Wiki]

#33576: Update pion-webrtc version to 2.2.3
-+-
 Reporter:  cohosh   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  snowflake, TorBrowserTeam202004R,|  Actual Points:
  tbb-9.5a12 |
Parent ID:   | Points:
 Reviewer:  boklm|Sponsor:
-+-
Changes (by sysrqb):

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


Comment:

 Looks good! Thanks! I merged it with commit
 `7464798ed3a34a2d492c55e34673dbe3d4a134d2`.

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

Re: [tor-bugs] #34029 [Metrics/CollecTor]: Add more command-line arguments to the Nagios CollecTor check script

[Tor Bug Tracker & Wiki]

#34029: Add more command-line arguments to the Nagios CollecTor check script
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * cc: anarcat, tpa (added)


Comment:

 I updated the script. Changes are:
  - The script now uses argparse to parse arguments.
  - The newly added `-m` argument allows ignoring missing timestamps. This
 makes it possible to also check the backup CollecTor host that doesn't
 archive all descriptor types.

 Regarding the host/address hack, I don't think we'll need that. We can
 simply put in the public DNS name, rather than the host name. Examples:

 {{{
 python3 tor-check-collector -s collector.torproject.org   # for
 colchicifolium
 python3 tor-check-collector -s -m collector2.torproject.org   # for
 corsicum
 }}}

 anarcat, can you review these changes and deploy two checks for the two
 hosts, ideally labeled as "colchicifolium/collector" and
 "corsicum/collector", so that I can quickly notice which one I need to
 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] #34029 [Metrics/CollecTor]: Add more command-line arguments to the Nagios CollecTor check script

[Tor Bug Tracker & Wiki]

#34029: Add more command-line arguments to the Nagios CollecTor check script
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * Attachment "tor-check-collector" 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] #28672 [Circumvention/Snowflake]: Android reproducible build of Snowflake

[Tor Bug Tracker & Wiki]

#28672: Android reproducible build of Snowflake
-+-
 Reporter:  dcf  |  Owner:  cohosh
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  GeorgKoppen201904, ex-sponsor-19,  |
  TorBrowserTeam201907   |
Parent ID:  #30318   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-
Changes (by cohosh):

 * owner:  (none) => cohosh
 * status:  needs_revision => assigned


Comment:

 Picking this up to work on it.

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

Re: [tor-bugs] #34056 [Internal Services/Tor Sysadmin Team]: Please remove irl from gitolite LDAP group

[Tor Bug Tracker & Wiki]

#34056: Please remove irl from gitolite LDAP group
-+-
 Reporter:  irl  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 done, thanks

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

Re: [tor-bugs] #34056 [Internal Services/Tor Sysadmin Team]: Please remove irl from gitolite LDAP group

[Tor Bug Tracker & Wiki]

#34056: Please remove irl from gitolite LDAP group
-+-
 Reporter:  irl  |  Owner:  anarcat
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  new => accepted
 * owner:  tpa => anarcat


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

Re: [tor-bugs] #33576 [Applications/Tor Browser]: Update pion-webrtc version to 2.2.3

[Tor Bug Tracker & Wiki]

#33576: Update pion-webrtc version to 2.2.3
-+-
 Reporter:  cohosh   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, TorBrowserTeam202004R,|  Actual Points:
  tbb-9.5a12 |
Parent ID:   | Points:
 Reviewer:  boklm|Sponsor:
-+-
Changes (by cohosh):

 * status:  reopened => needs_review


Comment:

 Just did a nightly build of the snowflake project for linux and it worked:

 https://gitweb.torproject.org/user/cohosh/tor-browser-
 build.git/commit/?h=ticket/33576=be5efccdf6aeb316a2b8c9888a942e647c544bc9

 I figured out what likely went wrong: I probably had the right git_url the
 first time I built it as an alpha testbuild. And then re-ran gomodtorbm
 which gave me the incorrect url, but the alpha testbuild didn't notice
 because the git hash didn't change. That's my current theory and I've
 switched to nightly testbuilds so this doesn't happen again, hopefully :)

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

Re: [tor-bugs] #33694 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Allow setting up a locked update channel programatically

[Tor Bug Tracker & Wiki]

#33694: Allow setting up a locked update channel programatically
-+-
 Reporter:  acat |  Owner:  legind
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 Reported this in https://github.com/EFForg/https-everywhere/issues/19207.

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

Re: [tor-bugs] #34022 [Applications/Tor Browser]: Rename the testbuild/torbrowser-testbuild targets

[Tor Bug Tracker & Wiki]

#34022: Rename the testbuild/torbrowser-testbuild targets
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 An other possible change, related to this, is having separate makefile
 rules and rbm targets for alpha and nightly builds.

 Currently, selecting whether you want to do a nightly or alpha testbuild
 is hidden into a configuration file, but it might be better to select
 explicitly for each testbuild whether you want it to be alpha or nightly,
 for example with `make testbuild-alpha` or `make testbuild-nightly`.

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

Re: [tor-bugs] #33576 [Applications/Tor Browser]: Update pion-webrtc version to 2.2.3

[Tor Bug Tracker & Wiki]

#33576: Update pion-webrtc version to 2.2.3
-+-
 Reporter:  cohosh   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, TorBrowserTeam202004R,|  Actual Points:
  tbb-9.5a12 |
Parent ID:   | Points:
 Reviewer:  boklm|Sponsor:
-+-

Comment (by cohosh):

 That's weird. The build worked for me o.O I wonder why

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

Re: [tor-bugs] #33131 [Core Tor/Tor]: Bug: buf->datalen >= 0x7fffffff

[Tor Bug Tracker & Wiki]

#33131: Bug: buf->datalen >= 0x7fff
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: 0.4.4.x-final => Tor: 0.4.3.x-final


Comment:

 Okay. CI is passing and this still looks good.  Merging to master and
 marking for possible backport.

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

Re: [tor-bugs] #34055 [Applications/Tor Browser]: Use and document 'tbb-backport' in the release process

[Tor Bug Tracker & Wiki]

#34055: Use and document 'tbb-backport' in the release process
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:6 cypherpunks]:
 > > And, yes, we *are* using the ticket in the release process.
 > s/ticket/tag

 Thanks, fixed.

 > > At the end there is no guarantee that things tagged with `tbb-
 backport` get backported.
 > They should be re-tagged or cleared out of it every major stable update.
 And that should be documented and used as part of the release process.

 They do get cleared out with every major stable update and I just amended
 the text on the hacking document.

 > > Oh, and I updated
 https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking
 accordingly so that our use of `tbb-backport` is documented there.
 > The hyperlink
 https://trac.torproject.org/projects/tor/query?status=!closed
 =~tbb-backport is a search query which lists `tbb-backported` too. That's
 why it cannot be used.

 Yeah, I added a better link

 > Could you backport #32493 to get parity with tba?

 It does not seem like we do this for the upcoming stable release and the
 next regular stable one is 9.5.

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

Re: [tor-bugs] #33817 [Core Tor/Tor]: Perform Basic Relay IPv6 Extends

[Tor Bug Tracker & Wiki]

#33817: Perform Basic Relay IPv6 Extends
---+
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:  3
Parent ID:  #33220 | Points:  1
 Reviewer:  nickm  |Sponsor:  Sponsor55-must
---+
Changes (by nickm):

 * reviewer:   => nickm


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

Re: [tor-bugs] #32910 [Core Tor/Tor]: trace: Add tracepoints and userspace tracer support

[Tor Bug Tracker & Wiki]

#32910: trace: Add tracepoints and userspace tracer support
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tracing   |  Actual Points:
Parent ID:| Points:  3
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 This code is looking a lot better now.  I think that all we need is the
 documentation, testing, and some quick feedback from the research safety
 folks.  I've also left a couple of cosmetic comments on gihub.

 For testing: We may need a CI option that builds with instrumentation
 turned on, but it would also be necessary to have tests that make sure
 that the trace events are generated.  I didn't see those tests here yet.

 For documentation, I don't feel too strongly about _where_ we put it -- I
 had been thinking that it might go in the files where we define the events
 -- but some kind of independent document would be fine too.  If we do a
 separate document, however, we should think about how to make sure that it
 stays in sync with the trace events.

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

Re: [tor-bugs] #32811 [UX/Research]: Research on information controls to extend our user personas to specific censored personas

[Tor Bug Tracker & Wiki]

#32811: Research on information controls to extend our user personas to specific
censored personas
-+-
 Reporter:  gaba |  Owner:
 |  antonela
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  UX/Research  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s30-o31a1, anti-censorship-roadmap-  |  Actual Points:
  2020Q1 |
Parent ID:  #31282   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-

Comment (by antonela):

 Tunde made 16 interviews in Cameroon, 9 in Nigeria, and 10 in Uganda. He
 is arranging the remaining ones to following up online due the
 circumstances.

 I already worked with half of Cameroon interviews and I started listening
 to the Nigerian ones. Some interviews mention Tor, some others not
 (interviews are between 1 and 1.5 hours length). I'm trying to highlight
 the ones that mention Tor so we can work deeper on those.

 My idea is to finish the analysis of the interviews with Tunde and shape
 the personas who are going to inform this effort, probably in May.

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

Re: [tor-bugs] #33681 [Core Tor/Tor]: Refactor using_default_dir_authorities() local address checks

[Tor Bug Tracker & Wiki]

#33681: Refactor using_default_dir_authorities() local address checks
---+
 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:  prop312, ipv6  |  Actual Points:
Parent ID:  #33236 | Points:  0.5
 Reviewer: |Sponsor:  Sponsor55-can
---+
Changes (by teor):

 * sponsor:  Sponsor55-must => Sponsor55-can


Comment:

 We don't have to do this refactor as part of Sponsor 55.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #33223, #33224, #33226, #33227, ...

[Tor Bug Tracker & Wiki]

Batch modification to #33223, #33224, #33226, #33227, #33229, #33230, #33231, 
#33233, #33234, #33235, #33236, #33238, #33239, #33240, #33241, #33242, #33243, 
#33244, #33245, #33246, #33247, #33249, #33252, #33253, #33262, #33263, #33264, 
#33265, #33268, #33270, #33681 by teor:


Action: reassign

Comment:
Un-assign myself from future Sponsor 55 tasks.

--
Tickets URL: 

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

Re: [tor-bugs] #33818 [Core Tor/Tor]: Add options for clients and relays to enable IPv6 extends

[Tor Bug Tracker & Wiki]

#33818: Add options for clients and relays to enable IPv6 extends
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:
Parent ID:  #33220 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-can
---+
Changes (by teor):

 * owner:  teor => (none)
 * sponsor:  Sponsor55-must => Sponsor55-can


Comment:

 I don't think these options are an essential part of Sponsor 55.

 We can test the extend code using the reachability self-test code.

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

Re: [tor-bugs] #33817 [Core Tor/Tor]: Perform Basic Relay IPv6 Extends

[Tor Bug Tracker & Wiki]

#33817: Perform Basic Relay IPv6 Extends
---+
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:  3
Parent ID:  #33220 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-must
---+
Changes (by teor):

 * keywords:  ipv6, prop311, technical-debt-partial => ipv6, prop311
 * status:  needs_revision => needs_review
 * actualpoints:   => 3


Old description:

> Currently, tor checks that extend cells have IPv4 addresses in:
> [ ] some functions in circuitbuild_relay.c (a new file introduced by
> #33633)
> [x] channel_get_for_extend() in channel.c
> [x] check_extend_cell() in onion.c
> [x] 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)
>
> Unlike the other changes, the connection_or_check_canonicity() change is
> a bug fix. Other code already considers IPv6 connections canonical.

New description:

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

 We want to allow IPv6 in all these places.

 And when we have an IPv4 and an IPv6 address, we want to choose between
 them at random.

--

Comment:

 This was a bit more complicated than I expected.

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

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

Re: [tor-bugs] #33919 [Core Tor/Tor]: Write unit tests for channel_matches_target_addr_for_extend()

[Tor Bug Tracker & Wiki]

#33919: Write unit tests for channel_matches_target_addr_for_extend()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop311, ipv6, technical-debt,   |  Actual Points:
  outreachy-ipv6, tests  |
Parent ID:  #33048   | Points:  0.5
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-can
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 I think this is mostly okay, except that this part makes me nervous.
 {{{
   channel_tls_t *tlschan = tor_malloc_zero(sizeof(*tlschan));
   or_connection_t *orcon = tor_malloc_zero(sizeof(*orcon));
 }}}

 It isn't creating a real channel or a real connection, but instead is
 creating a partially initialized version of each.  There's no actual
 guarantee in the rest of our code that this should work: it _happens_ to
 work, but that could change in the future.

 Maybe new_fake_channel() and free_fake_channel() would be a good choice
 for setting up  the channel-like object?

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

Re: [tor-bugs] #34055 [Applications/Tor Browser]: Use and document 'tbb-backport' in the release process

[Tor Bug Tracker & Wiki]

#34055: Use and document 'tbb-backport' in the release process
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > And, yes, we *are* using the ticket in the release process.
 s/ticket/tag
 > At the end there is no guarantee that things tagged with `tbb-backport`
 get backported.
 They should be re-tagged or cleared out of it every major stable update.
 And that should be documented and used as part of the release process.

 > Oh, and I updated
 https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking
 accordingly so that our use of `tbb-backport` is documented there.
 The hyperlink
 https://trac.torproject.org/projects/tor/query?status=!closed
 =~tbb-backport is a search query which lists `tbb-backported` too. That's
 why it cannot be used.

 Could you backport #32493 to get parity with tba?

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

Re: [tor-bugs] #15185 [Applications/Tor Browser]: Tor Browser: open URL from command line

[Tor Bug Tracker & Wiki]

#15185: Tor Browser: open URL from command line
--+
 Reporter:  ilf   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by rosh):

 as stated in #comment:2
 default "--no-remote" is set for good reason.
 it makes less footprint on the host TBB is running.

 we need to find other better way to open URL from command line under
 "--no-remote" setting.

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

Re: [tor-bugs] #33941 [Internal Services/Tor Sysadmin Team]: Nagios checks for op-??.onionperf.torproject.net

[Tor Bug Tracker & Wiki]

#33941: Nagios checks for op-??.onionperf.torproject.net
-+-
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Alright, I set up the Prometheus exporter on all three OnionPerf
 instances, firewalled except for prometheus2.torproject.org. You can find
 it at:

 {{{
 http://op-hk2.onionperf.torproject.net:9100/
 http://op-nl2.onionperf.torproject.net:9100/
 http://op-us2.onionperf.torproject.net:9100/
 }}}

 Can you include these in the dashboard, even without alerts, and tell me
 one or more links for keeping track of the basic metrics like "host up and
 reachable"?

 We just killed the AWS instance. I'll keep a closer eye on the instances
 as I would if we had alerts. If we have them next week or the week after,
 that's fine. If it takes longer I'll make new plans.

 Thank you!

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

Re: [tor-bugs] #34055 [Applications/Tor Browser]: Use and document 'tbb-backport' in the release process

[Tor Bug Tracker & Wiki]

#34055: Use and document 'tbb-backport' in the release process
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Oh, and I updated
 https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking
 accordingly so that our use of `tbb-backport` is documented 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] #34055 [Applications/Tor Browser]: Use and document 'tbb-backport' in the release process

[Tor Bug Tracker & Wiki]

#34055: Use and document 'tbb-backport' in the release process
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Replying to [comment:2 cypherpunks]:
 > #32505, #32414, #32493 are ready for Tor Browser 9.0.10.

 That does not necessarily follow. `tbb-backport` means tickets tagged with
 it could be considered for getting backported contrary to those we deem
 right from the beginning as not eligible for backport.

 However, whether they *actually* get backported depends on a number of
 reasons. We have only a small number of alpha users and as any backport
 still has a remaining risk of breaking things, this exacerbates that the
 risk. There are other factors to consider, like how close we are to the
 next major stable anyway etc.

 At the end there is no guarantee that things tagged with `tbb-backport`
 get backported. As I said above those tickets *could* be considered for a
 backport.

 And, yes, we *are* using the ticket in the release process.

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

Re: [tor-bugs] #34055 [Applications/Tor Browser]: Use and document 'tbb-backport' in the release process

[Tor Bug Tracker & Wiki]

#34055: Use and document 'tbb-backport' in the release process
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:1 cypherpunks]:
 > In ticket:32405#comment:7, it was used incorrectly.

 I removed the superfluous `tbb-backport`.

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

Re: [tor-bugs] #32405 [Applications/Tor Browser]: Crash immediately after bootstrap on Android

[Tor Bug Tracker & Wiki]

#32405: Crash immediately after bootstrap on Android
-+-
 Reporter:  sysrqb   |  Owner:  sisbell
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-crash, tbb-9.0-issues,   |  Actual Points:
  TorBrowserTeam201911R, tbb-backported  |
Parent ID:   | Points:  .25
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 tbb-crash, tbb-9.0-issues, TorBrowserTeam201911R, tbb-backport, tbb-
 backported
 => tbb-crash, tbb-9.0-issues, TorBrowserTeam201911R, tbb-backported


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

Re: [tor-bugs] #33882 [Applications/Tor Browser]: Launch torbrowsers on the same host from different users

[Tor Bug Tracker & Wiki]

#33882: Launch torbrowsers on the same host from different users
--+---
 Reporter:  rosh  |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by rosh):

 Replying to [comment:4 sysrqb]:
 Thanks for your review!

 I think the problem is 2nd user just fails when trying to start TBB, how
 they can know to try setting '''TOR_SOCKS_PORT''' and
 '''TOR_CONTROL_PORT'''?

 If applying the patch, 2nd user can seamless start TBB without any
 problem. Though it might be bit tricky in code.

 Actually the default port used, 9150 and 9190, may be occupied by other
 application. So I think this patch just fixes the common problem, not the
 special case for 2nd user on the same host.

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

Re: [tor-bugs] #33901 [Core Tor/Tor]: Allow IPv6 extend cells

[Tor Bug Tracker & Wiki]

#33901: Allow IPv6 extend cells
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  ipv6, prop311  |  Actual Points:  0.5
Parent ID:  #33817 | Points:  0.5
 Reviewer:  ahf|Sponsor:  Sponsor55-must
---+
Changes (by teor):

 * status:  needs_review => closed
 * resolution:   => fixed
 * parent:  #33220 => #33817


Comment:

 I think we should review this code along with #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] #34056 [Internal Services/Tor Sysadmin Team]: Please remove irl from gitolite LDAP group

[Tor Bug Tracker & Wiki]

#34056: Please remove irl from gitolite LDAP group
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by irl):

 #34057 for the gitolite config 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

[tor-bugs] #34057 [Internal Services/Service - git]: Please remove irl from the gitolite-admin repository

[Tor Bug Tracker & Wiki]

#34057: Please remove irl from the gitolite-admin repository
-+
 Reporter:  irl  |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 For trac.torproject.org 2020-04-29:

 Please remove irl from the gitolite-admin repository.

 I requested removal from the LDAP group in #34056
 -BEGIN PGP SIGNATURE-

 iQIzBAEBCgAdFiEE/ps4MHN0fw3t6AudF4mIfdjVvF0FAl6pLFwACgkQF4mIfdjV
 vF0a/Q/+N0QVADtlnaKPa2RDafDAwYJamofBMXq4GGq0bRit6zwfPrqp1H9XRS9j
 T4uLjGiTUa1yw2V3MJz33B2tFD+czclBOffdoSA4mHStM1RBBZ6PToi7GQbcoB1h
 U/xZJ1ik7oKR1/GB0PbltO2XcQyKGsZNoC6NhTazrLotR6L+zrc7UNCtKTNiUpL7
 U2a+0Rowzw+yI/pF53VQ9zA81I8TjqXjOK375P7dx9vaqnMb20hiQ/d+Rj7yOJ1e
 qwkTsOAdX0ztRAPOm40s5AyMTMSd26Emx7InyoaII7wXxXsGnxQ+1UTUzuQwiEur
 l9fLdAEta8THUye00F27n/FzvL9+w7T50FmcVGO88d785z2heOv4fpLRAADJXSj/
 hMtOYXNj01VYBSmBTzgmc09rJ2ZEFgdvxJgNLs/zJ4ka2XwHoq0GWlp2nQKN5dyM
 h/+VmDvarCVFVQY5kOtWtdxvzW8xmOh4Ut0/JG8ih4TeuqILnPEaUkeoUKnQZAs0
 DLjJOfc4PkP1+v0LSbPsQYiFQTwLwaN5cRmjfey6j8VABe3XgiN3sqxaIZxEca29
 cRBLXMgmji1ETU29wGU/LU50QhcdOK5HJz9jSc7qJwuu6y/2PSHOwOJs8HdFovzY
 UxXVDxYbTi0c8FpzsJNWyD/P9b6Jw1IhLa2Ru1Yxg7fMofXoCrQ=
 =5pBK
 -END PGP SIGNATURE-
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34056 [Internal Services/Tor Sysadmin Team]: Please remove irl from gitolite LDAP group

[Tor Bug Tracker & Wiki]

#34056: Please remove irl from gitolite LDAP group
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 For trac.torproject.org 2020-04-29:

 Please remove irl from the gitolite LDAP group.

 I will file another ticket to remove myself from the
 gitolite-admin group in the gitolite configuration.

 -BEGIN PGP SIGNATURE-

 iQIzBAEBCgAdFiEE/ps4MHN0fw3t6AudF4mIfdjVvF0FAl6pK+UACgkQF4mIfdjV
 vF28lQ//fQnd2uDUtop9qMbDuvrapHYeDj8SWhHUEpO7VesU1Mtya88waxvQ1z98
 NXjVRlcGoxB/+d296NNpiTFilO1ziC1+Ib22W0AVL8Ra8Q4EhYCpU8ck+JqXURTF
 C3e94fiI7nq/Qj6b3tmVGTjOHGoT6vwP0Bg2T7WYcHL0Zt2+viASWaBcA0bev8fq
 SqWGBfKb7q3SiCE/CCMyNsygXM/sKjmKm+r8/HFHL1bOTP1hPgOA9IyMtHtxsmt4
 F79hyFZ7/PfkBfD5Bfk0RWxUDLoGeqoMQNXlIbWjYDyxgGiQXniWhQTWZJkOngpT
 +tAWRyjK9V127h7SNttH3I0FH5jagWj+FMT92UW4nznwm8GrNDnX3DXxxE33XVNM
 eYmyenXxqMSE/VbyHoghEDe5U7fUF8/hq0EocVJc/mLDKU2rf7sSrgOvCjDjVPHU
 2tQOduWcEyk3uwSC8R9vJOsrMBFoy8EW4ykV8VGsHwwzpzwA47ea3K8H4CQDJNth
 n9FfZxIQgzwscNNBcGam7RzKwW+Ug5v/cViHGV+3U8+JBQEsxO6u0xDvUg65TbTf
 BZKMmkP7cSVc6gyZj8EEV3GPK6e6Hnkyjubp8WvT/sB08pfx3+sJ4E5BvwkZAUTL
 kIdDN6ulvgqqWVa0VcrSMaDvfjmxmSFL4iGdlw66E1DjyW37tp8=
 =9EI7
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #34055 [Applications/Tor Browser]: Use and document 'tbb-backport' in the release process

[Tor Bug Tracker & Wiki]

#34055: Use and document 'tbb-backport' in the release process
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 #32505, #32414, #32493 are ready for Tor Browser 9.0.10.

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

Re: [tor-bugs] #34055 [Applications/Tor Browser]: Use and document 'tbb-backport' in the release process

[Tor Bug Tracker & Wiki]

#34055: Use and document 'tbb-backport' in the release process
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 In ticket:32405#comment:7, it was used incorrectly.

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