| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | | |
We don't yet do much with these, but we can avoid discarding them.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I'm slightly concerned about whether this is behavior people would
expect to have on-by-default, so let's make this off-by-default for
now.
Maybe the `application` and `system` sections should merge?
|
| | | |
| | |
| | |
| | | |
Closes #270
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Fix severe reactor ordering problems
See merge request tpo/core/arti!282
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A number of severe problems with the circuit reactor were fixed which
could cause reordering of cells (which causes relays to terminate the
circuit with a protocol violation, as they become unable to decrypt
them). These mostly revolve around improper usage of queues:
- The code assumed that a failure to place cells onto the channel would
persist for the duration of a reactor cycle run. However, under high
contention, this wouldn't always be the case.
- This leads to some cells getting enqueued while others go straight
through, before the enqueued cells.
- To fix this, we block sending cells out of the channel while there
are still some enqueued.
- The hop-specific queues queued after encryption, not before. This was
very brittle, and led to frequent mis-ordering.
- This was fixed by making them not do that.
This is arti!264 / 5bce9db5628126be2b736f228211174fe4132918 without the
refactor part.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Add editorconfig to force some rules (Final Newline)
See merge request tpo/core/arti!289
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
dir-client: bug fix and more tests
See merge request tpo/core/arti!271
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Earlier versions have a bug in UnboundedReceiver that make our new
dirclient tests fail.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
These bring the case a tiny improvement in test coverage, and also
manage to turn up a few bugs.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
There are a couple of places where we forgot to truncate our
return-buffer to its actual size, and instead returned a big bunch
of zeros. Found while writing the tests in the next commit.
Someday, we'll have ReadBuf and won't have to worry about these
things.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fix typos
See merge request tpo/core/arti!285
|
| | | |/ / / /
| |/| | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Prompted by clippy::needless_question_mark. Sometimes Ok(r?) is
needed to do automatic error conversion. I assume the lint checks for
that. Anyway, in these cases it's not needed.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Found via clippy::needless_borrow. In some cases I removed needless
`[..]` too. See also:
needless_borrow suggestion doesn't go far enough
https://github.com/rust-lang/rust-clippy/issues/8389
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
clippy::needless_borrow quibbles here, IMO correctly. Its suggestion
didn't go far enough: output is a String and a &String can be passed
to write as-is for identical effect.
|
| |\ \ \ \ \
| |_|/ / /
|/| | / /
| | |/ /
| |/| | |
Preparatory work for auto config reload
See merge request tpo/core/arti!284
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
TorClient doesn't need to be wrapped in an Arc any longer, thanks
to other refactoring.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is by no means our final API, but should represent an
improvement. Here instead of having to specify a list of files and
their is-this-optional status, along with a list of command-line
options, we have a single structure that encapsulates all of that
information.
Two advantages here:
- Callers no longer have to remember what the boolean means.
- We can "reload" more easily, by keeping the source object around.
This change also implements the correct behavior for our default
configuration file in `arti::main`: if the file is absent and the
user doesn't list a config file, that's no problem. But if the user
lists _that very same config file, we should insist that it be
present.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This enum is required to use `TorClient::reconfigure` correctly, and
as such ought to be re-exported.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This implements the proposal from arti#298, making the
`BenchmarkResults` type be made out of a bunch of new `Statistic` types
(which summarize the mean, median, range, and standard deviation of an
arbitrary value) instead of overloading `TimingSummary` for this
purpose.
|
| |/ / |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
tor-netdir needs to bump because tor-netdoc bumped, even though
there were no other changes in tor-netdir. Whoops.
tor-guardmgr needs to bump because it already published, with the
older tor-netdir.
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Make max_file_limit configurable
Closes #299
See merge request tpo/core/arti!261
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This failure occurred because our tests use canned data to exercise
the directory state functionality, and the canned consensus has
suddenly become very expired.
There are better fixes possible, but this is a minimal one that
should get CI working on main again.
|
| | | |
| | |
| | |
| | |
| | | |
Nothing actually used these accessor functions, and it's not clear
what would. We can add them later if they're needed.
|
| | | |
| | |
| | |
| | |
| | | |
These probably aren't for things that will fail IRL, but it's nice
to have coverage on the code, just in case.
|
| | | |
| | |
| | |
| | | |
Now there's much less copy-and-paste.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This makes our layout more similar to our other crates, and
successfully informs our grcov exclusion pattern that these tests
are indeed tests.
Doing this knocks down the reported coverage for the tor-rtcompat
crate, but that's okay: we hadn't earned it.
I hereby promise that this commit is only code-movement.
|
| | | |
|
| | |
| |
| | |
Comment-only.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This avoids a future confusion with the new `SpawnBlocking` trait in
async_executors v0.5, and better describes what the trait provides.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This took some refactoring, so that I wouldn't need to define 9
different versions of the function. It also required that we change
the behavior of test_with_all_runtimes slightly, so that it asserts
on _any_ failure rather than asserting on most but returning Err()
for others. That in turn required changes to a few of its callers.
There's probably a better way to do all of this macro business, but
this is the best I could find.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit puts the native-tls crate behind a feature. The feature
is off-by-default in the tor-rtcompat crate, but can be enabled
either from arti or arti-client.
There is an included script that I used to test that tor-rtcompat
could build and run its tests with all subsets of its features.
Closes #300
|
| | |
| |
| |
| |
| | |
This helps us simplify our code in a few ways, and will help even
more once native_tls is optional.
|
| | |
| |
| |
| |
| | |
This should help avoid some amount of temptation towards API
proliferation.
|
| | | |
|
| | |
| |
| |
| |
| | |
If we implement our own clone on CompoundRuntime, we no longer need
Clone implementations on our TlsProvider implementations.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Having separate types here doesn't justify the (very limited)
benefit of distinguishing between the case where we have created an
executor that we own and the case where we have a handle to an
already-running tokio executor.
Part of #301.
|