| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
| |
The `keymgr` module selects one of the key manager implementations
(dummy or "real") and exposes all the APIs we need, so we can remove
all of the cfgs related to the `keymgr` feature from `client.rs`.
Part of #897
|
| |
|
|
|
|
|
|
| |
This moves the key manager API selection (dummy vs "real" impl) into the
`keymgr` module. The module exports the dummy API if the `keymgr`
feature is disabled, and the impl from `tor-keymgr` otherwise.
Part of #897
|
| |
|
|
|
|
| |
`insert` and `remove` should return an error rather than `Ok(())`, as
`Ok(())` implies the key was stored/removed, which is impossible in the
no-op implementation.
|
| |
|
|
|
|
| |
This will help us reduce the number of `#[cfgs(...)]` from `client.rs`
Part of #897
|
| |
|
|
| |
Part of #897
|
| |
|
|
| |
Part of #897
|
| | |
|
| |
|
|
|
|
|
|
|
| |
We currently initialize the `ArtiNativeKeyStore` with a dummy root dir,
so when `ArtiNativeKeyStore` starts validating directories, this code
will start to fail. Let's preemptively ignore any errors coming from
`ArtiNativeKeyStore::new`. This is temporary and will be removed when we
introduce the key store config (and a real default value for the
keystore root dir).
|
| | |
|
| | |
|
| |
|
|
| |
Reformatting deferred for clarity.
|
| |
|
|
| |
This test case shows that we return a suboptimal error in some cases.
|
| |
|
|
|
| |
ErrorDetail isn't PartialEq so we can't assert_eq! it.
But the discriminants will be.
|
| | |
|
| |
|
|
| |
This disposes of the TODO as well.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
(Taken from tpo/core/arti!1113 and squashed by Ian Jackson, with
conflicting hunk in StreamPrefs struct skipped.
The setter name is wrong, the cfg feature is wrong, there are no
docs, and the TODO is still there. These will be fixed in a moment.)
|
| |
|
|
|
| |
This should be enabled by default. There's still no setter for not,
nor is it honoured - those are separate TODOs.
|
| |
|
|
|
| |
Previously this error meant "we haven't written this code yet".
Now, we change it to "you haven't built Arti with this feature".
|
| | |
|
| |
|
|
| |
No functional change yet. We'll use this shortly.
|
| |
|
|
| |
Disposes of two TODOs.
|
| |
|
|
| |
This will make subsequent commits less noisy to read.
|
| |
|
|
|
| |
These have already been partially/replaced supplemented.
The other test referred to will appear shortly.
|
| | |
|
| |
|
|
|
|
| |
Rationale as per #756.
This is the same name as in the `arti` crate.
|
| | |
|
| |
|
|
|
|
| |
We need to allow some lints in the dummy key manager because its
implementation needs to mirror that of `tor_keymgr::KeyMgr` (so we can't
apply the API changes suggested by clippy).
|
| |
|
|
|
|
|
|
|
| |
TorClient now only uses the tor_keymgr::KeyMgr implementation if the
keymgr experimental feature is enabled. If the feature is disabled, a
dummy key manager implementation is used.
The new `keymgr` feature depends on `onion-client`, because the key
manager is only used for HS client auth.
|
| | |
|
| |
|
|
|
|
|
| |
This simplifies usage quite a bit and will enable us to implement a
dummy `KeyMgr` that doesn't depend on the error types from tor-keymgr
(which will replace the "real" `KeyMgr` if the keymgr feature is
disabled).
|
| | |
|
| |
|
|
|
|
| |
The HS `HsClientSpecifier` and `HsClientSecretKeySpecifier` are moved to
`tor-hsclient`. The HS service secret key specifier stubs are moved to
`tor-hsservice`.
|
| |
|
|
|
|
|
| |
The `KeyMgr` is now initialized with an `ArtiNativeKeyStore` built from
an invalid key store root dir (this is alright for the purposes of this
proof-of-concept, since `ArtiNativeKeyStore::new` won't fail as it
doesn't currently validate the keystore root dir).
|
| |
|
|
|
|
|
| |
This means `KeyMgr` users don't need to specify the underlying key type
(e.g. `ed25519::Keypair`) when retrieving keys. Instead, they can just
specify the type required (as long as it implements `ToEncodableKey`),
e.g. `HsClientIntroAuthKeypair`.
|
| |
|
|
|
| |
`TorClient` now uses a `KeyMgr` to retrieve the `HsClientSecretKeys`
client auth keys passed to `get_or_launch_connection`.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
RPC: Functionality to downcast dyn Object to a dyn Trait.
See merge request tpo/core/arti!1225
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a rather tricky piece of functionality. It works as
follows.
We introduce a `CastTable` type. Each `CastTable` tells us how to
downcast `dyn Object` for objects of a single concrete type.
The `Object` type now has a `get_casttable` method that returns
an empty `CastTable` by default.
`CastTable` is, internally, a map from the `TypeId` of the target
dyn Trait reference type to a function
`fn(&dyn Object) -> &dyn Trait`. These functions are stored as
`Box<dyn Any + ...>`. (They are Boxed because they may refer to
generic functions, which you can't get a static reference to,
and they're Any because the functions have different types.)
The `decl_object!` macro now implements `get_casttable` as
appropriate. (The syntax is a bit janky, but that's what we get
for not using derive_adhoc.) For non-generic types, `get_casttable`
uses a Lazy<CastTable>`. to initialize a CastTable exactly once.
For generic types, it use a `Lazy<RwLock<HashMap<..>>` to
build one CastTable per instantiation of the generic type.
This could probably be optimized a bit more, the yaks could be
shaved in a more scintillating hairstyle, and the syntax for
generic `decl_object` could definitely be improved.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
add documentation for configuring snowflake pt
Closes #879 and #875
See merge request tpo/core/arti!1216
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
