| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
| |
We put this behind a feature because we probably want to test this
out before we enable it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test was supposed to set both the current and the previous SRV in the
test netdir, but was actually only setting the previous one.
With the new SRV fixes from ee07c441909b41d5fbbfbffae310e954a69db478,
all the hsservice tests using this netdir were panicking on an
`.unwrap()`, because the SRV for the "previous" TP could not be found,
which is actually what you'd expect to happen, given that the netdir was
built with only one SRV. The reason the tests weren't failing before is,
funnily enough, because of the bug in SRV calculation that is fixed in
ee07c441909b41d5fbbfbffae310e954a69db478:
In `tor-netdir`, the `extract_srvs()` function (correctly) only returned
a single SRV from the consensus (the "previous one", set with
`bld.shared_rand_prev()` in the test), but the `find_params_for_time()`
was wrongly matching up that same SRV with multiple time periods. This
happened because the old implementation was computing the "previous SRV"
validity interval as:
* ts_begin = `[start_of_day_containing(consensus_ts) - ONE_DAY`
* ts_end = `ts_begin + srv_interval`
And because the test SRV interval is 288h(!), and the test TP length is
only 24h, the validity period of the previous SRV (incorrectly) covered
two TPs (both the previous and the current). So as a result, the test
was "successfully" getting back the same SRV for both the previous and
the current TP.
The bug was introduced in the commit that originally added the hsservice
tests: 279842526591918e25ca97e6392f211a50192396
|
| |
|
|
|
|
|
|
|
|
|
| |
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.
This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
|
| |
|
|
|
| |
This saves a little memory, but the technique will help save more
memory for other uploads.
|
| | |
|
| | |
|
| |
|
|
| |
This lint triggers now that the unnecessary `async` is gone.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an error from nightly. The trouble is that with nightly,
there's a now a [derive macro for From][issue]. That doesn't cause
a conflict when we `use derive_more::From`, but it _does_
cause a conflict when we import `derive_more::From` via
`use internal_prelude::*`.
So as a solution, we just import `derive_more::From` explicitly.
Closes #2124
[issue]: https://github.com/rust-lang/rust/pull/144922
|
| | |
|
| |\
| |
| |
| |
| | |
proto: Add a placeholder for the relay reactor.
See merge request tpo/core/arti!3162
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `stream` module is client-specific, for the most part, so I am
moving it under `client`. Later on, we will factor out the parts that
can be shared with the relay implementation.
Note: this is a breaking change as the deleted `stream` module was
`pub`. We could've kept the module and reexported from it the public
types from `tor_proto::client::stream`, but I think it's better to have
this `client` namespacing, because it makes the separation between the
client and relay parts clearer.
|
| | | |
|
| |/
|
|
|
|
| |
This does not currently allow this option to be changed at runtime,
although the code is structured so that allowing it to be changed at
runtime won't be too hard. This is tracked by #2082.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| | |
|
| |
|
|
|
| |
It would be better to take a more sophisticated approach;
see #2048.
|
| |
|
|
|
| |
These errors are suspicious as hsdir inflation attacks, in the
context of prop360.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently clippy nightly is better (or worse?) about detecting
complex functions than before, so I'm suppressing these warnings
where they occur.
I have mixed feelings about these warnings: On the plus side,
they really do help to detect functions that are twistier than they
need to be. On the minus side, they get confused by tracing macros,
and the "allows" do pile up. But on the plus side, those "allows"
do provide a way to find functions that need to be refactored,
and they are never uglier than the functions they decorate.
|
| |
|
|
|
|
| |
This adds a error type for internal errors, and in error cases where we
previously panicked, returns a Result instead. The publisher then simply
doesn't publish the pow_params line and warns the user.
|
| |
|
|
|
|
|
| |
This adds PowManager, as described in doc/dev/notes/service-side-pow.md,
hooks it into IptManager and Publisher, and adds code to publish and
rotate seeds, and to keep a updated list of Verifier instances for
currently active seeds.
|
| |
|
|
|
| |
Now that our MSRV is 1.83, clippy is happy to make more
recommendations for us.
|
| |
|
|
|
|
|
|
|
|
|
| |
We want to require that whenever we generate a key that's persistent
(stored in KeyMgr), it's going to be made from a stronger-than-usual
Rng. This trait helps us enforce that.
We also add a FakeEntropicRng struct to use for testing.
Note that this turned up a case that we'd missed, which required
an internal change in tor-hsservice.
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| |
|
|
| |
rustfmt.
|
| |
|
|
|
|
|
|
|
|
| |
We're going to distinguish top-level runtime entry, from *re*-entry to
an existing executor. It is most convenient to rename this trait
first. Documentation of the distinction will come later.
(We're going to retain the function name `block_on`, but we want the trait
to be more obviously a top-level only thing, though, so we give it a
name that will hopefully avoid it peroulating throughout the codebase..)
|
| |
|
|
|
| |
These helpers seem potentially broadly useful, and only really
discoverable if they're here.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a big change across multiple crates since there isn't a good way
to break it up.
This changes the signature of `CfgPath::path` to:
```
pub fn path(&self, path_resolver: &CfgPathResolver) -> Result<PathBuf, CfgPathError> {
```
Making this change means that our global `CfgPathResolver` needs to be
stored in the 'arti-client' library instead of `tor-config-path`, and
must be passed through to anything that calls `path` to expand the
variables.
|
| | |
|
| |
|
|
|
| |
Also updated other packages to get `CfgPath` directly from
`tor-config-path' instead of 'tor-config'.
|
| |
|
|
|
| |
These are the call sites where using this fucntion is correct.
(Outside tor-rtmock, which we'll do separately.)
|
| |
|
|
| |
As mentioned in #727, this is not supported yet.
|
| |\
| |
| |
| |
| |
| |
| | |
Bug 1613: Add support for inserting externally generated and removing arbitrary service discovery keys
Closes #1613
See merge request tpo/core/arti!2396
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
tor-hsservice: Improve descriptor publisher status reporting
Closes #1216 and #1572
See merge request tpo/core/arti!2397
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We will need to return a list of descriptor upload errors.
We can't return a `Vec<RetryError<DescUploadError>>` here because
`DescUploadError` is a lower-level error type that can't express that
e.g. the upload timed out.
|
| | | |
|
| | |
| |
| |
| |
| | |
We never return `UploadError::Timeout` (timeouts are represented as
`BackoffError::Timeout`).
|
| | |
| |
| |
| | |
This type is a `Result`, renaming for clarity.
|
| | |
| |
| |
| | |
Closes #1216
|