| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| | |
cargo: Bump futures-copy
See merge request tpo/core/arti!3580
|
| | |
| |
| |
| |
| | |
The dependencies of futures-copy got bumped in arti!3570, leading to a
change in futures-copy, hence why we bump the patch version.
|
| |\ \
| | |
| | |
| | |
| | | |
cargo: Update equix and hashx bench
See merge request tpo/core/arti!3579
|
| | |/
| |
| |
| | |
This commit runs `cargo update` on the respective crates.
|
| |/ |
|
| |\
| |
| |
| |
| | |
Bump dependencies for 1.9.0
See merge request tpo/core/arti!3570
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This only includes retry-error which had a few functional additions in
December, thereby rasing the minor version as new features were added to
the public API.
Done using the following:
* Find all non arti, non tor crates.
* `ls -1 crates/ | grep -v "^tor-\|^arti"`
* Exclude the ones without changes.
* `maint/changed_crates -v "arti-v$LAST_VERSION" 2>&1 >/dev/null | grep -i "no change"`
* Look into each with changes.
* In this case only retry-error.
* Bump the minor because it had non-trivial changes.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Done using the following:
```bash
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.38.0
done
```
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Fixes bug introduced in 0cc367b9fef37c0f7d7f04d54c4687b27ef251d0.
Without this fix, RPC's get_proxy_info command wouldn't work.
|
| | |
| |
| |
| |
| |
| |
| | |
This should never have been retained when we refactored our channels
for reporting responses into a single channel.
The bug became apparent when quicktest became derived from debug.
|
| |\ \
| |/
|/|
| |
| | |
cargo: Run fixup-features for release
See merge request tpo/core/arti!3569
|
| | |
| |
| |
| |
| |
| |
| | |
Executed command:
```
cargo run -p fixup-features -- --exclude examples/ --exclude maint/ Cargo.toml
```
|
| |/ |
|
| |
|
|
| |
Fixes a clippy warning.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Previously, the `arti_path` was needed to build the various `ArtiPath`
errors, but that's no longer the case.
|
| | |
|
| |
|
|
|
| |
The `ArtiPath` is included in the `KeyPathError::Arti` outer error type,
so there is no need to include it in `ArtiPathError` too.
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
This never returns any other type of error.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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()`).
|
| |
|
|
|
|
|
|
|
| |
If you try to use this macro within `tor-keymgr` (as we do in the
tests), clippy complains about the unreachable catch-all branch for
`KeyPath`s (we can't get rid of the catch-all, because outside of
`tor-keymgr` KeyPath` is non-exhaustive; but we should probably just go
ahead and make `KeyPath` exhaustive at this point, because it's very
unlikely it will ever grow new variants).
|
| |
|
|
|
| |
`KeyMgr::describe()` now works for `CTorPath`s too, so the key path
validation can be the same as for `ArtiPath`s.
|
| |
|
|
|
| |
C Tor keystore entries now use the same output format as the non-C Tor
entries.
|
| | |
|
| |
|
|
| |
This folds `display_arti_entry()` into `display_entry()`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This is no longer needed now that `KeyMgr::describe()` works on
`CTorPath`s.
Removing this special handling has the added bonus that the keymgr CLI
output is now uniform for all keystores (before this change, `keys list`
used a slightly different output format for displaying C Tor entries).
The corresponding tests will be updated in a future commit.
|
| |
|
|
|
|
|
| |
This is similar to `#[serde(with = "...")]`, and feels a bit nicer than
having to specify two separate functions for the conversions (because
with two separate functions, you *can* technically only specify one of
them, which shouldn't be allowed).
|
| |
|
|
|
| |
This enables us to implement `KeyMgr::describe()`, which relies on the
ability to extract the key specifier of the key from its `KeyPath`.
|