| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This will make it easier to see the correspondence between CTorPaths
and the HS client/service key specifiers.
Initially, I was hoping this would make it easier to write a d-d macro
that automatically derives a `CTorPath` variant (e.g.
`HsClientDescEncKeypair`) from the KeySpecifier type name
(`HsClientDescEncKeypairSpecifier`), but alas, I don't think d-d can
"chop off" name suffixes ("Specifier", in this case).
`from_ctor_path()`/`ctor_path()` implementations for converting
`CTorPath`s to and from key specifiers.
|
| | |
|
| | |
|
| |
|
|
|
| |
The `ArtiPath` is included in the `KeyPathError::Arti` outer error type,
so there is no need to include it in `ArtiPathError` too.
|
| | |
|
| |
|
|
|
| |
This makes the error handling around `KeyPath`s a bit more sensible,
IMO, and it will make it easier to extend it for `CTorPath` errors.
|
| |
|
|
|
|
|
| |
This is similar to `#[serde(with = "...")]`, and feels a bit nicer than
having to specify two separate functions for the conversions (because
with two separate functions, you *can* technically only specify one of
them, which shouldn't be allowed).
|
| |
|
|
|
| |
This enables us to implement `KeyMgr::describe()`, which relies on the
ability to extract the key specifier of the key from its `KeyPath`.
|
| | |
|
| |
|
|
| |
rend_handshake time
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This code was duplicated across hsclient and hsservice.
Logically, it belongs in netdir, since that's where we have the
latest required-protocol information, and the ability to look up
relays by IDs.
Closes #1223
|
| | |
|
| |\
| |
| |
| |
| | |
arti: Add rate_limit_at_intro to the example config
See merge request tpo/core/arti!3493
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
hsservice: Clarify what max_concurrent_streams_per_circuit does
See merge request tpo/core/arti!3492
|
| | |
| |
| |
| |
| |
| |
| | |
At first glance, this might seem equivalent to C Tor's
`HiddenServiceMaxStreams` option, but it's actually
`HiddenServiceMaxStreamsCloseCircuit` (Arti doesn't implement the
former).
|
| |/
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |\
| |
| |
| |
| |
| |
| | |
arti/arti-client/tor-hsservice: Support disabling onion services in the config
Closes #2133
See merge request tpo/core/arti!3253
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is no longer a hard error anywhere for trying to launch a service
which is disabled in the config. Instead, it always means returning
`Ok(None)`.
The axum and hyper examples were updated again as a consequence.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
The "enabled" config option is back to using a regular `bool`. When
unset, it defaults to true, and the service runs as if it had been set.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
As requested in the review, there's a TODO now so we can come back some
day and allow onion services to be started/stopped while the client is
running.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
The "enabled" config option now uses `tor_config::BoolOrAuto`. When
unset (which defaults to "Auto"), the service will run with a warning.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Added the `enabled` field to the config options for hidden services. The
default is `true`. If it is set to `false`, the service won't start. As
of this specific commit, it's a hard error; it'll be checked again at
an earlier stage where it won't be once the feature is ready.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| | |
Run maint/add_warning
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |\
| |
| |
| |
| | |
tor-hsservice: Replace `libc::EFBIG` with `io::ErrorKind::FileTooLarge`
See merge request tpo/core/arti!3218
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Resolved an MSRV TODO. We used `libc::EFBIG` previously because
`io::ErrorKind::FileTooLarge` was still unstable. It has since
stabilized and entered our MSRV (>= 1.83.0).
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
Unless this is a pun, I'm pretty sure this is supposed to be `EFBIG` and
not `EFBUG`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This behaviour was changed in humantime 2.3.0. Because they made this
breaking change on a minor semver bump, if we want to depend on this
behaviour, we would need to lock to a specific version. I don't think
this is critical, but I am still looking into where exactly this is
used.
|
| | |
| |
| |
| | |
This feature has been removed from nightly, in favor of doc_cfg.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
An `OnionService` represents a not-yet-running service. To launch it,
you have to call `OnionService::launch()`, which consumes the
`OnionService` and returns `RunningOnionService`, so the part of the
docs saying that an `OnionService` "may or may not be running" was
somewhat misleading.
|
| | |
| |
| |
| |
| |
| |
| | |
This adds some extra docs to `RunningOnionService`.
This also removes the TODO about #1228, because that ticket was closed
in !1945.
|
| | |
| |
| |
| | |
In #1247 we decided to stick with the current names.
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
various crates: Updated MSRV TODOs for `once_cell` removal
See merge request tpo/core/arti!2953
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
- Shortened the TODO added in cad6f9054a5ff4d16e953fd4617d3893639deeef in the
style of [this maintainer request] for consistency.
[this maintainer request]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2953#note_3197719
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
This is just code motion (I suggest reviewing with `--color-moved`).
This also moves the implementation-agnostic parts from
`tor_proto::client::circuit` to a new `tor_proto::circuit` module.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\ \
| | |
| | |
| | |
| | | |
Fix clippy errors on nightly
See merge request tpo/core/arti!3148
|