| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
Some of the behaviors of the existing types here are nonstandard;
I've kept them and documented them, to avoid breaking compatibility.
|
| |\
| |
| |
| |
| |
| |
| | |
proto: Replace circuit-scoped `CircSyncView` with per-hop alternative
Closes #2351
See merge request tpo/core/arti!3680
|
| | |
| |
| |
| | |
And update the docs
|
| |/
|
|
|
|
|
|
|
| |
`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.
|
| |
|
|
|
| |
See discussion at
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3613#note_3332767
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 84b31824f317458a2aad6fb021b623935870f5bd.
Reverted, as this is a public API that might actually need to become
`async` at some point.
See discussion at
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3613#note_3332767
|
| | |
|
| |
|
|
| |
This lint triggers now that the unnecessary `async` is gone.
|
| | |
|
| |
|
|
| |
This adds the lint to all our crates.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|