summaryrefslogtreecommitdiff
path: root/crates/arti/src/subcommands
Commit message (Collapse)AuthorAgeFilesLines
* arti-client: add path resolver to `TorClient` and `TorClientConfig`Steven Engler2024-11-181-1/+1
| | | | | | Rather than using `arti_client::config::path_resolver()`, third-party code can get the path resolver using `TorClientConfig`s `AsRef<CfgPathResolver>` impl instead.
* update `CfgPath::path` to use a `CfgPathResolver`Steven Engler2024-11-181-1/+1
| | | | | | | | | | | | | | | | This is a big change across multiple crates since there isn't a good way to break it up. This changes the signature of `CfgPath::path` to: ``` pub fn path(&self, path_resolver: &CfgPathResolver) -> Result<PathBuf, CfgPathError> { ``` Making this change means that our global `CfgPathResolver` needs to be stored in the 'arti-client' library instead of `tor-config-path`, and must be passed through to anything that calls `path` to expand the variables.
* arti: remove 'relay' subcommand and 'arti-relay' depSteven Engler2024-10-151-27/+0
|
* arti: move 'relay' subcommand to 'subcommands::relay' moduleSteven Engler2024-09-251-0/+27
|
* tor-keymgr: Rename the primary keystore for clarity.Gabriela Moldovan2024-09-231-1/+1
| | | | | | | | | | 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.
* arti: Tolerate lowercase "no" in confirmation prompt.Gabriela Moldovan2024-09-191-3/+7
| | | | Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2435#note_3080452
* arti: Fix typo in display_service_discovery_key function name.Gabriela Moldovan2024-09-191-3/+3
|
* arti: Add a subcommand for removing a client discovery key.Gabriela Moldovan2024-09-191-0/+35
| | | | Closes #1475
* arti: Add an hsc subcommand for rotating client keys.Gabriela Moldovan2024-09-191-0/+65
| | | | Part of #1475
* arti: Move public key output logic to a separate function.Gabriela Moldovan2024-09-191-4/+13
| | | | | This will be reused for `arti hsc key rotate`, which also outputs the public key.
* arti: Satisfy clippy.Gabriela Moldovan2024-09-181-4/+4
|
* arti: Add hsc key subcommand, deprecate hsc get-key.Gabriela Moldovan2024-09-181-3/+31
| | | | | | | | | | I am deprecating the old `hsc get-key` subcommand in favor of the new `hsc key get` subcommand. This is because I plan to implement the rest of the key management functionality (key deletion, rotation, etc.) as subcommands of the `hsc key` command. The alternative would be to add a new distinct top-level `hsc rotate-key`, `hsc remove-key`, etc. subcommand alongside the existing `hsc get-key` command (which IMO is less nice than the alternative I'm proposing).
* arti: Move the keygen-related args to a separate struct.Gabriela Moldovan2024-09-181-9/+17
| | | | These will be reused by a future `key rotate` subcommand.
* arti: Make sure we check the KeyType before running the command.Gabriela Moldovan2024-09-181-1/+5
| | | | | Otherwise, if/when we add support for other `KeyType`s we risk forgetting to update the rest of the implementation.
* arti: Move the shared arti hsc args to CommonArgs (fmt).Gabriela Moldovan2024-09-181-2/+4
|
* arti: Move the shared arti hsc args to CommonArgs.Gabriela Moldovan2024-09-181-16/+22
|
* arti: Move TorClient creation to the top-level (fmt).Gabriela Moldovan2024-09-181-4/+1
|
* arti: Move TorClient creation to the top-level.Gabriela Moldovan2024-09-181-8/+7
| | | | | The client will be used by future subcommands too, not just `prepare_service_discovery_key`.
* Merge branch 'svc-no-proxy-port' into 'main'David Goulet2024-09-171-14/+31
|\ | | | | | | | | | | | | arti: Allow running hidden services with SOCKS/DNS proxying disabled. Closes #1569 See merge request tpo/core/arti!2423
| * arti: Don't log that we are in SOCKS mode unless socks_listen is set.Gabriela Moldovan2024-09-171-6/+13
| | | | | | | | If `socks_listen` is disabled, we're not actually running in SOCKS mode.
| * arti: Allow running hidden services with SOCKS/DNS ports disabled.Gabriela Moldovan2024-09-171-8/+18
| | | | | | | | Closes #1569
* | arti: Remove get-key subcommand in favor of onion-name.Gabriela Moldovan2024-09-171-28/+7
| | | | | | | | | | | | | | | | The `hss get-key` subcommand is now folded into `onion-name`, which takes a `--generate` argument which specifies whether to generate the key if missing. Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2419#note_3078068
* | arti: Add CLI for generating an onion service hsid.Gabriela Moldovan2024-09-171-2/+83
| | | | | | | | | | | | | | | | | | | | | | This adds a new `hss get-key` subcommand for retrieving and generating service identity keys. The existing `hss onion-name` is now a convenience alias for `hss get-key --generate=no --key-type=onion-name`. Note: I am calling this new subcommand `get-key` for consistency with its client counterpart (`hsc get-key`). Closes #1621
* | arti: Add an enum for the hss subcommand.Gabriela Moldovan2024-09-171-12/+39
| | | | | | | | | | | | | | This is needed because we'll soon add an `hss get-key` subcommand for getting and/or generating a service identity key alongside `hss onion-name` (`hss onion-name` will become a convenience around `hss get-key --key-type=onion-name`).
* | arti: Refactor hss::onion_name() implementation.Gabriela Moldovan2024-09-171-11/+29
| | | | | | | | | | This splits `onion_name` into multiple functions (which will be repurposed for the future `hss get-key` implementation).
* | arti: Move hss onion-name implementation to a separate function.Gabriela Moldovan2024-09-171-29/+41
|/ | | | | `hss` will soon sprout another subcommand, so I am preemptively refactoring the `hss onion-name` implementation out of `hss::run()`.
* arti: Move proxy subcommand to a separate module.Gabriela Moldovan2024-09-121-7/+37
| | | | | | | | No functional changes, this is just code motion. This helps organize the code in `arti/src/lib.rs` a bit. It now only contains the argument parsing and various other setup, and all the subcommands are contained in separate modules.
* arti: Move arti::run to subcommands::proxy.Gabriela Moldovan2024-09-121-2/+168
| | | | No functional changes, this is just code motion.
* arti: Add a new module for the proxy subcommand.Gabriela Moldovan2024-09-121-0/+17
| | | | | The implementation for `arti proxy` will soon be relocated to this new module.
* Fix typosDimitris Apostolou2024-09-031-1/+1
|
* arti: Implement the hsc subcommand using an inert tor client.Gabriela Moldovan2024-08-281-1/+1
| | | | | | | | | This allows us to reenable the `arti hsc` tests, which were previously disabled due to flakiness (see #1496). The `help` test bit rotted a bit, so I had to tweak its expected output. Closes #1496
* Have `arti hss onion-name` error if it doesn't print the onion nameKunal Mehta2024-08-011-3/+5
| | | | | | | There are two error cases where the onion name isn't printed, but previously returned `Ok(())`. It now returns an error to exit with a non-zero status code.
* tor-hscrypto: Remove unnecessary Display wrapper.Gabriela Moldovan2024-07-081-1/+1
| | | | | | | | | | | I don't think we need a separate wrapper type for displaying `HsClientDescEncKey` keys in the "C Tor format" (`<auth-type>:<key-type>:<base32-encoded-public-key>`). I think this should be the canonical string representation of `HsClientDescEncKey`, so I'm removing the `display_authorized_client` function and corresponding `DisplayAuthorizedHsClientDescEncKey` wrapper type.
* Fix markdown quoting.Ian Jackson2024-07-081-1/+1
| | | | | | | | | | | | Fixes: warning: unclosed HTML tag `FILE` --> crates/arti/src/subcommands/hsc.rs:56:33 | 56 | /// Write the public key to <FILE>. Use - to write to stdout | ^^^^^^ | = note: `#[warn(rustdoc::invalid_html_tags)]` on by default
* arti: Rewrite the hsc prepare-service-discovery-key command (fmt).Gabriela Moldovan2024-06-271-11/+6
|
* arti: Rewrite the hsc prepare-service-discovery-key command.Gabriela Moldovan2024-06-271-10/+30
| | | | | | | The `arti hsc prepare-service-discovery-key` command is now `arti hsc get-key [--key-type=service-discovery]`. Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2212#note_3042903
* arti: Add an arti hsc subcommand.Gabriela Moldovan2024-06-271-0/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* arti: Move arti hss subcommand implementation to separate module.Gabriela Moldovan2024-06-171-0/+51
This addresses a TODO.