| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
Fixes bug 40078.
As reported by hdevalence our batch verification logic can cause an assert
crash.
The assert happens because when the batch verification of ed25519-donna fails,
the code in `ed25519_checksig_batch()` falls back to doing a single
verification for each signature.
The crash occurs because batch verification failed, but then all signatures
individually verified just fine.
That's because batch verification and single verification use a different
equation which means that there are sigs that can pass single verification
but fail batch verification.
Fixing this would require modding ed25519-donna which is not in scope for
this ticket, and will be soon deprecated in favor of arti and
ed25519-dalek, so my branch instead removes batch verification.
|
|
New list for all stable releases.
Closes #40447
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Fixes #40301
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Fixes #40301
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
Continue having a tor_gmtime_impl() unit test so that we can detect
any problems in our replacement function; add a new test function to
make sure that gmtime<->timegm are a round-trip on now-ish times.
This is a fix for bug #40383, wherein we ran into trouble because
tor_timegm() does not believe that time_t should include a count of
leap seconds, but FreeBSD's gmtime believes that it should. This
disagreement meant that for a certain amount of time each day,
instead of calculating the most recent midnight, our voting-schedule
functions would calculate the second-most-recent midnight, and lead
to an assertion failure.
I am calling this a bugfix on 0.2.0.3-alpha when we first started
calculating our voting schedule in this way.
|
|
My clang doesn't like it when we write code like this:
char *list[] = {
"abc",
"def",
"ghi"
"jkl"
}
It wonders whether we meant to put a comma between "ghi" and "jkl"
or not, and gives a warning.
To suppress this warning (since in this case, we did mean to omit
the comma), we just wrap the two strings in parentheses.
Closes #40426; bugfix on 0.4.0.4-rc.
|
|
|
|
We already did this in a couple of places, but there are more that
we didn't get. This is necessary for systems with versions of
NSS that don't do their prototypes properly.
Fixes #40409; bugfix on 0.3.5.1-alpha.
|
|
This patch enables the deterministic RNG for address set tests,
including the tests which uses address set indirectly via the nodelist
API.
This should prevent random test failures in the highly unlikely case of
a false positive which was seen in tor#40419.
See: tpo/core/tor#40419.
|
|
|
|
|
|
"ours" to avoid version bump.
|
|
|
|
|
|
|
|
|
|
|
|
(My bad!)
|
|
|
|
Conflicts resolved:
src/core/or/relay.c
|
|
This issue was reported by Jann Horn part of Google's Project Zero.
Jann's one-sentence summary: entry/middle relays can spoof RELAY_END cells on
half-closed streams, which can lead to stream confusion between OP and
exit.
Fixes #40389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously, we would detect errors from a missing RNG
implementation, but not failures from the RNG code itself.
Fortunately, it appears those failures do not happen in practice
when Tor is using OpenSSL's default RNG implementation. Fixes bug
40390; bugfix on 0.2.8.1-alpha. This issue is also tracked as
TROVE-2021-004. Reported by Jann Horn at Google's Project Zero.
|
|
|
|
|
|
|
|
|
|
"ours" to avoid version bump.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
Fixes bug 40931; bugfix on 0.2.4.4-alpha. Also tracked as
TROVE-2021-005.
This issue was reported by Jann Horn from Google's Project Zero.
|
|
|
