| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>>>`
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This new feature is experimental.
|
| |
|
|
|
| |
The implementation for `arti proxy` will soon be relocated to this new
module.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
This addresses a TODO.
|
