| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
| |
This will allow for testing, as the CircuitBuilder can be replaced with
a mocked version.
This did require moving some of what was in the CircuitBuilder impl into
the AbstractCircuitBuilder type, since Drop implementations can't be
specialized, but that's fine, as we'll probably be doing more of that in
the future anyways.
|
| |
|
|
|
|
|
| |
This tests that when requesting preemptive circuits, they are not given
out when a insufficient number of circuits are in the CircList, but that
they are given out once the required number of circuits has been
reached.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AbstractSpec and FakeSpec actually make testing more difficult, since
they prevent using FakeBuilder in code that relies on the concrete
TargetCircUsage and SupportedCircUsage types. Removing them means
FakeBuilder can be used in more places, and also means that the test
code is closer to the real code, since TargetCircUsage and
SupportedCircUsage are now exercised directly in more tests.
This did require making one change to a test, which I think was
previously testing behaviour that was true for FakeSpec but not for the
real code:
The mgr::test::isolated test previously asserted that, in the case where
three circuits were requested, two with isolation and one without, the
non-isolated circuit would be shared with one of the isolated circuits.
This was allowed by the FakeSpec::supports function. However, in the
actual code, the path is as follows:
* AbstractCircMgr::get_or_launch
* AbstractCircMgr::prepare_action
* CircList::find_open
* AbstractSpec::find_supported
* abstract_spec_find_supported
* OpenEntry::supports
* SupportedCircUsage::supports
* StreamIsolation::compatible_same_type
StreamIsolation::compatible_same_type checks owner_type, which is
always zero for non-isolated streams and always non-zero for isolated
streams, meaning that a isolated stream will never be compatible with a
non-isolated stream. The seems like desirable behaviour, so I simply
modified the test to make four connections, two isolated and two not,
and checked that the isolated streams never share any circuits, and that
the two non-isolated streams use the same circuit. As far as I can tell,
this is the intended behaviour in the existing code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.
|
| | |
|
| | |
|
| |
|
|
| |
Part of #1297
|
| |
|
|
|
|
|
|
|
|
|
| |
This lets us check long_lived_ports only when we are constructing
a TargetCircUsage, and lets us remember whether or not the circuit
we've built is suitable for non-long-lived ports.
It also lets us decide whether existing circuits are compatible with
new requests.
Closes #1100.
|
| |
|
|
|
|
| |
MockSleepRuntime wraps a MockRuntime instead of using
test_with_one_runtime!(), so the tests should be more
deterministic
|
| | |
|
| | |
|
| |
|
|
| |
cargo fmt, precisely.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This threads the country codes work through the rest of the codebase:
- `tor-dirmgr` will now enable GeoIP with the embedded database when the
`geoip` future is enabled
- This can be extended later using the `DirMgrConfig` to allow
specifying a custom database; this is not done here, though
- `tor-circmgr`'s `SupportedCircUsage` and `TargetCircUsage` fields gain
new `country_code` members to allow filtering circuits by country
- These are `()` in builds where the `geoip` feature is not enabled --
doing it this way means we don't have to copy and paste huge swathes
of code, since we can't use `#[cfg]` in patterns
- `ExitPathBuilder` gains (hacked-in) support for choosing a relay with
the correct country code
- Due to the lack of conjuction, we just copy and paste a small bit,
pending further refactoring
- `StreamPrefs` now lets you specify a country code, letting embedders
make use of the feature
|
| | |
|
| |\
| |
| |
| |
| | |
clippy: Allow some of our existing code patterns
See merge request tpo/core/arti!1396
|
| | | |
|
| |/
|
|
| |
In each of these, it is locally obvious that the range is nonempty.
|
| |\
| |
| |
| |
| | |
rng ranges: Use inclusive Duration ranges in several places
See merge request tpo/core/arti!1385
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Many of these call sites would panic if, somehow, the upper bound was
zero. In most cases it is very complicated to see if whether this
could happen.
However, there is a better answer:
Durations are (conceptually) dense, so picking the closed set (which
includes its boundary) rather than the open one (which doesn't) will
make little practical difference.
So change four call sites to use `..=` instead of just `..`.
|
| |\ \
| |/
|/|
| |
| | |
Optional tracing support in tor-error for error reporting
See merge request tpo/core/arti!1379
|
| | |
| |
| |
| | |
This simplifies our logging a little, and implements part of
|
| |/
|
|
| |
This appeases clippy-nightly.
|
| |\
| |
| |
| |
| |
| |
| | |
Change log levels of messages from INFO to others
Closes #854
See merge request tpo/core/arti!1172
|
| | |
| |
| |
| |
| |
| | |
This commit changes certain log messages to debug for recoverable errors
and a warn if all such attempts fail, in order to not clutter up the
info messages that end users get to see.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Now ClientCirc is no longer `Clone`, and the things that need it
to be `Clone` instead return and use an Arc<ClientCirc>
We're doing this so that ClientCirc can participate in the RPC
system, and so that its semantics are more obvious.
Closes #846.
Thanks to the type system, this was a much simpler refactoring than
I had feared it would be.
|
| |
|
|
| |
We'll use this to implement the circuits used by onion circuits.
|
| |
|
|
| |
Split off for ease of review and possible rebase.
|
| | |
|
| | |
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
| |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| | |
|
| |
|
|
|
|
|
| |
It turns out that bug #656 is not a real bug, but it was easy to
overlook the code that prevented it.
Closes #656.
|
| |\
| |
| |
| |
| | |
Channel padding
See merge request tpo/core/arti!657
|
| | |
| |
| |
| |
| | |
As suggested in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2827246
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Replace Channel::note_usage with Channel::engage_padding_activities,
which unconditionally causes the channel to (start to) do netflow
padding things.
The condition now lives in chanmgr.
Addresses
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826094
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Channel padding depends on what the channel is being used for. We
therefore need to let the channel code know this information.
The implementation of the per-channel padding control logic will be in
the new note_usage function, which for now is simply a stub.
A future commit will introduce a `PaddingControlState` which lives in
the channel frontend; consult the doc comment for that type to see why
the plumbing through the channel manager terminates in the channel
frontend.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
A "transient" error is one that does not indicate a true failure,
but rather an _expected_ need to retry. When we hit one of these,
we do not count it against the total number of permitted failures.
(We do impose a higher limit on "real failures plus transient
failures", though, to prevent infinite loops in the event of a
programming error.
Closes #517.
|
| |
|
|
|
|
| |
There are some downstream changes required for this to work, but
they are all just unit tests that could no longer infer the type of
an Ed25519 key.
|
| | |
|
| | |
|
| |
|
|
|
| |
Run rustfmt. Separate commit to make review of the substantive commit
easier.
|
| |
|
|
|
| |
This is a *lot* of unwraps. The function takes no parameters and
is used only for testing. It ought to be infallible.
|
| |
|
|
| |
It's a little overzealous sometimes, but it's mostly to the good.
|
| |
|
|
|
| |
Remove all `use` statements for `TryFrom` and `TryInto`. These are
now redundant in Rust 2021.
|
| |
|
|
|
|
|
| |
This feature is similar to ChanProvenance from ChanMgr, except that
we don't yet need to report it outside the crate. I'm going to use
it to distinguish newly created circuits from existing circuits in
the preemptive circuit builder.
|
| |
|
|
|
|
|
| |
This lets us say that the UsageMismatch cases in some parts of the
code reflect a programming error (RetryTime::Never), whereas in
other case it reflects another circuit request getting to the
circuit first (RetryTime::Immediate).
|
| |
|
|
|
|
|
|
|
| |
Use the new RetryTime type and its associates to decide how long to
wait (if at all) between attempts to build a circuit.
Closes #421.
Part of #329.
|
| |
|
|
|
|
|
| |
Previously we did not distinguish errors that came from pending
circuits from errors that came from the circuits we were
building. We also reported errors as coming from "Left" or "Right",
instead of a more reasonable description.
|