| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
Fixes a TODO.
|
| |
|
|
|
| |
This broke because `tor_keymgr::config::arti` was moved to
`tor_keymgr::config`.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This deduplicates the keymgr building logic in preparation for
supporting C Tor keystores (building the keymgr in a central place makes
things a bit easier, because regardless of the `kind` of the primary
keystore, we will need to extend the `KeyMgrBuilder` with the configured
secondary `ctor` keystores, if any).
|
| |
|
|
|
|
|
|
| |
The config will soon contain secondary C Tor keystore configuration too,
so the `arti` namespacing is about to stop making sense.
I recommend reviewing this commit using
`git diff --color-moved=zebra --ignore-space-change`
|
| |
|
|
|
|
|
|
|
|
| |
Currently, arti-client doesn't compile with just the features
experimental-api and onion-service-client enabled, because it
incorrectly depends on tor-hsservice.
This fixes that by gating the use statement behind the correct feature.
Fixes: #1638
|
| |\
| |
| |
| |
| | |
Implement memory quota tracking
See merge request tpo/core/arti!2493
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Plumb through a top-level account. This doesn't have any
channel-specific, circuit-specific or stream-specific accounts yet.
tor-circmgr's and tor-hsclient's *tests* need fake account.
In arti-relay, use a dummy account for now.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
arti-client: Clarify the launch_onion_service_with_hsid() docs.
Closes #1626
See merge request tpo/core/arti!2494
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This updates the docs to mention that the specified key may get
actually persisted to disk.
Closes #1626
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Use the new "restricted discovery" terminology throughout
Closes #1476
See merge request tpo/core/arti!2495
|
| | |/
| |
| |
| | |
Part of #1476
|
| | | |
|
| |/
|
|
|
|
| |
Previous documentation was more-or-less meant for the Arti developer
only. This new documentation is intended for actual users of RPC
functionality. It's meant to be extracted with `maint/rpc-doc-tool`.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Previously, arti's primary keystore was referred to as its "default"
keystore. However, "default" is inaccurate here: there is no way to
meaningfully override this "default" (the "default" store acts as the
main keystore). Throughout the codebase, we query all keystores for keys
(including the secondary ones), but only ever write to the
default/primary keystore. This is OK for now, because it enables us to
have one mutable keystore, and multiple secondary, read-only stores.
|
| |
|
|
| |
InertTorClient::create_keymgr()
|
| | |
|
| |
|
|
| |
HsIdKeypair
|
| |
|
|
| |
This was supposed to be a comment, not part of the docs.
|
| |
|
|
|
|
| |
`TorClient` and `InertTorClient` have a number of identical
state-management functions. This makes the `InertTorClient` link to the
`TorClient` docs instead of duplicating them.
|
| |
|
|
| |
remove_service_discovery_key methods
|
| |
|
|
| |
Nothing uses this yet.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements the `TorClientThatIsntRunning` mentioned in !2314 (see also
`doc/dev/notes/keymgr-porcelain.md`), except `TorClientThatIsntRunning`
is called `InertTorClient`.
This commit is mostly code motion: I've moved the `create_keymgr`
function and the impls of `generate_service_discovery_key` and
`get_service_discovery_key` from `TorClient` to `InertTorClient`.
The `InertTorClient` advertises itself as a handle for accessing the
keystores and other persistent state, but it currently only has 2
functions (`generate_service_discovery_key` and
`get_service_discovery_key`). I expect it will grow additional
functionality in the future.
|
| |
|
|
|
| |
I am about to use `state_dir()` outside of `TorClient`, so I am
preemptively moving it to `TorClientConfig`.
|
| | |
|
| | |
|
| |
|
|
| |
Closes #1490
|
| | |
|
| |
|
|
|
| |
Otherwise arti-client fails to build with `-no-default-features
--features onion-service-client,experimental-api`.
|
| |
|
|
| |
Part of #1281
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On its own, this might not seem like a huge improvement, but it will
later let us implement these RPC methods for types that can't
reasonably implement ClientConnectionTarget.
It also serves as a proof of concept that special-method invocation
can actually work, so that we can build things like this in cases
where introducing a trait isn't practical.
Closes #1427
|
| |
|
|
|
|
|
| |
If the circmgr retires all of its circuits, so should the HS circ pool.
The circuits can be retired for various reasons (for example, if the
configured vanguard mode changes).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Storing the VanguardMode in multiple places (in the VanguardMgr *and*
the HS circ Pool) is dangerous and can lead to split brain situations
where different parts of the code think they are running in different
VanguardModes.
See #1424
|
| |
|
|
|
|
|
|
|
| |
The application creates these, using a new-stream-handle RPC command,
on an object that can actually create streams.
Then later, the application provides the (global) identity of one of
these objects when it's making a SOCKS connection. This causes the
object to take hold of a `DataStreamCtrl`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(These will later become objects that can receive any application
request, once we have HTTP connect.)
For now, Session and TorClient implement this trait;
but soon there will be a new type to hold on to the created
DataStreamCtrl.
There are some XXXXs here, marking code that is too ugly to live.
I should fix it before I merge this branch.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This simplifies our implementation logic in a few places,
and simplifies our invocation syntax greatly. There are a few
infelicities, noted in `TODO RPC` comments.
|
| | |
|
| | |
|
| | |
|
| | |
|