- 09 Mar, 2021 2 commits
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
- 03 Mar, 2021 1 commit
-
-
Alexander Færøy authored
-
- 02 Mar, 2021 1 commit
-
-
Nick Mathewson authored
-
- 01 Mar, 2021 6 commits
-
-
David Goulet authored
-
David Goulet authored
-
David Goulet authored
-
David Goulet authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
- 26 Feb, 2021 2 commits
-
-
Alexander Færøy authored
This patch unbreaks the Windows build on master that was introduced in 99703eac.
-
George Kadianakis authored
-
- 24 Feb, 2021 3 commits
-
-
David Goulet authored
-
David Goulet authored
-
George Kadianakis authored
-
- 23 Feb, 2021 12 commits
-
-
David Goulet authored
-
David Goulet authored
-
David Goulet authored
Now deprecated in libc >= 2.33 Closes #40309 Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
David Goulet authored
Now deprecated in libc >= 2.33 Closes #40309 Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
David Goulet authored
The directory_fetches_from_authorities() is used to know if a client or relay should fetch data from an authority early in the boot process. We had a condition in that function that made a relay trigger that fetch if it didn't know its address (so we can learn it). However, when this is called, the address discovery has not been done yet so it would always return true for a relay. Furthermore, it would always trigger a log notice that the IPv4 couldn't be found which was inevitable because the address discovery process has not been done yet (done when building our first descriptor). It is also important to point out that starting in 0.4.5.1-alpha, asking an authority for an address is done during address discovery time using a one-hop circuit thus independent from the relay deciding to fetch or not documents from an authority. Small fix also is to reverse the "IPv(4|6)Only" flag in the notice so that if we can't find IPv6 it would output to use IPv4Only. Fixes #40300 Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
Nick Mathewson authored
-
David Goulet authored
Fix a bug introduced in 94b56eaa which overwrite the connection message line. Furthermore, improve how we generate that line by using a smartlist and change the format so it is clearer of what is being rejected/detected and, if applicable, which option is disabled thus yielding no stats. Closes #40308 Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Closes #40282 Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
- 22 Feb, 2021 13 commits
-
-
Alexander Færøy authored
-
David Goulet authored
Related to #40253 Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
David Goulet authored
No behavior change except for logging. This is so the connection related statistics are in the right object. Related to #40253 Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
David Goulet authored
This is a new detection type which is that a relay can now control the rate of client connections from a single address. The mechanism is pretty simple, if the rate/burst is reached, the address is marked for a period of time and any connection from that address is denied. Closes #40253 Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
David Goulet authored
Fixes #40301 Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
Alexander Færøy authored
-
Alexander Færøy authored
-
Nick Mathewson authored
0.1.9 fixed a range-coalescing bug; 0.1.10 fixed a performance regression.
-
Nick Mathewson authored
-
Nick Mathewson authored
The IPFire people provide a tool that collects data from several top-level sources, combines it into a single database, and annotates it with optional overrides. This tool transforms the "dump" format of their database into the form Tor expects.
-