| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | | |
(These weren't in the codebase when I started the first version of
this branch.)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
And now the complexity begins: when the user changes the path_rules,
they not only want new circuits to obey those rules: they want
_all new requests_ to be put onto circuits that obey those rules.
That means that when the path rules become more restrictive, we need
to retire all the circuits, and make sure that currently pending
circuits aren't used for any requests.
If it's any comfort, doing this was even more complicated in C tor. ;)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It's useful to keep configuration objects inside a RwLock<Arc<>>, so we
can have slightly-stale pointers to the existing configuration structure
without holding locks too long.
This code adds a MutCfg type with basic support for this pattern,
and functions to make it a bit more ergonomic.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch doesn't actually make anything reconfigurable, but it
does create an API that will tell you "you can't change the value of
that!" If the API looks reasonable, I can start making it possible
to change the values of individual items.
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Don't create circuits if the consensus is stale by over 72 hours
Closes #89
See merge request tpo/core/arti!190
|
| |/ / |
|
| | |
| |
| |
| |
| | |
[Edited by nickm: This applies one of Daniel's fixes in place of one
of Trinity's: Trinity says it's a bit cleaner, and I agree.]
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
[T;N] supports TryFrom<Vec<T>>, and has since Rust 1.48: we can just
use that.
This resolves an XXXX comment.
|
| | | |
|
| | |
| |
| |
| | |
These issues all have tickets, so can become TODOs.
|
| | |
| |
| |
| |
| |
| | |
We should never get one of these unless we have opted in to get it.
(This behavior is the same as C tor.)
|
| | |
| |
| |
| |
| | |
These features are necessary for digest to expose its CtOutput type;
without them, the tor-bytes crate doesn't build independently.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | | |
Our old algorithm could, on some inputs, exhaust RAM. That's not great,
since we try to be robust againt corruption to the state file.
|
| |\ \ \ |
|
| | | |/
| |/| |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We had no function to infallibly convert BoundedInt32<{0 or 1},H>
into a u32, even though we could have. Because of that, we were
treating weight_scale as an i32 when logically it's a u32 or a
NonZeroU32.
Moreover, it turns out we were using an incorrect minimum for the
bwweightscale param, which would in theory have allowed the
authorities to make us divide by zero.
This patch introduces the necessary From<> implementation and uses
it. It corrects the binimum bwweightscale, and prevents a
division-by-zero issue in case weight_scale is zero.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Because of arti#257, compatibility with earlier versions of rust are
broken: we hope this is temporary, but fixing it will probably
require a new version of rusqlite.
|
| | | |
| | |
| | |
| | |
| | | |
This comment was about an unspecified string; the issue of
specifying the string is now torspec!55.
|
| | |/
|/|
| |
| |
| | |
I've opened torspec!54 to fill in the missing parts of the spec
about these issues.
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
Upgrade to digest v0.10.0
See merge request tpo/core/arti!182
|
| |/
|
|
|
| |
We generally try to track the latest rust-crypto traits when we can:
fortunately, this upgrade didn't break much, considering.
|
| |\
| |
| |
| |
| | |
Small cleanups to stream timeout configurations
See merge request tpo/core/arti!179
|
| | |
| |
| |
| | |
We shouldn't have pub members in these config objects.
|
| |/
|
|
|
|
|
| |
(There are other timeout rules, after all.)
Also, rename stream_timeout to connect_timeout, to make it more clear
when it applies.
|
| |\
| |
| |
| |
| | |
Usability: renaming and documentation in preemptive circuit config
See merge request tpo/core/arti!176
|
| | |
| |
| |
| |
| | |
Also, use humantime_serde, rather than a number of seconds, to indicate
configuration time.
|
| | |
| |
| |
| |
| |
| | |
This obeys a few conventions:
* adjective before noun
* config objects end with "config"
|
| |\ \
| | |
| | |
| | |
| | | |
Make TlsConnector wrap TCP connections, not create its own
See merge request tpo/core/arti!166
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`tor-rtcompat`'s `TlsConnector` trait previously included a method to
create a TLS-over-TCP connection, which implied creating a TCP stream
inside that method. This commit changes that, and makes the function
wrap a TCP stream, as returned from the runtime's `TcpProvider` trait
implementation, instead.
This means you can actually override `TcpProvider` and have it apply to
*all* connections Arti makes, which is useful for issues like arti#235
and other cases where you want to have a custom TCP stream
implementation.
This required updating the mock TCP/TLS types in `tor-rtmock` slightly;
due to the change in API, we now store whether a `LocalStream` should
actually be a TLS stream inside the stream itself, and check this
property on reads/writes in order to detect misuse. The fake TLS wrapper
checks this property and removes it in order to "wrap" the stream,
making reads and writes work again.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Make DNS fields in arti-client/src/client.rs configurable
Closes #252
See merge request tpo/core/arti!171
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Detect and use CHUTNEY_PATH in test scripts.
See merge request tpo/core/arti!168
|
| | | |
| | |
| | |
| | | |
This is per a suggestion from @trinity-1686a.
|
| | | |
| | |
| | |
| | |
| | | |
Previously, if the arti process had died or been killed, we wouldn't
reach the point where we called "chutney stop".
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If the user has CHUTNEY_PATH set, respect that value, rather than
cloning a local chutney.
Also, if we have a local chutney, then update it in case there have
been changes.
|
| | | |
| | |
| | |
| | | |
There is now a ticket about this issue in general, at arti#254.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Squash, refactor, and test !139 (Don't use same family as exit when picking a guard)
Closes #183
See merge request tpo/core/arti!173
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Just as `in_same_family` is a member of Relay, so the function for
getting all the real family members of a relay should belong in the
same crate.
This change also removes the `family()` accessor: it gives the _claimed_ family rather
than the _acknlowedged_ family, and is therefore a bit dangerous.
There's still a hole in this logic; I've noted it in the Limitations
section. If we get a microdescriptor for a relay in between creating
and using the guard restriction, it might be omitted from the family
list.
|
| | | | |
| | | |
| | | |
| | | | |
This approach saves us from a linear search when picking guards.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There's not much reason to use a HashSet here, since we're just
going over the whole list.
This reverts commit 16e8489abbea1581b8e2 and does a little more
refactoring.
|