| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | | |
Fix Cargo.toml typo with `no_default_features = true`
Closes #1666
See merge request tpo/core/arti!2498
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
arti-rpcserver: minimal handling for request.meta.require
See merge request tpo/core/arti!2511
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We have defined a forward-compatibility mechanism for the RPC
system, where a request may list one or more required "features",
and if any feature is absent, the request will fail.
Since no "features" are currently implemented,
this code does the bare minimum to implement this mechanism,
by rejecting every request with a nonempty "require" field.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The `update` field in request.meta is optional, so we should allow
it to default to `false` when it is absent.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
These, like the other RPC-only error kinds, probably don't belong in
`tor-error`. But for now, that's where they all are, and moving
them is out of scope for this branch. See #1668.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
tor-keymgr: Support reading C Tor keys.
Closes #858
See merge request tpo/core/arti!2481
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This broke because `tor_keymgr::config::arti` was moved to
`tor_keymgr::config`.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This way we have a more intuitive layout, where all C Tor keystore
configuration is under the `ctor` key.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2481#note_3090486
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This enables us to build `arti` with C Tor keystore support.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This moves `assert_found` out of the `keystore::arti::test` so we can
reuse it for testing other keystore implementations too.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This moves the `assert_config_error` helper from the restricted
discovery config tests to a `testing` module in `tor-config` (I am about
to reuse it for the C Tor keystore config tests too).
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is intentionally partially mis-indented to make this more
reviewable (in case the reviewer isn't using `ignore-all-space`).
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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 `FilesystemError::Filesystem` variant was actually just for IO
errors.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This will be reused by other on-disk key stores (such as the C Tor ones
we're about to add).
I recommend reviewing this commit using
`git diff --color-moved=zebra --ignore-space-change`
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This will be used to create relative paths representing C Tor keys.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
We're about to add a separate constructor for CTor paths.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
We are about to use this for the ctor keystore implementation too.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is only used for representing portions of `ArtiPath`s, so let's
rename it accordingly.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`KeyPath::matches` now returns a boolean (because we can't return a
matching "range" for `CTorPaths`, because unlike ArtiPaths, they're not
represented as `String`s, and do not have variable parts that need to be
captured).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
C Tor's client restricted discovery keys don't have the service hsid
encoded in the filename (the hsid of the service each key is associated
with is encoded in contents of the key file). This means that given a
key specifier like `HsClientDescEncKeypairSpecifier` (which is a wrapper
over an HsId), we can't actually compute the relative path of the key in
its `KeySpecifier::ctor_path()` implementation. To do so we would need
to access the keystore to figure out which path contains the requested
HsId, which we can't (and shouldn't!) do from within the `KeySpecifier`
impl.
This suggests the String newtype (representing a relative path) we
previously had is not a good abstraction for `CTorPath`s. Moreover,
`CTorPath` are static (they don't have dynamic components like
`ArtiPath`), so it makes more sense to model `CTorPath` as an enum.
The new `CTorPath::ClientHsDescEncKey(HsId)` variant will be used to
instruct the C Tor client keystore to find the file that contains the
specified `HsId`, while the `Service` variant will be used for hidden
service keys.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The `KeyMgrBuilder` now returns an error if the configured keystores
don't have pairwise unique IDs. This is needed because some keymgr
operations take a `KeystoreSelector` specifying the ID of the keystore
the operation should be performed on, and assume that the keystore ID
uniquely identifies a single keystore.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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`
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We are about to need this in `tor-keymgr`, where we're about to add a
config for C Tor service keystores (the C Tor keystore config will have
an associated `HsNickname` that specifies which of the arti hidden
services it's supposed to be used with).
|
| |\ \ \ \ \ \
| |_|_|_|/ /
|/| | | | |
| | | | | |
| | | | | | |
tor-rtmock: dyn_time tests: Test the downcast fail path too
See merge request tpo/core/arti!2500
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This will make it possible to use on a DropCounter and get a
DropCounter back.
|