"ours" to avoid version bump

Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

George Kadianakis authored 3 years ago and Alexander Hansen Færøy committed 3 years ago

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>

David Goulet authored 4 years ago and Alexander Hansen Færøy committed 3 years ago

Fixes #40301

Signed-off-by: David Goulet <dgoulet@torproject.org>

David Goulet authored 4 years ago and Alexander Hansen Færøy committed 3 years ago

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

David Goulet authored 3 years ago and Nick Mathewson committed 3 years ago

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