| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| | |
hsc: remove onion-address flag in favour of stdin
Closes #1630
See merge request tpo/core/arti!2861
|
| | | |
|
| | |
| |
| |
| |
| | |
* Add `quite` to the common arguments
* Substitute dialoguer in favor of `read_line` in `get_onion_address`
|
| | | |
|
| | |
| |
| |
| |
| | |
* The user will be prompted interactively for the onion-address
to prevent onion-address leaking in shell history
|
| |\ \
| |/
|/|
| |
| | |
arti: hsc-key-get: Print LF after discovery key
See merge request tpo/core/arti!2856
|
| | |
| |
| |
| |
| | |
Did not print a newline after service discovery key. Looked bad.
Prints newline now. Looks better.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2435#note_3080452
|
| | |
|
| |
|
|
| |
Closes #1475
|
| |
|
|
| |
Part of #1475
|
| |
|
|
|
| |
This will be reused for `arti hsc key rotate`, which also outputs
the public key.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
| |
These will be reused by a future `key rotate` subcommand.
|
| |
|
|
|
| |
Otherwise, if/when we add support for other `KeyType`s we risk
forgetting to update the rest of the implementation.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The client will be used by future subcommands too, not just
`prepare_service_discovery_key`.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
| |
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
|
|
|
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
|
