| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Part of #2428.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Force use of standard hasher with weak_tables.
Closes #2418
See merge request tpo/core/arti!3801
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Closes #2418.
Fixes TROVE-2026-005, where we would use a less cryptographically
secure (and probably less DoS resistant) hash function for these
tables if:
- We are built alongside another crate that uses `weak-table`
- That crate enables the `weak-table/ahash` feature.
- We are running on a system without hardware AES.
Severity: Low
|
| |/
|
|
| |
Typos found with codespell
|
| | |
|
| |
|
|
|
|
|
|
|
| |
`clippy::collapsible_if` started triggering after bumping the MSRV to
1.88.
Since this triggers from a lot of places, and since there even are a
couple of instances where we explicitly allow `clippy::collapsible_ifs`,
I've opened #2342 for deciding what to do about it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This requires the `TlsKeyAndCert` so be passed on the TLS acceptor
settings. We assume that `RelayIdentities` has this information.
The ChanBuilder::new() was getting a bit too convoluted and feature
gated to instead we introduce new_client() and new_relay() and remove
the need for `with_identities()`.
Because of this, the ChanMgr::new() now returns a `Result<>`.
Related to #1597
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| |
|
|
| |
This adds the lint to all our crates.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This struct is used to pass configuration parameters to the ChanMgr when
building it.
At the moment, it holds the ChannelConfig and RelayIdentities (feature
gated) which will be used in subsequent commits.
Note that relays do require RelayIdentities to build channels.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
We'll rely on a RelayIdentities to pass in the right keys to the ChanMgr
instead of the entire KeyMgr.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
rend_handshake time
|
| | |
|
| | |
|
| |
|
|
|
| |
(We could tighten this up even more by inlining some of the default
values.)
|
| |
|
|
|
|
|
|
|
| |
Fixes part of #2193.
(Edits from nickm: I selected the cases here that I could verify
were correct from immediate context.)
Edited-by: Nick Mathewson <[email protected]>
|
| | |
|
| |
|
|
|
| |
Since "info" is the default level, we don't want to log by default each
time a circuit reactor is created.
|
| | |
|
| |
|
|
| |
This silences a new nightly warning.
|
| |
|
|
|
|
|
| |
Now that `vanguard_config()` is no longer conditional, we can handle
`vanguard_config` just like other accessors. This is a breaking change,
but I think we may as well make this change while we've already made
another breaking change in the previous commit.
|
| | |
|
| |
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rust was treating this as a wildcard match if the `hs-common` feature
wasn't enabled. This shouldn't have caused any bugs since the other
match arms were already exhaustive, but this could have lead to a bug if
new enum variants were added to `SupportedTunnelUsage`.
```text
warning: variable `HsOnly` should have a snake case name
--> crates/tor-circmgr/src/usage.rs:600:13
|
600 | HsOnly => {
| ^^^^^^ help: convert the identifier to snake case: `hs_only`
|
= note: `#[warn(non_snake_case)]` (part of `#[warn(nonstandard_style)]`) on by default
warning: `tor-circmgr` (lib) generated 1 warning
```
|
| |
|
|
|
|
|
| |
Abolish the constants with the transitional names.
This also abolishes the controversial name `H_S_DIR`, which Rust case
transformation rules generated from `HSDir`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're going to separate RelayFlag from RelayFlags.
We could continue to provide a bunch of constant values for
RelayFlags, for each individual type, but that would involve an ad-hoc
derive, and would still be a bit of an unusual API.
Instead, we're going to make ``RelayFlag` a normal enum.
In this commit, we change everyone to refer to it by its singular
name. Hopefully separating out this bulk change makes both this, and
the core commit, easier to review.
|
| |
|
|
| |
I would do `#[deprecated]` but empirically that has no effect...
|
| |
|
|
|
| |
Add underscores so that the spec keywords and the flag constants
correspond (according to `paste`'s case-changing rules).
|
| | |
|
| | |
|
| |
|
|
|
| |
(The only error possible is an internal error from
calling it with a non-long-lived tunnel.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code uses the algorithm of prop368: When a tunnel is
sufficiently isolated, we want to expire it after it has been
disused for a certain amount of time.
The implementation is a little tricky, since we need to call an
async function on ClientTunnel to look up the disused_since() check.
We don't want to call async functions while holding locks, so
we need to drop the TunnelList lock before we do the disused_since()
calls, and the grab it again.
As part of this change, I've had made expiration functions return
the earliest time at which any tunnel might expire. We can use
this in the future to spawn fewer expiration tasks, and scan the
list of tunnels less often.
|
| | |
|
| |
|
|
|
| |
Instead of a series of cutoffs, take an object with a set of
lifetimes.
|
| |
|
|
| |
We'll need them to be async so they can call disused_since() on tunnels.
|
| | |
|
| |
|
|
| |
Part of prop368.
|
| |
|
|
| |
Run maint/add_warning
|
| | |
|
