[tor-bugs] #33336 [Circumvention/Snowflake]: Deploy a Turbo Tunnel–aware Snowflake bridge

[Tor Bug Tracker & Wiki]

#6: Deploy a Turbo Tunnel–aware Snowflake bridge
-+-
 Reporter:  dcf  |  Owner:  dcf
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:  turbotunnel
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We now have a
 [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel
 turbotunnel branch] of Snowflake that uses an inner transport protocol to
 migrate session across multiple proxies.
  * https://lists.torproject.org/pipermail/anti-censorship-
 team/2020-February/59.html
 And some first-draft Tor Browser builds that can use it:
  * https://lists.torproject.org/pipermail/anti-censorship-
 team/2020-February/69.html

 I want to deploy a bridge that supports Turbo Tunnel, then make Tor
 Browser builds and invite testers to test them.

 There's the question of whether to run the Turbo Tunnel code on the
 existing public bridge, or to set up a second bridge reserved for the
 Turbo Tunnel experiment. I propose to run the Turbo Tunnel code on the
 existing public bridge (i.e., snowflake.torproject.net). This is because
 (1) the Turbo Tunnel server is [https://lists.torproject.org/pipermail
 /anti-censorship-team/2020-February/62.html backward-compatible] with
 non–Turbo Tunnel clients, and (2) we would need to somehow provide proxy
 capacity for the second bridge, which our current proxy code cannot easily
 handle. Running a separate bridge would have the advantage, though, that
 because we would have to run our own special proxy-go instances to support
 it, we could closely control the proxy environment; but part of my goal in
 an experimental deployment is to see how the Turbo Tunnel code fares with
 the organic proxies we have now.

 I've have versions of the code using two different session/reliability
 protocol libraries: kcp-go and quic-go. Other than to note that two two
 libraries are [https://github.com/net4people/bbs/issues/14 basically
 equivalent in features], I haven't done much to compare them as to
 performance. kcp-go is more mature and stable, while quic-go
 [https://lists.torproject.org/pipermail/anti-censorship-
 team/2020-February/69.html add fewer dependencies to the Tor Browser
 build].

 We could make use of this opportunity to compare the two options. We set
 up a triple-mode bridge: supporting legacy, KCP, and QUIC clients. We make
 two Tor Browser builds, one with KCP and one with QUIC, and invite testing
 of both. Based on the results of user testing, we decide which we like
 better, and finally deploy only that option (and the backward-compatible
 mode). The only thing is, giving people two options to test is more
 confusing than giving them one.

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

Re: [tor-bugs] #33232 [Core Tor/Chutney]: Test IPv4 Reachability using Chutney

[Tor Bug Tracker & Wiki]

#33232: Test IPv4 Reachability using Chutney
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:
Parent ID:  #33050| Points:  2
 Reviewer:|Sponsor:  Sponsor55-must
--+

Comment (by teor):

 And it might be nice to print a list of the networks that tor is running,
 otherwise it looks like make has just hung.

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

Re: [tor-bugs] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more

[Tor Bug Tracker & Wiki]

#32794: improve OOS (out-of-sockets) handler victim selection and more
--+
 Reporter:  starlight |  Owner:  starlight
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Normal| Resolution:
 Keywords:  security  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by teor):

 Replying to [comment:22 starlight]:
 > Replying to [comment:19 teor]:
 > > It's also worth thinking about onion services and single onion
 services here. A busy onion service may look similar to a bridge, from the
 perspective of the upstream hop: both open lots of circuits.
 >
 > Will appreciate some big picture help on how to figure bridges and
 single onions services, can drill into the details on my own if I have a
 general picture.

 Bridges and onion services try to look like clients, for anonymity
 reasons. If you find a reliable distinguisher, we'll try to fix it,
 because it's a security issue:

 Replying to [comment:17 nickm]:
 > 2. Checking whether a connection's identity_digest is zero will not
 always do what we want.  First, bridges do not set their identity digest,
 even though a bridge may have circuits from multiple users.

 However, busy bridges and onion services should only have one connection
 to your relay. So they shouldn't be taking up very many sockets at all.

 I think it's ok to have a bucket that's [client-OR (including onion
 services, bridges), exit, dir, OR-OR low consensus weight]. We just need
 to document where the onion services and bridges go, so people don't
 assume they're protected (like [OR-OR good consensus weight]).

 Replying to [comment:22 starlight]:
 > Replying to [comment:19 teor]:
 > > Also, bridges and onion services can experience a socket DoS, too. We
 should think about how this algorithm might work for them, even if we
 don't activate it right now.

 Bridges can use two buckets: [bridge-OR outbound] and [OR-bridge inbound,
 clients, onion services]. Bridges don't support exiting or DirPorts. OR-
 bridge inbound connections are reachability circuits, or a DoS via another
 relay. So they are not important.

 Onion services shouldn't have socket issues, because they use guards.

 Single onion services could also use two buckets: [long-term intro,
 directory fetches, HSDir posts] and [rendezvous]. Rendezvous connections
 are a big DoS risk. Keeping the long-term intro connections, directory
 fetches, and HSDir posts is important to keep the service online.

 You don't have to make these changes, but the code should be designed so
 it's easy to change the way we filter connections. (You don't have to do a
 redesign, either - we can do that if we decided to merge.)

 > > We may want to assign a lower probability to sockets that we have
 recently opened to fetch directory documents, and connections on which we
 are currently fetching directory documents. (Attackers can occupy these
 sockets using a slowloris attack, so we should still be prepared to close
 them, if we have a lot of them open.)
 >
 > something like a time-decaying rate as a negative priority factor, with
 a countervailing longer-horizon-and-higher-consumption positive priority
 factor?

 Directory fetches will either be OR-OR, or be an outbound directory fetch.

 So we could do:

 [OR-OR good consensus weight, outbound directory fetches], and [client-OR
 (including onion services, bridges), exit, inbound DirPort, OR-OR low
 consensus weight].

 > > Remember, relays can use remote DirPorts and ORPorts for directory
 fetches, the code should handle both.
 >
 > Again, a few big picture hints on how to figure will help.

 I think dir_connection_t.dirconn_direct is pretty much what you want here:

 
https://github.com/torproject/tor/blob/master/src/feature/dircommon/dir_connection_st.h#L31

 Again, you don't have to make that change, be we should make it before we
 merge.

 Replying to [comment:23 starlight]:
 > Replying to [comment:21 teor]:
 > > Is there an overview of this design somewhere?
 >
 > above in comment:6
 >
 > > It sounds like this change needs a proposal, or a good description of
 the algorithm used for choosing sockets.
 >
 > I'm a write code that works, then write the RFC kind -- similar to the
 folks who created the Internet (and Tor).

 Fair enough, but tor does have a proposals process now :-)

 You don't have to write the proposal, or the documentation. But someone
 should at least summarise the design before we merge.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs

Re: [tor-bugs] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more

[Tor Bug Tracker & Wiki]

#32794: improve OOS (out-of-sockets) handler victim selection and more
--+
 Reporter:  starlight |  Owner:  starlight
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Normal| Resolution:
 Keywords:  security  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by starlight):

 A bit of context:

 I wrote this as quick mitigation to an issue, and it works (very well) in
 combination with some other mitigations.  I've thought about it and do not
 necessarily see it as particularly great, just way way better then what it
 replaces and I don't advocate activating OOS by default.  The supporting
 changes to permit dynamic configuration of limits are nice.

 I have a bunch of much better and more important ideas I want to pursue
 and don't want to spend a whole lot more effort on this one.  Please keep
 this in mind.  I'm willing to improve it marginally, but if it turns into
 a time sink you've lost me.

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

Re: [tor-bugs] #32978 [Metrics]: Find a working alternative to using MaxMind's GeoLite2 databases

[Tor Bug Tracker & Wiki]

#32978: Find a working alternative to using MaxMind's GeoLite2 databases
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by computer_freak):

 Fingerprint: 951307BA

 The new one is more correct.

 The old one i think is incomplete because its at an OVH reseller.
 The new one at least got the location correct.

 
 Fingerprint: F51A927E

 Answer from my hosting company:
 **PINDC-AS should be the correct one, AS34665 is the newer ASN.**

 So it looks the new database is more accurate here 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

[tor-bugs] #33335 [Metrics/Relay Search]: Make it possible to select every existing flag in "Advanced Search"

[Tor Bug Tracker & Wiki]

#5: Make it possible to select every existing flag in "Advanced Search"
+--
 Reporter:  computer_freak  |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Metrics/Relay Search
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 Currently the dropdown-list in "Advanced Search" only provide a limited
 amount of flags to search for.

 For example missing are:
 - BadExit
 - HSDir
 - StaleDesc
 - V2Dir
 - Valid

 They can be searched in the "Simple Search" but are not in the dropdown-
 list of "Aggregated Search".

 Additionally it might be nice to have the option to search for the
 "Additional Flags" as well.
 So far i cant find any way to do this.

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

Re: [tor-bugs] #33214 [Core Tor/Tor]: ConnDirectionStatistics is off by default, but most relays report it

[Tor Bug Tracker & Wiki]

#33214: ConnDirectionStatistics is off by default, but most relays report it
--+
 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:  not a bug
 Keywords:|  Actual Points:
Parent ID:  #33052| Points:  1
 Reviewer:|Sponsor:  Sponsor55-can
--+
Changes (by karsten):

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


Comment:

 False alarm!

 I did mean conn-bi-direct lines, but I must have looked at the wrong `grep
 | wc -l` result when giving the 79,709 number. I was certain that the
 number was correct, but turns out I was wrong.

 I just ran another check for descriptors published in 2020 to be sure it
 was not a temporary thing when I looked a few days ago. Here are the
 stats-end times for conn-bi-direct lines contained in extra-info
 descriptors from 2020:

 {{{
 110 2019-12-31
 173 2020-01-01
 166 2020-01-02
 172 2020-01-03
 173 2020-01-04
 171 2020-01-05
 159 2020-01-06
 155 2020-01-07
 147 2020-01-08
 154 2020-01-09
 167 2020-01-10
 143 2020-01-11
 155 2020-01-12
 155 2020-01-13
 151 2020-01-14
 161 2020-01-15
 164 2020-01-16
 155 2020-01-17
 156 2020-01-18
 160 2020-01-19
 146 2020-01-20
 157 2020-01-21
 157 2020-01-22
 159 2020-01-23
 149 2020-01-24
 161 2020-01-25
 146 2020-01-26
 154 2020-01-27
 178 2020-01-28
 158 2020-01-29
 166 2020-01-30
 160 2020-01-31
 153 2020-02-01
 169 2020-02-02
 173 2020-02-03
 168 2020-02-04
 166 2020-02-05
 158 2020-02-06
 155 2020-02-07
 159 2020-02-08
 171 2020-02-09
 150 2020-02-10
 165 2020-02-11
 124 2020-02-12
   4 2020-02-13
 }}}

 All is good, the code does what it's supposed to do! I'm really sorry for
 the noise and for causing unnecessary bug hunting. I'm closing this ticket
 now, pretending it was never opened... Thanks, everyone!

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

Re: [tor-bugs] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more

[Tor Bug Tracker & Wiki]

#32794: improve OOS (out-of-sockets) handler victim selection and more
--+
 Reporter:  starlight |  Owner:  starlight
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Normal| Resolution:
 Keywords:  security  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by starlight):

 Replying to [comment:21 teor]:
 > Is there an overview of this design somewhere?

 above in comment:6

 > It sounds like this change needs a proposal, or a good description of
 the algorithm used for choosing sockets.

 I'm a write code that works, then write the RFC kind -- similar to the
 folks who created the Internet (and Tor).

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

Re: [tor-bugs] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more

[Tor Bug Tracker & Wiki]

#32794: improve OOS (out-of-sockets) handler victim selection and more
--+
 Reporter:  starlight |  Owner:  starlight
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Normal| Resolution:
 Keywords:  security  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by starlight):

 Replying to [comment:19 teor]:
 > It's also worth thinking about onion services and single onion services
 here. A busy onion service may look similar to a bridge, from the
 perspective of the upstream hop: both open lots of circuits.

 Will appreciate some big picture help on how to figure bridges and single
 onions services, can drill into the details on my own if I have a general
 picture.

 >
 > Also, bridges and onion services can experience a socket DoS, too. We
 should think about how this algorithm might work for them, even if we
 don't activate it right now.

 ok


 > I think randomising the sockets we close is the hardest algorithm to
 exploit, because the attacker can't know which sockets were going to close
 next.

 sure, agree next comment above

 > We may want to assign a lower probability to sockets that we have
 recently opened to fetch directory documents, and connections on which we
 are currently fetching directory documents. (Attackers can occupy these
 sockets using a slowloris attack, so we should still be prepared to close
 them, if we have a lot of them open.)

 something like a time-decaying rate as a negative priority factor, with a
 countervailing longer-horizon-and-higher-consumption positive priority
 factor?

 > We should also assign a threshold value, so we keep a few directory
 sockets. (150 seems like a good threshold for relays, because they do
 approximately 7000 relays / 96 descriptors per request * 2 requests for
 descriptors, when they don't have any cached descriptors.)

 Have some hard data that suggest this may be unnecessary, can share
 privately.

 > Remember, relays can use remote DirPorts and ORPorts for directory
 fetches, the code should handle both.

 Again, a few big picture hints on how to figure will help.

 > We should also try to think of any other kinds of essential sockets,
 that we don't want to close.

 In the current implementation, only OR, DIR and EXIT connection types are
 considered--all other types are exempt.

 Please take a fifteen minutes to read the one function pick_oos_victims().

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

Re: [tor-bugs] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more

[Tor Bug Tracker & Wiki]

#32794: improve OOS (out-of-sockets) handler victim selection and more
--+
 Reporter:  starlight |  Owner:  starlight
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Normal| Resolution:
 Keywords:  security  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by teor):

 Is there an overview of this design somewhere?

 It sounds like this change needs a proposal, or a good description of the
 algorithm used for choosing sockets.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33334 [Core Tor/Tor]: Add a mixed+hs-v23-ipv6 network to tor's test-network

[Tor Bug Tracker & Wiki]

#4: Add a mixed+hs-v23-ipv6 network to tor's test-network
+
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:  ipv6, prop311
Actual Points:  |  Parent ID:  #33232
   Points:  0.2 |   Reviewer:
  Sponsor:  Sponsor55-must  |
+
 We want to add the new mixed+hs-v23-ipv6 chutney network from #3 to
 tor's makefile tests:
 * test-network-all
 * test-network-ipv6

 We'll need some minor refactoring, so that we can test for "ipv6" and
 "mixed", before using this network.

 I think the resulting code will be simpler.

 We can pass the following network lists to the test-network-run target:
 * unconditional (ipv4 and not mixed)
 * ipv6
 * mixed
 * mixed_ipv6

 Then we can:
 * test for ipv6 and mixed in separate tests,
 * set flags for mixed and ipv6, and
 * skip or use the right network lists.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33333 [Core Tor/Chutney]: Add a mixed+hs-v23-ipv6 network to chutney

[Tor Bug Tracker & Wiki]

#3: Add a mixed+hs-v23-ipv6 network to chutney
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:  ipv6, prop311
Actual Points:|  Parent ID:  #33232
   Points:  0.1   |   Reviewer:
  Sponsor:  Sponsor55-must|
--+
 We want to test our new IPv6 code in mixed networks, so let's add a
 `mixed+hs-v23-ipv6` network to chutney.

 It should be pretty much a copy-paste from `mixed+hs-v23` and
 `hs-v23-ipv6-md`.

 (There's no need for a non-md variant, all supported tor versions can use
 microdescriptors for IPv6 onion services.)

 Proposed design:
 * 2 dual-stack authorities,
 * 2 IPv4-only relays,
 * 2 dual-stack relays
 * 2 IPv6-only v2 onion services
 * 2 IPv6-only v3 onion services
 * 2 IPv6-only clients
 For each kind of node, one should be a new version, and one should be an
 old version.

 Other networks test IPv4-only authorities and clients, so we don't need
 them. (But we want to test IPv4 and dual-stack relays in the same
 network.)

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

Re: [tor-bugs] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more

[Tor Bug Tracker & Wiki]

#32794: improve OOS (out-of-sockets) handler victim selection and more
--+
 Reporter:  starlight |  Owner:  starlight
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Normal| Resolution:
 Keywords:  security  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by starlight):

 Replying to [comment:17 nickm]:
 > 1. If we have a DirPort open, the attacker can open connections to our
 DirPort: so we should also consider DirPort connections that have sockets
 set.(The fix for this one is easy: just check Directory connections
 too.)

 hi!  This is implemented. . .can add more comments to pick_oos_victims()
 if desired.

 > 2. Checking whether a connection's identity_digest is zero will not
 always do what we want.  First, bridges do not set their identity digest,
 even though a bridge may have circuits from multiple users.

 ok, how to tell if it's a bridge?

 >Second, any client can pretend to be a relay and provide authentication
 when it connects to us, thereby setting an identity digest.  (This one is
 harder to fix: we could look for relays that are in the consensus, but a
 relay that is not in the consensus might just be a new one that we don't
 know about yet.  I don't know a supported way to detect bridges -- there
 isn't supposed to be one, really.  We could look at the number of
 circuits, perhaps?)

 but can "any client" set the digest ''and'' be in the consensus with a
 stable flag a cbw 500 or higher?  Perhaps I should add some more comments.

 > 3. The attacker is not required to flood us with connections: they can
 send a trickle instead.  Instead of opening a whole bunch of connections
 at once, the attacker can open a new connection every 5 minutes. This will
 still eat up all of our sockets over time, but when we go to close the
 newest ones, the attacker will still have a bunch of our capacity.  (I do
 not know the right fix for this. We could randomize the algorithm, I
 guess?)

 Adding randomness while retaining some degree of time priority in band A,
 age*cbw in band B makes sense to me.

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

Re: [tor-bugs] #33232 [Core Tor/Chutney]: Test IPv4 Reachability using Chutney

[Tor Bug Tracker & Wiki]

#33232: Test IPv4 Reachability using Chutney
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:
Parent ID:  #33050| Points:  2
 Reviewer:|Sponsor:  Sponsor55-must
--+
Changes (by teor):

 * keywords:  ipv6, prop311? => ipv6, prop311


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

Re: [tor-bugs] #33232 [Core Tor/Chutney]: Test IPv4 Reachability using Chutney

[Tor Bug Tracker & Wiki]

#33232: Test IPv4 Reachability using Chutney
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311?|  Actual Points:
Parent ID:  #33050| Points:  2
 Reviewer:|Sponsor:  Sponsor55-must
--+

Comment (by teor):

 We should also test reachability in mixed-version networks, and update the
 mixed-versions network to mixed+hs-v23.

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

Re: [tor-bugs] #33285 [Core Tor/Tor]: Make sure relay protocol lists are sorted

[Tor Bug Tracker & Wiki]

#33285: Make sure relay protocol lists are sorted
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, technical-debt, no-   |  Actual Points:  0.4
  backport   |
Parent ID:  #33048   | Points:  0.3
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-must
-+-
Changes (by teor):

 * status:  needs_revision => merge_ready
 * actualpoints:  0.3 => 0.4


Comment:

 Updated the comments as requested.

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

Re: [tor-bugs] #23225 [Applications/GetTor]: GetTor should ignore quoted keywords in email replies that quote the help message

[Tor Bug Tracker & Wiki]

#23225: GetTor should ignore quoted keywords in email replies that quote the 
help
message
+--
 Reporter:  catalyst|  Owner:  cohosh
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/GetTor |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1  |  Actual Points:
Parent ID:  #9036   | Points:  1
 Reviewer:  phw |Sponsor:
+--

Comment (by teor):

 Some popular email clients quote messages by top-posting, then including
 the original message after a header. (For example, Microsoft Outlook.)

 This behaviour might also affect the BrudgeDB changes in #17626.

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

Re: [tor-bugs] #30941 [Circumvention/BridgeDB]: Need better instructions for requesting bridges via email

[Tor Bug Tracker & Wiki]

#30941: Need better instructions for requesting bridges via email
-+-
 Reporter:  pili |  Owner:  sysrqb
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, s30-o22a2, anti-|  Actual Points:
  censorship-roadmap-2020Q1  |
Parent ID:  #31279   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor30
-+-

Comment (by teor):

 As far as the text itself goes, the following words are ambiguous:
 * vanilla
 * several
 * plain-ol'-vanilla
 * cool

 We should replace them with simpler English words, to help people who
 don't use our dialect of English.

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

Re: [tor-bugs] #30946 [Circumvention/BridgeDB]: Port BridgeDB to Python 3

[Tor Bug Tracker & Wiki]

#30946: Port BridgeDB to Python 3
+--
 Reporter:  phw |  Owner:  phw
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  python  |  Actual Points:
Parent ID:  | Points:  10
 Reviewer:  |Sponsor:
+--

Comment (by phw):

 Earlier today, I deployed my
 [https://github.com/NullHypothesis/bridgedb/tree/fix/30946 fix/30946]
 branch for BridgeDB and my [https://gitweb.torproject.org/user/phw
 /bridgedb-admin.git/commit/?h=fix/30946 fix/30946] branch for bridgedb-
 admin on polyanthum. I found a handful more string-related issues in
 moat's server code, which are now fixed. I was subsequently able to get
 bridges over HTTPS, moat, and email. Let's keep the branch running and see
 if any other issues emerge.

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

Re: [tor-bugs] #30941 [Circumvention/BridgeDB]: Need better instructions for requesting bridges via email

[Tor Bug Tracker & Wiki]

#30941: Need better instructions for requesting bridges via email
-+-
 Reporter:  pili |  Owner:  sysrqb
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, s30-o22a2, anti-|  Actual Points:
  censorship-roadmap-2020Q1  |
Parent ID:  #31279   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor30
-+-

Comment (by teor):

 > I suggest that BridgeDB should respond with obfs4 bridges even if the
 email request is invalid

 Careful with responding to invalid input: it can enable some kinds of
 attacks.

 I can't think of any attacks that are easier than "just send another,
 correctly-formatted email". But there can sometimes be risks with email
 forwarding, or mailing lists.

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

Re: [tor-bugs] #33195 [Core Tor/Tor]: Require IPv6 tests in Travis CI

[Tor Bug Tracker & Wiki]

#33195: Require IPv6 tests in Travis CI
-+-
 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:  consider-backport-immediately, tor-  |  Actual Points:  0.7
  ci, chutney, ipv6  |
Parent ID:  #33050   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-must
-+-

Comment (by teor):

 I just compared master and this PR:
 * https://travis-ci.org/torproject/tor/builds/650218289
 * https://travis-ci.org/torproject/tor/builds/650232465

 Both finish in about 18 minutes, the IPv6-only tests take 12 minutes on
 macOS.

 I think that's a win, because we:
 * added a slow chutney job (25-45 minutes), but made it faster (13
 minutes), and
 * deleted a redundant distcheck job (8 minutes),
 but kept the same CI wall clock run time.

 (The extra 5 minutes for the chutney job is hidden by the parallelism.)

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

Re: [tor-bugs] #33195 [Core Tor/Tor]: Require IPv6 tests in Travis CI

[Tor Bug Tracker & Wiki]

#33195: Require IPv6 tests in Travis CI
-+-
 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:  consider-backport-immediately, tor-  |  Actual Points:  0.7
  ci, chutney, ipv6  |
Parent ID:  #33050   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-must
-+-
Changes (by teor):

 * actualpoints:  0.6 => 0.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] #33195 [Core Tor/Tor]: Require IPv6 tests in Travis CI

[Tor Bug Tracker & Wiki]

#33195: Require IPv6 tests in Travis CI
-+-
 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:  consider-backport-immediately, tor-  |  Actual Points:  0.6
  ci, chutney, ipv6  |
Parent ID:  #33050   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-must
-+-
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 Thanks, I've quoted those variables, improved make's output, and improved
 the job display on Travis.

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

Re: [tor-bugs] #33201 [Core Tor/Tor]: Tor relays ignore some local bytes in their statistics

[Tor Bug Tracker & Wiki]

#33201: Tor relays ignore some local bytes in their statistics
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-stats |  Actual Points:  0.1
Parent ID:  #33052| Points:  0.1
 Reviewer:|Sponsor:  Sponsor55-must
--+
Changes (by teor):

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


Comment:

 These edge cases are pretty rare: relay operators and client users have to
 specifically configure tor to use internal addresses. (Or allow routing to
 tor from a private network.)

 For statistics and accounting, we really want to measure "public bytes".
 That is, bytes that the relay sent to other relays or clients.

 We don't want to measure someone's script that connects to their DirPort
 over localhost :-)

 I've modified the comment to explain the two different cases (internal
 traffic and linked connections), and pushed it as a comment-only change.

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

Re: [tor-bugs] #33214 [Core Tor/Tor]: ConnDirectionStatistics is off by default, but most relays report it

[Tor Bug Tracker & Wiki]

#33214: ConnDirectionStatistics is off by default, but most relays report it
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #33052| Points:  1
 Reviewer:|Sponsor:  Sponsor55-can
--+

Comment (by teor):

 I'm talking about conn-bi-direct, but I also mention read-history and
 write-history in the proposal.

 read-history and write-history are on by default, and they can only be
 turned off by turning off extra-info descriptors.

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

Re: [tor-bugs] #33291 [Core Tor/Tor]: Making the tor library size smaller

[Tor Bug Tracker & Wiki]

#33291: Making the tor library size smaller
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-size  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 We could also set tor's CacheDir to an ephemeral location, to reduce the
 disk usage.

 getCacheDir() is the relevant android function:
 https://developer.android.com/training/data-storage/app-specific#internal-
 create-cache

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

Re: [tor-bugs] #33291 [Core Tor/Tor]: Making the tor library size smaller

[Tor Bug Tracker & Wiki]

#33291: Making the tor library size smaller
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-size  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [ticket:33291 gaba]:
 > {{{
 > Now, distribution size is thing for sure, the second is amount of space
 on disk when
 > it is unpacked and running. Users of inexpensive phones  with limited
 storage will often
 > scroll through installed apps and look at actual storage size being
 used, and uninstall
 > apps based on that. This means we should be concerned with both
 distribution size an
 > runtime total storage use.
 > }}}

 Tor also downloads directory documents at runtime. Last time I checked,
 the extra storage was 5-10MB.

 Here are some things we could do to reduce that size:
 * store directory documents compressed, and uncompress them when we want
 to parse them
   * this change uses more CPU, but less disk
   * our directory mmap() changes reduced RAM usage, they may make
 compressed directory documents a bit harder. Does android use Tor's
 mmap()?

 >
 > '''Possible routes'''
 >
 >  1. making different parts of tor more optional/modular (like relay
 mode, dirauth mode) . Did we try this before? Is this possible?

 Yes, we created a relay module as part of Sponsor 31, and did
 more work on the existing dirauth module.

 But there's still a lot of relay-only code that we could move into
 the relay module.

 And there is a lot more lower-level code that clients never use.
 We could put it in the relay or dirauth modules, or make more
 modules as needed.

 I'll also do a small amount of relay module work as part of
 Sponsor 55, when adding new features, or modifying existing
 code.

 I suggest that other sponsored work adopts a similar policy.

 We can also continue to move config and control code into the
 relay module, as a separate project.

 And we should continue to delete old, unused code, particularly
 code for obsolete options. There's a large amount of IPv6
 DirPort code in tor that we could delete right now.

 >  2. Is there a TLS stack you can link on android? Only in Java

 Does Orbot / Tor Browser for Android use NSS?
 If so, we can use NSS in tor, rather than OpenSSL.

 Do we need to migrate some PTs off OpenSSL as well?

 >  4. A small java implementation of core onion routing. Would
 applications be able to run it?
 >
 >  * java ones, easily
 >  * other ones with some (considerable?) effort. JNI makes it possible,
 but not necessarily so easy.

 Any re-implementation of tor will probably be
 distinguishable on the network. That's ok, as long as
 enough users are running it.

 But a re-implementation will also come with its own
 bugs, privacy issues, and security issues. And its
 own costs for testing and release management. We
 should think about whether we want to maintain
 two parallel implementations, because that's a huge
 cost.

 As an alternative, we could rewrite tor's client and
 common code in Rust. We could use this Rust code
 in tor on relays, desktops, and mobile.

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

Re: [tor-bugs] #33214 [Core Tor/Tor]: ConnDirectionStatistics is off by default, but most relays report it

[Tor Bug Tracker & Wiki]

#33214: ConnDirectionStatistics is off by default, but most relays report it
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #33052| Points:  1
 Reviewer:|Sponsor:  Sponsor55-can
--+

Comment (by arma):

 from moria1:
 {{{
 $ grep "^extra-info " cached-extrainfo*|wc -l
 15207
 }}}
 {{{
 $ grep "^conn-bi-direct " cached-extrainfo*|wc -l
 200
 }}}

 So yeah, first question is, which stats line are we talking about?

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

Re: [tor-bugs] #33214 [Core Tor/Tor]: ConnDirectionStatistics is off by default, but most relays report it

[Tor Bug Tracker & Wiki]

#33214: ConnDirectionStatistics is off by default, but most relays report it
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #33052| Points:  1
 Reviewer:|Sponsor:  Sponsor55-can
--+
Changes (by teor):

 * cc: karsten (added)


Comment:

 Karsten said in his email:
 {{{
 It looks like these statistics are turned off by default, yet they are
 reported in 79,709 out of 80,468 recent extra-info descriptors I just
 looked at.
 }}}

 Maybe he can help us work out what the 1% of relays that don't report have
 in common?

 We should also confirm that we're all talking about "conn-bi-direct".

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

Re: [tor-bugs] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more

[Tor Bug Tracker & Wiki]

#32794: improve OOS (out-of-sockets) handler victim selection and more
--+
 Reporter:  starlight |  Owner:  starlight
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Normal| Resolution:
 Keywords:  security  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by teor):

 Replying to [comment:17 nickm]:
 > So as I understand it, the proposed new algorithm is:
 >
 > > Consider only edge connections and OR connections with no identity
 set.
 > >
 > > Close the newest N such connections, until we have regained enough
 sockets.
 >
 > There are some problems here that we should think about.  They all stem
 from the fact that an attacker is not required to do the kind of DoS
 attack that we expect: the attacker will know our algorithm, so they can
 adjust their attack to work around it.
 >
 > 1. If we have a DirPort open, the attacker can open connections to our
 DirPort: so we should also consider DirPort connections that have sockets
 set.(The fix for this one is easy: just check Directory connections
 too.)
 >
 > 2. Checking whether a connection's identity_digest is zero will not
 always do what we want.  First, bridges do not set their identity digest,
 even though a bridge may have circuits from multiple users.  Second, any
 client can pretend to be a relay and provide authentication when it
 connects to us, thereby setting an identity digest.  (This one is harder
 to fix: we could look for relays that are in the consensus, but a relay
 that is not in the consensus might just be a new one that we don't know
 about yet.  I don't know a supported way to detect bridges -- there isn't
 supposed to be one, really.  We could look at the number of circuits,
 perhaps?)

 It's also worth thinking about onion services and single onion services
 here. A busy onion service may look similar to a bridge, from the
 perspective of the upstream hop: both open lots of circuits.

 Also, bridges and onion services can experience a socket DoS, too. We
 should think about how this algorithm might work for them, even if we
 don't activate it right now.

 > 3. The attacker is not required to flood us with connections: they can
 send a trickle instead.  Instead of opening a whole bunch of connections
 at once, the attacker can open a new connection every 5 minutes. This will
 still eat up all of our sockets over time, but when we go to close the
 newest ones, the attacker will still have a bunch of our capacity.  (I do
 not know the right fix for this. We could randomize the algorithm, I
 guess?)

 I think randomising the sockets we close is the hardest algorithm to
 exploit, because the attacker can't know which sockets were going to close
 next.

 We may want to assign a lower probability to sockets that we have recently
 opened to fetch directory documents, and connections on which we are
 currently fetching directory documents. (Attackers can occupy these
 sockets using a slowloris attack, so we should still be prepared to close
 them, if we have a lot of them open.)

 We should also assign a threshold value, so we keep a few directory
 sockets. (150 seems like a good threshold for relays, because they do
 approximately 7000 relays / 96 descriptors per request * 2 requests for
 descriptors, when they don't have any cached descriptors.)

 Remember, relays can use remote DirPorts and ORPorts for directory
 fetches, the code should handle both.

 We should also try to think of any other kinds of essential sockets, that
 we don't want to close.

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

Re: [tor-bugs] #32901 [Internal Services/Tor Sysadmin Team]: puppetize Nagios

[Tor Bug Tracker & Wiki]

#32901: puppetize Nagios
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  assigned
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:  #31239   | Points:  10
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 forgot to mentioned I merged the icinga module in our puppet, without any
 changes, and without including it anywhere, after an audit, so at least
 that is ready to roll.

 however, considering how different this thing is from our configuration, i
 wonder if it might not be better to just setup a new server from scratch,
 using puppet.

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

Re: [tor-bugs] #30196 [Core Tor/sbws]: Add the tor version to the sbws bandwidth file header

[Tor Bug Tracker & Wiki]

#30196: Add the tor version to the sbws bandwidth file header
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  merge_ready
 Priority:  High   |  Milestone:  sbws: 1.2.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Major  | Resolution:
 Keywords:  sbws-roadmap   |  Actual Points:
Parent ID:  #33121 | Points:  1
 Reviewer:  ahf|Sponsor:
---+---

Comment (by teor):

 Hi Juga,

 I made a few comments on the pull request.

 Replying to [comment:17 juga]:
 > Replying to [comment:16 ahf]:
 > > I think both the spec change and the sbws changes are good, but I have
 two questions:
 > >
 > > 1. What is the purpose of the `xxx`'s with 'tech-dept'? Is the goal we
 go back here and do something actionable and is that something that is
 best to have in the code rather than in tickets?
 >
 > If i'd create a ticket with a tech-debt (i guess i wrote a typo there)
 changes, i don't know if it'll ever be solved and then in the ticket would
 need to point to all the parts of the code where i detected it while
 working on something else.
 >
 > > 2. The constant renaming seems OK to me, but it seems complicated to
 maintain all these lists and how they are subsets/supersets of each other?
 >
 > agree, do you have a suggestion on how to change that without having to
 increase minor version because changing API?

 The names of internal constants like HEADER_KEYS_V1_1_ORDERED aren't part
 of the API, so they don't need a version change.

 What changes are you thinking about? How do they change the API?

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

Re: [tor-bugs] #32914 [Internal Services/Tor Sysadmin Team]: review the puppet bootstrapping process

[Tor Bug Tracker & Wiki]

#32914: review the puppet bootstrapping process
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Minor| Resolution:
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:  #31239   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 step 5 eliminated and moved to the prerequisites (for /etc/hosts) or
 puppet bootstrap (for /etc/resolv.conf). steps 7 (nevii) and 9 (do more
 puppet runs) should probably be removed on next run.

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

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

[Tor Bug Tracker & Wiki]

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

Old description:

> right now, installing machines is mostly a manual, or semi-manual
> process: we install debian, preferably with crypto, and then do stuff on
> top.
>
> some of it is done by hand, some is done in puppet.
>
> we should have a standardized install process that gives us a
> reproducable, identical install across platforms. then Puppet is what
> customizes the machine on top of that.
>
> this ticket aims at documenting what we already have and where we could
> possibly go. this is one of the question we answered "no" on in the "ops
> questionnaire" in #30881. see also the automated upgrade part in #31957.

New description:

 right now, installing machines is mostly a manual, or semi-manual process:
 we install debian, preferably with crypto, and then do stuff on top.

 some of it is done by hand, some is done in puppet.

 we should have a standardized install process that gives us a
 reproducable, identical install across platforms. then Puppet is what
 customizes the machine on top of that.

 this ticket aims at documenting what we already have and where we could
 possibly go. this is one of the question we answered "no" on in the "ops
 questionnaire" in #30881. see also the automated upgrade part in #31957.

 When we started this work, the installer had this many manual steps:

  * new-machine (common trunk): 14 steps
  * new-machine-hetzner-robot: +43 steps (57 total)
  * new-machine-hetzner-cloud: +21 steps (35 total)

--

Comment (by anarcat):

 Document how many steps we had when we drew the diagrams:

 > When we started this work, the installer had this many manual steps:
 >
 > * new-machine (common trunk): 14 steps
 > * new-machine-hetzner-robot: +43 steps (57 total)
 > * new-machine-hetzner-cloud: +21 steps (35 total)

 Now we're at:

  * new-machine (common trunk): 13 steps (3 steps possibly obsolete, 4 more
 being worked on)
  * new-machine-hetzner-robot: +25 steps left (38 total)
  * new-machine-hetzner-cloud: +21 steps (35 total, unchanged, needs to
 merge with setup-storage process)

 i.e. we have eliminated a whopping 19 steps, most of which through the
 setup-storage refactoring.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33332 [Internal Services/Tor Sysadmin Team]: move root passwords to trocla?

[Tor Bug Tracker & Wiki]

#2: move root passwords to trocla?
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin   |Version:
  Team   |   Keywords:  tpa-
 Severity:  Major|  roadmap-february
Actual Points:   |  Parent ID:  #31239
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 one manual step of our install process is to initialize the root password
 and set it in the password manager. that manual step could be completely
 skipped if we just set the root password in trocla.

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

Re: [tor-bugs] #23225 [Applications/GetTor]: GetTor should ignore quoted keywords in email replies that quote the help message

[Tor Bug Tracker & Wiki]

#23225: GetTor should ignore quoted keywords in email replies that quote the 
help
message
+--
 Reporter:  catalyst|  Owner:  cohosh
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/GetTor |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1  |  Actual Points:
Parent ID:  #9036   | Points:  1
 Reviewer:  phw |Sponsor:
+--
Changes (by phw):

 * status:  needs_review => needs_revision


Comment:

 I left a bunch of comments and questions in the PR.

 FWIW, we recently fixed a similar issue (#17626) in BridgeDB; also by
 ignoring quoted commands.

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

Re: [tor-bugs] #32914 [Internal Services/Tor Sysadmin Team]: review the puppet bootstrapping process

[Tor Bug Tracker & Wiki]

#32914: review the puppet bootstrapping process
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Minor| Resolution:
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:  #31239   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 another thing we should check is whether we can hook step 5 in the puppet
 bootstrap (because that's probably why it's there, otherwise it's
 something puppet could do itself):

 > 5. sanitize DNS configuration:
 >
 > {{{
 > grep torproject.org /etc/resolv.conf || ( echo 'domain torproject.org';
 echo 'nameserver 8.8.8.8' ) > /etc/resolv.conf
 > vi /etc/hosts # make sure the local host is there with both FQDN and
 just hostname
 > }}}

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

Re: [tor-bugs] #33191 [Applications/GetTor]: Move from twisted adbapi to sqlite3 for GetTor

[Tor Bug Tracker & Wiki]

#33191: Move from twisted adbapi to sqlite3 for GetTor
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  .5
 Reviewer:  hiro |Sponsor:
-+
Changes (by cohosh):

 * cc: meejah (added)
 * status:  needs_review => needs_revision


Comment:

 Just had a conversation with meejah in irc. It turns out that using a
 different database library in a program run by the twisted reactor can
 cause some issues. I'm going to go back to using twisted-adbapi for this
 and try some things we discussed to get the tests working.

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

Re: [tor-bugs] #32901 [Internal Services/Tor Sysadmin Team]: puppetize Nagios

[Tor Bug Tracker & Wiki]

#32901: puppetize Nagios
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  assigned
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:  #31239   | Points:  10
 Reviewer:   |Sponsor:
-+-

Old description:

> one part of our install process is to configure Nagios, by hand, in the
> git repository. I usually do this by copy-pasting some similar blob of
> config from a possibly similar machine and hope for the best.
>
> this is a manual step, and as part of the automation of the install
> process, it should be made automatic.
>
> one way this could (and probably should) be done is by making Puppet
> automatically add its nodes into Nagios. this can be done using the
> [https://github.com/Icinga/puppet-icinga2 icinga2 module], for example.
> care should be taken to do a smooth transition, keeping existing
> configurations and just adding the Puppet ones on top, for new machines.
>
> but this could (eventually) be retroactively added to all nodes, removing
> all manual configuration.
>
> checklist:
>
> 1. [ ] audit and import the module in our monorepo
> 1. [ ] enable on the nagios server, without writing any config (hopefully
> a noop)
> 1. [ ] enable a single config from puppet, as a test
> 1. [ ] add a new host check configuration
> 1. [ ] add a new service check configuration
> 1. [ ] add all *base* service checks for the new host
> 1. [ ] convert legacy config into puppet (at this stage we only have the
> old hosts as legacy config)
> 1. [ ] convert old hosts into puppet
> 1. [ ] convert old *services* into puppet
>
> It's a long way there, but getting to the state where *new* hosts are
> covered would already be a great improvement.

New description:

 one part of our install process is to configure Nagios, by hand, in the
 git repository. I usually do this by copy-pasting some similar blob of
 config from a possibly similar machine and hope for the best.

 this is a manual step, and as part of the automation of the install
 process, it should be made automatic.

 one way this could (and probably should) be done is by making Puppet
 automatically add its nodes into Nagios. this can be done using the
 [https://github.com/Icinga/puppet-icinga2 icinga2 module], for example.
 care should be taken to do a smooth transition, keeping existing
 configurations and just adding the Puppet ones on top, for new machines.

 but this could (eventually) be retroactively added to all nodes, removing
 all manual configuration.

 checklist:

 1. [x] audit and import the module in our monorepo
 1. ~~[ ] enable on the nagios server, without writing any config
 (hopefully a noop)~~ not possible, config is overwritten by module,
 instead...
 1. [ ] move the base configuration (`config/static`) from git into Puppet
 (mostly icinga.cfg and so on, because they are overwritten by the module)
 1. [ ] enable a single config from puppet, as a test
 1. [ ] add a new host check configuration
 1. [ ] add a new service check configuration
 1. [ ] add all *base* service checks for the new host (e.g. the services
 defined for the `computers` hostgroup, equivalent of pieces of `from-
 git/generated/auto-services.cfg`)
 1. ~~[ ] convert legacy config into puppet (at this stage we only have the
 old hosts as legacy config)~~ done in third step
 1. [ ] convert NRPE service definitions (`puppet:///modules/nagios/tor-
 nagios/generated/nrpe_tor.cfg`, generated from the git repo)
 1. [ ] remove NRPE config sync from nagios to Puppet (the rsync to `pauli`
 in `config/Makefile`)
 1. [ ] convert old hosts checks into puppet
 1. [ ] convert old services checks into puppet
 1. [ ] remove git hook receiver on nagios server
 (`/etc/ssh/userkeys/nagiosadm` key, which calls `/home/nagiosadm/bin/from-
 git-rw`)

 It's a long way there, but getting to the state where *new* hosts are
 covered would already be a great improvement.

--

Comment (by anarcat):

 reorder checklist: we can't have nice things as the icinga module
 immediately rewrites the icinga.cfg, at the very least. also add items to
 convert NRPE, which I have overlooked.

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

Re: [tor-bugs] #33191 [Applications/GetTor]: Move from twisted adbapi to sqlite3 for GetTor

[Tor Bug Tracker & Wiki]

#33191: Move from twisted adbapi to sqlite3 for GetTor
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  .5
 Reviewer:  hiro |Sponsor:
-+--
Changes (by cohosh):

 * status:  merge_ready => needs_review


Comment:

 Okay this patch will update the callers of the new database functions.

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

Re: [tor-bugs] #19757 [Applications/Tor Browser]: Make a menu to add onion and auth-cookie to TB

[Tor Bug Tracker & Wiki]

#19757: Make a menu to add onion and auth-cookie to TB
-+-
 Reporter:  mrphs|  Owner:  brade
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-usability, tor-hs,  |  Actual Points:  7.1
  TorBrowserTeam202002R  |
Parent ID:  #3   | Points:  8
 Reviewer:  pospeselr, acat  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by mcs):

 Replying to [comment:40 pospeselr]:
 > This looks good to me, but a few nits that don't really matter:
 >
 > https://gitweb.torproject.org/user/brade/tor-
 
browser.git/tree/browser/components/onionservices/content/authPrompt.js?id=06f115cc028e27124b48b40aaa83e988c28a9d98#n165
 > > 165   let checkboxElem = this._getCheckboxElement();
 > > 166   let isPermanent = (checkboxElem && checkboxElem.checked);
 >
 > I'd move these down within the try block before the {{{onionAuthAdd}}}
 call as it doesn't seem like {{{isPermanent}}} is used anywhere else in
 the higher scope.

 Fixed.

 > https://gitweb.torproject.org/user/brade/tor-
 
browser.git/tree/browser/components/onionservices/content/authPreferences.js?id=06f115cc028e27124b48b40aaa83e988c28a9d98#n19
 > > 19string: {
 > > 20  groupBoxID: "torOnionServiceKeys",
 > > 21  headerSelector: "#torOnionServiceKeys-header",
 > > 22  overviewSelector: "#torOnionServiceKeys-overview",
 > > 23  learnMoreSelector: "#torOnionServiceKeys-learnMore",
 > > 24  savedKeysButtonSelector: "#torOnionServiceKeys-savedKeys",
 > > 25},
 >
 > I'd call {{{string}}} something like 'selectors' or something like that
 (here and also in authUtil.jsm, savedKeysDialog.js, etc)

 OK. We split things up into various buckets: `domid`, `selector`,
 `message`, `topic`. Kathy and I think this will work well since for #19251
 we have to add more topic values, etc.

 We also made this a squash! commit so eventually it will be combined with
 the #30237 patch.

 Finally, we slipped in a minor prompt fix: the revised code accepts
 lowercase letters within base32-encoded keys (see the comment we added
 inside `browser/components/onionservices/content/authPrompt.js`).

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

Re: [tor-bugs] #33123 [Applications/GetTor]: Update GetTor's rate limiting

[Tor Bug Tracker & Wiki]

#33123: Update GetTor's rate limiting
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:  1.5
Parent ID:   | Points:  2
 Reviewer:  hiro |Sponsor:
-+
Changes (by cohosh):

 * actualpoints:   => 1.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] #33191 [Applications/GetTor]: Move from twisted adbapi to sqlite3 for GetTor

[Tor Bug Tracker & Wiki]

#33191: Move from twisted adbapi to sqlite3 for GetTor
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  .5
 Reviewer:  hiro |Sponsor:
-+-

Comment (by cohosh):

 Thanks! I just realized this needs a bit more work because the returns for
 the database functions are no longer deferreds. I've merged what I have,
 but will work on this fix before we deploy 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] #33123 [Applications/GetTor]: Update GetTor's rate limiting

[Tor Bug Tracker & Wiki]

#33123: Update GetTor's rate limiting
-+
 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:  2
 Reviewer:  hiro |Sponsor:
-+
Changes (by cohosh):

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


Comment:

 Merged in
 
https://gitweb.torproject.org/gettor.git/commit/?id=c2930fe339d0be0deceb4120e771bc4f24f28770

 and deployed as of `2020-02-13T20:10:15+`.

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

Re: [tor-bugs] #31102 [Metrics/Analysis]: Produce guidelines for safe internet measurement

[Tor Bug Tracker & Wiki]

#31102: Produce guidelines for safe internet measurement
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  7
 Reviewer:|Sponsor:
--+--
Changes (by gaba):

 * keywords:  metrics-roadmap-october =>


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

Re: [tor-bugs] #26767 [Metrics/Relay Search]: add consensus weight line/graph

[Tor Bug Tracker & Wiki]

#26767: add consensus weight line/graph
--+--
 Reporter:  nusenu|  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gaba):

 * keywords:  metrics-roadmap-2019-q3 =>


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

Re: [tor-bugs] #33316 [Core Tor/Tor]: Re-order early subsystem init order to match dependency order

[Tor Bug Tracker & Wiki]

#33316: Re-order early subsystem init order to match dependency order
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  diagnostics, practracker  |  Actual Points:  .2
Parent ID:  #31634| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review
 * actualpoints:   => .2


Comment:

 See branch `ticket33316` with PR at
 https://github.com/torproject/tor/pull/1738

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #28327, #29459, #29460, #5830, ...

[Tor Bug Tracker & Wiki]

Batch modification to #28327, #29459, #29460, #5830, #6369, #6473, #16520, 
#16659, #24422, #26767, #29425, #29465, #29507 by gaba:


Comment:
Releasing tickets from 2019 roadmap into the universe.

--
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] #28327 [Metrics]: Make sure that each service has at least two operators

[Tor Bug Tracker & Wiki]

#28327: Make sure that each service has at least two operators
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * keywords:  metrics-roadmap-2019-q2 => metrics-team-roadmap-2020Q1


Comment:

 Let's see if we can include this in Q1

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

Re: [tor-bugs] #29281 [Webpages/Research]: Add research idea for GeoIP database comparison

[Tor Bug Tracker & Wiki]

#29281: Add research idea for GeoIP database comparison
-+-
 Reporter:  notirl   |  Owner:  karsten
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Webpages/Research|Version:
 Severity:  Normal   | Resolution:
 Keywords:  research-ideas, metrics-team-|  Actual Points:
  roadmap-2020Q1 |
Parent ID:  #32978   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

 * owner:  metrics-team => karsten
 * keywords:  research-ideas, metrics-roadmap-2019-q2 => research-ideas,
 metrics-team-roadmap-2020Q1
 * parent:   => #32978


Comment:

 Karsten: maybe this some of the work you are doing right now in #32978?

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

Re: [tor-bugs] #33178 [Metrics]: Figure out specific baselines we are interested in from a network health perspective

[Tor Bug Tracker & Wiki]

#33178: Figure out specific baselines we are interested in from a network health
perspective
-+-
 Reporter:  gk   |  Owner:
 |  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health, network-health-  |  Actual Points:
  roadmap-2020Q1, metrics-team-roadmap-2020Q1|
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

 * keywords:  network-health, network-health-roadmap-2020Q1 =>
 network-health, network-health-roadmap-2020Q1, metrics-team-roadmap-
 2020Q1


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

Re: [tor-bugs] #33176 [Metrics]: Check whether all of our growth stats we want are collected and accurate

[Tor Bug Tracker & Wiki]

#33176: Check whether all of our growth stats we want are collected and accurate
-+-
 Reporter:  gk   |  Owner:
 |  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health, network-health-  |  Actual Points:
  roadmap-2020Q1, metrics-team-roadmap-2020Q1|
Parent ID:  #33178   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

 * keywords:  network-health, network-health-roadmap-2020Q1 =>
 network-health, network-health-roadmap-2020Q1, metrics-team-roadmap-
 2020Q1


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

Re: [tor-bugs] #32978 [Metrics]: Find a working alternative to using MaxMind's GeoLite2 databases

[Tor Bug Tracker & Wiki]

#32978: Find a working alternative to using MaxMind's GeoLite2 databases
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by gaba):

 We are looking into the license of the new source to be sure it will 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] #32978 [Metrics]: Find a working alternative to using MaxMind's GeoLite2 databases

[Tor Bug Tracker & Wiki]

#32978: Find a working alternative to using MaxMind's GeoLite2 databases
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * keywords:   => metrics-team-roadmap-2020Q1


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

Re: [tor-bugs] #33330 [Circumvention/Snowflake]: Use Go modules for Snowflake

[Tor Bug Tracker & Wiki]

#0: Use Go modules for Snowflake
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+

Comment (by dcf):

 This will also need a patch in tor-browser-build.git
 [https://gitweb.torproject.org/builders/tor-browser-
 build.git/commit/?id=2e468e7b9b13cec82bd8034925433a7fd394a97d like for
 obfs4] (#28310) to remove go.mod, until rbm gets Go module support
 (#28325).

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

Re: [tor-bugs] #33008 [Metrics/Relay Search]: Display a bridge's distribution bucket

[Tor Bug Tracker & Wiki]

#33008: Display a bridge's distribution bucket
-+-
 Reporter:  phw  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Relay Search |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s30-o24a1, anti-censorship-roadmap-  |  Actual Points:
  2020Q1 metrics-team-roadmap-2020Q1 |
Parent ID:  #31281   | Points:  3
 Reviewer:   |Sponsor:
 |  Sponsor30-can
-+-
Changes (by gaba):

 * keywords:  s30-o24a1, anti-censorship-roadmap-2020Q1 => s30-o24a1, anti-
 censorship-roadmap-2020Q1 metrics-team-roadmap-2020Q1


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

Re: [tor-bugs] #33314 [Internal Services/Services Admin Team]: RT spams TPA with bounces

[Tor Bug Tracker & Wiki]

#33314: RT spams TPA with bounces
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * keywords:  tpa-roadmap-february =>


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

Re: [tor-bugs] #33308 [Internal Services/Tor Sysadmin Team]: Please no longer delegate onionperf-dev.torproject.net zone to AWS

[Tor Bug Tracker & Wiki]

#33308: Please no longer delegate onionperf-dev.torproject.net zone to AWS
-+-
 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:  0.1
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * keywords:  tpa-roadmap-february =>


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

Re: [tor-bugs] #33305 [Metrics/Exit Scanner]: Determine requirements for exit scanner machine

[Tor Bug Tracker & Wiki]

#33305: Determine requirements for exit scanner machine
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Exit Scanner |Version:
 Severity:  Critical | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * keywords:   => metrics-team-roadmap-2020Q1


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

Re: [tor-bugs] #29650 [Metrics/Exit Scanner]: Rewrite exit scanner to produce exit lists according to new format

[Tor Bug Tracker & Wiki]

#29650: Rewrite exit scanner to produce exit lists according to new format
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  project   | Status:  new
 Priority:  High  |  Milestone:
Component:  Metrics/Exit Scanner  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29399| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gaba):

 * keywords:  metrics-roadmap-2019-q2 exitscanner =>


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

Re: [tor-bugs] #33308 [Internal Services/Tor Sysadmin Team]: Please no longer delegate onionperf-dev.torproject.net zone to AWS

[Tor Bug Tracker & Wiki]

#33308: Please no longer delegate onionperf-dev.torproject.net zone to AWS
-+-
 Reporter:  irl  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tpa-roadmap-february |  Actual Points:  0.1
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * keywords:   => tpa-roadmap-february
 * status:  accepted => closed
 * points:   => 0.1
 * resolution:   => fixed
 * actualpoints:   => 0.1


Comment:

 done in:

 cccfda0 Remove onionperf-dev delegation (#33308).

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

Re: [tor-bugs] #33293 [Metrics/Exit Scanner]: Write a PowerDNS backend that serves data from a Tor Exit List

[Tor Bug Tracker & Wiki]

#33293: Write a PowerDNS backend that serves data from a Tor Exit List
-+--
 Reporter:  irl  |  Owner:  irl
 Type:  task | Status:  accepted
 Priority:  Very High|  Milestone:
Component:  Metrics/Exit Scanner |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * keywords:   => metrics-team-roadmap-2020Q1


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

Re: [tor-bugs] #33308 [Internal Services/Tor Sysadmin Team]: Please no longer delegate onionperf-dev.torproject.net zone to AWS

[Tor Bug Tracker & Wiki]

#33308: Please no longer delegate onionperf-dev.torproject.net zone to AWS
-+-
 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] #33314 [Internal Services/Services Admin Team]: RT spams TPA with bounces

[Tor Bug Tracker & Wiki]

#33314: RT spams TPA with bounces
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Minor| Resolution:
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  assigned => needs_review


Old description:

> Since I fixed the root aliases everywhere, we seem to be getting spam
> mail bounced back to the tpa alias, from the root@rude email account.
>
> It seems that this mail was previously being delivered locally to the
> `nobody` mailbox, which is now a whopping 630MB:
>
> {{{
> root@rude:/var/mail# ls -al /var/mail/*
> -rw-rw 1 amavismail  5688 May  4  2016 /var/mail/amavis
> -rw-rw 1 nobodymail 660486247 Feb 12 21:46 /var/mail/nobody
> -rw-rw 1 rtmailarchive mail 28174 Sep  1  2016
> /var/mail/rtmailarchive
> }}}
>
> Since #32283 was deployed, that has stopped growing but instead we're all
> getting spammed with that junk, which isn't much of an improvement. But
> at least those problems will have to get fixed.
>
> The first problem is messages in the form:
>
> > From: r...@rt.torproject.org
> > Subject: Failed attempt to create a ticket by email, from 
> >
> >  attempted to create a ticket via email in the queue help-es;
> you
> might need to grant 'Everyone' the CreateTicket right.
>
> We got 23 such emails since the alias was fixed, and this will probably
> just keep going forever.
>
> I reported this as a bug in the upstream forum, in:
>
> https://forum.bestpractical.com/t/rt-4-4-too-noisy-with-denied-
> users/34749
>
> I also filed this as a bug in Debian:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951272
>
> and filed a patch in:
>
> https://github.com/bestpractical/rt/pull/291
>
> That latter patch is directly applied on rude right now, with:
>
> {{{
> wget -O ~anarcat/PR-291-no-err-on-deny.patch https://patch-
> diff.githubusercontent.com/raw/bestpractical/rt/pull/291.patch
> cd /usr/share/request-tracker4
> patch -p1 < ~anarcat/PR-291-no-err-on-deny.patch
> }}}
>
> just skip the `t/` chunk.
>
> I'll wait and see what feedback I get from upstream and Debian before
> deciding what to do with this in the long term. Options include:
>
>  1. blocking users at the MTA level - requires TPA operation which we'd
> like to avoid, we want to train RT admins to be autonomous
>  2. patch the bug in Debian and follow that process to get rude updated
> in the long term
>  3. hotfix the Debian package in our archive
>
> we also need to decide what to do about that 600M mail archive... i'll
> probably just delete it once i'm happy with our solution.

New description:

 Since I fixed the root aliases everywhere, we seem to be getting spam mail
 bounced back to the tpa alias, from the root@rude email account.

 It seems that this mail was previously being delivered locally to the
 `nobody` mailbox, which is now a whopping 630MB:

 {{{
 root@rude:/var/mail# ls -al /var/mail/*
 -rw-rw 1 amavismail  5688 May  4  2016 /var/mail/amavis
 -rw-rw 1 nobodymail 660486247 Feb 12 21:46 /var/mail/nobody
 -rw-rw 1 rtmailarchive mail 28174 Sep  1  2016
 /var/mail/rtmailarchive
 }}}

 Since #32283 was deployed, that has stopped growing but instead we're all
 getting spammed with that junk, which isn't much of an improvement. But at
 least those problems will have to get fixed.

 The first problem is messages in the form:

 > From: r...@rt.torproject.org
 > Subject: Failed attempt to create a ticket by email, from 
 >
 >  attempted to create a ticket via email in the queue help-es; you
 might need to grant 'Everyone' the CreateTicket right.

 We got 23 such emails since the alias was fixed, and this will probably
 just keep going forever.

 I reported this as a bug in the upstream forum, in:

 https://forum.bestpractical.com/t/rt-4-4-too-noisy-with-denied-users/34749

 I also filed this as a bug in Debian:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951272

 and filed a patch in:

 https://github.com/bestpractical/rt/pull/291

 That latter patch is directly applied on rude right now, with:

 {{{
 wget -O ~anarcat/PR-291-no-err-on-deny.patch https://patch-
 diff.githubusercontent.com/raw/bestpractical/rt/pull/291.patch
 cd /usr/share/request-tracker4
 patch -p1 < ~anarcat/PR-291-no-err-on-deny.patch
 service apache2 restart
 }}}

 jus

Re: [tor-bugs] #33260 [Metrics]: Add option to filter graphed OnionPerf results by relay fingerprint

[Tor Bug Tracker & Wiki]

#33260: Add option to filter graphed OnionPerf results by relay fingerprint
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33327   | Points:  3
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * parent:   => #33327


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

Re: [tor-bugs] #33257 [Metrics]: Add CDF-DL graph

[Tor Bug Tracker & Wiki]

#33257: Add CDF-DL graph
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33327   | Points:  3
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * parent:   => #33327


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

Re: [tor-bugs] #33258 [Metrics]: Add CSV file export of graphed data

[Tor Bug Tracker & Wiki]

#33258: Add CSV file export of graphed data
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33327   | Points:  1
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * parent:   => #33327


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

Re: [tor-bugs] #33259 [Metrics]: Store measurements in a local database to reduce plotting time

[Tor Bug Tracker & Wiki]

#33259: Store measurements in a local database to reduce plotting time
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33327   | Points:  5
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * parent:   => #33327


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

Re: [tor-bugs] #33256 [Metrics]: Update CDF-TTFB graph

[Tor Bug Tracker & Wiki]

#33256: Update CDF-TTFB graph
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33327   | Points:  2
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * parent:   => #33327


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

Re: [tor-bugs] #33255 [Metrics]: Review existing graphing code

[Tor Bug Tracker & Wiki]

#33255: Review existing graphing code
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33327   | Points:  1
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * parent:   => #33327


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

Re: [tor-bugs] #33076 [Metrics/Analysis]: Graph onionperf and consensus information from Rob's experiments

[Tor Bug Tracker & Wiki]

#33076: Graph onionperf and consensus information from Rob's experiments
-+-
 Reporter:  mikeperry|  Owner:
 |  metrics-team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Analysis |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1, sbws-   |  Actual Points:  3
  roadmap|
Parent ID:  #33327   | Points:  6
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

 * parent:  #33121 => #33327


Comment:

 Moving it to other project for tracking.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33331 [Webpages/Website]: update zcash image on sponsors page

[Tor Bug Tracker & Wiki]

#1: update zcash image on sponsors page
--+--
 Reporter:  bekeela   |  Owner:  hiro
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 On the sponsors page https://www.torproject.org/about/sponsors/ please
 update the image for zcash. (I created the zcash page yesterday, so it's
 not live yet. Here's a link to it:
 https://dip.torproject.org/bekeela/tpo/tree/master/content/about/sponsors/Zcash

 In the images folder for the website, there is a zcash logo. Could it be
 changed so that it has the grey background like the other logos on the
 sponsors 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] #33275 [Core Tor/Tor]: Tor Manual: Alphabetize Remaining Tor Manual

[Tor Bug Tracker & Wiki]

#33275: Tor Manual: Alphabetize Remaining Tor Manual
-+-
 Reporter:  swati|  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy 043-can   |
Parent ID:  #4310| Points:
 Reviewer:  catalyst, teor   |Sponsor:
-+-
Changes (by swati):

 * status:  new => needs_review
 * reviewer:   => catalyst, teor


Comment:

 Please review the PR - https://github.com/torproject/tor/pull/1737.

 Note the following:
 - Exceptions are marked with the //Out of order comment.
 - Non-Persistent Options and Client Authorization Options don't need
 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] #33069 [Core Tor/Tor]: Init sk if loaded from service blob to be on the curve

[Tor Bug Tracker & Wiki]

#33069: Init sk if loaded from service blob to be on the curve
--+
 Reporter:  saibato   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  backport? 043-should  |  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+

Comment (by saibato):

 Replying to [comment:3 nickm]:
 > I've found the email that led to this PR, and forwarded it to the
 internal network-team list.  Thanks!
 Hope that helps.
 To support tuta here my tuta mail addr saib...@tutanota.com  PGP
 0x3765D3892F295B6C pls only --armor gpg format, or plain text.

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

Re: [tor-bugs] #26068 [Metrics/Website]: better describe bridges vs. relays in the glosary

[Tor Bug Tracker & Wiki]

#26068: better describe bridges vs. relays in the glosary
-+---
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31281   | Points:
 Reviewer:   |Sponsor:  Sponsor30-can
-+---
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

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

Re: [tor-bugs] #33008 [Metrics/Relay Search]: Display a bridge's distribution bucket

[Tor Bug Tracker & Wiki]

#33008: Display a bridge's distribution bucket
-+-
 Reporter:  phw  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Relay Search |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s30-o24a1, anti-censorship-roadmap-  |  Actual Points:
  2020Q1 |
Parent ID:  #31281   | Points:  3
 Reviewer:   |Sponsor:
 |  Sponsor30-can
-+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:7 karsten]:
 > Okay, if it's just the distributor bucket/strategy that we want to
 display, the Onionoo side is relatively simple. Please review
 [https://gitweb.torproject.org/user/karsten/metrics-
 web.git/commit/?h=task-33008&id=633aa3ed1727ca986dd4f193a2d8b9f993c202a9
 commit 633aa3e in my metrics-web task-33008 branch for step 2 above] and
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-33008&id=ff2db949e57f35df8cfffe691e2caeece8fdeccc
 commit ff2db94 in my Onionoo task-33008 branch for step 3 above].

 LGTM.

 The bridge model will need to be extended in relay search, and an extra
 row on the table. If you want to have a go at that it should be an easy
 change.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33330 [Circumvention/Snowflake]: Add module for Snowflake

[Tor Bug Tracker & Wiki]

#0: Add module for Snowflake
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:  .2   |   Reviewer:
  Sponsor:   |
-+
 Snowflake CI is currently failing because we use the latest version of all
 libraries, the master branch of pion/dtls in particular is not compatable
 with its usage by other libraries.

 We should add a go.mod and go.sum to snowflake

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

Re: [tor-bugs] #33330 [Circumvention/Snowflake]: Use Go modules for Snowflake (was: Add module for Snowflake)

[Tor Bug Tracker & Wiki]

#0: Use Go modules for Snowflake
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+

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

Re: [tor-bugs] #33316 [Core Tor/Tor]: Re-order early subsystem init order to match dependency order

[Tor Bug Tracker & Wiki]

#33316: Re-order early subsystem init order to match dependency order
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  diagnostics, practracker  |  Actual Points:
Parent ID:  #31634| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I have this mostly done, but I need to figure out what I want to do about
 pubsub and the unit tests. There are a few possible solutions: I need to
 figure out which is least ugly.

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

Re: [tor-bugs] #33299 [Circumvention/BridgeDB]: Remove retired pluggable transports from BridgeDB (was: Remove retired pluggable transports)

[Tor Bug Tracker & Wiki]

#33299: Remove retired pluggable transports from BridgeDB
+---
 Reporter:  phw |  Owner:  phw
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  s30-o22a2   |  Actual Points:
Parent ID:  #31279  | Points:  0.5
 Reviewer:  cohosh  |Sponsor:  Sponsor30-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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #29425, #30303, #30612, #32725, ...

[Tor Bug Tracker & Wiki]

Batch modification to #29425, #30303, #30612, #32725, #29624, #31071 by irl:
reviewer to 

Comment:
This is not currently in need of review.

--
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] #32724 [Metrics/Cloud]: Build latest Onionperf from git sources

[Tor Bug Tracker & Wiki]

#32724: Build latest Onionperf from git sources
---+
 Reporter:  acute  |  Owner:  acute
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Metrics/Cloud  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #32725 | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

 * status:  needs_review => needs_revision
 * reviewer:  irl =>


Comment:

 The paths that things are installed to don't align between the onionperf
 role and onionperf-webserver role. We probably want things that look like:

 {{{
 /srv/onionperf.torproject.net/onionperf -> onionperf clone
 /srv/onionperf.torproject.net/onionperf/onionperf-data -> www root
 /srv/onionperf.torproject.net/tgen -> tgen clone
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33329 [Metrics/Cloud]: Set Lets Encrypt hostname dynamically using ansible facts

[Tor Bug Tracker & Wiki]

#33329: Set Lets Encrypt hostname dynamically using ansible facts
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Cloud  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 It's hardcoded in the role right now, which is not optimal.

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

Re: [tor-bugs] #33291 [Core Tor/Tor]: making the tor library size smaller

[Tor Bug Tracker & Wiki]

#33291: making the tor library size smaller
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-size  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gaba):

 * keywords:   => tor-size


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

Re: [tor-bugs] #13770 [Applications/Tor Browser]: BusyBox-style bundling of Go programs can save space

[Tor Bug Tracker & Wiki]

#13770: BusyBox-style bundling of Go programs can save space
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-size  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gaba):

 * keywords:   => tor-size


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

Re: [tor-bugs] #33291 [Core Tor/Tor]: Making the tor library size smaller (was: making the tor library size smaller)

[Tor Bug Tracker & Wiki]

#33291: Making the tor library size smaller
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-size  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

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

Re: [tor-bugs] #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_review
 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 dgoulet):

 * status:  needs_revision => needs_review


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

[tor-bugs] #33328 [Metrics/Onionperf]: O3.2 Include additional OnionPerf filters.

[Tor Bug Tracker & Wiki]

#33328: O3.2 Include additional OnionPerf filters.
---+--
 Reporter:  gaba   |  Owner:  metrics-team
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #33326
   Points: |   Reviewer:
  Sponsor: |
---+--
 We will add the ability to filter out arbitrary relays from arbitrary time
 periods of historical OnionPerf data and compare the performance metrics
 to the baseline for that period as CDF graphs.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33327 [Metrics/Onionperf]: O3.1 Develop developer-facing tooling to quickly graph baseline performance metrics.

[Tor Bug Tracker & Wiki]

#33327: O3.1 Develop developer-facing tooling to quickly graph baseline 
performance
metrics.
---+--
 Reporter:  gaba   |  Owner:  metrics-team
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #33326
   Points: |   Reviewer:
  Sponsor: |
---+--
 In order for developers to evaluate performance metrics as we make network
 improvements, we will create developer tools that allow us to produce CDFs
 from snapshots of time for these OnionPerf metrics for periods of time
 that live network experiments are running. These graphing tools will also
 work with OnionPerfs that are attached to the Tor network simulator
 Shadow,1 allowing us to compare the live network to the simulator.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33326 [Metrics/Onionperf]: Objective 3: Make improvements to the way we analyze performance metrics.

[Tor Bug Tracker & Wiki]

#33326: Objective 3: Make improvements to the way we analyze performance 
metrics.
---+--
 Reporter:  gaba   |  Owner:  metrics-team
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Under sponsor 59's project we work on a dev tool to help people to analyze
 performance metrics.

 More info:
 https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor59

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

Comment (by dgoulet):

 Ok, per discussion with nickm, moved the LTTng specific probe code into a
 `.inc` file which should fix our problems and fix the CI.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33325 [Metrics/Onionperf]: O2.3 Implement static guard node support for OnionPerf.

[Tor Bug Tracker & Wiki]

#33325: O2.3 Implement static guard node support for OnionPerf.
---+--
 Reporter:  gaba   |  Owner:  metrics-team
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #33322
   Points: |   Reviewer:
  Sponsor: |
---+--
 Tor clients generally make three-hop circuits (that is, paths that go
 through three relays). The first position in the path called the guard
 node and is always chosen as the first hop for a fixed period of time.
 Using static guard nodes help protect against a certain kind of anonymity-
 breaking attack. The long-running OnionPerf instances that are currently
 deployed do not implement this mitigation because choosing a static guard
 at setup time would heavily influence their measured performance. Instead,
 they’re configured not to choose a guard for each measurement. We want to
 be able to measure the effects of good, bad, or average guards and compare
 the results, which is not possible without the opportunity to select a
 static guard node for an OnionPerf instance. Implementing the option to
 use a static guard in future OnionPerf instances will allow us to measure
 Tor performance closer to how clients experience 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

[tor-bugs] #33324 [Metrics/Onionperf]: O2.2 Develop at least one new OnionPerf model: An OnionPerf model defines the pattern of traffic that is generated by the instances for conducting a measurement.

[Tor Bug Tracker & Wiki]

#33324: O2.2 Develop at least one new OnionPerf model: An OnionPerf model 
defines
the pattern of traffic that is generated by the instances for conducting a
measurement.
---+--
 Reporter:  gaba   |  Owner:  metrics-team
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #33322
   Points: |   Reviewer:
  Sponsor: |
---+--
 For example, a bulk download model can be used to measure time to first
 byte and time to last byte simulating the download of a large file. In
 contrast, a ping/echo service model would be used to learn the round-trip
 time from a client sending a ping to receiving a pong back from a server,
 which more closely models a real-time chat application. These models allow
 us to evaluate distinct circumstances and collect distinct metrics, all of
 which are currently unavailable with the existing OnionPerf model. We will
 evaluate new OnionPerf models that will allow us to measure different
 network workloads and deploy at least one instance of these permanently.
 Deploying a new OnionPerf model allows us to gain new insight into the Tor
 network by taking measurements that are currently unavailable.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33323 [Metrics/Onionperf]: O2.1 Add instance metadata: We need a way to distinguish our current four long-term OnionPerf measurements that are automatically published to the Metrics portal

[Tor Bug Tracker & Wiki]

#33323: O2.1 Add instance metadata: We need a way to distinguish our current 
four
long-term OnionPerf measurements that are automatically published to the
Metrics portal from short-term experimental measurements.
---+--
 Reporter:  gaba   |  Owner:  metrics-team
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #33322
   Points: |   Reviewer:
  Sponsor: |
---+--
 In this task, we will add instance metadata to OnionPerf’s results in
 order to differentiate each experiment; we will store that data along with
 the actual measurement data in a separate, single archive. Without this
 task, we will be unable to distinguish the new experiments from the
 currently running OnionPerf instances, which makes the data collected
 unusable.

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

Re: [tor-bugs] #33322 [Metrics/Onionperf]: Objective 2: Expand the kinds of measurements OnionPerf can take by making improvements to its codebase.

[Tor Bug Tracker & Wiki]

#33322: Objective 2: Expand the kinds of measurements OnionPerf can take by 
making
improvements to its codebase.
---+--
 Reporter:  gaba   |  Owner:  metrics-team
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gaba):

 * type:  defect => 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

[tor-bugs] #33322 [Metrics/Onionperf]: Objective 2: Expand the kinds of measurements OnionPerf can take by making improvements to its codebase.

[Tor Bug Tracker & Wiki]

#33322: Objective 2: Expand the kinds of measurements OnionPerf can take by 
making
improvements to its codebase.
---+--
 Reporter:  gaba   |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Under sponsor 59's project we will expand kind of measurements for
 OnionPerf.

 More info:
 https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor59

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

Re: [tor-bugs] #32726 [Metrics/Cloud]: Automate the selection of SSH key in the CloudFormation templates

[Tor Bug Tracker & Wiki]

#32726: Automate the selection of SSH key in the CloudFormation templates
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Metrics/Cloud  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #32725 | Points:
 Reviewer:  irl|Sponsor:
---+--

Comment (by irl):

 This is merged 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] #32726 [Metrics/Cloud]: Automate the selection of SSH key in the CloudFormation templates

[Tor Bug Tracker & Wiki]

#32726: Automate the selection of SSH key in the CloudFormation templates
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Cloud  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #32725 | Points:
 Reviewer:  irl|Sponsor:
---+--
Changes (by irl):

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


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

Re: [tor-bugs] #32727 [Metrics/Cloud]: Automatically manage DNS names for OnionPerf dev with CloudFormation

[Tor Bug Tracker & Wiki]

#32727: Automatically manage DNS names for OnionPerf dev with CloudFormation
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Cloud  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #32725 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

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


Comment:

 https://github.com/torproject/metrics-cloud/pull/3

 Works great, merged.

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

Re: [tor-bugs] #33313 [Metrics/Cloud]: Documentation on metrics-cloud for Nagios and Onionperf

[Tor Bug Tracker & Wiki]

#33313: Documentation on metrics-cloud for Nagios and Onionperf
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Cloud  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #33321 | Points:  2
 Reviewer: |Sponsor:
---+--
Changes (by gaba):

 * parent:   => #33321


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