mirrors/arti.git/crates/arti/src/subcommands.rs, branch main

arti: hss: Add `arti hss ctor-migrate`

2025-07-31T11:05:12Z

arti: keys: Add arti keys-raw

2025-07-14T14:33:56Z

* 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>>`

arti: Add keys list and keys list-keystores

2025-06-12T11:16:29Z

arti: remove 'relay' subcommand and 'arti-relay' dep

2024-10-15T19:35:42Z

arti: move 'relay' subcommand to 'subcommands::relay' module

2024-09-25T17:46:07Z

arti: Gate the arti hsc subcommand behind a new "hsc" feature.

2024-09-19T14:29:34Z

This new feature is experimental.

arti: Add a new module for the proxy subcommand.

2024-09-12T18:06:18Z

The implementation for `arti proxy` will soon be relocated to this new module.

arti: Gate the hsc subcommand behind the keymgr feature (fmt).

2024-07-10T14:25:30Z

arti: Gate the hsc subcommand behind the keymgr feature.

2024-07-10T14:25:00Z

The `arti hsc` subcommand can't run without keymgr support. Previously, it relied on `tor-keymgr/keymgr` being enabled indirectly by its dependencies, via the `experimental` feature. We need to be able to enable this feature in `arti` without relying on `experimental` (because `arti hsc` will eventually be made non-experimental). Part of #1487

arti: Add an arti hsc subcommand.

2024-06-27T17:13:52Z

This adds an experimental `arti hsc` subcommand for managing client state and keys. Currently, it only supports the `prepare-service-discovery-keys` operation described in #1281 and `doc/dev/notes/client-auth.md`. A note on terminology: I am referring to services that encrypt the second layer of their descriptor as running in "restricted discovery" mode (because they can only be discovered, i.e. have their IPT points found out, by a set of authorized clients). The corresponding client "auth" keys, being the keys that enable the client to find out the list of intro points, pow-params etc. of the service, are referred to as service "discovery keys". Alternative names I considered: * extra descriptor encryption: accurate, but overly technical. IMO, the CLI should be accessible to users who aren't familiar with the nitty-gritty of the protocol * shielded mode: good, but slightly misleading. Calling it "shielded mode" makes it sound like a universally desirable "extra protection" that should almost always be enabled (which is not the case). Seeing `shielded_mode = off` in the config might be worry operators that don't fully understand what "extra descriptor encryption" or "shielded mode" means * restricted mode: slightly inaccurate. It implies this mechanism is a good substitute for conventional service-side authentication, which it isn't (because client authorization isn't instantaneous) Closes #1281