| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
This was replaced by the new `CertSpecifier` d-d macro.
|
| |
|
|
|
| |
Fix the conflict in tor-netdoc/semver.md by hand, including the new
entries already landed since v1.9.0.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Out of all the variants in `KeyPathError`, `Unrecognized` is the odd one
out, because unlike the others, which are mainly just lower level
parsing errors, `Unrecognized` is a higher level error constructed in
`KeyMgr::describe()`.
`KeyMgr::describe()` now returns an `Option`, because
* the failure to describe a user provided `KeyPath` may or may not be
an error
* previously, `describe()` would only ever return `Ok` or
`Err(KeyPathError::Unrecognized)`, which essentially a binary
result. Also, `describe()` would never return any of the other
`KeyPathError` kinds, which further suggests `Unrecognized`
doesn't belong there
The `Unrecognized` variant still exists, but is now part of
`KeystoreCorruptionError`, (returned from
`KeyMgr::validate_entry_integrity()`).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* CLI: Add `keys-raw` and subcommand `remove-by-path`
* arti: Add `arti::subcommand::raw` for the CLI `keys-raw`
* tor-keymgr: Add `ArtiNativeKeystoreError::UnexpectedRawEntry`,
`ArtiEphemeralKeystoreError::NotSupported`
* tor-keymgr: Add `tor-keymgr::raw` module
* tor-keymgr: Add `Keystore::remove_unchecked`
* tor-keymgr: Change `Keystore::list` to return `KeystoreEntry`
* tor-keymgr: Add field `KeystoreEntry::raw_id`
* doc: Update keys.md
* doc: Add raw.md
* tor-keymgr: BREAKING: `UnrecognizedEntryError::new` associated
function is now only accessible within the crate `tor-keymgr`
* tor-keymgr: BREAKING: `UnrecognizedEntryId` is renamed to
`UnrecognizedEntry`
* tor-keymgr: BREAKING: `KeyMgr::list()` and `Keystore::list()`
now return `Result<Vec<KeystoreEntryResult<KeystoreEntry>>>`
|
| | |
|
| |
|
|
|
| |
* Change return type `Result<Vec<(KeyPath, KeystoreItemType)>>` if favor
of `Result<Vec<StdResult<(KeyPath, KeystoreItemType), UnrecognizedEntryError>>>`
|
| |
|
|
|
|
|
|
| |
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.30.0
done
```
|
| |
|
|
|
|
| |
Drop redundant/unused param item_type: &KeystoreItemType from
keystore::Keystore::insert. Method now uses param
key: &dyn EncodableItem to obtain a KeystoreItemType
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
These are not actually needed anywhere.
In fact, it's a bad idea to have them in the first place (see the
comment from the dummy `KeyMgr` impl block).
|
| | |
|
| |
|
|
|
| |
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 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`
|
| | |
|
| |
|
|
|
| |
I am adding `is_enabled()` back because I plan to un-deprecate the
`enabled` setting.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* Bump in Cargo.toml
* Deal with `${Xmeta as ...}` incompatible change, by
always specifying an `as`, and changing `as tokens`.
|
| | |
|
| | |
|
| |
|
|
| |
Closes #1202
|
| |
|
|
|
| |
It appears within the public API (it is the error type returned from
`KeySpecifierComponent`), so let's make it public.
|
| |
|
|
|
|
| |
The offending `ArtiPath` should be included in the error.
Part of #1115
|
| |
|
|
|
|
|
|
|
| |
Originally, these functions converted to and from `ArtiPathComponent`.
In !1931, we replaced `ArtiPathComponent` with `Slug` without renaming
the conversion functions. Since we're converting to and from `Slug` now,
I think it makes sense to rename them too.
Part of #1115
|
| |
|
|
| |
Part of #1271
|
| |
|
|
| |
Part of #1271
|
| |
|
|
|
|
|
| |
NB: `KeyMgr::remove_with_type` will need to be renamed to
`KeyMgr::remove_entry`.
Part of #1271
|
| |
|
|
| |
Part of #1271
|
| |
|
|
|
|
|
|
|
|
| |
This type will soon replace `(KeyPath, KeyType)` in
`KeyMgr::list_matching`.
The KeystoreEntry documentation mentions a couple of functions that
don't exist right now (they will be added in a subsequent commit).
Part of #1271
|
| |
|
|
| |
Part of #1115
|
| |
|
|
| |
Part of #1115
|
| |
|
|
|
|
| |
This trait extracts a `KeyPathInfo`, not a `KeyInfo`.
Part of #1115
|
| |
|
|
| |
Part of #1115
|
| | |
|
| |
|
|
|
|
|
| |
This will be returned by `KeyMgr::generate` if the key to be generated
already exists and `overwrite` is `false`.
Part of #1074
|
| |
|
|
|
|
| |
`ArtiPathComponent`s are really just `Slugs`.
Part of #1193, #1092
|
| |
|
|
|
|
| |
This resolves a `TODO HSS` in arti-client.
Part of #1187
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
StaticSecret.
Previously, when retrieving `KS_hsc_desc_enc` keys (or any other x25519
keys) from the keystore, the keymgr would discard the public part of the
key (SSH private keys contain the public part of the key too). Instead
of discarding the public key and returning just the `StaticSecret`, the
keymgr now returns a `StaticKeypair`. This makes the x25519
`EncodableKey`/`ToEncodableKey` implementation consistent with the
ed25519 one (which retrieves key pairs rather than "unescorted"
secrets).
|
| | |
|