| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Part of #40476
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Some tests were removed because they were testing something not usable
anymore.
Some tests remains to make sure that things are indeed disabled.
Part of #40476
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Part of #40476
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Some tests were removed because they were testing something not usable
anymore.
Some tests remains to make sure that things are indeed disabled.
Part of #40476
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Part of #40476
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Some tests were removed because they were testing something not usable
anymore.
Some tests remains to make sure that things are indeed disabled.
Part of #40476
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Series 0.4.2.x, 0.4.3.x and 0.4.4.x will all be rejected at the
authority level at this commit.
Futhermore, the 0.4.5.x alphas and rc will also be rejected.
Closes #40480
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Closes #40469
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Fixes issue #22469 where port strings such as '0x00' get accepted, not
because the string gets converted to hex, but because the string is
silently truncated past the invalid character 'x'. This also causes
issues for strings such as '0x01-0x02' which look like a hex port range,
but in reality gets truncated to '0', which is definitely not what a
user intends.
Warn and reject such port strings as invalid.
Also, since we're throwing that "malformed port" warning a lot in the
function, wrap it up in a nice goto.
Fixes #22469
|
|
|
|
Tuning these may reduce memory usage and latency.
|
|
|
|
We currently assume that the only way for Tor to listen on ports in the
privileged port range (1 to 1023), on Linux, is if we are granted the
NET_BIND_SERVICE capability. Today on Linux, it's possible to specify
the beginning of the unprivileged port range using a sysctl
configuration option. Docker (and thus the CI service Tor uses) recently
changed this sysctl value to 0, which causes our tests to fail as they
assume that we should NOT be able to bind to a privileged port *without*
the NET_BIND_SERVICE capability.
In this patch, we read the value of the sysctl value via the /proc/sys/
filesystem iff it's present, otherwise we assume the default
unprivileged port range begins at port 1024.
See: tor#40275
|
|
|
|
This code is based directly on the specification, without looking at
the reference implementation or the implementation in Arti.
Nonetheless, it is now passing with the test vectors generated by
the reference implementation.
|
|
|
|
|
|
This will hopefully solve an issue where our gmtime related tests are
failing on 32-bit builds.
|
|
|
|
|
|
Since we merged 40383, we don't expect these to give the same
warning on every platform.
|
|
Fixes #40301
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Fixes #40301
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
|
|
This is an attempt to fix CID 1486280, where coverity warns us that,
if the tests failed, we might free() an uninitialized pointer.
|
|
This is an attempt to fix CID 1486276, where coverity warns us that,
if the tests failed, we might free() an uninitialized pointer.
|
|
|
|
Now the circuits look like this:
client rend: C -> G -> L2 -> Rend
client intro: C -> G -> L2 -> M -> Intro
client hsdir: C -> G -> L2 -> M -> HSDir
service rend: C -> G -> L2 -> M -> Rend
service intro: C -> G -> L2 -> M -> Intro
service hsdir: C -> G -> L2 -> M -> HSDir
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Co-authored-by: Mike Perry <mikeperry-git@torproject.org>
|
|
|
|
|
|
|
