| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | | |
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.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| |
| | |
We generally try to track the latest rust-crypto traits when we can:
fortunately, this upgrade didn't break much, considering.
|
| | |
| |
| |
| | |
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
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
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.
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Use a panic-free function to multiply timeouts.
See merge request tpo/core/arti!175
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously we used Duration::mul_f64, which panics if its output is
out-of-range. That shouldn't actually be possible for the values
we're giving it, but probably it's better to just multiply in a safe
way.
This resolves a couple of XXXXs and therefore relates to #231.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Allow configurability on preemptive circuits
Closes #245
See merge request tpo/core/arti!164
|
| | | |/ /
| |/| | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The rand crate's documentation says it's not okay to rely on StdRng
having reproducible output. So instead, let's switch to ChaCha12Rng
instead (which is what StrRng currently uses).
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | | |
We want to only use TODO in the codebase for non-blockers, and open
tickets for anything that is a bigger blocker than a TODO. These
XXXXs seem like definite non-blockers to me.
Part of arti#231.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
The redundant method was a `to_owned` that probably shouldn't have
been called that. It was only used in one place.
The tests should get tor-linkspec's line coverage up above 90%.
|
| |/ /
| |
| |
| |
| |
| |
| | |
This was a relic of the old, now-unused "caret_enum!" macro.
Removing it gets caret's coverage to 100%.
Yes, technically this is a semver breaker on caret.
|
| | |
| |
| |
| |
| |
| |
| | |
For this one I just wrote some "are things completely broken" tests
for the rand_compat wrappers. These won't detect subtle biases in
the RNGs! They'll only let you know if the wrappers have screwed up
in some way that always sets a given bit to 1 or 0.
|
| | |
| |
| |
| |
| | |
This is just a matter of writing a few tests for some very easy
functions.
|
| | |
| |
| |
| | |
This was just a matter of adding a call to one function.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is mostly a finger exercise, and an experiment in "what does
grcov consider to be coverage". Here's what I've found out...
* In grcov's eyes, most #[derive(Foo)] lines count as containing code;
but calling any one derived function counts as calling those lines.
* Unlike with tarpaulin, it is actually possible to reach 100% grcov
line coverage. (Tarpaulin likes to pick "}" lines and tell you that
you never reached them; or sometimes it picks expression
statements that have the effect of a return, and tells you that
they're unreached. Even with these tests, tarpaulin claims that
the line coverage of tor-units is only 97.3%.)
* In rust, it may be a bit hopeless trying to get high function
coverage. Even though we've hit every line of the tor-units crate,
the function coverage from its own tests is only 9.38% (55.41%
from other crates). I think this is probably due to derived
functions, or maybe due to generics getting instantiated?
I've got no idea; the denominator for the function coverage
lines fluctuates oddly.
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
Don't warn in bootstrap_from_config when error is Error::ManagerDropped
See merge request tpo/core/arti!157
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This makes sure that we're checking for a nonzero port in all cases.
|