| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\ \
| | |
| | |
| | |
| | | |
add example: axum router as onion service
See merge request tpo/core/arti!2422
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
socks: Implement proposal 351.
See merge request tpo/core/arti!2401
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Introduce an enum, and use explicit `format_code @` syntax.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
(These streams would already be isolated by accident, since streams
with an RPC object are always on a client that's isolated from the
main client. But, as discussed on torspec!280, it's best to do this
sort of thing explicitly.)
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
The current best source here is prop351,
and later will be socks-extensions.md.
The examples are now correct.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
See https://spec.torproject.org/proposals/351-socks-auth-extensions.html
This proposal changes the interpretation of SOCKS5
usernames/passwords to give a more principled and extensible way of
getting RPC IDs and isolation strings.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
rpclib: Use prop351 protocol to open streams.
See merge request tpo/core/arti!2434
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now that prop351 is what Arti speaks, it's what the rpclib
needs to provide.
Note one change in particular: the `isolation` string
is no longer an optional argument when opening a stream.
(With prop351, there is no longer such a thing as an "absent"
isolation string, and we don't want to imply that there is a
difference between None and "".)
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
arti SOCKS proxy: Tear down connections when client sends optimistic data
See merge request tpo/core/arti!2443
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We *do* want to support optimistic data, see
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2436#note_3081886
However, right now, Arti risks mis-framing bugs if clients do send
optimistic data, which would be quite serious.
Mitigates #1627 / TROVE-2024-010 by replacing the misframing bug with
connection failure.
It doesn't seem so easy to write a test case for this.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
RPC: Expose delegation information to help documentation
Closes #1624
See merge request tpo/core/arti!2418
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Closes #1624.
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When specifying a delegation, the template user must also say what
type they're delegating to.
We're going to use this to document and expose delegations.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Make `HsCircPool` generic over circuit builder type
See merge request tpo/core/arti!2420
|
| | | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will allow for testing, as the CircuitBuilder can be replaced with
a mocked version.
This did require moving some of what was in the CircuitBuilder impl into
the AbstractCircuitBuilder type, since Drop implementations can't be
specialized, but that's fine, as we'll probably be doing more of that in
the future anyways.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
rtcompat: Second attempt at AF_UNIX support
Closes #1152
See merge request tpo/core/arti!2437
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It turns out that these types are generally useful, and that they
are in fact needed for tor-rtmock to compile without a PreferredRuntime.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
(The trait no longer has any async methods.)
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is feature-complete, but will need tests.
I'm holding off at this point so we can discuss naming on these types.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since there is no way to construct a unix::SocketAddr on these
platforms, it's harmless to provide an implementation for
NetStreamProvider. What's more, doing so greatly simplifies our
AbstractAddr implementation.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As before, this commit does nothing interesting: it's a separate commit
because it reindents a lot of code.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This commit does nothing interesting yet: it's a separate commit
because it reindents a lot of code.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This change will let us make a NetStreamProvider that works for
AF_UNIX addresses, and for "abstract" addresses.
I've decided to let this parameter have a default value of
`std::net::SocketAddr` for now. We can remove the default later
if we decide it's confusing.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Stop referring to TCP streams in its documentation;
update other documentation to refer to NetStreamProvider
rather than TcpProvider.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
(And similarly rename TcpListener to NetStreamListener,
along with their TcpStream/TcpListener associated types.)
These types are about to become generic over addresses,
and therefore shouldn't be named after TCP.
Renaming was done mostly with Rust Analyzer,
except for some macros that needed to be hand-edited.
(I'll revise the comments in the next commit;
this one is all about renaming.)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It's redundant with the incoming() method (which turns the
TcpListener into a Stream of connections), and nothing actually used
it outside of tests.
Removing this method allows us to simplify our TcpListener code a
good deal, as can be seen by some of the implementations we removed
from our example and testing code.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
With this extension trait, we no longer need to construct
`CompoundRuntime` directly outside of tor-rtcompat. This in turn
will make it a little less painful when we have to add more generics
to CompoundRuntime.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
tor-keymgr: Move keystore.kind under keystore.primary.kind
Closes #858
See merge request tpo/core/arti!2441
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In !2394 we settled on `kind`. This updates the error messages to
reference the new field name.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The keystore settings only configure the *primary* keystore, so they
should be under `keystore.primary`.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is a follow-up from !2394
I want to keep the `keystore.enabled` option, because I'm planning on
extending `ArtiKeystoreConfig` to support configuring secondary
keystores too (currently, the only supported setting is `keystore.kind`,
which configures the primary keystore). `keystore.enabled` will disable
keystore use altogether (i.e. both primary and secondary).
Currently, we only support configuring the "primary" (previously known
as "default") keystore, which can be either "native" (the on-disk Arti
keystore), or "ephemeral" (an in-memory keystore). To implement #858,
we will need to support configuring additional keystores too, so we will
need to move to a config of the form
```toml
[storage.keystore]
# Whether the keystore is enabled.
#enabled = "auto"
# Configure the primary keystore.
[storage.keystore.primary]
# The type of primary keystore to use
kind = "auto" | "native" | "ephemeral"
# Optionally configure C Tor keystores for arti to use.
#
# Note: The keystores listed here are read-only (keys are only
# ever written to the primary keystore, configured in
# `storage.keystore.primary`).
[[storage.keystore.ctor]]
# If the `kind` is `service`, this should be set to the `HiddenServiceDirectory`
# of your hidden service. Arti will read `HiddenServiceDirectory/hostname`
# and `HiddenServiceDirectory/private_key`. (Note: if your service is running
# in restricted discovery mode, you must set the
# `[[onion_services."<the nickname of your svc>".restricted_discovery.key_dirs]]`
# to `HiddenServiceDirectory/client_keys`
#
# If the `kind` is `client`, this should be set to `ClientOnionAuthDir` of
# your client. If Arti is configured to run as a client (i.e. if it runs in SOCKS
# proxy mode), it will read the client restricted discovery keys from this path.
path = "/foo/bar"
# The type of keystore `path` should be interpreted as
kind = "client" | "service"
```
This moves the current keystore settings to `storage.keystore.primary`
in preparation for that change.
|
| |/ / / /
| | | |
| | | |
| | | |
| | | | |
I am adding `is_enabled()` back because I plan to un-deprecate the
`enabled` setting.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-keymgr: Rename the primary keystore for clarity.
See merge request tpo/core/arti!2438
|
| | | | | | |
|