- Jun 10, 2021
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
- Jun 07, 2021
-
-
Nick Mathewson authored
-
Nick Mathewson authored
"ours" to avoid version bump.
-
Nick Mathewson authored
-
Nick Mathewson authored
"ours" to avoid version bump.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
- Jun 01, 2021
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
David Goulet authored
-
- May 28, 2021
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
The new version of shellcheck says that that this idiom is unnecessary, and its presence here is making the shellcheck tests fail. No changes file needed, since this is not user-facing code.
-
- May 27, 2021
-
-
Nick Mathewson authored
Without this message getting logged at 'WARN', it's hard to contextualize the messages we get about compression bombs, so this message should fix #40175. I'm rate-limiting this, however, since it _could_ get spammy if somebody on the network starts acting up. (Right now it should be very quiet; I've asked Sebastian to check it, and he says that he doesn't hit this message in practice.) Closes #40175.
-
David Goulet authored
-
- May 26, 2021
-
-
Nick Mathewson authored
Cached_dir_t is a somewhat "legacy" kind of storage when used for consensus documents, and it appears that there are cases when changing our settings causes us to stop updating those entries. This can cause trouble, as @arma found out in #40375, where he changed his settings around, and consensus diff application got messed up: consensus diffs were being _requested_ based on the latest consensus, but were being (incorrectly) applied to a consensus that was no longer the latest one. This patch is a minimal fix for backporting purposes: it has Tor do the same search when applying consensus diffs as we use to request them. This should be sufficient for correct behavior. There's a similar case in GETINFO handling; I've fixed that too. Fixes #40375; bugfix on 0.3.1.1-alpha.
-
- May 25, 2021
-
-
Alexander Hansen Færøy authored
-
Alexander Hansen Færøy authored
-
Alexander Hansen Færøy authored
-
Nick Mathewson authored
It was used nowhere outside its own unit tests, and it was causing compilation issues with recent OpenSSL 3.0.0 alphas. Closes ticket 40399.
-
- May 17, 2021
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
- May 12, 2021
-
-
David Goulet authored
The connection type for the listener part was missing from the "is connection a listener" function. This lead to our periodic event that retries our listeners to keep trying to bind() again on an already opened MetricsPort. Closes #40370 Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
- May 10, 2021
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
"ours" to avoid version bump.
-
Nick Mathewson authored
-
- May 07, 2021
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
This change permits the newfstatat() system call, and fixes issues 40382 (and 40381). This isn't a free change. From the commit: // Libc 2.33 uses this syscall to implement both fstat() and stat(). // // The trouble is that to implement fstat(fd, &st), it calls: // newfstatat(fs, "", &st, AT_EMPTY_PATH) // We can't detect this usage in particular, because "" is a pointer // we don't control. And we can't just look for AT_EMPTY_PATH, since // AT_EMPTY_PATH only has effect when the path string is empty. // // So our only solution seems to be allowing all fstatat calls, which // means that an attacker can stat() anything on the filesystem. That's // not a great solution, but I can't find a better one.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-