| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| |
|
|
| |
I don't expect that we'll need this.
|
| | |
|
| |
|
|
|
| |
This does not yet get the OR port from the config, and the channel
manager doesn't yet do anything with the incoming connection.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We don't want to create new files just when creating a `InertTorRelay`.
We should only generate the keys before bootstrapping.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have bootstrap() to prepare everything we need before starting the
relay which yields a TorRelay.
This commit then adds a run() function which starts the relay by
launching background task. At the moment, we only have one task and it
is the channel expiry one.
The relay blocks on the task handle set until one task is on error or
stops which leads to shutting down the relay.
Part of #2217
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
We decided to move away from the `Error` + `ErrorDetail`
all-encompassing enum design, and will use `anyhow::Error` in more
places. When we need to handle specific errors, we will create smaller
more-specific error types in those cases.
|
| | |
|
| |
|
|
| |
And remove one that we didn't need.
|
| | |
|
| | |
|
| |
|
|
| |
We'll add a `TorRelay` back in a following commit.
|
| |
|
|
|
|
| |
This currently can't be used due to upstream limitations in the ssh_key
crate, which will be removed likely in the next release. In the
meantime, we can put in all the groundwork.
|
| |
|
|
|
|
|
| |
This is so a relay can build authenticated channels. Several keys/cert
are required for this that are within the key manager.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| |
|
|
|
|
|
| |
We think that for relays, the 'override_net_params' config option is
overly broad and a footgun. We can always re-add this back later if we
want to, but for now the focus will be on exposing specific config
options for features that are okay to be changed by users.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This is a bunch of boilerplate code that we don't currently need, and
may not need in the future since we don't need to provide a lot of
library-API-level customization for `TorRelay` like we do with
`TorClient`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This will enable us to store more than one `K_relaysign_ed` in the
keystore.
Closes #1692
|
| |
|
|
|
|
|
|
|
|
| |
According to its docs, `RelayIdentityKeySpecifier` was meant to be the
key specifier for the relay identity keypair, so its role prefix should
be `KS_`.
This also renames `RelayIdentityKeySpecifier` to
`RelayIdentityKeypairSpecifier` for clarity (we're about to add another
specifier here, for the public relay identity key).
|
| |
|
|
| |
Fixes a TODO.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
|
|
Simply, the lib.rs is renamed to relay.rs (containing TorRelay object)
so this crate can never be used as a library.
This is important because at the moment, we don't want to have a relay
stable API that can be used to embed relays in applications.
Closes #1674
Signed-off-by: David Goulet <[email protected]>
|