Re: [tor-bugs] #33018 [Core Tor/Tor]: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix

[Tor Bug Tracker & Wiki]

#33018: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix
---+---
 Reporter:  arma   |  Owner:  dgoulet
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health 043-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by starlight):

 How about this?  A hashlimit rule that establishes a maximum byte rate out
 to any /24, /22 or such.  My point is netfilter allows rapid what-if
 testing of various rate limit strategies, up-to and including HTB ingress
 schemes with IMQ and arbitrary schemes with nfqueue.  Dirport queries are
 clear-text, it should be manageable to distinguish between compressed and
 uncompressed queries and mark connections accordingly.

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

Re: [tor-bugs] #33018 [Core Tor/Tor]: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix

[Tor Bug Tracker & Wiki]

#33018: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix
---+---
 Reporter:  arma   |  Owner:  dgoulet
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health 043-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by starlight):

 Consensus documents are large and I suppose a fairly low rate per address,
 coming from a few thousand would result in overload. . .was just a
 thought.

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

Re: [tor-bugs] #33022 [Internal Services/Service - git]: Grant Georg DocTor permissions

[Tor Bug Tracker & Wiki]

#33022: Grant Georg DocTor permissions
-+
 Reporter:  atagar   |  Owner:  tor-gitadm
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 Replying to [ticket:33022 atagar]:
 > * Cron jobs hosted on carinatum

 I believe I have now added gk to the doctor group. Woo.

 But atagar, it looks like there is a doctor *user* too? And {{{crontab -u
 doctor -l}}} seems to think that it's the doctor user that is running the
 cron tasks.

 Is this a separate user that you log in as? Do you sudo to it from your
 atagar ldap login?

 Seems like it might be really useful to have a "crash course on being the
 doctor maintainer" written up at
 https://trac.torproject.org/projects/tor/wiki/org/operations/services
 Maybe gk already knows these things and he can help write 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] #33018 [Core Tor/Tor]: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix

[Tor Bug Tracker & Wiki]

#33018: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix
---+---
 Reporter:  arma   |  Owner:  dgoulet
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health 043-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 Replying to [comment:19 starlight]:
 > How about throwing up an iptables recent module rule limiting the
 maximum request rate from any single IP address and seeing if it helps?
 My observation is botnet abuse often arrives with high intensity from a
 limited number of addresses during a given interval.  Set at a perhaps
 twice the maximum rate expected of a bootstrapping relay.  If it works
 similar logic could be added to the relay.  I have a couple of rules I'll
 share privately, though it's hardly rocket science.

 I believe Sebastian has done some exploration of the IP addresses, and
 found that many of the requests come from their own IP address. That is,
 this really is thousands of places around the internet, not just a
 handful.

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

Re: [tor-bugs] #33018 [Core Tor/Tor]: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix

[Tor Bug Tracker & Wiki]

#33018: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix
---+---
 Reporter:  arma   |  Owner:  dgoulet
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health 043-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by starlight):

 How about throwing up an iptables recent module rule limiting the maximum
 request rate from any single IP address and seeing if it helps?  My
 observation is botnet abuse often arrives with high intensity from a
 limited number of addresses during a given interval.  Set at a perhaps
 twice the maximum rate expected of a bootstrapping relay.  If it works
 similar logic could be added to the relay logic.  I have a couple of rules
 I'll share privately, though it's hardly rocket science.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33127 [- Select a component]: Snowflake Extension proxy bug

[Tor Bug Tracker & Wiki]

#33127: Snowflake Extension proxy bug
-+--
 Reporter:  t  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  - Select a component
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 I downloaded the snowflake tor extension on my Google Chrome desktop
 browser to serve as a proxy, and it's off now because it can't connect to
 the bridge. I don't know why that is.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33126 [- Select a component]: Snowflake Extension bug

[Tor Bug Tracker & Wiki]

#33126: Snowflake Extension bug
--+--
 Reporter:  eddytorres96  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  - Select a component
  Version:|   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I downloaded the Snowflake Tor extension on my Google Chrome desktop
 browser to serve as a proxy, and it's off now because it can't connect to
 the bridge. I don't know why that is.

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

Re: [tor-bugs] #33067 [Metrics/Consensus Health]: DocTor should fetch microdesc consensus, and use compression

[Tor Bug Tracker & Wiki]

#33067: DocTor should fetch microdesc consensus, and use compression
--+--
 Reporter:  arma  |  Owner:  gk
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:  GeorgKoppen202002 |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Replying to [comment:6 atagar]:
 > Do we have any thoughts on a longer term DoS mitigation mechanism?

 Those tickets are #33018, #33029, and #33072.

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

Re: [tor-bugs] #33067 [Metrics/Consensus Health]: DocTor should fetch microdesc consensus, and use compression

[Tor Bug Tracker & Wiki]

#33067: DocTor should fetch microdesc consensus, and use compression
--+--
 Reporter:  arma  |  Owner:  gk
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:  GeorgKoppen202002 |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Good point -- let's stick with using the DirPort, but let's still change
 (both DocTor and DepicTor) to fetching the microdesc consensus (or fetch
 both, that's fine too), and most importantly, let's change them to
 requesting compression for the http requests.

 For context, I believe that my Tor is including this header in its http
 request:
 {{{
 Accept-Encoding: deflate, gzip, identity
 }}}
 and then of course it gets a thing back that is deflated or gzipped or
 something and it uncompresses 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] #33055 [Applications/Tor Browser]: TOR_TRANSPROXY=0 not working

[Tor Bug Tracker & Wiki]

#33055: TOR_TRANSPROXY=0 not working
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Please delete this ticket as the issue is not reproducible anymore.

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

Re: [tor-bugs] #33067 [Metrics/Consensus Health]: DocTor should fetch microdesc consensus, and use compression

[Tor Bug Tracker & Wiki]

#33067: DocTor should fetch microdesc consensus, and use compression
--+--
 Reporter:  arma  |  Owner:  gk
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:  GeorgKoppen202002 |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 Hi Roger. Stem can download descriptors through ORPorts so this isn't a
 problem...

 https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html
 #where-can-i-get-the-current-descriptors

 That said, DocTor intentionally downloads from DirPorts for
 troubleshootability. With a DirPort we can demonstrate problems to dirauth
 operators with curl, whereas with ORPorts that is not possible.

 This is, of course, up to Georg but I would be wary of dirauths becoming
 complacent in breaking their DirPort as DoS mitigation (as tor26 has).
 Doing so will complicate maintenance for you, and encourages DoS attackers
 to target your ORPort.

 Do we have any thoughts on a longer term DoS mitigation mechanism?

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

Re: [tor-bugs] #27268 [Applications/Tor Browser]: preferences cleanup

[Tor Bug Tracker & Wiki]

#27268: preferences cleanup
-+-
 Reporter:  rzb  |  Owner:  gk
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff68-esr, TorBrowserTeam202001,  |  Actual Points:
  tbb-pref   |
Parent ID:   | Points:  1
 Reviewer:  acat |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff68-esr, TorBrowserTeam202001 => ff68-esr,
 TorBrowserTeam202001, tbb-pref


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33125 [Applications/Tor Browser]: Remove xpinstall.whitelist.add* as they don't do anything anymore

[Tor Bug Tracker & Wiki]

#33125: Remove xpinstall.whitelist.add* as they don't do anything anymore
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-pref
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 See: https://searchfox.org/mozilla-
 esr68/search?q=xpinstall.whitelist.add=false=false=

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

Re: [tor-bugs] #33124 [Core Tor/Tor]: Controller circuits don't pass the SOCKS request address in relay begin cells

[Tor Bug Tracker & Wiki]

#33124: Controller circuits don't pass the SOCKS request address in relay begin
cells
--+
 Reporter:  opara |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 I think 0.4.4 is right here -- this is sounding as if it were a feature
 that had never worked, and so doing it in the next series is correct.

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

Re: [tor-bugs] #31565 [Core Tor/Tor]: static Tor building against openssl-1.1.1 fails: configure unable to find linkable OpenSSL

[Tor Bug Tracker & Wiki]

#31565: static Tor building against openssl-1.1.1 fails: configure unable to 
find
linkable OpenSSL
+--
 Reporter:  shredder|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor,openssl,1.1.1,static,mingw  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 It might help enormously to have the config.log outputs from running the
 configure script in both cases: once with 1.0.2 and once with 1.1.1.

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

Re: [tor-bugs] #31565 [Core Tor/Tor]: static Tor building against openssl-1.1.1 fails: configure unable to find linkable OpenSSL

[Tor Bug Tracker & Wiki]

#31565: static Tor building against openssl-1.1.1 fails: configure unable to 
find
linkable OpenSSL
-+-
 Reporter:  shredder |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor,openssl,1.1.1,static,mingw   |  Actual Points:
  043-should backport|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor,openssl,1.1.1,static,mingw =>
 tor,openssl,1.1.1,static,mingw 043-should backport
 * milestone:  Tor: unspecified => Tor: 0.4.3.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #25021, #32379, #32380, #32381, ...

[Tor Bug Tracker & Wiki]

Batch modification to #25021, #32379, #32380, #32381, #32389, #32640, #32864 by 
gk:


Comment:
Move my tickets to Feb 2020.

--
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] #33067 [Metrics/Consensus Health]: DocTor should fetch microdesc consensus, and use compression

[Tor Bug Tracker & Wiki]

#33067: DocTor should fetch microdesc consensus, and use compression
--+--
 Reporter:  arma  |  Owner:  gk
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:  GeorgKoppen202002 |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: gk (removed)
 * cc: tom (added)
 * owner:  tom => gk
 * status:  new => assigned
 * keywords:   => GeorgKoppen202002


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

Re: [tor-bugs] #33067 [Metrics/Consensus Health]: DocTor should fetch microdesc consensus, and use compression (was: DocTor should also fetch microdesc consensus, plus maybe downplay the vanilla conse

[Tor Bug Tracker & Wiki]

#33067: DocTor should fetch microdesc consensus, and use compression
--+-
 Reporter:  arma  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 I changed the ticket title to reflect the growing plan on #33072 --
 ideally consensus-health would fetch the microdescriptor consensus, using
 compression, from the ORPort. But the most important change looks like it
 will be "start using compression".

 And come to think of it, that's probably a good and smart and polite thing
 to be doing anyway, right?

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

Re: [tor-bugs] #33072 [Core Tor/Tor]: When under load, give 503 aggressively for dirport requests without compression

[Tor Bug Tracker & Wiki]

#33072: When under load, give 503 aggressively for dirport requests without
compression
---+---
 Reporter:  nickm  |  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health 043-should  |  Actual Points:
Parent ID:  #33018 | Points:
 Reviewer:  nickm, teor, armadev   |Sponsor:
---+---

Comment (by arma):

 Thought 1: ORPort begindir requests from clients ask for compression,
 right? So this patch is a substantive and useful change, because it will
 resume answering real Tor clients who are trying to bootstrap from
 directory authorities, in a way that the #33029 patch broke (because all
 the dir auths running the #33029 patch are now returning 503 to nearly
 every consensus fetch attempt from non-relays, including ORPort-based
 begindir requests).

 Thought 1b: Other effective ways to make us resume answering clients, but
 still survive the current flood, include "always answer microdesc-flavored
 requests" or "always answer ORPort-based requests". I think just favoring
 microdesc-flavored requests would not be enough to reenable the fetches
 from torflows though, because torflows set UseMicrodescriptors to 0. And
 "always answer ORPort-based requests" would not be enough to reenable the
 fetches for relays that haven't yet ~~gotten into the consensus~~published
 their relay descriptor, because they would be fetching via the DirPort
 because they think they're a relay, yet the dir auths do not yet think
 they are a relay. A third edge case is DocTor and DepicTor (aka consensus-
 health), because right now with the defenses in place they're failing to
 fetch dir info from the authorities (#33067). But consensus-health is
 doing its fetches wrong in all three ways -- it is fetching the vanilla
 consensus, uncompressed, from the dirport -- so it is going to have to
 change here no matter what. In sum: looking at whether compression is
 requested is the best choice of these three.

 Thought 2: This commit looks fine to me, and it's a good start, but for me
 it is not enough.

 Right now all it does is always answer compressed requests, which will
 implicitly drive bandwidth use toward compressed requests, because this
 strategy will leave less bandwidth available for uncompressed requests.

 So it does not accomplish the "aggressively" part. With just this patch,
 moria1 will still max out its bandwidth use for whatever bandwidthrate I
 pick. So I will be forced to pick something tiny like 10MBytes/s because I
 know that whatever I pick, I will use that amount 24/7. And that situation
 will make the network more brittle, because moria1 won't be able to burst
 to handle larger directory loads if some other anomaly appears that
 requires dir auth responses to be able to scale suddenly.

 So what I want in addition to the above is some way to say 503 to these
 unwanted requests even if I'm not at the edge of my bandwidth rate this
 very moment. I would be ok with a config option to just send 503 to
 uncompressed requests, and be done with it. In that case we are simply
 declaring that uncompressed requests are no longer supported by dir auths.
 Or I would also be ok with a config option that specifies what level of
 bandwidth to give to these requests, i.e., a bucket water level below
 which we send a 503, even if there are otherwise quite a few tokens in my
 bucket. That approach is a bit more complicated to build, but it would
 preserve the illusion that we're still willing to answer uncompressed
 requests. And it would more seamlessly handle the situation where the
 current ddos slowly fades away and/or returns later.

 Thought 2b: We might worry that flat-out denying uncompressed requests
 will force this current ddoser to change, and we'll end up finding it
 harder to distinguish their requests and discard them. But I think with
 #33029 plus dgoulet's patch here, we'll already be denying the great
 majority of the uncompressed requests. With the "bucket water level"
 design I just described, we'll reject more but it won't be a substantive
 difference. Or said another way, if we're worried that the ddoser will
 change their approach, we should worry about that even if we just do
 #33029 plus dgoulet's patch, because we will definitely be making their
 directory fetches very unreliable. So if we're committed to that risk
 (which I think we have to be, unless we can think of something smarter),
 we might as well maximize the good side of the tradeoff, and defend
 ourselves, and our bandwidth use, better.

--
Ticket URL: 

Re: [tor-bugs] #33072 [Core Tor/Tor]: When under load, give 503 aggressively for dirport requests without compression

[Tor Bug Tracker & Wiki]

#33072: When under load, give 503 aggressively for dirport requests without
compression
---+---
 Reporter:  nickm  |  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health 043-should  |  Actual Points:
Parent ID:  #33018 | Points:
 Reviewer:  nickm, teor, arma  |Sponsor:
---+---
Changes (by arma):

 * reviewer:  nickm, teor, armadev => nickm, teor, arma


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

Re: [tor-bugs] #33097 [Core Tor/Tor]: outbuf_flushlen seems to serve no purpose

[Tor Bug Tracker & Wiki]

#33097: outbuf_flushlen seems to serve no purpose
--+
 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:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 outbuf_flushlen is for exactly what you described: "how much of the outbuf
 should we attempt to flush now?" The outbuf could be arbitrary-sized, for
 example if a pile of cells came in but the corresponding place to send
 them to is blocked. And so when that destination unblocks, we don't just
 want to write the entire outbuf to the network right then, because it
 could be unfair to the other places that also want to write, especially if
 it uses up our write tokens and we stop wanting to flush anything else.

 If we now do all of that using other logic, sounds great.

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

Re: [tor-bugs] #33022 [Internal Services/Service - git]: Grant Georg DocTor permissions

[Tor Bug Tracker & Wiki]

#33022: Grant Georg DocTor permissions
-+
 Reporter:  atagar   |  Owner:  tor-gitadm
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 Replying to [ticket:33022 atagar]:
 > * [https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-consensus-
 health tor-consensus-health@ email list]

 I've added gk as a moderator for the list, and sent him the moderation
 password.

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

Re: [tor-bugs] #33022 [Internal Services/Service - git]: Grant Georg DocTor permissions

[Tor Bug Tracker & Wiki]

#33022: Grant Georg DocTor permissions
-+
 Reporter:  atagar   |  Owner:  tor-gitadm
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 Yes please!

 This ticket is blocking a key fix for consensus-health (#33067). Because
 of the dir auth ddos (#33018), and the defenses deployed against it
 (#33029), fetching the vanilla consensus over the dirport from the
 consensus-health server has become inconsistent.

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